Le vendredi 10 février 2012 à 15:45 -0800, Quanah Gibson-Mount a écrit :
--On Friday, February 10, 2012 6:21 PM -0500 Daniel Savard dsavard@cids.ca wrote:
For the records, I did upgrade to OpenLDAP 2.4.28, latest stuff. It doesn't solve anything.
If the issue is what version of Kerberos sasl is linked against, upgrading OpenLDAP isn't going to help you at all. I suggest you run your ldapsearch command under gdb and get a backtrace of where the segfault is occurring.
Very strange findings. First, I decided to try the ldapwhoami from another client and here what I got:
$ ldapwhoami SASL/GSSAPI authentication started SASL username: dsavard@CIDS.CA SASL SSF: 56 SASL data security layer installed. dn:cn=daniel savard,dc=cids,dc=ca $ echo $? 0 $
Then I did ran with gdb the ldapwhoami on the previous client and here is what I got:
(gdb) run Starting program: /usr/bin/ldapwhoami [Thread debugging using libthread_db enabled] SASL/GSSAPI authentication started SASL username: dsavard@CIDS.CA SASL SSF: 56 SASL data security layer installed. dn:cn=daniel savard,dc=cids,dc=ca
Program received signal SIGSEGV, Segmentation fault. 0xb7e82231 in free () from /lib/libc.so.6 (gdb)
glibc is same version everywhere, as openldap, openssl, sasl and mit-krb5. So far, the only difference I see is the architecture, the working one is 64-bits while others are 32-bits.
I did the same with a ldapsearch which is working but SIGSEGV on the 32-bits clients.
Anything else I can do to identify the problem and fix it?
THX