> Doubtful. Several things might cause this behavior (slow slapd timing > out, nscd caching bad information, group queries set up wrong), but it's
Nscd's off since it *WILL* cache up the wrong info every now and then
without a clear indication of why. This I thought might be ldap timeout
issue, but instead of trying to figure it out, I removed nscd.
As to slapd timing out, I doubt it since this also happens on the slapd
servers themselves (which should *not* be too slow with the modest db we
have). The connect timeout is 5 seconds, search timeout 30 - they are
intentionally low so that it would swiftly fall back to next LDAP replica
in case the primary one dies. Perhaps the resolver does not implement
this fall-back cleanly?
Group queries may indeed be set up wrong - but I have dug thourgh all the
docs I can and cannot figure out what would be wrong there. Remember:
this affects just three user accounts (perhaps more - I haven't done
extensive testing) and all out accounts are analogous to each other: only
the attributes uid, uidNumber, gidNumber, mail and krb5PrincipalName
differ (yes, userPasswords are identical: {KERBEROS}<krb5PrincipalName).
> hard to say. The fact that it's so random leads me to believe it's
> something like a slapd timeout.
I just tried to increase the timeouts to 30 and 120 seconds, but the
effect remains.
Still as baffled as ever,
Juha
--
-----------------------------------------------
| Juha Jäykkä, [EMAIL PROTECTED] |
| Laboratory of Theoretical Physics |
| Department of Physics, University of Turku |
| home: http://www.utu.fi/~juolja/ |
-----------------------------------------------
signature.asc
Description: PGP signature
