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..

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:

1. 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 { ... } }

2. 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 } }

3. 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, 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.

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.

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.

1. 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 { ... } }

2. 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 } }

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.

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".

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.