director_username_hash = %d and doveadm director map

older
Dovecot cannot access mailcrypt...

Ralf Becker

23 Nov 2020 23 Nov '20

4:15 p.m.

Our directors hash by domain (director_username_hash = %d), as some of our users share folders with other users of the same domain.

We now started using director tags to map domains to their backends.

Unfortunately doveadm director map seems no to work with director_username_hash = %d

user hash mail server ip expire time <unknown> 432784257 10.44.88.1 2020-11-23 13:10:55 <unknown> 4244233328 10.44.88.1 2020-11-23 13:13:55 <unknown> 1913982503 10.44.88.1 2020-11-23 13:15:40

How can I check to which backend / IP a domain is maped, aka how is that hash calculated?

doveadm director move seems also not to do anything meaningful for %d, or at least I have not found out how to use it to move a domain to a different backend.

Hoping for some insight :)

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

Show replies by date

Ralf Becker

29 Nov 29 Nov

5:10 p.m.

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 3766880388 10.44.88.5 nfs 2020-11-29 15:06:53 rbz-yyyyyyyyyyyy.de 3088689059 10.44.88.1 extern 2020-11-29 15:07:11

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.

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? Is doveadm director move supposted to work with director_username_hash = %d?

Ralf

Am 23.11.20 um 15:15 schrieb Ralf Becker:

...

Our directors hash by domain (director_username_hash = %d), as some of our users share folders with other users of the same domain.

We now started using director tags to map domains to their backends.

Unfortunately doveadm director map seems no to work with director_username_hash = %d

user hash mail server ip expire time <unknown> 432784257 10.44.88.1 2020-11-23 13:10:55 <unknown> 4244233328 10.44.88.1 2020-11-23 13:13:55 <unknown> 1913982503 10.44.88.1 2020-11-23 13:15:40

How can I check to which backend / IP a domain is maped, aka how is that hash calculated?

doveadm director move seems also not to do anything meaningful for %d, or at least I have not found out how to use it to move a domain to a different backend.

Hoping for some insight :)

Ralf

Aki Tuomi

11:09 p.m.

Did you try doveadm director flush?

Aki

...

On 29/11/2020 17:10 Ralf Becker 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 3766880388 10.44.88.5 nfs 2020-11-29 15:06:53 rbz-yyyyyyyyyyyy.de 3088689059 10.44.88.1 extern 2020-11-29 15:07:11

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.

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? Is doveadm director move supposted to work with director_username_hash = %d?

Ralf

Am 23.11.20 um 15:15 schrieb Ralf Becker:

...
Our directors hash by domain (director_username_hash = %d), as some of our users share folders with other users of the same domain.

We now started using director tags to map domains to their backends.

Unfortunately doveadm director map seems no to work with director_username_hash = %d

user hash mail server ip expire time <unknown> 432784257 10.44.88.1 2020-11-23 13:10:55 <unknown> 4244233328 10.44.88.1 2020-11-23 13:13:55 <unknown> 1913982503 10.44.88.1 2020-11-23 13:15:40

How can I check to which backend / IP a domain is maped, aka how is that hash calculated?

doveadm director move seems also not to do anything meaningful for %d, or at least I have not found out how to use it to move a domain to a different backend.

Hoping for some insight :)

Ralf

Ralf Becker

30 Nov 30 Nov

3:47 p.m.

Am 29.11.20 um 22:09 schrieb Aki Tuomi:

...

Did you try doveadm director flush?

Yes, thought together with (different) tags it gives this wired behavior.

I use doveadm director flush all the time to get connections to the other backend of one pair.

Ralf

...

...
On 29/11/2020 17:10 Ralf Becker 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 3766880388 10.44.88.5 nfs 2020-11-29 15:06:53 rbz-yyyyyyyyyyyy.de 3088689059 10.44.88.1 extern 2020-11-29 15:07:11

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.

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? Is doveadm director move supposted to work with director_username_hash = %d?

Ralf

Am 23.11.20 um 15:15 schrieb Ralf Becker:

...
Our directors hash by domain (director_username_hash = %d), as some of our users share folders with other users of the same domain.

We now started using director tags to map domains to their backends.

Unfortunately doveadm director map seems no to work with director_username_hash = %d

user hash mail server ip expire time <unknown> 432784257 10.44.88.1 2020-11-23 13:10:55 <unknown> 4244233328 10.44.88.1 2020-11-23 13:13:55 <unknown> 1913982503 10.44.88.1 2020-11-23 13:15:40

How can I check to which backend / IP a domain is maped, aka how is that hash calculated?

doveadm director move seems also not to do anything meaningful for %d, or at least I have not found out how to use it to move a domain to a different backend.

Hoping for some insight :)

Ralf

Timo Sirainen

4:07 p.m.

On 29. Nov 2020, at 16.10, Ralf Becker 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 3766880388 10.44.88.5 nfs 2020-11-29 15:06:53 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.

...

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.

...

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.

...

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

Ralf Becker

7:39 p.m.

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

1395

Age (days ago)

1402

Last active (days ago)

List overview

5 comments

3 participants

participants (3)

Aki Tuomi
Ralf Becker
Timo Sirainen