[Dovecot] A new director service in v2.0 for NFS installations

[Timo Sirainen]

On ma, 2010-05-31 at 05:02 -0700, Brandon Davidson wrote:
> > So instead of having separate proxies and mail servers, have only hybrids
> > everywhere? I guess it would almost work, except proxy_maybe isn't yet
> > compatible with director. That's actually a bit annoying to implement.. You
> > could of course run two separate Dovecot instances, but that also can be a bit
> > annoying.
> 
> Would I have to run two separate instances, or could I just set up multiple
> login services on different ports; one set to proxy (forwarding the password
> to the remote server) and one set to not? I suppose each login service would
> have to use a different authdb, which I don't know how to do.

Well .. maybe you could use separate services. Have the proxy listen on
public IP and the backend listen on localhost. Then you can do:

local_ip 127.0.0.1 {
  passdb { 
    ..
  }
}

and things like that. I think it would work, but I haven't actually
tried.

> > No. The director service simply adds "host" field to auth lookup replies if
> > the original reply had proxy=y but didn't have host field.
> 
> Interesting. It sounds like proxying requires a database query that will
> return 'proxy=y' as part of the auth lookup. It would be nice to have a
> static password authdb for proxying that didn't require a real database
> backend. I'm using PAM now, and don't see a good way to enable proxying.
> 
> The wiki also says that there's a way to let the proxy backend handle
> authentication, but I don't see an example of that anywhere.

There's not yet a static passdb .. perhaps there should be. But you
could use e.g. sqlite backend for the proxy and use:

password_query = select null as password, 'Y' as nopassword, 'Y' as
proxy

> It looks like the mailserver list is initially populated from
> director_mail_servers, but can be changed by discovering hosts from other
> directors or by adding/removing hosts with doveadm. Since the initial host
> list is not written back in to the config file, changes made with doveadm
> are not persistent across service restarts. 

Right. I considered using a more permanent database for them, but .. I
don't know if that's a good idea.

> Does 'doveadm director
> <add|remove>' need to be run against each director individually, or will the
> changes be sent around the ring?

The changes are sent around the ring.

> If a new host comes up with a mailserver in
> its list that has been removed by doveadm, will the handshake remove it from
> the list?

If a new director joins an existing ring, it ignores its own mail server
list and uses the ring's.

> The list of director servers used to build the ring is read from
> director_servers, and cannot be changed at runtime. A host finds its
> position within the ring based on its order within the list, and connects to
> hosts to its left and right until it has a connection on either side and can
> successfully send a test message around the ring.

The way directors can be added currently is:

1. Add the new host to one director's config.
2. Reload config, this should restart director process and have it
reconnect to the ring, announcing the new host to everyone
3. Start up the new host, it'll insert itself to the ring.

That's anyway the theory, haven't tried yet. :) Also of course it's a
good idea to add the host to all directors' config, but only one of them
needs to be restarted to have it reload its config.

> Is that all correct? What happens if some hosts have only a subset, or
> different subsets, of a group of hosts in their mail server or director
> server list?

That should never happen (well, except temporarily).