[MDEV-26741] Cannot load galera library since it now expects libssl.so.1.0.0 Created: 2021-10-01  Updated: 2022-02-08  Resolved: 2021-12-01

Status: Closed
Project: MariaDB Server
Component/s: Galera
Affects Version/s: 10.5.12
Fix Version/s: 10.5.13, 10.6.5

Type: Bug Priority: Major
Reporter: Jaikiran Pai Assignee: Daniel Bartholomew
Resolution: Fixed Votes: 0
Labels: None


 Description   

We are using 10.5.8 of MariaDB and recently decided to move to 10.5.12 (latest released). We use Galera for HA. We use the .tar.gz binaries available at https://downloads.mariadb.org/mariadb (Linux x86_64 variant) to install the server.

Moving to 10.5.12, we haven't been able to boot the MariaDB server at all since it fails to load the galera library due to a dependency on libssl.so.1.0.0 and libcrypto.so.1.0.0. We checked our current 10.5.8 installation and it uses libssl.so.10 and libcrypto.so.10. Looking back at the releases, it looks like starting 10.5.10 version of MariaDB, galera now expects libssl.so.1.0.0 and libcrypto.so.1.0.0 instead of libssl.so.10 and libcrypto.so.10. We don't have those versions on the setups we use.
More specifically, here's the "ldd" output from 10.5.8 and 10.5.10 against libgalera_smm.so:

10.5.8:

ldd libgalera_smm.so 
	linux-vdso.so.1 =>  (0x00007ffda4ddb000)
 
	libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fa9914c5000)
 
	librt.so.1 => /lib64/librt.so.1 (0x00007fa9912bd000)
 
	libssl.so.10 => /lib64/libssl.so.10 (0x00007fa99104a000)
 
	libcrypto.so.10 => /lib64/libcrypto.so.10 (0x00007fa990be7000)
 
	libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007fa9908df000)
 
	libm.so.6 => /lib64/libm.so.6 (0x00007fa9905dc000)
 
	libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fa9903c6000)
 
	libc.so.6 => /lib64/libc.so.6 (0x00007fa990005000)
 
	/lib64/ld-linux-x86-64.so.2 (0x00007fa991986000)
 
	libgssapi_krb5.so.2 => /lib64/libgssapi_krb5.so.2 (0x00007fa98fdb6000)
 
	libkrb5.so.3 => /lib64/libkrb5.so.3 (0x00007fa98facf000)
 
	libcom_err.so.2 => /lib64/libcom_err.so.2 (0x00007fa98f8cb000)
 
	libk5crypto.so.3 => /lib64/libk5crypto.so.3 (0x00007fa98f698000)
 
	libdl.so.2 => /lib64/libdl.so.2 (0x00007fa98f494000)
 
	libz.so.1 => /lib64/libz.so.1 (0x00007fa98f27e000)
 
	libkrb5support.so.0 => /lib64/libkrb5support.so.0 (0x00007fa98f06e000)
 
	libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x00007fa98ee6a000)
 
	libresolv.so.2 => /lib64/libresolv.so.2 (0x00007fa98ec50000)
 
	libselinux.so.1 => /lib64/libselinux.so.1 (0x00007fa98ea28000)
 
	libpcre.so.1 => /lib64/libpcre.so.1 (0x00007fa98e7c7000)

10.5.10:

ldd libgalera_smm.so 
ldd: warning: you do not have execution permission for `./libgalera_smm.so'
 
	linux-vdso.so.1 =>  (0x00007ffd101fb000)
 
	libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fbe5ca57000)
 
	librt.so.1 => /lib64/librt.so.1 (0x00007fbe5c84f000)
 
	libssl.so.1.0.0 => not found
 
	libcrypto.so.1.0.0 => not found
 
	libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007fbe5c546000)
 
	libm.so.6 => /lib64/libm.so.6 (0x00007fbe5c243000)
 
	libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fbe5c02d000)
 
	libc.so.6 => /lib64/libc.so.6 (0x00007fbe5bc6c000)
 
	/lib64/ld-linux-x86-64.so.2 (0x00007fbe5d0a7000)

I checked the release notes of these versions and can't find anything that mentions any changes in this area.

Is this an expected change? What version of OpenSSL is expected to be installed on such setups?

 Comments   
Comment by Jaikiran Pai [ 2021-10-02 ]

The precise error message that we receive on 10.5.12 MariaDB version is as follows:

2021-10-02 6:03:12 0 [Note] WSREP: Loading provider /usr/local/mysql/lib/libgalera_smm.so initial position: 00000000-0000-0000-0000-000000000000:-1
2021-10-02 6:03:12 0 [Note] WSREP: wsrep_load(): loading provider library '/usr/local/mysql/lib/libgalera_smm.so'
2021-10-02 6:03:12 0 [ERROR] WSREP: wsrep_load(): dlopen(): libssl.so.1.0.0: cannot open shared object file: No such file or directory
2021-10-02 6:03:12 0 [ERROR] WSREP: Failed to create a new provider '/usr/local/mysql/lib/libgalera_smm.so' with options 'evs.suspect_timeout=PT30S; evs.inactive_timeout=PT45S; evs.inactive_check_period=PT15S': Failed to load wsrep library
2021-10-02 6:03:12 0 [ERROR] WSREP: Failed to load provider
2021-10-02 6:03:12 0 [ERROR] Aborting

Comment by Jaikiran Pai [ 2021-10-07 ]

Any inputs on this one please? We haven't been able to upgrade to this new version of MariaDB.

Comment by Sergei Golubchik [ 2021-10-13 ]

dbart: non-systemd bintars. 10.5.8 has libgalera_smm.so from centos7x builder, 10.5.12 — from trusty. systemd builds both have it from trusty

Comment by Daniel Bartholomew [ 2021-10-14 ]

jaikiran:
I've created an updated mariadb-10.5.12-linux-x86_64.tar.gz bintar that I've uploaded here:

I've verified on a test machine that this bintar does have a working libgalera_smm.so (i.e. linked to the correct libcrypto and libssl), but I'd like to confirm that it works in your environment before rolling out the fixed bintar everywhere.

Comment by Jaikiran Pai [ 2021-10-15 ]

Hello Daniel,

Thank you for your work on this. I'll use that custom tar in some of our internal setups and test it out. I'll get back to you shortly on how those test runs go.

Comment by Jaikiran Pai [ 2021-10-15 ]

Hello Daniel,

I have run some basic tests with the tar you linked and it has fixed the issue. Here's the relevant snippet from the logs:

2021-10-15 13:03:23 0 [Note] mariadbd (mysqld 10.5.12-MariaDB-log) starting as process 93434 ...
 
2021-10-15 13:03:23 0 [Note] WSREP: Loading provider /usr/local/mysql/lib/libgalera_smm.so initial position: 00000000-0000-0000-0000-000000000000:-1
 
2021-10-15 13:03:23 0 [Note] WSREP: wsrep_load(): loading provider library '/usr/local/mysql/lib/libgalera_smm.so'
 
2021-10-15 13:03:23 0 [Note] WSREP: wsrep_load(): Galera 26.4.9(r819f29c) by Codership Oy <info@codership.com> loaded successfully.

Additionally, for reference, here's the ldd output from this patched version:

ldd /usr/local/mysql/lib/libgalera_smm.so
 
	linux-vdso.so.1 =>  (0x00007ffc1235d000)
 
	libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fdf73c61000)
 
	librt.so.1 => /lib64/librt.so.1 (0x00007fdf73a59000)
 
	libssl.so.10 => /lib64/libssl.so.10 (0x00007fdf737e7000)
 
	libcrypto.so.10 => /lib64/libcrypto.so.10 (0x00007fdf73384000)
 
	libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007fdf7307d000)
 
	libm.so.6 => /lib64/libm.so.6 (0x00007fdf72d7b000)
 
	libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fdf72b65000)
 
	libc.so.6 => /lib64/libc.so.6 (0x00007fdf72797000)
 
	/lib64/ld-linux-x86-64.so.2 (0x00007fdf7429f000)
 
	libgssapi_krb5.so.2 => /lib64/libgssapi_krb5.so.2 (0x00007fdf7254a000)
 
	libkrb5.so.3 => /lib64/libkrb5.so.3 (0x00007fdf72261000)
 
	libcom_err.so.2 => /lib64/libcom_err.so.2 (0x00007fdf7205d000)
 
	libk5crypto.so.3 => /lib64/libk5crypto.so.3 (0x00007fdf71e2a000)
 
	libdl.so.2 => /lib64/libdl.so.2 (0x00007fdf71c26000)
 
	libz.so.1 => /lib64/libz.so.1 (0x00007fdf71a10000)
 
	libkrb5support.so.0 => /lib64/libkrb5support.so.0 (0x00007fdf71800000)
 
	libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x00007fdf715fc000)
 
	libresolv.so.2 => /lib64/libresolv.so.2 (0x00007fdf713e3000)
 
	libselinux.so.1 => /lib64/libselinux.so.1 (0x00007fdf711bc000)
 
	libpcre.so.1 => /lib64/libpcre.so.1 (0x00007fdf70f5a000)

I haven't yet run the entire testsuite of our product which this tar and I'll be doing that next week. But for the issue at hand, I think the fix you provided in that tar is working. Thank you very much for addressing this issue.

Comment by prashant Jadhav [ 2022-02-08 ]

I ma facing same issue in 10.5.13.. have created a issue for same. MDEV-27773

Generated at Thu Feb 08 09:47:35 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.