[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: AW: Problems with ldapwhoami -> slapd -> segmentation fault





--On Wednesday, August 25, 2004 9:19 PM +0200 "Guus Leeuw jr." <Guus-Leeuw@gmx.de> wrote:

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
does
Not traverse well enough... And skips the SASL_CB_LIST_END id? (Wild
guess!)

Anything else you can think of, Quanah? (and others ;)

Hi Guus,

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:

<http://www.stanford.edu/services/directory/openldap/configuration/>

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.

--Quanah



--
Quanah Gibson-Mount
Principal Software Developer
ITSS/Shared Services
Stanford University
GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html