[Dovecot] Dovecot Alpha 4

[Timo Sirainen]

On Thu, 2005-10-27 at 17:42 +0100, Marcus Don wrote:
> 1. index files
> 
> The main problem has always been the index files becoming corrupted. This
> seems to have improved with the Alpha 4 release, but still happens for
> several users each day. 

Reporting the exact errors here is useful. I do fix them once in a
while :)

> Perhaps it would be possible for Dovecot to just
> delete index files and re-create them when they are corrupted, rather than
> just erroring? 

It should do that. If it doesn't do it with some errors, please tell
which errors and I'll fix it.

> Also, how do you turn off index files altogether? Even when
> mail_never_cache_fields is set for all available fields, they still get
> created.

That just means nothing is stored to dovecot.index.cache file.
dovecot.index is still used.

> Another issue relating to the index files is that, if a user is deleted and
> then another user created with the same name, dovecot doesn't have
> permissions to re-write the index files, because it has a different uid. So,
> whenever a user is deleted, we have to delete the index files from every
> machine in the cluster. We could store index files on the NFS device, but
> this would affect performance (and might cause locking problems). 

In theory storing the indexes in NFS would be faster, if the mailbox was
accessed from multiple computers.. But there are still some problems
with it.

Hmm. Wonder if it would be a good idea to delay the index updates and
write them only when closing the mailbox. That way there would be less
NFS traffic, but the indexes still would be updated globally, and if
another computer accessed the mailbox later it would have already
up-to-date indexes..

> A better
> solution would be to make the uid one of the variables available in
> default_mail_env. By naming index files by uid rather than username, this
> wouldn't be an issue.

I guess.. Added %i to CVS.

> 2. initgroups()
> 
> We use an nss-mysql to store all non-administrative system users in a mysql
> database. We often encounter problems with applications that use the
> initgroups() function, since this returns all users and groups - which in
> our case returns masses of data from mysql. When using mysql (or ldap etc)
> for authentication, it would be useful if there were an option to prevent
> additional system lookups. At present, we have to comment out the following
> in /src/lib/restrict-access.c, or the server load goes through the roof:
> 
> if (initgroups(env, gid) != 0) {
>     i_fatal("initgroups(%s, %s) failed: %m", env, dec2str(gid));
> } 

I think it's becuse of login processes, not because of imap/pop3
processes? The initgroups() is used only if userdb returns "system_user"
parameter, which by default is only returned if you use passwd userdb.
I'll change even that at some point so that auth process can just give a
GID-list to be used.

Hmm. And as for login process, it doesn't ever need more than one GID. I
guess it shouldn't break anything if I just don't let it do the
initgroups() call. Removed.

> 3. base_dir permissions bug
> 
> Since the alpha 4 release, it seems that the permissions dovecot
> automatically sets for the base_dir are not sufficient to allow the
> authentication user to access sockets, unless this user belongs to the same
> group as the login user - which is contrary to the instructions in the
> documentation. I'm pretty sure this is a bug, but perhaps someone could
> confirm.

You probably mean with mysql passdb/userdb? That's a bug..

> 4. authentication caching
> 
> Also since the alpha 4 release, we have found that, once the authentication
> cache is full, all subsequent login attempts for users that haven't been
> cached return "password mismatch". I though this might be a conflict with
> nscd, but it happens whether nscd is running or not. So, for the time being,
> we have had to disable the authentication cache.

Looks like auth cache was pretty much completely broken in alpha4 for
sql/ldap. Fixed.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://dovecot.org/pipermail/dovecot/attachments/20051028/1d123efa/attachment.pgp