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

Brandon Davidson brandond at uoregon.edu
Mon May 31 15:02:58 EEST 2010


Timo,

After straightening out some issues with Axel's spec file, I'm back to
poking at this.

On 5/25/10 3:14 PM, "Timo Sirainen" <tss at iki.fi> 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.

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

> Yes. So the connections between the proxies should be pretty fast. I think the
> maximum bytes transferred per user is 38.

Cool.

> The proxies always try to keep connecting to next available server (i.e. if
> the next server won't connect, it tries one further away until it finally
> connects to something or reaches itself). So the segmentation could happen
> only if there was no network connection between the two segments.

Ahh, OK - good to know. That sounds like a good way to do it. Can I confirm
my understanding of a few other things?

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. Does 'doveadm director
<add|remove>' need to be run against each director individually, or will the
changes be 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?

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.

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?

Thanks!

-Brad




More information about the dovecot mailing list