[Dovecot] Configuration file changes
I was going to add support for "configuration groups", but got a bit stuck at how the logic is supposed to work. I think there could be different settings based on IP/port it's listening in, or based on given username.
I can't really describe how it would work, and I'm not entirely sure myself either :) Does this make sense:
# (default settings here) # if auth groups are defined here, they are included in all groups below
group 1.server.org { protocols = imap imaps pop3 pop3s ssl_cert_file = /etc/ssl/certs/server1.pem login_dir = /var/run/dovecot/login/server1 login { # common for imap/pop3 listen = 1.server.org } auth server1 { mechanisms = plain userdb = ldap /etc/ldap-server1.conf passdb = ldap /etc/ldap-server1.conf }
group admins { mail_full_filesystem_access = yes auth admins { mechanisms = plain userdb = passwd-file /etc/admins.passwd passdb = passwd-file /etc/admins.passwd } } }
# (any setting changes here would affect only new groups below, otherwise # the config file parsing would get difficult..)
group anonymous { protocols = imap ssl_disable = yes login_dir = /var/run/dovecot/login/anonymous login { listen = anonymous.server.org process_per_connection = no processes_count = 1 } auth anonymous { mechanisms = plain anonymous userdb = passwd-file /etc/anon.passwd passdb = passwd-file /etc/anon.passwd } }
I like the idea, but I don't realy under stand the example. what I'd like to see a default session in the config file and server specific part(s) in the config file. eg a different base dir for each server. or different userdb and passwd db for each server. since I can run different sub-server for each domain with different ldap search base and base_dir. it'd be very useful for me!:-)))
Timo Sirainen wrote:
I was going to add support for "configuration groups", but got a bit stuck at how the logic is supposed to work. I think there could be different settings based on IP/port it's listening in, or based on given username.
I can't really describe how it would work, and I'm not entirely sure myself either :) Does this make sense:
# (default settings here) # if auth groups are defined here, they are included in all groups below
group 1.server.org { protocols = imap imaps pop3 pop3s ssl_cert_file = /etc/ssl/certs/server1.pem login_dir = /var/run/dovecot/login/server1 login { # common for imap/pop3 listen = 1.server.org } auth server1 { mechanisms = plain userdb = ldap /etc/ldap-server1.conf passdb = ldap /etc/ldap-server1.conf }
group admins { mail_full_filesystem_access = yes auth admins { mechanisms = plain userdb = passwd-file /etc/admins.passwd passdb = passwd-file /etc/admins.passwd } } }
# (any setting changes here would affect only new groups below, otherwise # the config file parsing would get difficult..)
group anonymous { protocols = imap ssl_disable = yes login_dir = /var/run/dovecot/login/anonymous login { listen = anonymous.server.org process_per_connection = no processes_count = 1 } auth anonymous { mechanisms = plain anonymous userdb = passwd-file /etc/anon.passwd passdb = passwd-file /etc/anon.passwd } }
-- Levente "Si vis pacem para bellum!"
On Mon, 2003-06-30 at 23:28, Farkas Levente wrote:
I like the idea, but I don't realy under stand the example. what I'd like to see a default session in the config file and server specific part(s) in the config file. eg a different base dir for each server. or different userdb and passwd db for each server. since I can run different sub-server for each domain with different ldap search base and base_dir. it'd be very useful for me!:-)))
Well, that was kind of how the "group 1.server.org" was supposed to work. So that you could add 2.server.org etc. Like:
protocols = imap imaps
group server-a { login_dir = /var/run/dovecot/login/a login { listen = a.server.org } auth a { mechanisms = plain userdb = ldap /etc/ldap-a.conf passdb = ldap /etc/ldap-a.conf } }
group server-b { login_dir = /var/run/dovecot/login/b login { listen = b.server.org } auth b { mechanisms = plain userdb = ldap /etc/ldap-b.conf passdb = ldap /etc/ldap-b.conf } } ..etc..
as most people point out, it's better not to create subfolders under /var/run (at least with redhat) and it currently still not a god solution. anyway what was the group inside the group in the first example? and what was the anonymous?
Timo Sirainen wrote:
On Mon, 2003-06-30 at 23:28, Farkas Levente wrote:
I like the idea, but I don't realy under stand the example. what I'd like to see a default session in the config file and server specific part(s) in the config file. eg a different base dir for each server. or different userdb and passwd db for each server. since I can run different sub-server for each domain with different ldap search base and base_dir. it'd be very useful for me!:-)))
Well, that was kind of how the "group 1.server.org" was supposed to work. So that you could add 2.server.org etc. Like:
protocols = imap imaps
group server-a { login_dir = /var/run/dovecot/login/a login { listen = a.server.org } auth a { mechanisms = plain userdb = ldap /etc/ldap-a.conf passdb = ldap /etc/ldap-a.conf } }
group server-b { login_dir = /var/run/dovecot/login/b login { listen = b.server.org } auth b { mechanisms = plain userdb = ldap /etc/ldap-b.conf passdb = ldap /etc/ldap-b.conf } } ..etc..
-- Levente "Si vis pacem para bellum!"
On Tue, 2003-07-01 at 15:22, Farkas Levente wrote:
as most people point out, it's better not to create subfolders under /var/run (at least with redhat) and it currently still not a god solution.
It doesn't matter where you put the files, as long as different server groups have different login_dir.
anyway what was the group inside the group in the first example?
Well, those are where the logic is still somewhat messy in my head :) I think you would want to have groups which:
- Simply provide default settings for any subgroups without doing anything themselves:
group { protocols = imap # some IMAP defaults for a/b group server-a { ... } group server-b { ... } }
group { protocols = pop3 # different POP3 defaults for a/b group server-a { ... } group server-b { ... } }
- Are servers themselves, providing defaults for subgroups:
group main-server { # defaults login { listen = main.server.org } auth default { # ... } group debug-server { login { listen = debug.main.server.org auth_verbose = yes } # possibly a few other settings changed } }
- Belong to same server instance, but use different settings for different users:
group server { # ... auth default { mechanisms = plain userdb = ldap /etc/main-ldap.conf passdb = ldap /etc/main-ldap.conf } group power-users { # .. different settings for power-users auth power-users { mechanisms = plain userdb = ldap /etc/power-users-ldap.conf passdb = ldap /etc/power-users-ldap.conf } } group lusers { # .. different settings for lusers auth lusers { mechanisms = plain userdb = ldap /etc/lusers-ldap.conf passdb = ldap /etc/lusers-ldap.conf } } }
and what was the anonymous?
Nothing special. Just another server with different settings.
Oh, and the group name doesn't actually matter at all. You wouldn't even need to give it at all. I was also thinking that if group name wasn't given, that would mean that it's a dummy group (type 1 above) which shouldn't tried to be started.
On Tue, Jul 01, 2003 at 03:41:42PM +0300, Timo Sirainen wrote:
Simply provide default settings for any subgroups without doing anything themselves:
Are servers themselves, providing defaults for subgroups:
Belong to same server instance, but use different settings for different users:
Time to make an appeal.
One of the great advantages of Dovecot, currently, is ease of configuration. It's pretty straightforward, even though it's got a good bit of flexibility.
The examples that you give above (which I snipped) are ... kinda frightening. And it raises some questions about Yet Another Configuration Language and Parser.
So. If it's possible to define the configuration files as simple unix config files/property files (name value pairs), I say do that. Postfix manages pretty well with that, plus external maps. Uses more than one file, keeping the configuration in a directory.
If there will only be one file, with sections, maybe consider just using ini file style? Ugly, yes, but familiar.
If it's going to be heavily structured, as the example seemed to indicate, could you *please* consider using stuff designed to handle that sort of heavy structuring? *sigh* I realize that you hate XML, but it's starting to look like another markup format. Maybe look at YAML? If you're completely opposed to using that, then maybe try really, really hard to make it look as much like a Bind 8/9 named.conf file as possible?
I realize that there are some very complex setups that are going to need interesting kinds of work. It would be nice, though, if there were some fairly simple way of configuring them, something that scales up ... and down, so that relatively simple installations don't have to learn something as complex as sendmial.cf to bring up an imap server.
Amy!
Amelia A. Lewis amyzing {at} talsever.com I don't know that I ever wanted greatness, on its own. It seems rather like wanting to be an engineer, rather than wanting to design something, or wanting to be a writer, rather than wanting to write. It should be a by-product, not a thing in itself. Otherwise, it's just an ego trip. -- Merlin, son of Corwin, Prince of Chaos (Roger Zelazny)
On Tue, 2003-07-01 at 19:24, Amelia A Lewis wrote:
Time to make an appeal.
One of the great advantages of Dovecot, currently, is ease of configuration. It's pretty straightforward, even though it's got a good bit of flexibility.
The examples that you give above (which I snipped) are ... kinda frightening. And it raises some questions about Yet Another Configuration Language and Parser.
It's all actually only a few simple additions to current code, at least if I get the logic sensible (which I don't think it currently is).
Also you won't have to use those "group" groups at all. I probably won't even given an example of their use in dovecot-example.conf so it won't confuse people who don't need it.
The only visible change for most people will be just that login/auth group definitions would be inside { .. } which I think makes more sense than the current kludgy way.
I do plan to keep the config file as simple as possible for normal installations.
Amelia A Lewis wrote:
On Tue, Jul 01, 2003 at 03:41:42PM +0300, Timo Sirainen wrote:
Simply provide default settings for any subgroups without doing anything themselves:
Are servers themselves, providing defaults for subgroups:
Belong to same server instance, but use different settings for different users:
Time to make an appeal.
One of the great advantages of Dovecot, currently, is ease of configuration. It's pretty straightforward, even though it's got a good bit of flexibility.
The examples that you give above (which I snipped) are ... kinda frightening. And it raises some questions about Yet Another Configuration Language and Parser.
So. If it's possible to define the configuration files as simple unix config files/property files (name value pairs), I say do that. Postfix manages pretty well with that, plus external maps. Uses more than one file, keeping the configuration in a directory.
If there will only be one file, with sections, maybe consider just using ini file style? Ugly, yes, but familiar.
If it's going to be heavily structured, as the example seemed to indicate, could you *please* consider using stuff designed to handle that sort of heavy structuring? *sigh* I realize that you hate XML, but it's starting to look like another markup format. Maybe look at YAML? If you're completely opposed to using that, then maybe try really, really hard to make it look as much like a Bind 8/9 named.conf file as possible?
I realize that there are some very complex setups that are going to need interesting kinds of work. It would be nice, though, if there were some fairly simple way of configuring them, something that scales up ... and down, so that relatively simple installations don't have to learn something as complex as sendmial.cf to bring up an imap server.
I've to agree with the above. but at the same time I'd like to be able to configure more virtual servers. so let's keep it as simple as possible and be able to configure more server with one config file.
ps. I still not understand that 3 new config example...why there is group inside group. may be a concrate example...
-- Levente "Si vis pacem para bellum!"
On Tue, 2003-07-01 at 21:52, Farkas Levente wrote:
ps. I still not understand that 3 new config example...why there is group inside group. may be a concrate example...
The point is that (sub)groups always inherit settings from their parents. You could do everything (well, except the 3. case which I'm beginning to think isn't such a good idea anyway) without subgroups, but you might need to do more copy&pasting.
I think the previous "debug server" is good enough example. You might want to have 10 different virtual servers, plus each one listening in another port for debugging sessions. The debugging port would have all the same settings than the real server, except some debugging options enabled. You could create two root level groups for them, but you'd have to keep their settings duplicated. Or you could create a debug subgroup where you just override listening port and the few debug settings.
On Tue, 2003-07-01 at 15:41, Timo Sirainen wrote:
Or maybe this makes more sense: "group" means that is only groups some settings. It doesn't create a server. "server" creates a server.
- Simply provide default settings for any subgroups without doing anything themselves:
group imap { protocols = imap # some IMAP defaults for a/b server a { ... } server b { ... } }
group pop3 { protocols = pop3 # different POP3 defaults for a/b server a { ... } server b { ... } }
- Are servers themselves, providing defaults for subgroups:
server main-server { # defaults login { listen = main.server.org } auth default { # ... } server debug-server { login { listen = debug.main.server.org auth_verbose = yes } # possibly a few other settings changed } }
so what I do not understand:
- what the "group" means? why not just a simple {} pair?
- until no there wasn't any king of grouping eg. what can I write inside a login {} part? what is the server part ? etc... it seems to me a config file can become a big mass.
- in the 1. case server a is a union of all group where "server a" appear or???
everybody else understand it and just I'm so stupid?
Timo Sirainen wrote:
On Tue, 2003-07-01 at 15:41, Timo Sirainen wrote:
Or maybe this makes more sense: "group" means that is only groups some settings. It doesn't create a server. "server" creates a server.
- Simply provide default settings for any subgroups without doing anything themselves:
group imap { protocols = imap # some IMAP defaults for a/b server a { ... } server b { ... } }
group pop3 { protocols = pop3 # different POP3 defaults for a/b server a { ... } server b { ... } }
- Are servers themselves, providing defaults for subgroups:
server main-server { # defaults login { listen = main.server.org } auth default { # ... } server debug-server { login { listen = debug.main.server.org auth_verbose = yes } # possibly a few other settings changed } }
-- Levente "Si vis pacem para bellum!"
On Tue, 2003-07-01 at 22:16, Farkas Levente wrote:
so what I do not understand:
- what the "group" means? why not just a simple {} pair?
- until no there wasn't any king of grouping eg. what can I write inside a login {} part? what is the server part ? etc... it seems to me a config file can become a big mass.
- in the 1. case server a is a union of all group where "server a" appear or???
everybody else understand it and just I'm so stupid?
For me it's simpler and more structured... It could also minimize the actual size needed for a really cool config.
If you had ever worked with bind (dns) you'd recognize the syntax immediately but you don't have to add the semicolons.
Example: zone "0.0.127.in-addr.arpa" { type master; file "named.local"; };
group imap { protocols = imap # some IMAP defaults for a/b server a { ... } server b { ... } }
group pop3 { protocols = pop3 # different POP3 defaults for a/b server a { ... } server b { ... } }
How about protocol <protocol name> { protocol specific options } ?
Since i have some comments i'll be chipping in here.
- Are servers themselves, providing defaults for subgroups:
server main-server { # defaults login { listen = main.server.org }
or listen { comma-seperated-list }
auth default { # ... } server debug-server { login { listen = debug.main.server.org auth_verbose = yes
couldn't auth verbose be in a global or per server entry 'options { comma-seperated-list } ? or have i been playing to much with bind?
} # possibly a few other settings changed
} }
All-in-all i like the C like syntax and i find it more *nix than var = value. (been using to many old deamons it seems... =))
PS. Hi Emma, you show up everywhere except arcnet =) DS.
-- Ian Kumlien pomac@vapor.com
On Tue, 2003-07-01 at 23:16, Farkas Levente wrote:
so what I do not understand:
- what the "group" means? why not just a simple {} pair?
Well, it's just the syntax.. I think simple {} would be less readable.
- until no there wasn't any king of grouping eg. what can I write inside a login {} part? what is the server part ? etc... it seems to me a config file can become a big mass.
Currently there's:
login = imap login_executable = /usr/libexec/dovecot/imap-login login_user = dovecot login_process_size = 16 ..etc..
login = pop3 login_executable = /usr/libexec/dovecot/pop3-login .. you could override any other login_* settings here for pop3..
"login {}" would simply replace this with:
login imap { executable = /usr/libexec/dovecot/imap-login user = dovecot process_size = 16 }
login pop3 { executable = /usr/libexec/dovecot/pop3-login }
Although I'm still not really sure how this would work either. Currently the settings in login group you defined first (imap by default) are used as defaults for the second login group (pop3). That's kind of messy I think..
Maybe I should completely drop the login group and rather make protocol groups. Something like:
# settings here would be global for both imap and pop3, but nothing # would stop you from overriding them inside imap/pop3 group. login_user = dovecot
imap { login_executable = /usr/libexec/dovecot/imap-login login_process_size = 16 default_mail_env = maildir:~/Maildir }
pop3 { login_executable = /usr/libexec/dovecot/pop3-login login_process_size = 16 default_mail_env = maildir:~/Maildir:INDEX=MEMORY }
- in the 1. case server a is a union of all group where "server a" appear or???
Um. No. There was 4 different servers. Two IMAP servers, two POP3 servers. Each one listening in different address, each one having separate settings. The groups around them were used only to provide some common settings for the servers under it.
everybody else understand it and just I'm so stupid?
I don't know, it seems quite clear to me :) The basic idea should be this:
# default setting for everything that is defined below: default_mail_env = /var/mail/%u
server { # this server uses the default_mail_env above listen = a.server.org }
server { listen = b.server.org # here we override the default_mail_env. it's used only by this server default_mail_env = ~/Maildir }
group { # this is used for the two servers defined below default_mail_env = maildir:~/Maildir:INDEX=MEMORY server { listen = c.server.org } server { listen = d.server.org } }
server { # default_mail_env is again the /var/mail/%u which was defined in # root level listen = e.server.org }
So most of the settings wouldn't belong to any group. You can define them in the root level which means they're global. You can override globals inside groups. You can override group settings in subgroups. etc.
I'm not sure if I should allow naming the groups/servers/etc. They don't really matter, but they might be useful for statistics and error messages.
Here's two full configuration files attached.
Yes, protocol groups are a good idea. No more login groups. :) Neither of attached confs includes any "group" groups. I didn't bother to write dovecot-complex.conf yet..
Although I'm still not really sure how this would work either. Currently the settings in login group you defined first (imap by default) are used as defaults for the second login group (pop3). That's kind of messy I think..
Maybe I should completely drop the login group and rather make protocol groups. Something like:
(etc)
Perhaps some of the confusion is that it looks like you are using groups as a way both to encapsulate a group of settings and as a way to override inheritence of global settings. While those things are similar it's hard to generalize them by way of nested statements.
On the other hand I could be all wet :-)
(Somebody mentioned BIND9, but it looks more like you have been reading innfeed conf files. Bind9 configs are completely block oriented- innfeed confs have the peculiar line-oriented commands with block encapsulations).
At any rate perhaps a different way to accomplish parameter grouping would be to define templates and invoke those templates within scoped declarations, e.g.:
template standard { login_process_size = 16 login_process_count = 3 first_valid_uid = 100 last_valid_gid = 0 }
template wide-open { like standard first_valid_uid = 0 }
server a { like standard // nested reference to another template imap_listen a.b.c.d ... }
server b { like wide-open imap_listen e.f.g.h }
I could imagine implementing a "template" as a set of context-free tag/value pairs. When invoked (e.g. via "like") the parser would simply note the reference to the template, and eventually parse the tag/value pairs when the scope is closed, applying those that had not already been specifically set.
This may not be what you were thinking about, in which case, you can ignore it...
-mm-
On Wed, 2003-07-02 at 01:44, Mark E. Mallett wrote:
Perhaps some of the confusion is that it looks like you are using groups as a way both to encapsulate a group of settings and as a way to override inheritence of global settings. While those things are similar it's hard to generalize them by way of nested statements.
Yes .. Well, currently there's only auth group which encapsulates settings. Although it also allows overriding global settings :) That's a bit messy. You have to be able to define multiple auth processes - how would you show that they work differently? Another similiar thing is namespace configuration which I'll add later.
At any rate perhaps a different way to accomplish parameter grouping would be to define templates and invoke those templates within scoped declarations, e.g.:
Ah, yes :) That could be better. More powerful and probably easier to understand as well.
I could imagine implementing a "template" as a set of context-free tag/value pairs. When invoked (e.g. via "like") the parser would simply note the reference to the template, and eventually parse the tag/value pairs when the scope is closed, applying those that had not already been specifically set.
It probably should also be possible to add some subgroups in it .. Such as:
template modular_imap { protocol imap { mail_use_modules = yes } }
server a { like modular_imap }
Anyway, I think we'd still need to have everything default to root-level definitions. So that I wouldn't need to add "template standard {" to beginning of config file. And add "like standard" to every server definition. Also good for backwards compatibility..
But template certainly replaces the old "group".
Timo Sirainen tss@iki.fi writes:
I was going to add support for "configuration groups", but got a bit stuck at how the logic is supposed to work. I think there could be different settings based on IP/port it's listening in, or based on given username.
I can't really describe how it would work, and I'm not entirely sure myself either :) Does this make sense:
One thing that I like about Courier components is its "sysconftool" approach that allows to add or remove parameters/examples/defaults to the configuration file as the software changes. If the concept supported rewriting the configuration file, without losing user customizations, but adding new parameters and their documentation, that'd be really helpful.
-- Matthias Andree
On Tue, 2003-07-01 at 12:09, Matthias Andree wrote:
One thing that I like about Courier components is its "sysconftool" approach that allows to add or remove parameters/examples/defaults to the configuration file as the software changes. If the concept supported rewriting the configuration file, without losing user customizations, but adding new parameters and their documentation, that'd be really helpful.
Yes, it would be nice.. Hmm. I think I'd use external script for that though, probably written with Perl. It could use dovecot-example.conf and maybe some dovecot.conf.history file to determine what comments belong to which configuration option.
participants (6)
-
Amelia A Lewis
-
Farkas Levente
-
Ian Kumlien
-
Mark E. Mallett
-
Matthias Andree
-
Timo Sirainen