IRIS ODBC configuration failure

Question

Question

Alan Macdonald · Sep 21, 2023

#.NET #Debugging #Interoperability #ODBC #Red Hat Enterprise Linux (RHEL) #System Administration #InterSystems IRIS

I'm at a loss with configuring the IRIS ODBC driver (v02.10) on my Amazon Linux machine, connecting to a REMOTE IRIS backend. It should be simplified by not requiring a DSN (the app uses a DSN-less connection and generates the connection string). I have

Downloaded and unpacked iris-driver-distribution/ODBC/lnxrh7/ODBC-2022.1.0.209.0-lnxrh7x64.tar.gz at main · intersystems-community/iris-driver-distribution · GitHub
Followed the instructions at Defining an ODBC Data Source on UNIX® | Using the InterSystems ODBC Driver | InterSystems IRIS Data Platform 2023.2 including
- unpacking to /opt/iris-odbc/
- Executing the ODBCInstall script
- Copying the content of the bundled ./dev/odbc/redist/unixodbc/odbcinst.ini_unixODBCtemplate into my /etc/odbcinst.ini file.

Things got interesting here. I'd unpacked the driver bundle to /opt/iris-odbc/ so had to update the unixODBC /etc/odbcinst.ini IRIS section to
Driver=/opt/iris-odbc/bin/libirisodbcu35.so

But the libirisodbcu35.so file doesn't exist in the lnxrh7x64 bundle I'd downloaded. I've updated it again to point at:
Driver=/opt/iris-odbc/bin/libirisodbcur6435.so

That seems OK:

$ ldd /opt/iris-odbc/bin/libirisodbcur6435.so
        linux-vdso.so.1 (0x00007ffd8f1e6000)
        libdl.so.2 => /lib64/libdl.so.2 (0x00007fddc16f1000)
        libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007fddc136f000)
        libm.so.6 => /lib64/libm.so.6 (0x00007fddc102f000)
        libc.so.6 => /lib64/libc.so.6 (0x00007fddc0c82000)
        libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fddc0a6c000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fddc084e000)
        /lib64/ld-linux-x86-64.so.2 (0x00007fddc18f5000)

When I run the app that spawns the connection, I get a "communication link failure message. The ODBC Trace output contains the following:

[ODBC][25452][1695200601.140120][SQLDriverConnectW.c][290]
                Entry:
                        Connection = 0x555cf7153480
                        Window Hdl = (nil)
                        Str In = [DRIVER={InterSystems IRIS ODBC};SERVER=127.0.0.1;DATABASE=[REDACTED];UID=[REDACTED];PWD=[REDACTED];][length = 92 (SQL_NTS)]
                        Str Out = (nil)
                        Str Out Max = 0
                        Str Out Ptr = 0x7ffd8898d550
                        Completion = 0
                UNICODE Using encoding ASCII 'ISO8859-1' and UNICODE 'UCS-2LE'

[ODBC][25452][1695200601.143386][SQLDriverConnectW.c][845]
                Exit:[SQL_ERROR]
[ODBC][25452][1695200601.146154][SQLGetDiagRecW.c][508]
                Entry:
                        Connection = 0x555cf7153480
                        Rec Number = 1
                        SQLState = 0x7f67402e33b8
                        Native = 0x7ffd8898d470
                        Message Text = 0x7f67402e33e0
                        Buffer Length = 1024
                        Text Len Ptr = 0x7ffd8898d468
[ODBC][25452][1695200601.146215][SQLGetDiagRecW.c][550]
                Exit:[SQL_SUCCESS]
                        SQLState = 08S01
                        Native = 0x7ffd8898d470 -> 461
                        Message Text = [[unixODBC][Iris ODBC][State : 08S01][Native Code 461]
[libirisodbcur6435.so]
Communication link failure]

I re-ran with $IRISODBCTRACE=1 and get the following at the following in libirisodbcur6435.log

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
        Started At: Thu Sep 21 12:19:13 2023

        Driver Name:    libirisodbcur6435.so
        Unicode Client Version: 2022.1.0.209.0
        Compiled at:    May 31 2022 12:32:25
        ODBC Version:   03.51
        Locale Setting: <B0><<E7>_<EC>U
        ODBC Config file:       /etc/odbc.ini
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Warning: IRISConnect Failed to load, Error Code: 2; Reason=irisconnect.so: cannot open shared object file: No such file or directory
--> SQLAllocHandle: (12:19:13:204) htype = 1, inhandle = 00000000
    --> SQLAllocEnv: (12:19:13:204)
    <-- SQLAllocEnv: (12:19:13:204) henv = 0x55ec5fe911f0 returning 0
<-- SQLAllocHandle: (12:19:13:204) Returning 0, outhandle = 0x55ec5fe911f0

--> SQLSetEnvAttr: (12:19:13:204) henv = 0x55ec5fe911f0, Attribute=200, Value=3, StringLength=0
<-- SQLSetEnvAttr: (12:19:13:204) Returning 0

--> SQLGetEnvAttr: (12:19:13:204) henv = 0x55ec5fe911f0, Attribute=200, ValuePtr=0x7fff8a0bb4a4, BufferLength=0, StringLengthPointer=00000000
<-- SQLGetEnvAttr: (12:19:13:204) Returning 0

--> SQLAllocHandle: (12:19:13:204) htype = 2, inhandle = 0x55ec5fe911f0
    --> SQLAllocConnect: (12:19:13:204) henv = 0x55ec5fe911f0
    <-- SQLAllocConnect: (12:19:13:204) hdbc = 0x55ec5fea1280 returning 0
<-- SQLAllocHandle: (12:19:13:204) Returning 0, outhandle = 0x55ec5fea1280

--> SQLSetConnectAttr: (12:19:13:204) hdbc = 0x55ec5fea1280, Attribute=103, Value=15, StringLength=4
    --> SQLSetConnectOption: (12:19:13:204) hdbc = 0x55ec5fea1280 fOption = 103 vParam = 15
    <-- SQLSetConnectOption: (12:19:13:204) Returning 0
<-- SQLSetConnectAttr: (12:19:13:204) Returning 0

--> SQLSetConnectAttr: (12:19:13:204) hdbc = 0x55ec5fea1280, Attribute=103, Value=15, StringLength=0
    --> SQLSetConnectOption: (12:19:13:204) hdbc = 0x55ec5fea1280 fOption = 103 vParam = 15
    <-- SQLSetConnectOption: (12:19:13:204) Returning 0
<-- SQLSetConnectAttr: (12:19:13:204) Returning 0

--> SQLDriverConnect: (12:19:13:204) hdbc = 0x55ec5fea1280  fDriverCompletion = 0
    Connection String: D
    ERROR: Sockets::Connect: (12:19:13:204) select()/getsockopt(SO_ERROR) failed: Operation now in progress 115
    ERROR: Connect: (12:19:13:204) Connect returned: 12111
<-- SQLDriverConnect: (12:19:13:204) Returning -1
szConnStrOut: (null)

--> SQLError: (12:19:13:204) henv = 00000000 hdbc = 0x55ec5fea1280  hstmt = 00000000  swMessageMax=513
*** error message =

--> SQLError: (12:19:13:204) henv = 00000000 hdbc = 0x55ec5fea1280  hstmt = 00000000  swMessageMax=513
*** error message =
[Iris ODBC][State : 08S01][Native Code 461]
[libirisodbcur6435.so]
Communic
ation link failure
***
<-- SQLError: (12:19:13:204) state = 08S01 native = 461

--> SQLError: (12:19:13:204) henv = 00000000 hdbc = 0x55ec5fea1280  hstmt = 00000000  swMessageMax=513
<-- SQLError: (12:19:13:204) Returning 100

--> SQLFreeHandle: (12:19:13:204) handle = 0x55ec5fea1280, handle type=2
    --> SQLFreeConnect: (12:19:13:204) hdbc = 0x55ec5fea1280
    <-- SQLFreeConnect: (12:19:13:204) Returning 0
<-- SQLFreeHandle: (12:19:13:204) Returning 0

--> SQLFreeHandle: (12:19:13:204) handle = 0x55ec5fe911f0, handle type=1
    --> SQLFreeEnv: (12:19:13:204) henv = 0x55ec5fe911f0
    <-- SQLFreeEnv: (12:19:13:204) Returning 0
<-- SQLFreeHandle: (12:19:13:204) Returning 0

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
        Started At: Thu Sep 21 12:19:13 2023

        Ended At  : Thu Sep 21 12:19:27 2023
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

irisconnect.so appears fine so far as I can see, but perhaps there are issues with knowing where to find it...?

$ ldd /opt/iris-odbc/bin/irisconnect.so
        linux-vdso.so.1 (0x00007fff042fd000)
        libssl.so.10 => /lib64/libssl.so.10 (0x00007f74371ec000)
        libcrypto.so.10 => /lib64/libcrypto.so.10 (0x00007f7436d95000)
        libdl.so.2 => /lib64/libdl.so.2 (0x00007f7436b91000)
        librt.so.1 => /lib64/librt.so.1 (0x00007f7436989000)
        libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007f7436607000)
        libm.so.6 => /lib64/libm.so.6 (0x00007f74362c7000)
        libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f74360b1000)
        libc.so.6 => /lib64/libc.so.6 (0x00007f7435d04000)
        libgssapi_krb5.so.2 => /lib64/libgssapi_krb5.so.2 (0x00007f7435ab8000)
        libkrb5.so.3 => /lib64/libkrb5.so.3 (0x00007f74357d4000)
        libcom_err.so.2 => /lib64/libcom_err.so.2 (0x00007f74355d0000)
        libk5crypto.so.3 => /lib64/libk5crypto.so.3 (0x00007f743539f000)
        libz.so.1 => /lib64/libz.so.1 (0x00007f743518a000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f743745b000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f7434f6c000)
        libkrb5support.so.0 => /lib64/libkrb5support.so.0 (0x00007f7434d5d000)
        libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x00007f7434b59000)
        libresolv.so.2 => /lib64/libresolv.so.2 (0x00007f7434943000)
        libselinux.so.1 => /lib64/libselinux.so.1 (0x00007f743471c000)
        libpcre.so.1 => /lib64/libpcre.so.1 (0x00007f74344b8000)

In my scenario, there is no $LD_LIBRARY_PATH environment set. If I make any attempt to set it, it seems to break everything to the point that I get no ODBC Trace output at all. Likewise if I try to add a module with the IRIS driver path to /etc/ld.so.conf.d/ and run ldconfig.

I'm stumped.

For completeness, we are attempting to a connect to a REMOTE database over an SSH tunnel forward localhost:1972 to the remote IRIS host:1972. We are not running IRIS locally, but have proven that the SSH connection and it's port forwarding rule are functioning. We also have a Cache ODBC driver that connects to other remote Cache hosts using the same code paths, but calling the different unixODBC driver name, and those are all working successfully. It is just the IRIS driver path that is failing.

Product version: IRIS 2022.1

Discussion (2)2

Log in or sign up to continue

score 0 · Answer 1 · 2023-09-21T09:28:33-04:00

Luis Angel Pére... · Sep 21, 2023

Maybe it's a problem of privileges of the IRIS user.

0 0

score 0 · Answer 2 · 2023-09-22T05:15:10-04:00

Thanks for the reply! I don't think it's permissions...

The app is running under a normal user, but created specifically for creating the environment for the app (so a non-system, unprivileged, userland user). Let's call it "[appuser]".

The drivers have been installed by the root user, are owned by root:root but are all 774, so executable by anyone.

sh-4.2$ ls -lAFhZ /opt/cache-odbc/bin/
-rwxrwxr-x root root ?                                cconnect.so*
-rwxrwxr-x root root ?                                cgateiw.so*
-rwxrwxr-x root root ?                                cgate.so*
-rwxrwxr-x root root ?                                cgateur64.so*
-rwxrwxr-x root root ?                                cgateu.so*
-rwxrwxr-x root root ?                                libcachedb.so*
-rwxrwxr-x root root ?                                libcacheodbc35.so*
-rwxrwxr-x root root ?                                libcacheodbciw35.so*
-rwxrwxr-x root root ?                                libcacheodbciw.so*
-rwxrwxr-x root root ?                                libcacheodbc.so*
-rwxrwxr-x root root ?                                libcacheodbcu35.so*
-rwxrwxr-x root root ?                                libcacheodbcur6435.so*
-rwxrwxr-x root root ?                                libcacheodbcur64.so*
-rwxrwxr-x root root ?                                libcacheodbcu.so*
-rwxrwxr-x root root ?                                libcacheodbcuw35.so*
-rwxrwxr-x root root ?                                libcacheodbcuw.so*
-r-xr-xr-x root root ?                                libiodbc.so*
-rwxrwxr-x root root ?                                libodbc.so*

There are no SELinux labels (all "?") , but on this Amazon Linux image, SELinux appears to be disabled (a bit terrifying, but means we can discount it as an issue!)

sh-4.2$ getsebool
getsebool:  SELinux is disabled

If I become the app user (with sudo su - [appuser]) and check the library for dependencies, I get:

[appuser]@ip-172-16-121-87 ~]$ ldd /opt/iris-odbc/bin/irisconnect.so
        linux-vdso.so.1 (0x00007ffc65ceb000)
        libssl.so.10 => /lib64/libssl.so.10 (0x00007f860e377000)
        libcrypto.so.10 => /lib64/libcrypto.so.10 (0x00007f860df20000)
        libdl.so.2 => /lib64/libdl.so.2 (0x00007f860dd1c000)
        librt.so.1 => /lib64/librt.so.1 (0x00007f860db14000)
        libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007f860d792000)
        libm.so.6 => /lib64/libm.so.6 (0x00007f860d452000)
        libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f860d23c000)
        libc.so.6 => /lib64/libc.so.6 (0x00007f860ce8f000)
        libgssapi_krb5.so.2 => /lib64/libgssapi_krb5.so.2 (0x00007f860cc43000)
        libkrb5.so.3 => /lib64/libkrb5.so.3 (0x00007f860c95f000)
        libcom_err.so.2 => /lib64/libcom_err.so.2 (0x00007f860c75b000)
        libk5crypto.so.3 => /lib64/libk5crypto.so.3 (0x00007f860c52a000)
        libz.so.1 => /lib64/libz.so.1 (0x00007f860c315000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f860e5e6000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f860c0f7000)
        libkrb5support.so.0 => /lib64/libkrb5support.so.0 (0x00007f860bee8000)
        libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x00007f860bce4000)
        libresolv.so.2 => /lib64/libresolv.so.2 (0x00007f860bace000)
        libselinux.so.1 => /lib64/libselinux.so.1 (0x00007f860b8a7000)
        libpcre.so.1 => /lib64/libpcre.so.1 (0x00007f860b643000)

Perhaps strangely, if I ask ldd to check dependencies for the Driver we're actually pointing at from the unixODBC driver manager, it doesn't mention irisconnect.so, but certainly doesn't throw any errors or missing dependencies.

[appuser]@ip-172-16-121-87 ~]$ ldd /opt/iris-odbc/bin/libirisodbcur6435.so
        linux-vdso.so.1 (0x00007ffc455fa000)
        libdl.so.2 => /lib64/libdl.so.2 (0x00007f38debe7000)
        libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007f38de865000)
        libm.so.6 => /lib64/libm.so.6 (0x00007f38de525000)
        libc.so.6 => /lib64/libc.so.6 (0x00007f38de178000)
        libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f38ddf62000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f38ddd44000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f38dedeb000)

So the app user appears to be able read and interrogate the various libraries.

I remain suspicious that, given the lack of an obvious dependency, and given the lack of a path in the trace output, perhaps we simply don't know where to find irisconnect.so, but as mentioned in the earlier post, any attempt to set $LD_LIBRARY_PATH or add a module to ld.so.conf.d seems to make the situation worse, not better.