On Mon, 22 Apr 2013 09:36:34 +0100, Richard W.M. Jones wrote:
I'm not sure whether or not this is a bug, but it sure looks strange.
$ rpm -qf /usr/bin/ssh
openssh-clients-6.1p1-6.fc18.x86_64
$ ldd /usr/bin/ssh|grep ldap
libldap-2.4.so.2 => /lib64/libldap-2.4.so.2 (0x00007fad274fc000)
/usr/lib64/libldap-2.4.so.2 is a symbolic link to a symbolic link
which passes through a -devel package.
/usr/lib64/libldap-2.4.so.2 -> libldap.so # openldap-2.4.34-1.fc18
/usr/lib64/libldap.so -> libldap-2.4.so.2.9.0 # openldap-devel-2.4.34-1.fc18
/usr/lib64/libldap-2.4.so.2.9.0 is a real file # openldap-2.4.34-1.fc18
To cut a long story short, I fixed this by uninstalling openldap-devel
and reinstalling it. Now there is no -devel package in the chain:
$ ldd /usr/bin/ssh | grep ldap
libldap-2.4.so.2 => /lib64/libldap-2.4.so.2 (0x00007fe8caf69000)
/lib64/libldap-2.4.so.2 -> libldap-2.4.so.2.9.0
I'd like to understand how the original situation happened, because it
broke a supermin-built appliance (RHBZ#954185). I assume ldconfig
must have something to do with it. There is nothing unusual in the
%scripts of openldap (it just runs ldconfig as you'd expect), nor is
there any special openssh/openldap config file in /etc/ld.so.conf.d.
Some thoughts:
1) ldconfig does not touch the non-versioned .so libs (especially not if
they are development-only symlinks), since it only cares about the
run-time libs. It adjusts the SONAME -> FULLY-VERSIONED-LIBNAME symlinks,
so .so.2 will point at the latest .so.2.x.y, for example. It would not
recreate a deleted .so symlink and would not redirect it either.
2) The openldap-devel package contains a (harmless) bug, since it runs
ldconfig in its scriptlets. It doesn't need to.
3) Funny things going on (f19 here), but haven't examined anything
beyond this:
# rpm -e openldap-devel
# ldconfig -v|grep ldap
libldap_r-2.4.so.2 -> libldap_r-2.4.so.2.9.1
libldap-2.4.so.2 -> libldap-2.4.so.2.9.1
# yum -y install openldap-devel
# ldconfig -v|grep ldap
libldap_r-2.4.so.2 -> libldap_r.so
libldap-2.4.so.2 -> libldap.so
That makes no sense.
In /lib64 it looks different (and correct), however:
# ls -la /lib64/*ldap*
lrwxrwxrwx. 1 root root 20 Apr 17 22:30 /lib64/libldap-2.4.so.2 ->
libldap-2.4.so.2.9.1
-rwxr-xr-x. 1 root root 336504 Apr 15 10:56 /lib64/libldap-2.4.so.2.9.1
lrwxrwxrwx. 1 root root 22 Apr 17 22:30 /lib64/libldap_r-2.4.so.2 ->
libldap_r-2.4.so.2.9.1
-rwxr-xr-x. 1 root root 358720 Apr 15 10:56 /lib64/libldap_r-2.4.so.2.9.1
lrwxrwxrwx. 1 root root 22 Apr 22 11:18 /lib64/libldap_r.so ->
libldap_r-2.4.so.2.9.1
lrwxrwxrwx. 1 root root 20 Apr 22 11:18 /lib64/libldap.so -> libldap-2.4.so.2.9.1
-rwxr-xr-x. 1 root root 45896 Apr 10 16:52 /lib64/libsmbldap.so.0
--
Fedora release 19 (Schrödinger’s Cat) - Linux 3.9.0-0.rc7.git3.1.fc19.x86_64
loadavg: 0.27 0.17 0.26