[Dovecot] Syntax for doveadm auth cache
Hello,
What is the correct syntax of doveadm auth cache command? According to command line help:
usage: doveadm [-Dv] [-f <formatter>] <command> [<args>]
altmove [-u <user>|-A] [-S
but when I try to run doveadm auth cache, then I'm asked for a password, so I think the command is trying to authenticate cache user.
Moreover... according to previous mails (thread http://www.dovecot.org/list/dovecot/2012-June/066691.html) there is a patch to remove a specific user entry from cache. This patch I think is included in dovecot 2.1.9 (which I'm running) and the syntax is (I think):
doveadm auth cache flush <user> 4 cache entries flushed
So I'm running this command. Whenever I run it, I get the message that 3 (sometimes, is 4) entries are removed, but user information isn't really reloaded and I doubt it is really removed from cache (I have the user in a passwd-file and information used by imap processes is still the old one, no the new one, changed before the flush)
-- Angel L. Mateo Martínez Sección de Telemática Área de Tecnologías de la Información y las Comunicaciones Aplicadas (ATICA) http://www.um.es/atica Tfo: 868887590 Fax: 868888337
On 3.9.2012, at 14.16, Angel L. Mateo wrote:
Moreover... according to previous mails (thread http://www.dovecot.org/list/dovecot/2012-June/066691.html) there is a patch to remove a specific user entry from cache. This patch I think is included in dovecot 2.1.9 (which I'm running) and the syntax is (I think):
doveadm auth cache flush <user> 4 cache entries flushed
Yep.
So I'm running this command. Whenever I run it, I get the message that 3 (sometimes, is 4) entries are removed, but user information isn't really reloaded and I doubt it is really removed from cache (I have the user in a passwd-file and information used by imap processes is still the old one, no the new one, changed before the flush)
Works in my tests.
El 11/09/12 16:24, Timo Sirainen escribió:
On 3.9.2012, at 14.16, Angel L. Mateo wrote:
Moreover... according to previous mails (thread http://www.dovecot.org/list/dovecot/2012-June/066691.html) there is a patch to remove a specific user entry from cache. This patch I think is included in dovecot 2.1.9 (which I'm running) and the syntax is (I think):
doveadm auth cache flush <user> 4 cache entries flushed
Yep.
So I'm running this command. Whenever I run it, I get the message that 3 (sometimes, is 4) entries are removed, but user information isn't really reloaded and I doubt it is really removed from cache (I have the user in a passwd-file and information used by imap processes is still the old one, no the new one, changed before the flush)
Works in my tests.
Is this cache the same than the user information cache?
The parameter of the user I want to change is his quota, so I have modified quota value in my ldap diretory, then I run:
doveadm auth cache flush <myuser>
in the logs I get:Sep 18 08:47:13 myotis34 dovecot: auth: Debug: master in: CACHE-FLUSH#0111#011<myuser>
now I ask for user information with:doveadm user <myuser>
and this is what I get from logs:Sep 18 08:47:19 myotis34 dovecot: auth: Debug: master in: USER#0111#011<myuser>#011service=doveadm
Sep 18 08:47:19 myotis34 dovecot: auth: Debug: prefetch(<myuser>): passdb didn't return userdb entries, trying the next userdb
Sep 18 08:47:19 myotis34 dovecot: auth: Debug: userdb-cache(<myuser>): hit: <myuser>#011home=/home/otros/99/151299#011uid=151299#011gid=405
Sep 18 08:47:19 myotis34 dovecot: auth: Debug: master out: USER#0111#011<myuser>#011home=/home/otros/99/151299#011uid=151299#011gid=405
Sep 18 08:47:41 myotis34 dovecot: auth: Debug: master in: USER#0111#011<myuser>#011service=doveadm
Sep 18 08:47:41 myotis34 dovecot: auth: Debug: prefetch(<myuser>): passdb didn't return userdb entries, trying the next userdb
Sep 18 08:47:41 myotis34 dovecot: auth: Debug: userdb-cache(<myuser>): hit: <myuser>#011home=/home/otros/99/151299#011uid=151299#011gid=405
Sep 18 08:47:41 myotis34 dovecot: auth: Debug: master out: USER#0111#011<myuser>#011home=/home/otros/99/151299#011uid=151299#011gid=405
As you can see in the third message, it is still using information from userdb cache
On 18.9.2012, at 9.59, Angel L. Mateo wrote:
So I'm running this command. Whenever I run it, I get the message that 3 (sometimes, is 4) entries are removed, but user information isn't really reloaded and I doubt it is really removed from cache (I have the user in a passwd-file and information used by imap processes is still the old one, no the new one, changed before the flush)
Works in my tests.
Is this cache the same than the user information cache?
Yes.
The parameter of the user I want to change is his quota, so I have modified quota value in my ldap diretory, then I run:
doveadm auth cache flush <myuser>
What is your doveconf -n output and the dovecot-ldap.conf contents? Is <myuser> with or without @domain? Also try this:
doveadm auth cache flush foo # make sure it isn't there doveadm user foo doveadm auth cache flush foo
Does the second flush return 1 or 0 entries? If 0, then there's a problem. If 1, then it really should have worked.
You could try also if disabling userdb prefetch makes any difference. And if you still have multiple userdb try with only one.
El 18/09/12 18:31, Timo Sirainen escribió:
On 18.9.2012, at 9.59, Angel L. Mateo wrote:
So I'm running this command. Whenever I run it, I get the message that 3 (sometimes, is 4) entries are removed, but user information isn't really reloaded and I doubt it is really removed from cache (I have the user in a passwd-file and information used by imap processes is still the old one, no the new one, changed before the flush)
Works in my tests.
Is this cache the same than the user information cache?
Yes.
The parameter of the user I want to change is his quota, so I have modified quota value in my ldap diretory, then I run:
doveadm auth cache flush <myuser>
What is your doveconf -n output and the dovecot-ldap.conf contents? Is <myuser> with or without @domain? Also try this:
doveadm auth cache flush foo # make sure it isn't there doveadm user foo doveadm auth cache flush foo
Does the second flush return 1 or 0 entries? If 0, then there's a problem. If 1, then it really should have worked.
You could try also if disabling userdb prefetch makes any difference. And if you still have multiple userdb try with only one.
I have made the test in my test server (it has no real activity). In this server, user entry is refreshed correctly. But the same test in my production servers fails.
I have checked (in the production one) that the second flush delete entries (in fact, 2, not 1):
amateo_adm@myotis31:/etc/dovecot/conf.d$ sudo doveadm auth cache flush angel.luis 2 cache entries flushed amateo_adm@myotis31:/etc/dovecot/conf.d$ sudo doveadm user angel.luis userdb: angel.luis home : /home/alumnos/46/113246 uid : 113246 gid : 1001 quota_rule: *:storage=400M amateo_adm@myotis31:/etc/dovecot/conf.d$ sudo doveadm auth cache flush angel.luis 2 cache entries flushed amateo_adm@myotis31:/etc/dovecot/conf.d$ sudo doveadm user angel.luis userdb: angel.luis home : /home/alumnos/46/113246 uid : 113246 gid : 1001 quota_rule: *:storage=400M
but quota information is not reloaded from ldap server.
I have also checked my ldap server, and dovecot is not performing any search operation for the user after flushing him from the cache.
I have attached my doveconf -n. In my ldap configuration I have:user_attrs = irisMailbox=mail,homeDirectory=home,uidNumber=uid,gidNumber=gid,quota=quota_rule pass_attrs = irisMailbox=userdb_mail,userPassword=password,homeDirectory=userdb_home,uidNumber=userdb_uid,gidNumber=userdb_gid,quota=userdb_quota_rule
and I have check that my test and production server has the same configuration (but client_limit and number of processes).
Any idea?(I forgot the attach)El 19/09/12 11:15, Angel L. Mateo escribió:
El 18/09/12 18:31, Timo Sirainen escribió:
On 18.9.2012, at 9.59, Angel L. Mateo wrote:
So I'm running this command. Whenever I run it, I get themessage that 3 (sometimes, is 4) entries are removed, but user information isn't really reloaded and I doubt it is really removed from cache (I have the user in a passwd-file and information used by imap processes is still the old one, no the new one, changed before the flush)
Works in my tests.
Is this cache the same than the user information cache?Yes.
The parameter of the user I want to change is his quota, so Ihave modified quota value in my ldap diretory, then I run:
doveadm auth cache flush <myuser>
What is your doveconf -n output and the dovecot-ldap.conf contents? Is <myuser> with or without @domain? Also try this:
doveadm auth cache flush foo # make sure it isn't there doveadm user foo doveadm auth cache flush foo
Does the second flush return 1 or 0 entries? If 0, then there's a problem. If 1, then it really should have worked.
You could try also if disabling userdb prefetch makes any difference. And if you still have multiple userdb try with only one.
I have made the test in my test server (it has no real activity).In this server, user entry is refreshed correctly. But the same test in my production servers fails.
I have checked (in the production one) that the second flush deleteentries (in fact, 2, not 1):
amateo_adm@myotis31:/etc/dovecot/conf.d$ sudo doveadm auth cache flush angel.luis 2 cache entries flushed amateo_adm@myotis31:/etc/dovecot/conf.d$ sudo doveadm user angel.luis userdb: angel.luis home : /home/alumnos/46/113246 uid : 113246 gid : 1001 quota_rule: *:storage=400M amateo_adm@myotis31:/etc/dovecot/conf.d$ sudo doveadm auth cache flush angel.luis 2 cache entries flushed amateo_adm@myotis31:/etc/dovecot/conf.d$ sudo doveadm user angel.luis userdb: angel.luis home : /home/alumnos/46/113246 uid : 113246 gid : 1001 quota_rule: *:storage=400M
but quota information is not reloaded from ldap server. I have also checked my ldap server, and dovecot is not performingany search operation for the user after flushing him from the cache.
I have attached my doveconf -n. In my ldap configuration I have:user_attrs = irisMailbox=mail,homeDirectory=home,uidNumber=uid,gidNumber=gid,quota=quota_rule
pass_attrs = irisMailbox=userdb_mail,userPassword=password,homeDirectory=userdb_home,uidNumber=userdb_uid,gidNumber=userdb_gid,quota=userdb_quota_rule
and I have check that my test and production server has the sameconfiguration (but client_limit and number of processes).
Any idea?
Hello,
I've been doing some more tests with this problem I have (I need to solve it because I'm planning to migrate mailboxes from maildir to mdbox and I need to change mail_location for my users without rebooting the server).
I think I have found the source of the problem, although I don't know how to fix it. The problem is that I have different results if I ask for user information with just the login or with the whole email:
root@myotis30:/etc/dovecot/conf.d# doveadm user angel.luis@um.es userdb: angel.luis@um.es mail : mdbox:/home/alumnos/46/113246/mdbox:INDEX=/var/indexes/mdbox/angel.luis home : /home/alumnos/46/113246 uid : 113246 gid : 1001 quota_rule: *:storage=10G root@myotis30:/etc/dovecot/conf.d# doveadm user angel.luis userdb: angel.luis home : /home/alumnos/46/113246 uid : 113246 gid : 1001 quota_rule: *:storage=10G
I guess I'm using different keys depending the user database used. I have configured three user databases, one for master-password, one for a ldap server and the other with pam (I need it because my webmail users authenticate in my SSO system through PAM).
This is my config:passdb { driver = passwd-file master = yes args = /etc/dovecot/master-users
# Unless you're using PAM, you probably still want the destination user to # be looked up from passdb that it really exists. pass=yes does that. pass = yes }
passdb { driver = pam # [session=yes] [setcred=yes] [failure_show_msg=yes] [max_requests=<n>] # [cache_key=<key>] [<service name>] #args = dovecot args = session=yes cache_key=%n dovecot }
passdb { driver = ldap
# Path for LDAP configuration file, see example-config/dovecot-ldap.conf.ext args = /etc/dovecot/dovecot-ldap.conf.ext }
# "prefetch" user database means that the passdb already provided the
# needed information and there's no need to do a separate userdb lookup.
#
userdb { driver = ldap args = /etc/dovecot/dovecot-ldap.conf.ext
# Default fields can be used to specify defaults that LDAP may override #default_fields = home=/home/virtual/%u }
In my ldap configuration, I have a filter that looks for the uid of the user or the hole email:
user_filter = (&(<other requirements>)(|(uid=%u)(mail=%u)))
I need this, because I have users that authenticate with just his/her login, not the complete email address.
How can I unify those entries, so they use always just the login as key?El 18/09/12 18:31, Timo Sirainen escribió:
On 18.9.2012, at 9.59, Angel L. Mateo wrote:
So I'm running this command. Whenever I run it, I get the message that 3 (sometimes, is 4) entries are removed, but user information isn't really reloaded and I doubt it is really removed from cache (I have the user in a passwd-file and information used by imap processes is still the old one, no the new one, changed before the flush)
Works in my tests.
Is this cache the same than the user information cache?
Yes.
The parameter of the user I want to change is his quota, so I have modified quota value in my ldap diretory, then I run:
doveadm auth cache flush <myuser>
What is your doveconf -n output and the dovecot-ldap.conf contents? Is <myuser> with or without @domain? Also try this:
doveadm auth cache flush foo # make sure it isn't there doveadm user foo doveadm auth cache flush foo
Does the second flush return 1 or 0 entries? If 0, then there's a problem. If 1, then it really should have worked.
You could try also if disabling userdb prefetch makes any difference. And if you still have multiple userdb try with only one.
On 2.10.2012, at 11.41, Angel L. Mateo wrote:
I've been doing some more tests with this problem I have (I need to solve it because I'm planning to migrate mailboxes from maildir to mdbox and I need to change mail_location for my users without rebooting the server).
You could flush the whole cache also.
I think I have found the source of the problem, although I don't know how to fix it. The problem is that I have different results if I ask for user information with just the login or with the whole email:
Flush both the user and user@domain entries?
El 02/10/12 22:18, Timo Sirainen escribió:
On 2.10.2012, at 11.41, Angel L. Mateo wrote:
I've been doing some more tests with this problem I have (I need to solve it because I'm planning to migrate mailboxes from maildir to mdbox and I need to change mail_location for my users without rebooting the server).
You could flush the whole cache also.
Oh... I was so obfuscated trying to expire just the user that I forgot I could flush the whole cache :-(
I think I have found the source of the problem, although I don't know how to fix it. The problem is that I have different results if I ask for user information with just the login or with the whole email:
Flush both the user and user@domain entries?
Yes, I could do this, but why there are entries with user and user@domain?, because I have three user databases:
- master password: it is not normally used
- pam: I have the cache_key=%n on it
- ldap: I don't know to configure cache_key (I tried args = cache_key=%n /etc/dovecot/dovecot-ldap.conf.ext but it didn't work)
On 3.10.2012, at 9.25, Angel L. Mateo wrote:
I think I have found the source of the problem, although I don't know how to fix it. The problem is that I have different results if I ask for user information with just the login or with the whole email:
Flush both the user and user@domain entries?
Yes, I could do this, but why there are entries with user and user@domain?, because I have three user databases:
- master password: it is not normally used
- pam: I have the cache_key=%n on it
- ldap: I don't know to configure cache_key (I tried args = cache_key=%n /etc/dovecot/dovecot-ldap.conf.ext but it didn't work)
For LDAP the cache_key is figured out automatically based on the used %variables. You can't override the cache key. The only way to make it work would be to change the LDAP query to use only %n and no %u/%d (which I guess would be possible by checking for %n@* ?)
participants (2)
-
Angel L. Mateo
-
Timo Sirainen