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)
> 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.Worse, it also moved all the "subscriptions" files, so customers no longer saw their folders, and different result in each cluster. (it'd would have to move to a NFS volume). Seems the only real solution is for us to patch Dovecot, or hope for future features. Lund -- 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)
On Fri, 2008-04-11 at 10:56 +0900, Jorgen Lundman wrote:> 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.What do you mean by %h? That expands to home directory. %Hu then would give a hash of the entire user name.> => Dovecot would call "mkdir_parents" on "%h" _before_ setuid, but > create the final directory after.Probably won't work well at least everywhere, since the same problem would be with deliver. Also mail_drop_priv_before_exec=yes is useful sometimes and then this wouldn't be possible either.> OR, Dovecot support (at least 2 level) directory hashing when specifying > CONTROL=%1/%2/%uThis is already possible. You could use first two letters of the username (CONTROL=%1u/%2.1u/%u = u/s/user) or first two letters of a MD5 sum of the user (CONTROL=%1u/%2.1u/%u). Precreating the directories for at least the MD5 sum should be easy.> OR, The ability to disable dovecot-uidlist (in memory is fine). (Setting > INDEX=memory does not work for CONTROL=).For POP3 with pop3_uidl_format=%f this would be a possibility, but for IMAP it would cause UIDVALIDITY to change for every login and cause IMAP clients to re-download all messages all the time. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: <http://dovecot.org/pipermail/dovecot/attachments/20080504/378d936f/attachment-0002.bin>