[Dovecot] doveadm quota does not list all accounts
Hello,
I am running dovecot-2.0.13-1_128.el5 x86_64 RPM on CentOS 5.7.
All accounts are virtual, hosted on LDAP Server.
My problem is that the command:
doveadm quota get -Astopped listing all accounts. I think this problem started after I changed in LDAP lookup configuration from "scope = subtree" to "scope = onelevel", because it did not occur before (I did no other changes).
Now, the above command only lists 12 accounts. If I query for a particular user:
doveadm quota get -u userxthis works fine, but userx (and all users except those 12) is NOT listed when trying to display all users.
How can I run the above command without problems again?
Thanks in advance, Nick
Le 2011-12-15 23:00, Nikolaos Milas a écrit :
Hello,
I am running dovecot-2.0.13-1_128.el5 x86_64 RPM on CentOS 5.7.
All accounts are virtual, hosted on LDAP Server.
My problem is that the command:
doveadm quota get -A
stopped listing all accounts. I think this problem started after I changed in LDAP lookup configuration from "scope = subtree" to "scope = onelevel", because it did not occur before (I did no other changes).
Now, the above command only lists 12 accounts. If I query for a particular user:
doveadm quota get -u userx
this works fine, but userx (and all users except those 12) is NOT listed when trying to display all users.
How can I run the above command without problems again?
Thanks in advance, Nick
upgrade to the latest rpm i any problem with the last release
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x092164A7 gpg --keyserver pgp.mit.edu --recv-key 092164A7
http://urlshort.eu fakessh @ http://gplus.to/sshfake http://gplus.to/sshswilting http://gplus.to/john.swilting
On 16.12.2011, at 0.00, Nikolaos Milas wrote:
I am running dovecot-2.0.13-1_128.el5 x86_64 RPM on CentOS 5.7.
All accounts are virtual, hosted on LDAP Server.
My problem is that the command:
doveadm quota get -A
stopped listing all accounts. I think this problem started after I changed in LDAP lookup configuration from "scope = subtree" to "scope = onelevel", because it did not occur before (I did no other changes).
Can you try if changing it back helps? Or by running the same LDAP query using ldapsearch. Is there a reason why you changed the scope? (I'm not entirely sure what the LDAP schemes usually look like..)
Also to make sure the problem is listing instead of something quota related, list the users:
doveadm user '*'
On 20/12/2011 7:41 πμ, Timo Sirainen wrote:
Can you try if changing it back helps? Or by running the same LDAP query using ldapsearch. Is there a reason why you changed the scope? (I'm not entirely sure what the LDAP schemes usually look like..)
Hi Timo,
The same query, using ldapsearch (with the same binddn, same scope, same filter) returns 247 entries. The command is (all searches are against localhost - it's a local replication slave [openldap syncrepl consumer]):
/usr/local/openldap/bin/ldapsearch -x -W -vv -D "uid=authenticate,ou=System,dc=noa,dc=gr" -s one -b "ou=people,dc=example,dc=com" uid
doveadm user '*' and doveadm quota get -A both return the same 30 entries. I noticed that most of them are the LDAP user entries most recently updated in the LDAP Server (although it doesn't make any sense to me why it so happens).
I changed the scope in the search because my "ou=people,dc=example,dc=com" branch has some new sub-branches which contain user accounts not related with mailboxes and I didn't want them to be returned by the Dovecot search (they were useless).
I only now tried changing the scope back to subtree and again to onelevel and found that nothing changes (again 30 entries are returned).
For reference: /etc/dovecot/dovecot-userdb-ldap.conf (identical to dovecot-passdb-ldap.conf):
hosts = localhost tls = no base = ou=people, dc=example, dc=com scope = onelevel ldap_version = 3 dn = uid=authenticate,ou=System,dc=example,dc=com dnpass = secret auth_bind = yes user_filter = (uid=%u) pass_filter = (uid=%u) pass_attrs = uid=user,userPassword=password auth_bind_userdn = uid=%u,ou=people,dc=example,dc=com user_attrs = roomNumber=quota_rule=*:bytes=%$,uid=home=/home/vmail/%u
I have not managed yet to upgrade to 2.0.16 to see what happens...
Thank you for your assistance, Nick
On Tue, 2011-12-20 at 10:10 +0200, Nikolaos Milas wrote:
On 20/12/2011 7:41 πμ, Timo Sirainen wrote:
Can you try if changing it back helps? Or by running the same LDAP query using ldapsearch. Is there a reason why you changed the scope? (I'm not entirely sure what the LDAP schemes usually look like..)
The same query, using ldapsearch (with the same binddn, same scope, same filter) returns 247 entries. The command is (all searches are against localhost - it's a local replication slave [openldap syncrepl consumer]):
/usr/local/openldap/bin/ldapsearch -x -W -vv -D "uid=authenticate,ou=System,dc=noa,dc=gr" -s one -b "ou=people,dc=example,dc=com" uid
doveadm user '*' and doveadm quota get -A both return the same 30 entries. I noticed that most of them are the LDAP user entries most recently updated in the LDAP Server (although it doesn't make any sense to me why it so happens).
Try adding (objectClass=posixAccount) as filter in the ldapsearch. That's the default iterate_filter.
On 20/12/2011 10:15 πμ, Timo Sirainen wrote:
Try adding (objectClass=posixAccount) as filter in the ldapsearch. That's the default iterate_filter.
We've caught it! Only the returned (30) accounts include the posixAccount objectClass!
So I added in the LDAP setup:
iterate_filter = (objectClass=*)and now everything works fine!
Perhaps page: http://wiki2.dovecot.org/Tools/Doveadm/Altmove should explicitly state which is the default iterate_filter value, because in most LDAP applications (objectClass=*) is the default filter.
Thanks very much Timo.
All the best, Nick
On Tue, 2011-12-20 at 10:47 +0200, Nikolaos Milas wrote:
On 20/12/2011 10:15 πμ, Timo Sirainen wrote:
Try adding (objectClass=posixAccount) as filter in the ldapsearch. That's the default iterate_filter.
We've caught it! Only the returned (30) accounts include the posixAccount objectClass!
So I added in the LDAP setup:
iterate_filter = (objectClass=*)and now everything works fine!
Isn't that basically the same as an empty filter? What other types of objectClasses are there with user accounts? Perhaps the default should be changed to empty, or maybe to (uid=*)
On 20/12/2011 10:57 πμ, Timo Sirainen wrote:
On Tue, 2011-12-20 at 10:47 +0200, Nikolaos Milas wrote:
So I added in the LDAP setup:
iterate_filter = (objectClass=*)and now everything works fine! Isn't that basically the same as an empty filter? What other types of objectClasses are there with user accounts? Perhaps the default should be changed to empty, or maybe to (uid=*)
I agree that the default should be changed to empty.
There are various ObjectClasses available.
For example, for normal user accounts (physical persons) the main objectClass we use is inetOrgPerson (with its parents: organizationalPerson, person) and for other, non-personal accounts we use objectClass: account.
posixAccount objectClass is added to particular accounts when we want to assign further access privileges, mainly shell and FTP.
Best regards, Nick
On Tue, 2011-12-20 at 12:06 +0200, Nikolaos Milas wrote:
Isn't that basically the same as an empty filter? What other types of objectClasses are there with user accounts? Perhaps the default should be changed to empty, or maybe to (uid=*)
I agree that the default should be changed to empty.
But that also returns non-user results, like at least in my test setup it returns an organization and admin.
There are various ObjectClasses available.
For example, for normal user accounts (physical persons) the main objectClass we use is inetOrgPerson (with its parents: organizationalPerson, person) and for other, non-personal accounts we use objectClass: account.
So you can have Dovecot accounts that aren't "person"s?
Perhaps: iterate_filter = (uid=*)
On Tue, 2011-12-20 at 12:13 +0200, Timo Sirainen wrote:
I agree that the default should be changed to empty.
But that also returns non-user results, like at least in my test setup it returns an organization and admin. .. Perhaps: iterate_filter = (uid=*)
Actually, the current default iterate_filter is fine, if you look at the default pass/user filters:
#user_filter = (&(objectClass=posixAccount)(uid=%u)) #pass_filter = (&(objectClass=posixAccount)(uid=%u))
On 20/12/2011 12:15 μμ, Timo Sirainen wrote:
Perhaps: iterate_filter = (uid=*)
Actually, the current default iterate_filter is fine, if you look at the default pass/user filters:
#user_filter = (&(objectClass=posixAccount)(uid=%u)) #pass_filter = (&(objectClass=posixAccount)(uid=%u))
This means that default values for all these settings are compatible. I would say that it would be enough to explicitly state the default value for iterate_filter in the documentation.
I guess the filter uid=* might probably also return all entries, because in many cases uid is part of the DN, so it is included in all entries. But this is not always the case.
Nick
On 20/12/2011 10:57 πμ, Timo Sirainen wrote:
On Tue, 2011-12-20 at 10:47 +0200, Nikolaos Milas wrote:
So I added in the LDAP setup:
iterate_filter = (objectClass=*)and now everything works fine! Isn't that basically the same as an empty filter?
And I forgot to answer: Yes, (objectClass=*) is the same as an empty filter.
An empty filter defaults to: (objectClass=*)
Nick
I resend, because I forgot to change the true domain once and the previous message would appear to include inconsistencies...
Sorry for this...
On 20/12/2011 7:41 πμ, Timo Sirainen wrote:
Can you try if changing it back helps? Or by running the same LDAP query using ldapsearch. Is there a reason why you changed the scope? (I'm not entirely sure what the LDAP schemes usually look like..)
Hi Timo,
The same query, using ldapsearch (with the same binddn, same scope, same filter) returns 247 entries. The command is (all searches are against localhost - it's a local replication slave [openldap syncrepl consumer]):
/usr/local/openldap/bin/ldapsearch -x -W -vv -D "uid=authenticate,ou=System,dc=example,dc=com" -s one -b "ou=people,dc=example,dc=com" uid
doveadm user '*' and doveadm quota get -A both return the same 30 entries. I noticed that most of them are the LDAP user entries most recently updated in the LDAP Server (although it doesn't make any sense to me why it so happens).
I changed the scope in the search because my "ou=people,dc=example,dc=com" branch has some new sub-branches which contain user accounts not related with mailboxes and I didn't want them to be returned by the Dovecot search (they were useless).
I only now tried changing the scope back to subtree and again to onelevel and found that nothing changes (again 30 entries are returned).
For reference: /etc/dovecot/dovecot-userdb-ldap.conf (identical to dovecot-passdb-ldap.conf):
hosts = localhost tls = no base = ou=people, dc=example, dc=com scope = onelevel ldap_version = 3 dn = uid=authenticate,ou=System,dc=example,dc=com dnpass = secret auth_bind = yes user_filter = (uid=%u) pass_filter = (uid=%u) pass_attrs = uid=user,userPassword=password auth_bind_userdn = uid=%u,ou=people,dc=example,dc=com user_attrs = roomNumber=quota_rule=*:bytes=%$,uid=home=/home/vmail/%u
I have not managed yet to upgrade to 2.0.16 to see what happens...
Thank you for your assistance, Nick
participants (3)
-
ml
-
Nikolaos Milas
-
Timo Sirainen