Hi,
Are configurations (with separate formats per namespace) - such as ...
namespace {
type = shared
list = children
inbox = no
separator = /
subscriptions = no
prefix = shared1/%%n/
location = maildir:/var/mail1/%%n/
}
namespace {
type = shared
list = children
inbox = no
separator = /
subscriptions = no
prefix = shared2/%%n/
location = mdbox:/var/mail2/%%n/
}
With separate userdbs serving part of the users with maildirs in /var/mail1/
and the other part with mdboxes in /var/mail2
... valid in dovecot ?
To be more precise:
1) Is current version dovecot expected to work with configuration as above ?
E.g. if some user's mail location returned from userdb doesn't match
location/format from one of the above namespaces - would it be ignored for it
? A very old version of dovecot I could check quickly (2.1.7) was segfaulting
(imap processes) all the time with this kind of config. While I'll be
upgrading it and the whole system to modern versions, I'm wondering if this
kind of thing is formally allowed at all.
An interesting variation of the above setup I tested - with the second
namespace "un-variabled" and pointing to single user (with matching
passwd-file returning that user) managed to work somehow - but the user itself
was still created on the fly for the 1st namespace - having just a directory
with empty dovecot-acl-list file. This essentially seemed to have worked like
a typical public profile (shared acl db didn't seem to be used either)
2) For shared namespace with variables, would overriding shared namespace
location in userdb query work ? For example if we had single namespace such as
the first one (maildir) above with explicit share1 name, and then in userdb
for some users:
userdb_namespace/share1/location=mdbox:/var/mail2/some_user_name
Would that override a shared namespace pattern on per user basis correctly ?
3) Is there perhaps a way to constraint which userdbs are considered per which
shared namespace ?
4) Not strictly related to the above, but in LDAP part of documentation -
namely http://wiki2.dovecot.org/AuthDatabase/LDAP/Userdb - why
user_attrs = \
=home=%{ldap:homeDirectory}, \
=uid=%{ldap:uidNumber}, \
=gid=%{ldap:gidNumber}
instead of
user_attrs = \
homeDirectory=home, \
uidNumber=uid, \
gidNumber=gid
Do both are equivalent with differet syntax (opening the way for templates for
%{} based syntax), or are there some subtle differences between those ? (aside
later example with 'attr=' instead of just '=').
Would this kind of syntax also be correct for pass_attrs, such as:
pass_attrs = \
=password=%{ldap:uid}, \
=userdb_home=%{ldap:homeDirectory}
Yeah, that's valid configuration. As long as they have unique prefix. Aki> On January 2, 2017 at 5:58 PM Michal Soltys <soltys at ziu.info> wrote: > > > Hi, > > Are configurations (with separate formats per namespace) - such as ... > > namespace { > type = shared > list = children > inbox = no > separator = / > subscriptions = no > prefix = shared1/%%n/ > location = maildir:/var/mail1/%%n/ > } > > namespace { > type = shared > list = children > inbox = no > separator = / > subscriptions = no > prefix = shared2/%%n/ > location = mdbox:/var/mail2/%%n/ > } > > With separate userdbs serving part of the users with maildirs in /var/mail1/ > and the other part with mdboxes in /var/mail2 > > ... valid in dovecot ? > > To be more precise: > > 1) Is current version dovecot expected to work with configuration as above ? > E.g. if some user's mail location returned from userdb doesn't match > location/format from one of the above namespaces - would it be ignored for it > ? A very old version of dovecot I could check quickly (2.1.7) was segfaulting > (imap processes) all the time with this kind of config. While I'll be > upgrading it and the whole system to modern versions, I'm wondering if this > kind of thing is formally allowed at all. > > An interesting variation of the above setup I tested - with the second > namespace "un-variabled" and pointing to single user (with matching > passwd-file returning that user) managed to work somehow - but the user itself > was still created on the fly for the 1st namespace - having just a directory > with empty dovecot-acl-list file. This essentially seemed to have worked like > a typical public profile (shared acl db didn't seem to be used either) > > 2) For shared namespace with variables, would overriding shared namespace > location in userdb query work ? For example if we had single namespace such as > the first one (maildir) above with explicit share1 name, and then in userdb > for some users: > > userdb_namespace/share1/location=mdbox:/var/mail2/some_user_name > > Would that override a shared namespace pattern on per user basis correctly ? > > 3) Is there perhaps a way to constraint which userdbs are considered per which > shared namespace ? > > 4) Not strictly related to the above, but in LDAP part of documentation - > namely http://wiki2.dovecot.org/AuthDatabase/LDAP/Userdb - why > > user_attrs = \ > =home=%{ldap:homeDirectory}, \ > =uid=%{ldap:uidNumber}, \ > =gid=%{ldap:gidNumber} > > instead of > > user_attrs = \ > homeDirectory=home, \ > uidNumber=uid, \ > gidNumber=gid > > Do both are equivalent with differet syntax (opening the way for templates for > %{} based syntax), or are there some subtle differences between those ? (aside > later example with 'attr=' instead of just '='). > > Would this kind of syntax also be correct for pass_attrs, such as: > > pass_attrs = \ > =password=%{ldap:uid}, \ > =userdb_home=%{ldap:homeDirectory}
On January 2, 2017 at 5:58 PM Michal Soltys <soltys at ziu.info> wrote:>> >> >> Hi, >> >> Are configurations (with separate formats per namespace) - such as ... >> >> namespace { >> type = shared >> list = children >> inbox = no >> separator = / >> subscriptions = no >> prefix = shared1/%%n/ >> location = maildir:/var/mail1/%%n/ >> } >> >> namespace { >> type = shared >> list = children >> inbox = no >> separator = / >> subscriptions = no >> prefix = shared2/%%n/ >> location = mdbox:/var/mail2/%%n/ >> } >> >> With separate userdbs serving part of the users with maildirs in /var/mail1/ >> and the other part with mdboxes in /var/mail2 >> >> ... valid in dovecot ? >> >> To be more precise: >> >> 1) Is current version dovecot expected to work with configuration as above ? >> E.g. if some user's mail location returned from userdb doesn't match >> location/format from one of the above namespaces - would it be ignored for it >> ? A very old version of dovecot I could check quickly (2.1.7) was segfaulting >> (imap processes) all the time with this kind of config. While I'll be >> upgrading it and the whole system to modern versions, I'm wondering if this >> kind of thing is formally allowed at all. >> >> An interesting variation of the above setup I tested - with the second >> namespace "un-variabled" and pointing to single user (with matching >> passwd-file returning that user) managed to work somehow - but the user itself >> was still created on the fly for the 1st namespace - having just a directory >> with empty dovecot-acl-list file. This essentially seemed to have worked like >> a typical public profile (shared acl db didn't seem to be used either) >>> On 2017-01-02 19:21, Aki Tuomi wrote: >> Yeah, that's valid configuration. As long as they have unique prefix. >> >> Aki >>Well, I retested it under 2.2.27 - and the behaviour is essentially the same (segfaults). Below is the simplified configuration under which it can be observed with 2 passwd-files (each with 1 user, passwords removed to save space) passwd-file local-mdbox: nmm:{SHA256}<cut>:::nmm:/var/mail2/nmm::userdb_mail=mdbox:/var/mail2/nmm userdb_home=/var/mail2/nmm passwd-file local-maildir: msl:{SHA256}<cut>:::msl:/var/mail/msl::userdb_mail=maildir:/var/mail/msl userdb_home=/var/mail/msl Both of the accounts have some mails/subfolders, nmm is sharing some of its contents to msl. doveconf -n (note thare are some leftovers from old configuration - particularly weird last/first uids and mail_uid using dovecot user - but those are not relevant to the issue): # 2.2.27 (c0f36b0): /etc/dovecot/dovecot.conf # OS: Linux 4.8.13-1-ARCH x86_64 ext4 auth_debug = yes auth_mechanisms = plain login disable_plaintext_auth = no first_valid_gid = 8 first_valid_uid = 105 last_valid_gid = 8 last_valid_uid = 105 listen = * log_path = /var/log/dovecot.log mail_access_groups = mail mail_debug = yes mail_gid = mail mail_location = maildir:/var/mail/%n mail_plugins = acl mail_uid = dovecot namespace { inbox = yes location = prefix = separator = / type = private } namespace share1 { inbox = no list = children location = maildir:%%h prefix = shared1/%%n/ separator = / subscriptions = no type = shared } namespace share2 { inbox = no list = children location = mdbox:%%h prefix = shared2/%%n/ separator = / subscriptions = no type = shared } passdb { args = username_format=%n /etc/dovecot/local-maildir default_fields = userdb_uid=dovecot userdb_gid=mail driver = passwd-file } passdb { args = username_format=%n /etc/dovecot/local-mdbox default_fields = userdb_uid=dovecot userdb_gid=mail driver = passwd-file } plugin { acl = vfile acl_shared_dict = file:/var/mail/shared-database/shared-mailboxes.db } protocols = imap service auth { unix_listener auth-userdb { group = mail mode = 0660 user = dovecot } user = dovecot } service imap-login { inet_listener imap { port = 0 } user = dovecot } service imap { executable = /usr/lib/dovecot/imap } userdb { driver = prefetch } userdb { args = username_format=%n /etc/dovecot/local-maildir default_fields = uid=dovecot gid=mail driver = passwd-file } userdb { args = username_format=%n /etc/dovecot/local-mdbox default_fields = uid=dovecot gid=mail driver = passwd-file } protocol imap { mail_max_userip_connections = 100 mail_plugins = acl imap_acl } With the configuration and 2 passwd-files as above, all imap processes (when logged as user msl) constantly crash with segfaults. Replacing %%h by template such as /var/mail/%%n (as in my initial report) behaves the same way. Now - IF share1 namespace is commented out or removed - everything works fine (and msl sees content shared by nmm under shared2/nmm/ ). Similarly - if only one shared namespace uses variables and the other points directly to some user - no crashes then. Any ideas ? I can get systraces/cores (though the latter without debug symbols - but I can recompile if need be).