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 > <[email protected]> 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: [email protected] 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: [email protected] 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 -- Daniel Savard
