[Dovecot] linuxconf migration story
Hi, just subscribed after successfully (?) migrating from a somewhat old linuxconf/vimap config. dovecot-1.1.7, x86
A few issues: The index files seem to be created with the wrong permissions. I get numerous ``Dec 24 15:36:29 mail dovecot: POP3(user@domain): stat(/var/run/dovecot/imap-index/domain/user/.imap/INBOX) failed: Permission denied (euid=60107 egid=231 missing +x perm: /var/run/dovecot/imap-index/domain)'' errors. the directory /var/run/dovecot/imap-index is drwxrwxrwt 29 dovecot dovecot 4.0k Dec 24 15:57 imap-index but the directories inside it are created as drwx------ 15 60107 popusers 4.0k Dec 24 15:50 domain
Questions:
- Why is POP3 interested in the imap indices ?
- IMAP clients do not complain all that much, as far as I can see, but what happens to POP3 ?
- Is there something to configure to get rid of this ?
Also, I have written a somewhat sloppy patch to determine the domain from the server's IP. That way it is not necessary to persuade all users to switch to logging in as ``user@domain'' (which I've tried with very limited success). Would this be the correct place to post the patch and discuss ?
Best Regards, Thanos Chatziathanassiou
On Wed, 2008-12-24 at 16:26 +0200, Thanos Chatziathanassiou wrote:
``Dec 24 15:36:29 mail dovecot: POP3(user@domain): stat(/var/run/dovecot/imap-index/domain/user/.imap/INBOX) failed: Permission denied (euid=60107 egid=231 missing +x perm: /var/run/dovecot/imap-index/domain)'' errors.
/var/run is a pretty bad place for indexes. Either disable them completely or point them to a directory that doesn't get deleted on reboots.
the directory /var/run/dovecot/imap-index is drwxrwxrwt 29 dovecot dovecot 4.0k Dec 24 15:57 imap-index but the directories inside it are created as drwx------ 15 60107 popusers 4.0k Dec 24 15:50 domain
Questions:
- Why is POP3 interested in the imap indices ?
They're not really imap indexes. I just chose a bad name years ago. They should be "Dovecot indexes" in a .dovecot/ directory.
- IMAP clients do not complain all that much, as far as I can see, but what happens to POP3 ?
There shouldn't be a difference.
- Is there something to configure to get rid of this ?
Where are IMAP's non-INBOX mailboxes located? The index files should be in the same directory.
Also, I have written a somewhat sloppy patch to determine the domain from the server's IP. That way it is not necessary to persuade all users to switch to logging in as ``user@domain'' (which I've tried with very limited success). Would this be the correct place to post the patch and discuss ?
Go ahead and post it. But I'm not sure if it really belongs to Dovecot itself, since it's possible to do with several passdbs already (at least SQL and checkpassword).
O/H Timo Sirainen έγραψε:
On Wed, 2008-12-24 at 16:26 +0200, Thanos Chatziathanassiou wrote:
``Dec 24 15:36:29 mail dovecot: POP3(user@domain): stat(/var/run/dovecot/imap-index/domain/user/.imap/INBOX) failed: Permission denied (euid=60107 egid=231 missing +x perm: /var/run/dovecot/imap-index/domain)'' errors.
/var/run is a pretty bad place for indexes. Either disable them completely or point them to a directory that doesn't get deleted on reboots.
Indeed...though I do not reboot all that often and I overlooked this.
- Is there something to configure to get rid of this ?
Where are IMAP's non-INBOX mailboxes located? The index files should be in the same directory.
Since this is a (previous) linuxconf installation, they are located in
/vhome/<domain>/home/<user>'' This is an NFS mounted directory in my case. Would I want to store the indexes there after disabling mmap(), using fcntl locks and adding mail_privileged_group = mail'' to dovecot.conf ?
Also, I have written a somewhat sloppy patch to determine the domain from the server's IP. That way it is not necessary to persuade all users to switch to logging in as ``user@domain'' (which I've tried with very limited success). Would this be the correct place to post the patch and discuss ?
Go ahead and post it. But I'm not sure if it really belongs to Dovecot itself, since it's possible to do with several passdbs already (at least SQL and checkpassword).
Attached. Rather crude though...
On Mon, 2009-01-12 at 21:21 +0200, Thanos Chatziathanassiou wrote:
- Is there something to configure to get rid of this ?
Where are IMAP's non-INBOX mailboxes located? The index files should be in the same directory.
Since this is a (previous) linuxconf installation, they are located in ``/vhome/<domain>/home/<user>'' This is an NFS mounted directory in my case.
Are there multiple servers accessing it or just one? If just one there are really no problems. If multiple then there might be problems, but it still might be better to keep them on NFS.
Would I want to store the indexes there after disabling mmap(), using fcntl locks and adding ``mail_privileged_group = mail'' to dovecot.conf ?
mmap disabling is good, fcntl locks are the default but why would you need the mail_privileged_group? http://wiki.dovecot.org/NFS anyway lists the issues.
Also, I have written a somewhat sloppy patch to determine the domain from the server's IP. That way it is not necessary to persuade all users to switch to logging in as ``user@domain'' (which I've tried with very limited success). Would this be the correct place to post the patch and discuss ?
Go ahead and post it. But I'm not sure if it really belongs to Dovecot itself, since it's possible to do with several passdbs already (at least SQL and checkpassword).
Attached. Rather crude though...
Ah, reverse DNS lookups again. I really hate the blocking DNS lookups. Especially when DNS server happens to be answering really slowly you start getting these weird hangs that are difficult to debug.. Some day I'm thinking about including some asynchronous DNS lookup library with Dovecot that could do these lookups.
O/H Timo Sirainen έγραψε:
On Mon, 2009-01-12 at 21:21 +0200, Thanos Chatziathanassiou wrote:
- Is there something to configure to get rid of this ?
Where are IMAP's non-INBOX mailboxes located? The index files should be in the same directory.
Since this is a (previous) linuxconf installation, they are located in ``/vhome/<domain>/home/<user>'' This is an NFS mounted directory in my case.
Are there multiple servers accessing it or just one? If just one there are really no problems. If multiple then there might be problems, but it still might be better to keep them on NFS.
There are 4 servers with linux-vs in front. I moved the index files to NFS and things seem to work fine. Maybe use the persistent (-p) option on LVS ?
Would I want to store the indexes there after disabling mmap(), using fcntl locks and adding ``mail_privileged_group = mail'' to dovecot.conf ?
mmap disabling is good, fcntl locks are the default but why would you need the mail_privileged_group? http://wiki.dovecot.org/NFS anyway lists the issues.
I clearly misunderstood the use of mail_privileged_group, that's why. As for the locks, as of linux 2.6.13 there's flock emulation via fcntl for nfs, but I don't suppose there's any benefit in it.
Also, I have written a somewhat sloppy patch to determine the domain from the server's IP. That way it is not necessary to persuade all users to switch to logging in as ``user@domain'' (which I've tried with very limited success). Would this be the correct place to post the patch and discuss ?
Go ahead and post it. But I'm not sure if it really belongs to Dovecot itself, since it's possible to do with several passdbs already (at least SQL and checkpassword).
Attached. Rather crude though...
Ah, reverse DNS lookups again.
I didn't come across any relevant discussion in the list archives or I would have spared you the details
I really hate the blocking DNS lookups. Especially when DNS server happens to be answering really slowly you start getting these weird hangs that are difficult to debug.. Some day I'm thinking about including some asynchronous DNS lookup library with Dovecot that could do these lookups.
You're probably right, however there is some justification: If the user bothered to use user@domain login, the code would never execute (and consequently block). In essence, we can either do this or fail the login right away. And DNS is running on localhost and authoritative for the zone in question, so any delay should be quite small. I understand that its usefulness in general is questionable though...
participants (2)
-
Thanos Chatziathanassiou
-
Timo Sirainen