Build on CentOS 7.4 mod_ssl.so does not resolve libssl.so.1.0.0 and libcrytop.so1.0.0

[Tece Httpd]

I need to move my httpd from RedHat 6.3 OS to CentOS 7.4 as provided by my company. I tried latest builds of httpd 2.4.38 and found this problem. So I used exactly the same builds as from my RedHat 6.2 OS so using httpd 2.4.25. Both httpd versions come up with the same ld failure to resolve libssl.so and libcrytop.so.

% ldd mod_ssl.so
linux-vdso.so.1 => (0x00007fff2b7f2000)
libssl.so.1.0.0 => not found
libcrypto.so.1.0.0 => not found
librt.so.1 => /lib64/librt.so.1 (0x00007f6a23ec8000)
libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00007f6a23c91000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f6a23a75000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007f6a23871000)
libc.so.6 => /lib64/libc.so.6 (0x00007f6a234a4000)
libfreebl3.so => /lib64/libfreebl3.so (0x00007f6a232a1000)
/lib64/ld-linux-x86-64.so.2 (0x00007f6a24308000)

If I look in /lib64 I see:

% ls -l libssl*
-rwxr-xr-x 1 root root 341000 May 14 2018 libssl3.so
lrwxrwxrwx 1 root root 16 Feb 21 12:51 libssl.so -> libssl.so.1.0.2k
-rwxr-xr-x. 1 root root 340832 Mar 8 2016 libssl.so.0.9.8e
lrwxrwxrwx 1 root root 16 Feb 21 12:49 libssl.so.10 -> libssl.so.1.0.2k
-rwxr-xr-x 1 root root 466288 Apr 12 2018 libssl.so.1.0.2k
lrwxrwxrwx. 1 root root 16 Feb 21 03:42 libssl.so.6 -> libssl.so.0.9.8e

I don't have enough knowledge to figure out why ld does not find/resolve to libssl.so.1.0.2k. I suspect it is a regex / matching problem of the libtool.

Here is my config.nice:

#! /bin/sh
#
# Created by configure

"./configure" \
"--verbose" \
"--prefix=/opt/BEER/tools/httpd-2.4.25" \
"--with-pcre=/opt/BEER/tools/pcre-8.40/pcre-config" \
"--with-perl" \
"--enable-so" \
"-with-ldap" \
"--enable-file-cache" \
"--enable-cache" \
"--enable-mem-cache" \
"--enable-usertrack" \
"--enable-cgi" \
"--with-apr=/opt/BEER/tools/apr-1.5.2" \
"--with-apr-util=/opt/BEER/tools/apr-util-1.5.4" \
"--with-mpm=worker" \
"--with-nghttp2=/opt/BEER/tools/nghttp2-1.20.0" \
"--enable-mods-shared=most" \
"$@"


Google search tells me to install libssl.so, but there is already a 1.0.02k version existing.

Should I create some link to a new name of libssl.so.1.0.0 or something?

Here is the exact message when attempting to start the compiled httpd - and I should note there are NO errors detected in the compile or install phases of the build, that I can see.

"httpd.conf: Cannot load modules/mod_ssl.so into server: libssl.so.1.0.0: cannot open shared object file: No such file or directory"

Thanks

[I R A Darth Aggie]

On Fri, 15 Mar 2019 10:28:51 -0700 (PDT),
Tece Httpd <tony.o...@broadcom.com>, in

<16f5294c-24c0-4c8d...@googlegroups.com> wrote:

> % ldd mod_ssl.so
> linux-vdso.so.1 => (0x00007fff2b7f2000)
> libssl.so.1.0.0 => not found
> libcrypto.so.1.0.0 => not found

> If I look in /lib64 I see:
>
> % ls -l libssl*
> -rwxr-xr-x 1 root root 341000 May 14 2018 libssl3.so
> lrwxrwxrwx 1 root root 16 Feb 21 12:51 libssl.so -> libssl.so.1.0.2k
> -rwxr-xr-x. 1 root root 340832 Mar 8 2016 libssl.so.0.9.8e
> lrwxrwxrwx 1 root root 16 Feb 21 12:49 libssl.so.10 -> libssl.so.1.0.2k
> -rwxr-xr-x 1 root root 466288 Apr 12 2018 libssl.so.1.0.2k
> lrwxrwxrwx. 1 root root 16 Feb 21 03:42 libssl.so.6 -> libssl.so.0.9.8e
>

> I don't have enough knowledge to figure out why ld does not
> find/resolve to libssl.so.1.0.2k. I suspect it is a regex /
> matching problem of the libtool.

Correct. Specifically, you do not have anything named libssl.so.1.0.0
and libcrypto.so.1.0.0. Tho looking at a CentOS 7.3(?) I see that
libcrypto.so is in /usr/lib64/. Both are provided by the package
openssl-devel-1.0.2k-8.el7.x86_64 . Are you using the package manager
or compiling them from source?

The quick & dirty solution is to make a link

ln -s /lib64/libssl.so.1.0.2k /lib64/libssl.so.1.0.0

so that way you have the exact file name and ldd will at least try to
make use of the library.

The better solution is to

yum install openssl-devel-1.0.2k-8.el7.x86_64

--
Consulting Minister for Consultants, DNRC
I can please only one person per day. Today is not your day. Tomorrow
isn't looking good, either.
I am BOFH. Resistance is futile. Your network will be assimilated.

[tony.o...@broadcom.com]

> Correct. Specifically, you do not have anything named libssl.so.1.0.0
> and libcrypto.so.1.0.0. Tho looking at a CentOS 7.3(?) I see that
> libcrypto.so is in /usr/lib64/. Both are provided by the package
> openssl-devel-1.0.2k-8.el7.x86_64 . Are you using the package manager
> or compiling them from source?
>
> The quick & dirty solution is to make a link
>
> ln -s /lib64/libssl.so.1.0.2k /lib64/libssl.so.1.0.0

Yes. After several trials I came up with similar to your suggestion: create the fake link.

ldd utility appeared to be satisfied, so I attempted to start my httpd with the result of:

httpd: Syntax error on line 183 of /opt/BEER/tools/LoadBalancer/conf/httpd.conf: Cannot load modules/mod_ssl.so into server: /opt/BEER/tools/httpd/modules/mod_ssl.so: undefined symbol: SSL_set_srp_server_param


>
> yum install openssl-devel-1.0.2k-8.el7.x86_64
>
> --

Yes I attempted to do this too, but got into a some kind of install mess where dependencies and packages could not be resolved by yum. The underlying issue is that the OS and host is delivered to me/us in this state by our IT dept. and I'm not knowledgeable enough to figure out how to get the yum dependencies resolved. My suspicion is that IT has closed that gate for me.

This was attempted on a CentOS 7.4 build.

Following this I tried to make use of the installed httpd on the OS.

% /usr/sbin/apachectl -f /opt/BEER/tools/LoadBalancer/conf/httpd.conf

- yes my own httpd.conf not /etc/httpd/conf/httpd.conf

This results in:

>>Passing arguments to httpd using apachectl is no longer supported.
>>You can only start/stop/restart httpd using this script.
>>If you want to pass extra arguments to httpd, edit the /etc/sysconfig/httpd config file.

and googled solutions were unhelpful to say the least.




Today I created, with help, a RedHat 7.5 build and did the

yum install openssl-devel-1.0.2k-8.el7.x86_64

install on it. After the usual mucking about I was SUCCESSFUL in getting that host to build and run my httpd installation. But that doesn't solve the original problem - of getting my httpd build running on the IT CentOS 7.4 image. I won't be allowed to use that solution.