Date: Wed, 10 Jan 2007 16:07:03 +0100 From: "J.M. Maurer" mmaurer@betterbe.com Subject: Re: [Dovecot] LDAP authentication stops working... To: dovecot@dovecot.org Message-ID: 1168441623.11613.3.camel@sigma.lan.uwog.net Content-Type: text/plain
On Tue, 2007-01-09 at 09:54 +0000, Gavin Henry wrote:
<quote who="Adrian Close">
Hi all,
I'm running dovecot-1.0.rc17 on OpenBSD 3.9, using userdb and passdb methods of "ldap" (SSL on 636/tcp) in addition to "passwd".
Occasionally (generally after a few hours of operation, but not always), LDAP-based logins stop working (e.g. hang/timeout after POP3 PASS command). Accounts with local passwords (as opposed to accounts with a password field of "x") still work fine at this point.
We also get this. Twice a day we have to restart dovecot, using userdb and passdb via LDAP, with userdb_prefetch.
Just to add: we moved from rc
to rc15 recently, and we now also see a lot of hangs with The result handler for the initial ldap_search to find the dn to bind to is never called. I assume Timo fscked something up recently in my auth_bind code ;-P
Anyway, restarting ldap every hour or so with cron does the job :-|
I'd debug this if I had the time, but I won't have before next week.
Cheers, Marc
I haven't documented it properly (yet) but when using rc15 with userdb_prefetch + passdb + ldap_authbind (200-500 concurrent clients) directly with LDAP it operates OK only for a few minutes. After a while authentication freezes. On the LDAP server (openldap v2.2.28) I see countless log entries such as: " slapd[24721]: connection_input: conn=1134942 deferring operation: binding". Dovecot show I tried to increase various dovecot and openldap limits without success. Until the problem is solved, I use Dovecot with getpwnam (/etc/passwd) + pamldap which works always OK.
Could anybody please verify that direct LDAP userdb_prefetch, passdb, auth_bind work ok with openldap under heavy stress? Is it possible that multiple concurrent LDAP bind requests and searches under different LDAP credentials through the very same TCP connection produce some kind of spourious problem?
Apostolis Papagiannakis Aristotle University of Thessaloniki, Greece