[Dovecot] The CONTROL problem with fs quotas.

[Jorgen Lundman]

dovecot-1.0.10 on Solaris 10 x86, with NFS.

We currently have the problem that when customers go over their disk 
quota, the dovecot-uidlist file stops them from logging in.

In the interest of solving it, we considered moving the CONTROL file to 
a different file system. But:

1:

Using CONTROL= with "%u" will quite quickly run into the problem that 
the directory will fill up, and hit the maximum (around 32k) or so. We 
have 170k users so far, and more are being imported.
You could cull some from crontab or similar, but is generally a poor way 
to solve a problem.

2:

We attempted to use CONTROL= with "%h", which would give us full 
directory hashing, however, we found that when it creates all the 
directories, it does so as the uid of the first user. So all following 
users (that hash in at least one part) will fail. Most likely because 
dovecot has already setuid()ed.  Pre-creating the hashes is not feasible.

3:

Using 2, we could change umask to "0000" and hence it does not matter 
than all directory hash node are owned by a user's id, but this 
unfortunately includes all other directories, and having all directories 
at 777 is not an option.


Now, naturally, I can easily patch dovecot to call mkdir_parents with 
0777 only for CONTROL. But I would rather not have local patches, 
meaning upgrades will be difficult. It would be preferable if:

=> Dovecot would call "mkdir_parents" on "%h" _before_ setuid, but 
create the final directory after.

OR, Dovecot support (at least 2 level) directory hashing when specifying 
CONTROL=%1/%2/%u

OR, The ability to disable dovecot-uidlist (in memory is fine). (Setting 
INDEX=memory does not work for CONTROL=).

Are there other solutions out there?

-- 
Jorgen Lundman       | <lundman at lundman.net>
Unix Administrator   | +81 (0)3 -5456-2687 ext 1017 (work)
Shibuya-ku, Tokyo    | +81 (0)90-5578-8500          (cell)
Japan                | +81 (0)3 -3375-1767          (home)