ImportError: /lib64/libldap.so.2: undefined symbol: EVP_md2, version OPENSSL_3.0.0

This fixed the problem:

Upgrading OpenSSL manually on CentOS Stream 9 is likely causing your yum issue. Let’s explore why this happens and how to fix it.

The Problem:

When you compiled and installed OpenSSL 3.4.0 to /usr/local/openssl-3.4, you didn’t replace the system’s default OpenSSL libraries. Instead, you added the new version to your PATH and LD_LIBRARY_PATH. This allows you to use the new openssl command, but system libraries and tools like yum (which relies on Python and other system libraries) are still linked against the older OpenSSL version that came with CentOS Stream 9.

The libldap.so.2 library, which dnf is trying to use, was likely built against the system’s OpenSSL. When it tries to load and use OpenSSL functions, it’s looking for them in the system’s default OpenSSL libraries, not the ones in /usr/local/openssl-3.4/lib. The EVP_md2 symbol with the OPENSSL_3.0.0 version requirement suggests that the system’s OpenSSL is older than 3.0.0, hence the “undefined symbol” error.

Troubleshooting and Resolution Steps:

1. Avoid Replacing the System OpenSSL Directly:

Directly replacing the system’s OpenSSL libraries with your manually compiled version is risky and can break many core system components. Package managers like rpm are not aware of these manual changes, leading to inconsistencies and potential instability.

2. Use the System’s OpenSSL for System Tools:

Ensure that yum/dnf and its dependencies are using the OpenSSL version provided by CentOS Stream 9.

3. Temporarily Remove the Custom OpenSSL from Environment Variables:

Try running yum after removing the custom OpenSSL from your environment variables to force the system to use its default libraries.

# unset PATH
# export PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/root/bin
# unset LD_LIBRARY_PATH

After running these commands, try running yum again:

# yum --version

If yum works now, it confirms that your custom OpenSSL in the environment variables was the issue. Avoid setting these environment variables globally or permanently if you want system tools to function correctly. You can still use your newer OpenSSL by explicitly calling it with its full path (/usr/local/openssl-3.4/bin/openssl) or by setting the environment variables only when you specifically need to use it.

4. Investigate Packages that Might Require a Newer OpenSSL:

If removing the environment variables doesn’t fix yum, some other package you installed might have dependencies on a newer OpenSSL version and is causing a conflict. Identify recently installed packages:

# rpm -qa --last | head

If you see any packages related to cryptography or installed around the time you upgraded OpenSSL, they might be the culprit. Reinstall them to link against the system’s OpenSSL.

5. Reinstall openldap-clients and python3-libdnf:

Since the error message mentions libldap.so.2 and the traceback involves dnf, try reinstalling these packages to ensure they are linked against the correct system libraries.

# sudo yum reinstall openldap-clients python3-libdnf

Note: You need yum to be at least partially functional for this to work. If yum is completely broken, explore other recovery methods.

6. Consider Using Software Collections (SCL) for Newer Software:

If you need to use a newer version of OpenSSL alongside the system’s default libraries without causing conflicts, consider using Software Collections (SCL). SCL allows you to install and use different versions of software in isolated environments without affecting the base system.

Summary:

Ensure that your system tools like yum are not influenced by your manually installed OpenSSL through environment variables. If that doesn’t work, reinstalling the openldap-clients and python3-libdnf packages might resolve the dependency issue.