[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: SASL/GSSAPI auth stops working after slapd restart: SOLUTION
--On Thursday, March 11, 2004 1:39 PM +0100 denis.havlik@t-mobile.at wrote:
> I presume that "broken threading" means that problems occur if/when two
> authorisation requests come at a same time?
No, problems come simply as long as you have multiple connections,
regardless of whether or not they are simultaneous.
> - slapd dies?
Yes, or it locks up.
> - LDAP DB corruption?
Yes, if slapd locks up
> - other?
Memory leak problems that cause slapd to grow over time. When we initially
used MIT KRB5 in our testing, we could routinely lock the server up within
4 minutes.
OK, this is a kind of stuff I can test. Something tells me that I'll get aquinted to hemdai very soon. :-(
For the record, I found out why SASL/GSSAPI ldap bind would not work after slapd restart. It's quite dumb, as one would expect:
On reboot, no temporary directory is defined, and both kerberos and ldap choose /var/tmp. If root restarts services afterwards, temporary directory IS defined, and points to /root/tmp. As slapd rund as "ldap" user, it not only looses contact to the old cache file, but also attempts to access the new file in /root/tmp, and fails for obvious reasons.
Let me stress again that this problem ONLY affects SASL/GSSAPI ldap binds - simple binds (even though they eventually check passwords against kerbberos sue to UserPassword: {SASL}<principal>@<REALM>) do NOT use this cache file, and will thus happily work after a reboot regardles of the tmp directory choice.
This problem surely exists on all MandrakeLinux versions up and including the 10.0, and possibly on other Linux distributions as well.
hope this will save time to others in the future...
regards
Denis
T-Mobile Austria GmbH,
Information Technologies / Services
Knowledge Management & Process Automation
Dr. Denis Havlik, eMail: denis.havlik@t-mobile.at
Rennweg 12, Zi. 444 Phone: +43-1-79-585/6237
A-1030 Vienna