Re: director_username_hash = %d and doveadm director map

Hi Timo,

it's a long time :)

Am 30.11.20 um 15:07 schrieb Timo Sirainen:

On 29. Nov 2020, at 16.10, Ralf Becker mailto:rb@egroupware.org> wrote:

...

To answer my question I was able to identify the director code on Github and the hashes are the first 4 byte of the binary md5 written as a 32 bit integer.

With that I was able to write a script that runs doveadm director map, queries all domains from our internal management, calculates the hashes and displays a joined list:

doveadm-director map | grep rbz rbz-xxxxxxxxx.de http://rbz-xxxxxxxxx.de 3766880388 10.44.88.5   nfs      2020-11-29 15:06:53 rbz-yyyyyyyyyyyy.de http://rbz-yyyyyyyyyyyy.de 3088689059 10.44.88.1   extern   2020-11-29 15:07:11

Are you doing this to lots of domains or just a few? I think you could have also individually looked up the backends with "doveadm director status anything@domain.de mailto:anything@domain.de tag". Of course, requires knowing also the tag for the domain already in this lookup.

I only moved single domains from one tag / backend-pair to an other. doveadm director status x@domain.com tag1 gives one of the IPs of backends of tag1, same with tag2.

...

When I move a domain between backends / tags, I see for some time the moved domain is listed for both tags, thought doveadm who on the backends show users are only connected to the new backend. No idea why that ist. Trying doveadm director move does NOT change that situation.

There's not really a concept of "moving user between tags". The intention was that you could have "user1@domain" in tag1 and "user1@domain" in tag2 and they would be different users. So when you're returning a new tag from passdb then director just treats it as a different user. The old user is remembered until director_user_expire has passed without the user being accessed.

That explains it. I was able to verify, that all connections go to the new tag, by doing a doveadm who on all backends.

...

I currently disable the domain in our dict used for userdb and passdb, clear the auth cache of all directors and flush them, before (final) rsync of the mailboxes of the domain to the new backend. When our dicts answer again with the new director tag, connections are going to the correct backend-pair. But it takes some hours for the old mapping to disappear.

Is that the expected behavior?

Yes. And as long as the user isn't accessed via the old tag it doesn't matter.

That's what I observed too. Just looks a bit scarry ...

...

Is doveadm director move supposted to work with director_username_hash = %d?

It should work if you do:

doveadm director move anything@domain.de mailto:anything@domain.de backend2

It updates the director internal mapping, and it also sends a KICK-DIRECTOR-HASH to each login process in each director. This in turn should match every user with that same domain and kick them out.

But maybe the issue is that you're again trying to move the user between tags? That's not what is really happening. It's moving anything@domain.de mailto:anything@domain.de in backend2's tag from its currently assigned backend to backend2. If domain.de http://domain.de's backend was already backend2 then nothing is done. You could maybe kludge this by moving it to backend1 and then quickly to backend2 so at least one of them does the kicking.

Yes, I tried to move between tags, not backends of a tag.

Ok, then I know now the tags in director are really separate and I dont need to worry about the domain being mapped twice for different tags.

Only thing which is a bit annoying with director_username_hash = %d, it that doveadm director map writes <unknown> instead of the domain:

kubectl exec -t dovecot-director-0 -c dovecot-director -- doveadm director map user                  hash       mail server ip expire time <unknown>             518789780  10.44.88.1     2020-11-30 17:38:39 <unknown>             2520389888 10.44.88.1     2020-11-30 17:39:18

Thanks a lot for you explenations :)

Ralf

-- Ralf Becker EGroupware GmbH [www.egroupware.org] Handelsregister HRB Kaiserslautern 3587 Geschäftsführer Birgit und Ralf Becker Leibnizstr. 17, 67663 Kaiserslautern, Germany Telefon +49 631 31657-0