"Unable to locate SQLGetPrivateProfileString function" with Snowflake ODBC on Ubuntu 22 - odbc

I have installed the Snowflake ODBC driver on Ubuntu 20 (Focal) successfully before, and it works fine. After installing the same packages on a new Ubuntu 22 (Jammy) system, the Snowflake ODBC driver refuses to connect, with this error:
$ isql -v snowflake-dev <redacted> <redacted>
[S1000][unixODBC][Snowflake][ODBC] (11560) Unable to locate SQLGetPrivateProfileString function.
[ISQL]ERROR: Could not SQLConnect
The same command works fine on Ubuntu 20.
Here are the relevant bits of my config files (which of course are the same on the two systems):
/etc/odbc.ini:
[snowflake-dev]
Description=SnowflakeDB
Driver=SnowflakeDSIIDriver
Locale=en-US
SERVER=<redacted>.east-us-2.azure.snowflakecomputing.com
PORT=443
SSL=on
ACCOUNT=<redacted>
/etc/odbcinst.ini:
[SnowflakeDSIIDriver]
APILevel=1
ConnectFunctions=YYY
Description=Snowflake DSII
Driver=/usr/lib/snowflake/odbc/lib/libSnowflake.so
DriverODBCVer=03.52
SQLLevel=1
UsageCount=1
and the driver file does exist in that directory:
$ ls -l /usr/lib/snowflake/odbc/lib/libSnowflake.so*
-rwxr-xr-x 1 root root 177405464 Aug 1 15:14 /usr/lib/snowflake/odbc/lib/libSnowflake.so
$ file /usr/lib/snowflake/odbc/lib/libSnowflake.so*
/usr/lib/snowflake/odbc/lib/libSnowflake.so: ELF 64-bit LSB shared object, x86-64, version 1 (GNU/Linux), dynamically linked, BuildID[sha1]=61282db74b8db4d446540d7f53458245a6ef6997, with debug_info, not stripped
Am I missing something essential? Is there something new required on Ubuntu 22 that wasn't before?

I found that the file /usr/lib/x86_64-linux-gnu/libodbcinst.so.1 did not exist on my system. I changed the file <snowflake path>/lib/simba.snowflake.ini to point to /usr/lib/x86_64-linux-gnu/libodbcinst.so.2 instead, and now it works.

Related

Problems Connecting to Database within Docker Image via RStudio using DBI

I'm attempting to connect to a database within a local Docker image I've spun up using DBI and am running into some pretty cryptic errors... I've successfully started the Docker container (below shows result of docker ps -a):
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
131ab042012c mcr.microsoft.com/mssql/server:2017-latest "/opt/mssql/bin/nonr…" 27 minutes ago Up 27 minutes 127.0.0.1:1433->1433/tcp admiring_northcutt
I then try to connect via:
pool<- pool::dbPool(odbc::odbc(),
Driver = "ODBC Driver 17 for SQL Server",
Server = "localhost",
Database = "master",
UID = "sa",
PWD = "***********",
Port = 1433)
and receive the error:
Error: nanodbc/nanodbc.cpp:1021: 00000: [Microsoft][ODBC Driver 17 for SQL Server]Client unable to establish connection [Microsoft][ODBC Driver 17 for SQL Server]Invalid connection string attribute
Checking my odbc driver using odbc::odbcListDrivers() returns the output below, so the drivers seem to be present.
name attribute value
1 ODBC Driver 17 for SQL Server Description Microsoft ODBC Driver 17 for SQL Server
2 ODBC Driver 17 for SQL Server Driver /usr/local/lib/libmsodbcsql.17.dylib
3 ODBC Driver 17 for SQL Server UsageCount 2
In addition, executing the container and attempting to connect to the database via the commands:
docker exec -it <container-name> /bin/bash
/opt/mssql-tools/bin/sqlcmd -S 127.0.0.1 -U sa -P '<password>'
EDIT: The above method now works and I'm able to actively query within the database. I know that the error can't be due to invalid login credentials because I'm using the same exact ones as I ran above in the container.
This same process works for a coworker, so I'm wondering if it's a local issue with my set up. We already compared our .ini files as suggested in this link and they're identical, I've clean re-installed Docker, and I've even ran the coworker's identical container with no luck. Any ideas what could be happening here?
Computer specs:
MacBook Pro (16-inch 2019)
OS: macOS Monterey (version 12.2.1)
Processor: 2.3 GHz 8-Core Intel Core i9
Memory: 16GB 2667MHz DDR4
Startup Disk: Macintosh HD
Graphics: AMD Radeon Pro 5500M 4 GB
Rstudio Version: 2021.09.0 Build 351
OpenSSL Version: 1.1

brew install mariadb fails as system can not chown for auth_pam_tool

brew
brew install not work. this is the log.
% brew install mariadb
==> Downloading https://homebrew.bintray.com/bottles/mariadb-10.4.13.mojave.bottle.tar.gz
Already downloaded: /Users/shingo/Library/Caches/Homebrew/downloads/d56104142081a8230646ac3f245adf2414e515cd5f2aeeb0637614e9966e882c--mariadb-10.4.13.mojave.bottle.tar.gz
==> Pouring mariadb-10.4.13.mojave.bottle.tar.gz
==> /usr/local/Cellar/mariadb/10.4.13/bin/mysql_install_db --verbose --user=shingo --basedir=/usr/local/Cellar/mariadb/10.4.13 --datadir=/usr/local/var/mysql --tmpdir=/tmp
Last 15 lines from /Users/shingo/Library/Logs/Homebrew/mariadb/post_install.01.mysql_install_db:
shell> /usr/local/Cellar/mariadb/10.4.13/bin/mysql -u root mysql
mysql> show tables;
Try 'mysqld --help' if you have problems with paths. Using
--general-log gives you a log in /usr/local/var/mysql that may be helpful.
The latest information about mysql_install_db is available at
https://mariadb.com/kb/en/installing-system-tables-mysql_install_db
You can find the latest source at https://downloads.mariadb.org and
the maria-discuss email list at https://launchpad.net/~maria-discuss
Please check all of the above before submitting a bug report
at http://mariadb.org/jira
Warning: The post-install step did not complete successfully
You can try again using `brew postinstall mariadb`
==> Caveats
A "/etc/my.cnf" from another install may interfere with a Homebrew-built
server starting up correctly.
MySQL is configured to only allow connections from localhost by default
To start mariadb:
brew services start mariadb
Or, if you don't want/need a background service you can just run:
mysql.server start
==> Summary
🍺 /usr/local/Cellar/mariadb/10.4.13: 744 files, 169.9MB
I have tried to execute mysql_install_db
I have tried to execute mysql_install_db without brew. this is the log.
The brew displays only the last 15 lines, so I can't help it.
% /usr/local/Cellar/mariadb/10.4.13/bin/mysql_install_db --verbose --user=shingo --basedir=/usr/local/Cellar/mariadb/10.4.13 --datadir=/usr/local/var/mysql --tmpdir=/tmp
chown: /usr/local/Cellar/mariadb/10.4.13/lib/plugin/auth_pam_tool_dir/auth_pam_tool: Operation not permitted
Couldn't set an owner to '/usr/local/Cellar/mariadb/10.4.13/lib/plugin/auth_pam_tool_dir/auth_pam_tool'.
It must be root, the PAM authentication plugin doesn't work otherwise..
Installing MariaDB/MySQL system tables in '/usr/local/var/mysql' ...
2020-05-29 22:13:03 0 [Note] /usr/local/Cellar/mariadb/10.4.13/bin/mysqld (mysqld 10.4.13-MariaDB) starting as process 45440 ...
2020-05-29 22:13:03 0 [ERROR] /usr/local/Cellar/mariadb/10.4.13/bin/mysqld: option '--innodb-large-prefix' requires an argument
2020-05-29 22:13:03 0 [ERROR] Parsing options for plugin 'InnoDB' failed.
2020-05-29 22:13:03 0 [ERROR] /usr/local/Cellar/mariadb/10.4.13/bin/mysqld: unknown variable 'mysqlx-bind-address=127.0.0.1'
2020-05-29 22:13:03 0 [ERROR] Aborting
Installation of system tables failed! Examine the logs in
/usr/local/var/mysql for more information.
The problem could be conflicting information in an external
my.cnf files. You can ignore these by doing:
shell> /usr/local/Cellar/mariadb/10.4.13/bin/mysql_install_db --defaults-file=~/.my.cnf
You can also try to start the mysqld daemon with:
shell> /usr/local/Cellar/mariadb/10.4.13/bin/mysqld --skip-grant-tables --general-log &
and use the command line tool /usr/local/Cellar/mariadb/10.4.13/bin/mysql
to connect to the mysql database and look at the grant tables:
shell> /usr/local/Cellar/mariadb/10.4.13/bin/mysql -u root mysql
mysql> show tables;
Try 'mysqld --help' if you have problems with paths. Using
--general-log gives you a log in /usr/local/var/mysql that may be helpful.
The latest information about mysql_install_db is available at
https://mariadb.com/kb/en/installing-system-tables-mysql_install_db
You can find the latest source at https://downloads.mariadb.org and
the maria-discuss email list at https://launchpad.net/~maria-discuss
Please check all of the above before submitting a bug report
at http://mariadb.org/jira
I noticed that the system can not chown for auth_pam_tool because Operation not permitted.
auth_pam_tool permission
this is my permission the directory.
% ls -l /usr/local/Cellar/mariadb/10.4.13/lib/plugin/auth_pam_tool_dir/auth_pam_tool
-r-xr-xr-x 1 shingo staff 13608 5 10 04:28 /usr/local/Cellar/mariadb/10.4.13/lib/plugin/auth_pam_tool_dir/auth_pam_tool
How to fix Operation not permitted?
Or is there any other reason why it cannot be installed?
Self resolved.
Anyway I gave it try start
Even though the installation was not successful, anyway I gave it try % mysql.server start.
A error log file was created.
A error log file was created by starting mysql server.
the error log shows:
2020-05-30 8:47:10 0 [Warning] InnoDB: innodb_open_files 300 should not be greater than the open_files_limit 256
2020-05-30 8:47:10 0 [ERROR] /usr/local/Cellar/mariadb/10.4.13/bin/mysqld: unknown variable 'mysqlx-bind-address=127.0.0.1'
2020-05-30 8:47:10 0 [ERROR] Aborting
An unknown value in the mysqlx-bind-address seems to be causing the error.
How to fix unknown variable
I found
the same error question. This question discussed a my.conf file.
~/.my.conf did not exist on my mac
/etc/my.conf did not exist on my mac
this question teach me the my.conf location.
Finally I found my.conf in /usr/local/etc/my.cnf.Certainly the settings for mysqlx-bind-address were written in my.conf.
So rm /usr/local/etc/my.cnf, then brew reinstall SUCCESS!.
The permission was irrelevant at all.
this work for me:
rm /opt/homebrew/etc/my.cnf

tpm2 tools fail because /dev/tpm0 missing although the tpm server is running

I'm following this guide to use tpm2.0 simulator.
This is my situation:
Firstly, I ran:
$ ./tpm_server
TPM command server listening on port 2321
Platform server listening on port 2322
Then, I opened a new terminal and ran:
sudo tpm2-abrmd --allow-root --tcti=mssim
Nothing happened but in the previous terminal, there were:
$ ./tpm_server
TPM command server listening on port 2321
Platform server listening on port 2322
Command IPv6 client accepted
Platform IPv6 client accepted
I opened a new terminal more and ran command as the guide showed and there was some errors:
$ tpm2_pcrlist
ERROR:tcti:src/tss2-tcti/tcti-device.c:319:Tss2_Tcti_Device_Init() Failed to open device file /dev/tpm0: No such file or directory
ERROR: tcti init allocation routine failed for library: "device" options: "(null)"
ERROR: Could not load tcti, got: "device"
How should I do to fix it?
I got some error like you while running tpm2 command as you did.
You could try to run with "sudo". it works for me.
Same Issue!
Any answers. It was working but now it is not.

initctl: Unknown instance: error after Rstudio conf change

I have a new version of R installed on an aws-machine (which always come with an old version for some reason and it's near impossible to just have yum or apt-get to work). I want rstudio to point to this new version which I've built from source without throwing the old version away. I therefore go to /etc/rstudio/rserver.conf (documentation) and change the contents to:
# Server Configuration File
rsession-which-r=/root/R-3.2.1/bin/R
I can confirm that at this location a new version of R is installed but then I get an error after rstudio-server restarts.
root#ip-172-31-40-49 rstudio]$ rstudio-server restart
initctl: Unknown instance:
What am I to do?
Below worked for me:
1) check the process that used 8787
sudo fuser 8787/tcp
2) with the -k option to kill all process.
sudo fuser -k 8787/tcp
3) Start RStudio Server
sudo rstudio-server start
The solution above is provided here by Leon Zhang.
The first thing to do is to check your configuration with:
rstudio-server verify-installation
a number of times when updating R or RStudio I have run into the same error as you have and get the following error message.
-bash-4.1$ sudo rstudio-server verify-installation
29 Sep 2015 18:24:11 [rserver] ERROR system error 98 (Address already in use); OCCURRED AT: rstudio::core::Error rstudio::core::http::initTcpIpAcceptor(rstudio::core::http::SocketAcceptorService<boost::asio::ip::tcp>&, const std::string&, const std::string&) /root/rstudio/src/cpp/core/include/core/http/TcpIpSocketUtils.hpp:103; LOGGED FROM: int main(int, char* const*) /root/rstudio/src/cpp/server/ServerMain.cpp:436
rstudio-server start/running, process 48632
Although I have never been able to figure out the cause, I can suggest the following workaround:
1. change the port /etc/rstudio/rserver.conf for example from 8787 to 8788
2. open the new ports in your firewall settings. (allow access to the new port in /etc/sysconfig/iptables)
3. update your firewall: sudo /sbin/service iptables restart
4. restart Rstudio server: sudo rstudio-server restart
This has worked for me each of the ~4-5 times this has happened. Although I am not 100% sure this can help with your use case, it may. As an alternative, if you can use containers in your AWS setup, you may be interested in a great off-the shelf docker image with the latest R/Rstudio.
It happened for me on my Cento-7.x machine while I upgraded from old RStudio server to the new version. Rebooting the machine seems to have fixed the problem.

Dealing with GConf Error: No D-BUS daemon running error in Ubuntu 12.0.4 LTS

I would like to run some R scripts in terminal on an Ubuntu 12.04 LTS (no GUI) that is hosted as a virtual server inside a Windows 2008 Server. I log into the server through ssh and whenever I run R scripts or gnome-open command in the terminal I get the following error
(gnome-open:10138): GConf-WARNING **: Client failed to connect to the D-BUS daemon:
Unable to autolaunch a dbus-daemon without a $DISPLAY for X11
GConf Error: No D-BUS daemon running
I have tried everything including:
1.Installing Xvfb and configuring it.
2.Exporting display variable set in /etc/environment & ~/.bashrc
3.Trying to export dbus-launch to no avail
4.Getting & loading the session dbus id from file
X11 forwarding has been enabled
I need help dealing with this issue. Any ideas?
Try
apt-get install dbus-x11
this helps me on a ubuntu 12.04 with X installed and the same error message.

Resources