Wouter Verhelst <[EMAIL PROTECTED]> writes: > Since I could successfully log on using 'ldapsearch -Y GSSAPI' and using > Authen::SASL::Perl, I assumed Authen::SASL::Cyrus was to blame. This, at > least, shows something more is going on...
Oh, hey, look, Authen::SASL::Perl can do GSSAPI now. That's interesting. One of the reasons why I worked on Authen::SASL::Cyrus in the first place is because Authen::SASL::Perl couldn't do GSSAPI. > When I stop slapd, and start it with '-d Any' (so that it doesn't > detach, but throws a *huge* bunch of debugging details on stdout), I > can't reproduce the bug. Luckily, the bug is reproducible when changing > the configuration file to get those details in syslog, but that pollutes > things... *sigh*. OpenLDAP debugging is always annoying. > Checking the logs reveals that there's a little bug in the script: > > $res = $ldap->search(base => 'ou=People,dc=grep,dc=be', filter => > "(&(objectClass=posixUser)(uid=wouter))"); > > should get an s/posixUser/posixAccount/. Doing that changes the error > message from "Broken pipe" to "Connection reset by peer". This suggests > that the only bug in Authen::SASL::Cyrus is one of insufficient error > handling, but that the real bug is in slapd. What a surprise. Still very odd that it would just drop the connection on you and that it would be different depending on what SASL library you use. We run slapd with a log level of 256, which seems to be about the right balance on verbosity versus useful output in the logs. I wonder if it would still show the error there. -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
