[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: GSSAPI (SASL) + LDAP
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
--
Daniel Savard