On Tue, 2007-09-11 at 00:41 -0400, Tom Diehl wrote: > For the most part it works as advertised but every once in a while it > stops talking to the auth server. I think I have tracked this to periods > of high auth requests. Today the machine experienced a dictionary attack and > I had log entries like the following: > > Sep 10 13:31:06 rocky dovecot: pop3-login: Disconnected: Shutting down: > rip=::ffff:24.0.201.240, lip=::ffff:192.168.0.16 > Sep 10 13:31:06 rocky dovecot: pop3-login: Can't connect to auth server at > default: Resource temporarily unavailable > Sep 10 13:31:07 rocky last message repeated 47 times
So there were about 50 auth requests/sec. > passdb: > driver: sql > args: /etc/dovecot/sql.conf > passdb: > driver: pam I think this PAM lookup is your worst problem. Dovecot forks a new process for each lookup. Do you really need it? You could also try giving blocking=yes setting to it to make it use auth worker processes. But even with that if your PAM implementation makes Dovecot wait for 2 seconds after unsuccessful lookup, with your configured 20 workers it can handle only 10 invalid logins/sec. If your PAM lookup uses /etc/shadow, you could instead use passdb shadow. > userdb: > driver: static > args: uid=509 gid=509 home=/home/vmail/domains/%d/%n > userdb: > driver: sql > args: /etc/dovecot/sql.conf > userdb: > driver: prefetch Your userdb static catches all the userdb lookups (that aren't in passwd). The userdb sql and prefetch are pointless here.
signature.asc
Description: This is a digitally signed message part
