CSE srvcoord error "undefined symbol: tircrypto_decrypt_string"
search cancel

CSE srvcoord error "undefined symbol: tircrypto_decrypt_string"

book

Article ID: 381972

calendar_today

Updated On:

Products

Gen

Issue/Introduction

New Gen 8.6 Linux server with both CSE (Client/Server Encyclopedia) and IT (Implementation Toolset) installed.
After installing IT PTF RTX86200 when CSE was restarted there was an error MDEXI0057E at Encyclopedia Client Logon time:



This message is seen in the iefmd.log file:
***
  MESSAGE DISPATCHER...................................Ready.
/opt/Gen/CSE/cse/bin/srvcoord: symbol lookup error: /opt/Gen/CSE/cse/bin/srvcoord: undefined symbol: tircrypto_decrypt_string
***

Environment

Gen CSE/IT under Linux or Unix (AIX/HP)

Cause

The CSE binary srvcood has a dependency on library libcrypto.so which is located in the same directory $IEFCSGEN (/opt/Gen/CSE/cse/bin). If $IEFCSGEN is at the front of environment variable LD_LIBRARY_PATH the ldd command will show:
***
$ ldd srvcoord
        linux-vdso.so.1 (0x00007ffed75e1000)
        libcrypto.so => /opt/Gen/CSE/cse/bin/libcrypto.so (0x00007f7e9f22c000)
        libcdb.so => /opt/Gen/CSE/cse/bin/libcdb.so (0x00007f7e9eec5000)
...
***

Running command nm on that library confirms it contains the symbol tircrypto_decrypt_string i.e.
***
$ nm libcrypto.so | grep tircrypto_decrypt_string
000000000000beaa T tircrypto_decrypt_string
$
***

The IT GA install does not have a library libcrypto.so in its $IEFH/lib directory but the RTX86200 installs one.
However that library does not have the symbol tircrypto_decrypt_string i.e.
***
$ cd $IEFH/lib
$ nm libcrypto.so | grep tircrypto_decrypt_string
$
***

Environment variable LD_LIBRARY_PATH controls how shared object libraries (.so) are found 
The CSE script file cse.sh file adds the cse bin directory (/opt/Gen/CSE/cse/bin) to the front of any existing LD_LIBRARY_PATH and also sets IEFCSGEN to that same directory.
The IT requires LD_LIBRARY_PATH environment variable to contain $IEFH/lib

If add $IEFH/lib to the front of the LD_LIBRARY_PATH then srvcoord will pick up the incorrect IT version of libcrypto.so
***
$ echo $LD_LIBRARY_PATH
/opt/CA/CAGen/runtime/lib:/opt/Gen/CSE/cse/bin:/opt/oracle/product/19c/dbhome_1/lib:/opt/CA/SharedComponents/lib
$ cd $IEFCSGEN
$ ldd srvcoord
        linux-vdso.so.1 (0x00007ffe69dd1000)
        libcrypto.so => /opt/CA/CAGen/runtime/lib/libcrypto.so (0x00007f1b61414000)
...
***

If then start the CSE the srvcoord will start OK but if try to login with a user that has a non-blank password that needs to be decrypted the login fails and the reported message is seen in the iefmd.log file:
***
  MESSAGE DISPATCHER...................................Ready.
/opt/Gen/CSE/cse/bin/srvcoord: symbol lookup error: /opt/Gen/CSE/cse/bin/srvcoord: undefined symbol: tircrypto_decrypt_string
***

Resolution

The libcrypto.so in $IEFCSGEN is Gen's cryptography library used for password encryption.
The libcrypto.so (originally a symbolic link to libcrypto.so.1.0.0) in $IEFH/lib is OpenSSL's library.
So the files are completely separate, and therefore LD_LIBRARY_PATH needs to be handled one way for the CSE and another way for the IT.

As starting the CSE is an infrequent process the advice would be as follows when using the same Linux account for CSE and IT installations

  1. The user can have a script to start the CSE which ensures that $IEFCSGEN is at the front of LD_LIBRARY_PATH.

  2. The same user could have $IEFH/lib at the front of LD_LIBRARY_PATH in their default Linux profile for using with the IT which is a more frequent usage task, compared to starting the CSE.

NOTES:
Later PTF RTX86300 actually removes libcrypto.so from $IEFH/lib but even later PTFs (RTX86304, RTX86310) install new versions of libcrypto.so (symbolic link to libcrypto.so.3).
So ongoing it is best to follow the above practice when using the same Linux account for CSE and IT installations.


For an example CSE startup script please see this article: Gen 8.6 UNIX/Linux CSE logs & work files in single directory

Additional Information

A similar problem can occur on the other UNIX CSE/IT platforms AIX and HP-UX but in those cases the CSE will fail to start when shared libraries are first loaded and not during subsequent use like on Linux.


AIX

The corresponding environment variable is LIBPATH.
The error is completely different because the CSE on AIX is 32 bit, while the IT is 64 bit.
When prepend LIBPATH with $IEFH/lib an error will occur when the srvcoord starts and attempts to load $IEFH/lib/libcrypto.a. The iefmd log file contains the following:

% cat $IEFCSGEN/../cfg/md26.err
MESSAGE DISPATCHER for CA Gen 8.6 Starting at 2024-11-14 14:16:01
/MDERR = md26.err

Log files: /opt/CA/cse86/cse/logs/iefmd.01 thru /opt/CA/cse86/cse/logs/iefmd.01
Could not load program /opt/CA/cse86/cse/bin/srvcoord:
        Dependent module /home/genuser/it/gen86/runtime/lib/libcrypto.a(libcrypto.so) could not be loaded.
        Member libcrypto.so is not found in archive

Since the 32 bit version of libcrypto.so (within libcrypto.a) cannot be loaded, no other servers also start.



HP-UX

The corresponding environment variable is SHLIB_PATH.
When prepend SHLIB_PATH with $IEFH/lib an error will occur when the srvcoord starts and attempts to load $IEFH/lib/libcrypto.so.  The iefmd log file contains the following:

%cat $IEFCSGEN/../cfg/md05.err
MESSAGE DISPATCHER for CA Gen 8.6 Starting at 2024-11-14 14:57:37
/MDERR = md05.err

Log files: /opt/CA/cse86/cse/logs/iefmd.01 thru /opt/CA/cse86/cse/logs/iefmd.02
/usr/lib/hpux64/dld.so: Unsatisfied code symbol 'tircrypto_encrypt_string' in load module '/opt/CA/cse86/cse/bin/srvcoord'.
/usr/lib/hpux64/dld.so: Unsatisfied code symbol 'tircrypto_decrypt_string' in load module '/opt/CA/cse86/cse/bin/srvcoord'.
/usr/lib/hpux64/dld.so: Unsatisfied code symbol 'tircrypto_error_string' in load module '/opt/CA/cse86/cse/bin/srvcoord'.

Like AIX, no servers start.