A VPS on Centos 7 came with a very old version of openssl. I built and installed a newer version of openssl. (details below) This newer openssl was only installed in order to upgrade to a much newer version of curl. It was intended to call this curl specifically by location and not to integrate it into any other programs.
Apparently, the installation caused an issue for exim (and who knows what else). Now, updating exim is failing due to not finding libssl.so.1.1.
Can the openssl binary in /usr/local/openssl/bin/openssl
be hidden from the system? (so that exim will update) I'm not quite sure what is happening in the exim build, but of course it worked before.
I suppose two solutions are to move the openssl install to /opt or to rename the openssl to something else. However, I'd like to learn if there is a simpler solution.
All ideas welcome. Thanks for considering this.
Some system info:
[root@vps ~]# which openssl
/usr/bin/openssl
[root@vps ~]# whereis openssl
openssl: /usr/bin/openssl /usr/lib64/openssl /usr/include/openssl /usr/local/openssl /usr/share/man/man1/openssl.1ssl.gz /usr/share/man/man1/openssl.1
[root@vps ~]# /usr/bin/openssl version
OpenSSL 1.0.2k-fips 26 Jan 2017
[root@vps ~]# /usr/lib64/openssl version
-bash: /usr/lib64/openssl: Is a directory
[root@vps ~]# /usr/include/openssl version
-bash: /usr/include/openssl: Is a directory
[root@vps ~]# /usr/local/openssl/bin/openssl version
OpenSSL 1.1.1t 7 Feb 2023
---
*** Could not run ./exim -bV -C /dev/null to find version number ***
*** Exim installation failed ***
./exim: error while loading shared libraries: libssl.so.1.1: cannot open shared object file: No such file or directory
make: *** [install] Error 1
Moving exim binary.
---
First of all, you showed nothing to really display that some "binary file is hidden".
Exim is likely expecting to find the library not in /usr/local/lib(64) but in /usr/lib(64) or /lib(64). Check your
/etc/ld.so.conf
for details. You can direct you application to prefer some path, usingLD_LIBRARY_PATH
environment variable, e.g. runLD_LIBRARY_PATH=/some/path exim
to define this variable for just one command. This is the way one might run ancient programs on newer systems (for one case I need to use old OpenSSL and old build of a specific program, but I don't want to have old OpenSSL system-wide, so I put enough old libraries for that program into custom directory and start it like this).Also, notice the soname: if you built newer OpenSSL, you had to rebuild all the dependent software; different soname means ABI is likely changed. New OpenSSL creates
libssl3.so
and doesn't createlibssl.so.1.1
which your build of an application expects. In some cases you may symlink one to another, but problems are likely; rebuild is necessary to resolve such issues. (This is why long-term support distros are so hard to maintain: one needs to backport all fixes into older versions of applications and libraries to not change ABIs and sonames so you can just upgrade the library package version without creating other problems for dependent applications.)Lastly, when working with production servers, never use
make
andmake install
, it'll turn your system into mess you'll never be able to clean. Build your own packages out from SRPMs (or DEB-SRCs, if we talk about Debian-based systems) and install them using package manager.When you pick a stable distro such as CentOS, part of the deal is that things won't break. Sure, you won't get new features, but RedHat/CentOS will back port security fixes and bug fixes to old versions of the software, so that you will see minimal changes.
You don't get a new curl. To get that, you have to update to a newer release; CentOS 7 is stuck with the version it shipped with.
Furthermore, both curl and openssl is essential system libraries, used by a lot of other software. When you start mucking with those, things break. Don't.
Upgrade to a newer distro release. If you want new shiny toys look at a distro with a more frequent release cycle.