On Thu, 2005-10-27 at 17:42 +0100, Marcus Don wrote:
- 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.
- 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.
- 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..
- 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.