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 <[email protected]
<mailto:[email protected]>> 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 [email protected] <mailto:[email protected]> 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 [email protected] 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 [email protected]
<mailto:[email protected]> 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
[email protected] <mailto:[email protected]> 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
