I noticed 2 minor things with the director.
if I start 2 directors, but in 1 of them I dont add the other as a director_servers, they both start spamming the logfiles really really fast. It seems there is no backoff mechanism in the protocol between directors.
user mail server ip expire time
cor 194.109.26.171 2010-09-02 14:32:13
<unknown> 194.109.26.172 2010-09-02 14:33:13
Why does it say 'unknown'? That session is active, im manually logged in with telnet, issued a login and a select inbox. The first one is a normal mail client login.
Regards,
Cor
On Thu, 2010-09-02 at 14:22 +0200, Cor Bosman wrote:
I noticed 2 minor things with the director.
- if I start 2 directors, but in 1 of them I dont add the other as a director_servers, they both start spamming the logfiles really really fast. It seems there is no backoff mechanism in the protocol between directors.
I've added some delays to a few places, but I guess not enough. I'll see about fixing this.
user mail server ip expire time
cor 194.109.26.171 2010-09-02 14:32:13 <unknown> 194.109.26.172 2010-09-02 14:33:13Why does it say 'unknown'? That session is active, im manually logged in with telnet, issued a login and a select inbox. The first one is a normal mail client login.
Director doesn't know what users are logged in, only CRC32 of their username. So doveadm first gets a list of all users, adds them to hash table, then gets the list of CRC32s of users from director and maps them to usernames via the hash table. <unknown> means that the user wasn't found from the hash table.
So .. my guess is that doveadm didn't get a full list of usernames. And you probably don't even want it to read those 2 million (or whatever) user records from SQL? :)
Director doesn't know what users are logged in, only CRC32 of their username. So doveadm first gets a list of all users, adds them to hash table, then gets the list of CRC32s of users from director and maps them to usernames via the hash table. <unknown> means that the user wasn't found from the hash table.
So .. my guess is that doveadm didn't get a full list of usernames. And you probably don't even want it to read those 2 million (or whatever) user records from SQL? :)
Ah ofcourse! cor is in the local password file, while the other login is in the NIS database. That explains it. And we dont allow processes to ask for the whole NIS table :)
Thanks,
Cor
On Thu, 2010-09-02 at 16:11 +0200, Cor Bosman wrote:
Director doesn't know what users are logged in, only CRC32 of their username. So doveadm first gets a list of all users, adds them to hash table, then gets the list of CRC32s of users from director and maps them to usernames via the hash table. <unknown> means that the user wasn't found from the hash table.
So .. my guess is that doveadm didn't get a full list of usernames. And you probably don't even want it to read those 2 million (or whatever) user records from SQL? :)
Ah ofcourse! cor is in the local password file, while the other login is in the NIS database. That explains it. And we dont allow processes to ask for the whole NIS table :)
Note also the -f parameter. You can get a list of usernames and dump them into a file and use that.
On Thu, 2010-09-02 at 15:06 +0100, Timo Sirainen wrote:
Director doesn't know what users are logged in, only CRC32 of their username. So doveadm first gets a list of all users, adds them to hash table, then gets the list of CRC32s of users from director and maps them to usernames via the hash table. <unknown> means that the user wasn't found from the hash table.
Oops, not CRC32, but a 32bit hash based on MD5 of the username. Still, it's 32bit so with lots of users there will be a lot of collisions (which shouldn't be a problem, except doveadm director map will list users who haven't really logged in).
Oops, not CRC32, but a 32bit hash based on MD5 of the username. Still, it's 32bit so with lots of users there will be a lot of collisions (which shouldn't be a problem, except doveadm director map will list users who haven't really logged in).
Isn't it possible to keep a copy of the username with the md5 checksum? Or is that problematic because of the collisions?
Cor
On Fri, 2010-09-03 at 10:25 +0200, Cor Bosman wrote:
Oops, not CRC32, but a 32bit hash based on MD5 of the username. Still, it's 32bit so with lots of users there will be a lot of collisions (which shouldn't be a problem, except doveadm director map will list users who haven't really logged in).
Isn't it possible to keep a copy of the username with the md5 checksum? Or is that problematic because of the collisions?
It's done this way to avoid wasting lots of memory and also network bandwidth when sending data across directors. Doing all that just for a small statistics check that is probably rarely used doesn't seem like a good idea..
participants (2)
-
Cor Bosman
-
Timo Sirainen