Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Application I use requires OpenSSL 0.9.8, which was already installed (0.9.8e to be specific) on my CentOS alongside 1.0.1e which unfortunately is used by default. I tried to change libssl.so.10 symbolic link to point to the older version like so:

[mckulpa@nuance-vm ~]$ ldd /usr/bin/openssl 
/usr/bin/openssl: /usr/lib64/libssl.so.10: no version information available (required by /usr/bin/openssl)
    linux-vdso.so.1 =>  (0x00007fff2edff000)
    libssl.so.10 => /usr/lib64/libssl.so.10 (0x00007f664457c000)
    libgssapi_krb5.so.2 => /lib64/libgssapi_krb5.so.2 (0x0000003927600000)
    libkrb5.so.3 => /lib64/libkrb5.so.3 (0x0000003926200000)
    libcom_err.so.2 => /lib64/libcom_err.so.2 (0x0000003925a00000)
    libk5crypto.so.3 => /lib64/libk5crypto.so.3 (0x0000003926e00000)
    libcrypto.so.10 => /usr/lib64/libcrypto.so.10 (0x0000003927200000)
    libdl.so.2 => /lib64/libdl.so.2 (0x000000391a600000)
    libz.so.1 => /lib64/libz.so.1 (0x000000391aa00000)
    libc.so.6 => /lib64/libc.so.6 (0x0000003919e00000)
    libcrypto.so.6 => /usr/lib64/libcrypto.so.6 (0x00007f664421d000)
    libkrb5support.so.0 => /lib64/libkrb5support.so.0 (0x0000003925e00000)
    libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x0000003926a00000)
    libresolv.so.2 => /lib64/libresolv.so.2 (0x000000391be00000)
    libpthread.so.0 => /lib64/libpthread.so.0 (0x000000391a200000)
    /lib64/ld-linux-x86-64.so.2 (0x0000003919600000)
    libselinux.so.1 => /lib64/libselinux.so.1 (0x000000391b600000)
[mckulpa@nuance-vm ~]$ export LD_LIBRARY_PATH=~/libs:$LD_LIBRARY_PATH
[mckulpa@nuance-vm ~]$ echo $LD_LIBRARY_PATH 
/home/mckulpa/libs:/usr/local/Nuance/Recognizer_Service/amd64/lib:/usr/local/Nuance/OAM/x86/lib:/usr/local/Nuance/Common/x86/lib:/usr/local/Nuance/Common/amd64/lib
[mckulpa@nuance-vm ~]$ ldd /usr/bin/openssl 
/usr/bin/openssl: /home/mckulpa/libs/libssl.so.10: no version information available (required by /usr/bin/openssl)
    linux-vdso.so.1 =>  (0x00007fff91dbc000)
    libssl.so.10 => /home/mckulpa/libs/libssl.so.10 (0x00007ffe1af50000)
    libgssapi_krb5.so.2 => /lib64/libgssapi_krb5.so.2 (0x0000003927600000)
    libkrb5.so.3 => /lib64/libkrb5.so.3 (0x0000003926200000)
    libcom_err.so.2 => /lib64/libcom_err.so.2 (0x0000003925a00000)
    libk5crypto.so.3 => /lib64/libk5crypto.so.3 (0x0000003926e00000)
    libcrypto.so.10 => /usr/lib64/libcrypto.so.10 (0x0000003927200000)
    libdl.so.2 => /lib64/libdl.so.2 (0x000000391a600000)
    libz.so.1 => /lib64/libz.so.1 (0x000000391aa00000)
    libc.so.6 => /lib64/libc.so.6 (0x0000003919e00000)
    libcrypto.so.6 => /usr/lib64/libcrypto.so.6 (0x00007ffe1abd9000)
    libkrb5support.so.0 => /lib64/libkrb5support.so.0 (0x0000003925e00000)
    libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x0000003926a00000)
    libresolv.so.2 => /lib64/libresolv.so.2 (0x000000391be00000)
    libpthread.so.0 => /lib64/libpthread.so.0 (0x000000391a200000)
    /lib64/ld-linux-x86-64.so.2 (0x0000003919600000)
    libselinux.so.1 => /lib64/libselinux.so.1 (0x000000391b600000)
[mckulpa@nuance-vm ~]$ ls -l libs
total 316
-rwxr-xr-x. 1 mckulpa mckulpa 321224 05-28 14:59 libssl.so.0.9.8e
lrwxrwxrwx. 1 mckulpa mckulpa     16 05-28 15:18 libssl.so.10 -> libssl.so.0.9.8e

but all I get is a warning and still the 1.0.1e version is printed out:

[mckulpa@nuance-vm ~]$ openssl version
openssl: /home/mckulpa/libs/libssl.so.10: no version information available (required by openssl)
OpenSSL 1.0.1e-fips 11 Feb 2013

Any ideas how to do this properly?

share|improve this question
    
As part of building OpenSSL, you should have built the binary. Run the new binary (perhaps /home/mckulpa/bin/openssl?). –  MadHatter May 28 '14 at 13:59
1  
If you really have a binary application that requires OpenSSL 0.9.8, you should run it on a system that has that version of OpenSSL already, such as CentoS 5 (not CentOS 6). –  Michael Hampton May 28 '14 at 14:33
    
@MadHatter I did not build OpenSSL unfortunately, I copied libssl.so.0.9.8e from /usr/lib64 directory. I might try building it though if no easier solutions will be suggested. –  byyyk May 28 '14 at 15:39
    
@MichaelHampton I will probably do that if everything else fails but I wish there was some other solution as I would really like to be able to use it on newer systems (not only CentOS but also Debian) –  byyyk May 28 '14 at 15:43
    
Upgrade the application, then? –  Michael Hampton May 28 '14 at 16:01

2 Answers 2

up vote 1 down vote accepted

Your application needs the 0.9.8 openssl -- but does it need the 0.9.8 openssl executable, or the 0.9.8 library? (Is it trying to run openssl, or link against it?)

The CentOS openssl098e package is a "A compatibility version of a general cryptography and TLS library", and will install the libraries only - it will not install the 0.9.8 executable.

Run ldd against your application to see whether it's linking in one of the openssl libraries (libssl and libcrypto). To see what your application is trying to run, you can strace it with strace -fo /tmp/strace.out and look for the execv lines.

If your application needs the openssl executable, you'd need to recompile the 0.9.8 package for CentOS 6.

If your application needs the openssl library, then verify whether you need the x86_64 or i686 version, with ldd application. If it's looking in /lib64, then yum install yum install openssl098e.x86_64. If it's looking in /lib then yum install openssl098e.i686.

share|improve this answer
    
I was only suggested by support that it needs openssl 0.9.8 without mentioning whether its library or executable. I suppose it was meant to be executable as ldd doesn't show any version of libssl. Thanks, I will try to compile it myself then. –  byyyk May 30 '14 at 8:08
    
What about libcrypto? This is also provided by the openssl package(s). –  MadHatter May 30 '14 at 8:54
    
You are right, I wasn't aware of that - there was a libcrypto dependency (now i see @R Perrin also suggested that). The application now seems to work... I believe what helped after installing 0.9.8 was the removal of devel package of openssl 1.0.1. Thanks for the help. –  byyyk Jun 2 '14 at 7:59
    
If anyone is reading this then I might want to add that doing the same thing I did with libssl in my question but with libcrypto (that is changing so's through LD_LIBRARY_PATH) would have probably worked as well and might be a cleaner solution. –  byyyk Jun 2 '14 at 8:18

Copying single libraries from other machines is an exercise almost guaranteed to fail, likely in strange and difficult-to-diagnose ways. Don't do that, and if you must do it don't describe it as "installed"; that process definitely doesn't constitute installation.

There does appear to be an openssl098e RPM in the CentOS 6 base repository, which means it's very likely to be in RHEL6 as well. It will be packaged to coexist peacefully with the main system OpenSSL, and it seems to contain the necessary libraries for something that absolutely must have the old version. It doesn't have the userspace openssl tool, but I'd be quite surprised if your application required that.

Try doing a yum install openssl098e.

share|improve this answer
    
I'm sorry... I probably wasn't clear enough. Openssl098e was already installed. I didn't copy it from other machine, I just copied it from /usr/lib64 from the same machine to my home directory in order to reconfigure LD_LIBRARY_PATH (which worked as ldd command shows). I wanted to point the executable to a different library. But as it has already been suggested i might need to recompile. –  byyyk May 30 '14 at 8:02
    
They are right; the executable doesn't work like that. But I'd still be very surprised if another tool needed the userspace binary rather than the libraries; check my comment above about libcrypto. –  MadHatter May 30 '14 at 8:55

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.