On Mon, 2007-08-06 at 15:37 +0100, Daniel Watts wrote:
Seems to work well (though haven't tried looking at stats). Only problem is that every so often, one of our new users tries to log in quickly before the account is marked (in a db) as 'active'. They use the right password but the sql query fails because the active flag is not yet set.
This results in their trying to log in and failing for 15 minutes (900 seconds) until the cache clears.
Is this dovecot caching negative results?
Yes.
Is this a good idea and can it be disabled?
It can't be disabled. Perhaps there could be a separate auth_cache_negative_ttl setting. OK, implemented for v1.1: http://hg.dovecot.org/dovecot/rev/6c48466c23fa
It might apply to v1.0 also.
- Is the expire time on a per-login basis or for the entire cache? If someone logs in 14 minutes after the last expiry is their data cached for just 1 minute?
1 minute.
- How does the cache size relate to number of distinct logins? Roughly how many auth datasets cached per 1MB of cache?
It depends on what kind of information you're returning. Dovecot caches both passdb and userdb lookups, so it's basically the length of the string that contains all the returned data.
For example if you set auth_debug=yes you'll see in logs:
client out: OK 1 user=tss master out: USER 458 tss uid=1000 gid=1000 home=/home/tss
Password is hidden. These are stored in two different cache entries. Besides this information it also contains cache key which contains at least username and possibly other information. Also some internal records are counted.
So above two would use about 65 bytes for the strings and maybe 30 bytes for internal records.