Dear Timo,
Thank you for your advice!
Am 08.02.2011 18:35, schrieb Timo Sirainen:
On 8.2.2011, at 17.23, Lukas Haase wrote:
[...]
I know, but the message is somehow "weird" since it says it is *currently* unsupported. However, it seems to me that it is not supported any more. Is this true? Is there a reason for this?
I'm pretty sure it never worked. I think in v1.0 it simply ignored the first uid=user. So you could probably just remove that.
Unfortunately not. I am really sure it worked in v1.0. For example:
# id luke uid=1000(luke) gid=100(users) groups=51683(family),25783(ssh_users),63315(projects),19580(multimedia),1019(data),51684(friends),100(users)
So luke's *primary* group is "users" but he is also member of the other groups (like "family").
An IMAP folder in my shared namespace has permissions as follows:
# ls -la /var/mail/shared [...] drwxrwx--- 5 root family 4096 Feb 8 22:53 .Family [...]
So the folder "Family" in the shared namespace is *not* accessible in the *default* configuration since the directory is not accessible by the group "users" but only by the group "family". And in the default configuration the groups are ignored by dovecot (except the primary group).
In Debian Lenny (dovecot 1.xx) I set "uid=system_user" in the "user_attrs" setting of my ldap config. According to the Wiki, this should read out the primary groups of the user contained in the LDAP field "uid". And this worked: I could access the folder.
Now I upgraded to Debian sequeeze (dovecot 1.2) and I get the mentioned error message. So I am somehow sure that it actually worked and was not just ignored.
Nevertheless, is there a way to overcome this issue? Can dovecot just read out the group membership from the "user" field of "pass_attrs"?
Another obvious solution would be to define a manual scheme with a manual attribute "uid_dovecot" and copy the value of "uid". But this seems to me like a using a sledgehammer method since it provides unnecessary redundancy in the LDAP tree (where the increased complexity might cause problems and inconsistencies) and requires defined a manual LDAP scheme.
Any solution would be greatly appreciated!
Best regads, Luke