3
1
User database extra fields
4
2
==========================
7
A user database lookup typically returns >>uid, gid, home and mail<< fields. Other possibilities are:
9
* *nice*: Set the mail process's priority to be the given value.
10
* *chroot*: Chroot to given directory. Overrides 'mail_chroot' setting in 'dovecot.conf'.
11
* *system_user*: If this is given, the user's groups are read from '/etc/group' (or wherever NSS is configured to taken them from).
12
* It's possible to override settings from 'dovecot.conf'.
13
These fields can be returned the exact same way as uid, gid, home and mail fields. Below are examples for some user databases.
4
A user database lookup typically returns <uid, gid, home and mail>
5
[UserDatabase.txt] fields. Other possibilities are:
7
* *nice*: Set the mail process's priority to be the given value.
8
* *chroot*: Chroot to given directory. Overrides 'mail_chroot' setting in
10
* *system_user*: If this is given, the user's groups are read from
11
'/etc/group' (or wherever NSS is configured to taken them from).
12
* It's possible to override settings from 'dovecot.conf'.
14
These fields can be returned the exact same way as uid, gid, home and mail
15
fields. Below are examples for some user databases.
16
17
Overriding settings
20
Most commonly settings are overridden from plugin section. For example if your plugin section has 'quota=maildir:storage=1024' value and the userdb lookup returns 'quota=maildir:storage=2048', the original quota setting gets overridden. In fact if the lookup always returns a quota field, there's no point in having the quota setting in plugin section at all, because it always gets overridden anyway.
21
To understand how imap and pop3 processes see their settings, it may be helpful to know how Dovecot internally passes them:
23
1. All actual settings are first placed into environment variables. The environment name may be different than the setting name.
24
2. Everything inside plugin section is placed into environment variables. >>%variables<< in values are expanded first.
25
3. Everything from userdb lookup is placed into environment variables.
26
4. At this point if >>post-login scripting is used<<, it may modify the environment if wanted.
27
5. imap/pop3 reads the settings from environment variables. It doesn't matter how they got there, they're read the exact same way.
28
At each step if the environment variable already exists, it's replaced with the new value (ie. the setting is overridden).
31
* If you want to override a setting from userdb you must use its environment name, not the setting name. See >>PostLoginScripting<< for how to find out what the environment is named.
32
* Boolean settings are checked simply by the environment variables' existence and their values are ignored. For example having a userdb lookup return 'mmap_disable=no' would still enable it.
20
Most commonly settings are overridden from plugin section. For example if your
21
plugin section has 'quota=maildir:storage=1024' value and the userdb lookup
22
returns 'quota=maildir:storage=2048', the original quota setting gets
23
overridden. In fact if the lookup always returns a quota field, there's no
24
point in having the quota setting in plugin section at all, because it always
25
gets overridden anyway.
27
To understand how imap and pop3 processes see their settings, it may be helpful
28
to know how Dovecot internally passes them:
30
1. All actual settings are first placed into environment variables. The
31
environment name may be different than the setting name.
32
2. Everything inside plugin section is placed into environment variables.
33
<%variables> [Variables.txt] in values are expanded first.
34
3. Everything from userdb lookup is placed into environment variables.
35
4. At this point if <post-login scripting is used> [PostLoginScripting.txt],
36
it may modify the environment if wanted.
37
5. imap/pop3 reads the settings from environment variables. It doesn't matter
38
how they got there, they're read the exact same way.
40
At each step if the environment variable already exists, it's replaced with the
41
new value (ie. the setting is overridden).
45
* If you want to override a setting from userdb you must use its environment
46
name, not the setting name. See<PostLoginScripting.txt> for how to find out
47
what the environment is named.
48
* Boolean settings are checked simply by the environment variables' existence
49
and their values are ignored. For example having a userdb lookup return
50
'mmap_disable=no' would still enable it.
46
60
---%<-------------------------------------------------------------------------
47
61
# NOTE: \ line splitting works only with v1.1
48
62
user_query = SELECT home, uid, gid, \
50
64
FROM users WHERE userid = '%u'
51
65
---%<-------------------------------------------------------------------------
60
---%<-------------------------------------------------------------------------
61
user_attrs = homeDirectory=home,uidNumber=uid,gidNumber=gid,quotaDovecot=quota,mail_plugins
62
---%<-------------------------------------------------------------------------
72
---%<-------------------------------------------------------------------------
74
homeDirectory=home,uidNumber=uid,gidNumber=gid,quotaDovecot=quota,mail_plugins
75
---%<-------------------------------------------------------------------------
71
---%<-------------------------------------------------------------------------
72
user:{plain}pass:1000:1000::/home/user::userdb_quota=maildir:storage=102400 mail_plugins=quota,imap_quota
73
---%<-------------------------------------------------------------------------
75
(This file was created from the wiki on 2007-12-11 04:42)
80
---%<-------------------------------------------------------------------------
81
user:{plain}pass:1000:1000::/home/user::userdb_quota=maildir:storage=102400
82
mail_plugins=quota,imap_quota
83
---%<-------------------------------------------------------------------------
85
(This file was created from the wiki on 2008-06-20 04:42)
added
removed
doc/wiki/UserDatabase.ExtraFields.txt
