Bug 1156154

(In reply to Donald Berry from comment #0)
> The problem here is that python-rhsm is a package installed by default
> by the @Base group, and since we've specified rhn-tools as an add on
> Anaconda "helpfully" finds the latest available version to install.

You're welcome.

> However something that fulfills the libcrypto dependency is not
> available in the 6.4 kickstart tree (only the rhel 6 channel, which is
> different), so anaconda displays this error message.

So the rhn-tools repo that you are using is not compatible with RHEL-6.4. Use RHEL-6.5 or fix the packages in your addon repos.

This bug should have been filed against Satellite not RHEL. The fix is going to have to be updating content in the rhn-tools channel. I am changing the product and re-opening.

Temporary work-arounds include:

1) not selecting rhn-tools as a child channel in the kickstart profile, and subscribing the server to rhn-tools after the kickstart

2) not selecting rhn-tools as a child-channel in the kickstart profile but instead associating an activation key with the kickstart profile that will subscribe the server to rhn-tools

3) creating a custom channel that contains openssl-1.0.0-27.el6 (and any dependencies) and selecting both the custom channel and rhn-tools as child channels in the kickstart profile

*** Bug 1156181 has been marked as a duplicate of this bug. ***

The root problem here is actually very tricky. python-rhsm contains a C file that gets compiled and used as a python library. This C file depends on various other C libraries, like x509 libraries.

What happens is that at RPM build time RPM helpfully runds ldd on all executables in the package for us and automatically includes any shared libraries as rpm requirements.
http://www.rpm.org/max-rpm/s1-rpm-depend-auto-depend.html

In this case when ldd runs on this compiled C file it sticks in (among other things) the version of libcrypto that it was compiled against. Yum / anaconda must be able to find a package that fulfills the shared library requirements when they try to install python-rhsm.

That would be a huge problem if the libraries were not available. However in this case I think they are available (all the way back to RHEL 6.0, RHEL is generally very good about maintaining ABI compatibility of system-level libraries), and the problem is something much stupider (but fortunately easier to fix). If we look at the python-rhsm package we'll notice that RPM has helpfully added two auto-dependencies for libcrypto 10:

# rpm -q python-rhsm
python-rhsm-1.13.2-1.el6.x86_64

# rpm -q --requires python-rhsm | grep libcrypto
libcrypto.so.10()(64bit)  
libcrypto.so.10(libcrypto.so.10)(64bit)

However if we look at the version of openssl available in the RHEL 6.4 kickstart trees (and it's similar for previous versions) we'll see that it only provides one of them:

# rpm -q openssl
openssl-1.0.0-27.el6.x86_64

# rpm -q --provides openssl | grep libcrypto
libcrypto.so.10()(64bit)

This is why anaconda throws the error at kickstart time, it cannot find any package that provides the "libcrypto.so.10(libcrypto.so.10)(64bit)" dependency. This is also why everything works correctly if you tell it to ignore the error and continue with the install: because libcrypto.so.10 is available and the ABI has not changed, the only difference is a superfluous dependency string is missing from old openssl packages.

I believe the fix for this error is to release an updated python-rhsm package into rhn-tools that does not contain the duplicate "libcrypto.so.10(libcrypto.so.10)(64bit)" dependency.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2014-1735.html