[Dovecot] The CONTROL problem with fs quotas.
lundman at lundman.net
Fri Apr 11 04:56:49 EEST 2008
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:
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.
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.
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
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)
More information about the dovecot