director_username_hash = %d and doveadm director map

[Ralf Becker]

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 <rb at egroupware.org 
> <mailto:rb at 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 at domain.de <mailto:anything at 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 at 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 at domain" in tag1 and 
> "user1 at 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 at domain.de 
> <mailto:anything at 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 at domain.de <mailto:anything at 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