Re: [Dovecot] minor director issues
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..
Re: [Dovecot] minor director issues
> 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
Re: [Dovecot] minor director issues
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. 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).
Re: [Dovecot] minor director issues
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. 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.
Re: [Dovecot] minor director issues
> 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. 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
Re: [Dovecot] minor director issues
On Thu, 2010-09-02 at 14:22 +0200, Cor Bosman wrote: > I noticed 2 minor things with the director. > > 1) 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. > 2) > > usermail server ip expire time > cor 194.109.26.171 2010-09-02 14:32:13 >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. 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. 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? :)
