[Date Prev][Date Next]
Re: AW: Problems with ldapwhoami -> slapd -> segmentation fault
--On Wednesday, August 25, 2004 9:19 PM +0200 "Guus Leeuw jr."
I suggest reading the list archives for "MIT" and "Heimdal"
to see why you
probably do not want to use MIT Krb5 on top, and should
instead use Heimdal.
Yeah, I might try that one day... ;)
I'm not too sure though, the problem is with MIT...
I rather think the problem is somehow with SASL&slapd or slapd by
itself... Slapd really seems to think (by the sasl2 lib, that it
should open /etc/sasldb2 (which has no use in case of GSSAPI...
Or so the manpage says...) So I guess I am missing some kind of
Configuration to this piece or that piece (not slapd.conf, since
that one seems to go for SASL2... ;)
*but* the sample-server and sample-client work together upto the point
Where the client says: Expecting encrypted message (which it says after
It reports authentication OK). Also the saslauthd and testsaslauthd
indicate OK, so I think SASL is not really off...
Must be somthing in slapd then?
In which function is the session_callbacks array actually used? Maybe it
Not traverse well enough... And skips the SASL_CB_LIST_END id? (Wild
Anything else you can think of, Quanah? (and others ;)
Well, I assume you are using SASL/GSSAPI to bind to the server. That is
what we use @ Stanford, and it has been quite solid for me in 2.2.15. It
is fine to use MIT Kerberos with OpenLDAP in a client library setting where
threads are not involved. On the server side, I've found I can routinely
kill slapd within about 30 seconds (with segfaults) because MIT as it ships
is not thread safe. You might want to read:
You may also wish to run slapd with "-d -1" as a parameter to get slapd
going with full debugging output, and see where it is segfaulting. I do
strongly suggest either using Heimdal as the Kerberos for the server, or
finding Simon's patches (if you search on MIT, you'll find them somewhere)
for MIT, which I assume he keeps up to date.
MIT is working actively on the threading issue (I've been doing some
testing for them), so hopefully someday this will all be a moot issue.
Principal Software Developer
GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html