dovecot - Jul 2011 - Parallel auth

Hello,

we run a Dovecot 2.0.13 instance purely as SASL backend for Postfix,
authenticating against a local passwd-file and our central LDAP
database.

# dovecot -n
# 2.0.13: /etc/dovecot/dovecot.conf
# OS: Linux 2.6.32.36-0.5-default x86_64 SUSE Linux Enterprise Server 11
# (x86_64)
auth_mechanisms = plain login
auth_verbose = yes
passdb {
  args = /etc/dovecot/dovecot-passwd
  driver = passwd-file
}
passdb {
  args = /etc/dovecot/dovecot-ldap-simauth.conf.ext
  driver = ldap
}
protocols = none
service auth {
  unix_listener /var/spool/postfix-postout/private/auth {
    group = postfix
    mode = 0660
    user = postfix
  }
}
ssl = no

There is only a single user in the passwd-file for monitoring. We
monitor authentication delays for both this local user and one user from
LDAP.

Due to a firmware bug, our six-figures NAS causes extremely high LDAP
delays (in the range of 20-60 seconds, instead of the usual 50ms) once
an hour. The weird thing is, I also see these delays in the graph for
the local user. Which got me thinking

* are authentication requests handled serially by dovecot/auth?
* any way to solve this situation for the local user (not to be blocked
  by the delayed LDAP query)?
* any way to solve this situation for LDAP users? We could possibly do
  some loadbalancing if the auth-daemon opened several LDAP connections

Thanks,
Bernhard

On 22.7.2011, at 9.42, Bernhard Schmidt wrote:
> passdb {
>  args = /etc/dovecot/dovecot-passwd
>  driver = passwd-file
> }
> passdb {
>  args = /etc/dovecot/dovecot-ldap-simauth.conf.ext
>  driver = ldap
> }
Dovecot should first try the passwd-file and if it succeeds, stop. If it fails,
continues to ldap.
> Due to a firmware bug, our six-figures NAS causes extremely high LDAP
> delays (in the range of 20-60 seconds, instead of the usual 50ms) once
> an hour. The weird thing is, I also see these delays in the graph for
> the local user. Which got me thinking
Yes, that is weird.
> * are authentication requests handled serially by dovecot/auth?
Yes.
> * any way to solve this situation for the local user (not to be blocked
>  by the delayed LDAP query)?
Shouldn't happen! Maybe the delay was caused by something not directly
related to the LDAP lookups.. You could also verify with straceing the auth
process and authenticating as the local user to verify that it doesn't do an
LDAP lookup.
> * any way to solve this situation for LDAP users? We could possibly do
>  some loadbalancing if the auth-daemon opened several LDAP connections
Not currently, at least not until I rewrite LDAP's connection pooling to
work in a similar way to SQL. Although even that doesn't solve the latency
problems, someone else also recently complained about one of their SQL servers
giving high latency replies and Dovecot not dropping that server in favor of the
second fast one.. I should do something about that.