Timo Sirainen wrote:
blocking=yes doesn't break anything with nss_ldap, since without
blocking=yes it'll run in one process anyway. PAM works differently.
Thanks for clarifying that.
You're somehow mixing up these things. :) Probably because of the
"blocking" naming, which actually does the opposite of what it's named..
Yes, thanks for explaining further -- I was completely reading
blocking=yes backwards from what you had designed as you pointed out. I
was reading it as an instruction to Dovecot what to do, not an
explanation to Dovecot what the machine is already doing.
blocking=no pam, blocking=yes nss_ldap: No memory leaks leaks. Fixes
nss_ldap problems. Each PAM lookup is done in a forked process. NSS
lookups are done in auth worker processes, as described above. So again
no lookup blocks others.
OK this seems like the perfect solution; in dovecot.conf terms for a
setup such as mine (nothing in /etc/passwd, 100% LDAP lookups for
homedir, password, /etc/nsswitch.conf "passwd: files ldap", etc.) this
would then be:
passdb pam {
args = cache_key=%u dovecot
}
userdb passwd {
args = blocking=yes
}
This would not block/stall in the pipelines, not cause memory leaks
(since underlying code is released each cycle), avoid/fix nss_ldap
issues with file descriptor reuse.
Do I finally have a good understanding now? (thanks for taking the time
to work it out)
-te
--
Troy Engel | Systems Engineer
Fluid, Inc | http://www.fluid.com
