[Dovecot] Dovecot fails to come up when using ACLs (1.0.b5)
Hi,
I just had a go at enabling ACLs with 1.0b5. As per the docs I've done the configuration bit:
protocol imap { .. mail_plugins = acl } ... plugin { acl = vfile:/usr/local/etc/dovecot-acls }
and created the dovecot-acls file. When I start dovecot, it hangs for a few seconds and dies with this:
[root@redback root]# /etc/init.d/dovecot restart Shutting down IMAP daemon (/usr/local/sbin/dovecot1.0rc5): [ OK ] Starting IMAP daemon (/usr/local/sbin/dovecot1.0rc5): IEffective uid=65534, gid=65534 INamespace: type=private, prefix=, sep=/, inbox=yes, hidden=no, subscriptions=no Imaildir: data=/imap/mailboxes/dump-capability Imaildir: root=/imap/mailboxes/dump-capability, index=/imap/mailboxes/dump-capability, control=, inbox= INamespace: type=public, prefix=JiraSupport/, sep=/, inbox=no, hidden=no, subscriptions=no Imaildir: data=/imap/mailboxes/jira-support:CONTROL=/imap/mailboxes/dump-capability/shared-settings/jira-support/control:INDEX=/imap/mailboxes/dump-capability/shared-settings/jira-support/index Imaildir: root=/imap/mailboxes/jira-support, index=/imap/mailboxes/dump-capability/shared-settings/jira-support/index, control=/imap/mailboxes/dump-capability/shared-settings/jira-support/control, inbox= Elstat(/imap/mailboxes/jira-support/cur) failed: Permission denied [FAILED]
there's a strange dump-capability mailbox created:
[root@redback root]# ls -la /imap/mailboxes/dump-capability/ total 20 drwxrwx--- 5 nfsnobody nfsnobody 4096 Aug 4 19:59 . drwxr-xrwx 28 root mail 4096 Aug 4 19:59 .. drwxrwx--- 2 nfsnobody nfsnobody 4096 Aug 4 19:59 cur drwxrwx--- 2 nfsnobody nfsnobody 4096 Aug 4 19:59 new drwxrwx--- 2 nfsnobody nfsnobody 4096 Aug 4 19:59 tmp [root@redback root]#
First I tried making /imap/mailboxes/jira-support/* world-readable, which fixes the 'Permisison denied' error. Dovecot still fails to come up. When I strace the process on startup, this is what it looks like:
...... open("/etc/passwd", O_RDONLY) = 3 fcntl64(3, F_GETFD) = 0 fcntl64(3, F_SETFD, FD_CLOEXEC) = 0 fstat64(3, {st_mode=S_IFREG|0644, st_size=3091, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40016000 read(3, "root:x:0:0:root:/root:/bin/bash\n"..., 4096) = 3091 close(3) = 0 munmap(0x40016000, 4096) = 0 access("/usr/local/libexec/dovecot/imap", X_OK) = 0 access("/usr/local/lib/dovecot/imap", R_OK|X_OK) = 0 geteuid32() = 0 pipe([3, 4]) = 0 fcntl64(3, F_GETFD) = 0 fcntl64(3, F_SETFD, FD_CLOEXEC) = 0 fcntl64(4, F_GETFD) = 0 fcntl64(4, F_SETFD, FD_CLOEXEC) = 0 dup(2) = 5 fcntl64(5, F_GETFD) = 0 fcntl64(5, F_SETFD, FD_CLOEXEC) = 0 fork() = 16282 close(5) = 0 close(4) = 0 alarm(5) = 0 wait4(-1, IEffective uid=65534, gid=65534 INamespace: type=private, prefix=, sep=/, inbox=yes, hidden=no, subscriptions=no Imaildir: data=/imap/mailboxes/dump-capability Imaildir: root=/imap/mailboxes/dump-capability, index=/imap/mailboxes/dump-capability, control=, inbox= INamespace: type=public, prefix=JiraSupport/, sep=/, inbox=no, hidden=no, subscriptions=no Imaildir: data=/imap/mailboxes/jira-support:CONTROL=/imap/mailboxes/dump-capability/shared-settings/jira-support/control:INDEX=/imap/mailboxes/dump-capability/shared-settings/jira-support/index Imaildir: root=/imap/mailboxes/jira-support, index=/imap/mailboxes/dump-capability/shared-settings/jira-support/index, control=/imap/mailboxes/dump-capability/shared-settings/jira-support/control, inbox= 0xbfffcb7c, 0, NULL) = ? ERESTARTSYS (To be restarted) --- SIGALRM (Alarm clock) @ 0 (0) --- +++ killed by SIGALRM +++
I tried chmod ugo+r'ing the /imap/dump-capability/ directory tree and it made no difference.
I've attached my dovecot.conf, stripped of comments.
Cheers, Jeff
On Fri, 2006-08-04 at 21:03 +1000, Jeff Turner wrote:
[root@redback root]# /etc/init.d/dovecot restart Shutting down IMAP daemon (/usr/local/sbin/dovecot1.0rc5): [ OK ] Starting IMAP daemon (/usr/local/sbin/dovecot1.0rc5): IEffective uid=65534, gid=65534 INamespace: type=private, prefix=, sep=/, inbox=yes, hidden=no, subscriptions=no Imaildir: data=/imap/mailboxes/dump-capability Imaildir: root=/imap/mailboxes/dump-capability, index=/imap/mailboxes/dump-capability, control=, inbox= INamespace: type=public, prefix=JiraSupport/, sep=/, inbox=no, hidden=no, subscriptions=no Imaildir: data=/imap/mailboxes/jira-support:CONTROL=/imap/mailboxes/dump-capability/shared-settings/jira-support/control:INDEX=/imap/mailboxes/dump-capability/shared-settings/jira-support/index Imaildir: root=/imap/mailboxes/jira-support, index=/imap/mailboxes/dump-capability/shared-settings/jira-support/index, control=/imap/mailboxes/dump-capability/shared-settings/jira-support/control, inbox= Elstat(/imap/mailboxes/jira-support/cur) failed: Permission denied [FAILED]
Well, this is a bit strange. When setting mail_plugins Dovecot executes imap binary as a dump-capability user so that it can check if the plugins added some IMAP capabilities. However it shouldn't get this far, it should have already printed the capability and exited. So it looks as if something removes DUMP_CAPABILITY environment variable.
Dovecot still fails to come up. When I strace the process on startup, this is what it looks like:
The strace is from the dovecot master process only. "strace -f dovecot" would show also what the child processes are doing.
You could also change mail_executable to be a script which does:
#!/bin/sh
set > /tmp/dovecot.sets exec /usr/local/libexec/dovecot/imap
And then check if dovecot.sets contains DUMP_CAPABILITY=1 line.
I've attached my dovecot.conf, stripped of comments.
I tested with this, but it worked fine with me. So the problem has something to do with your system instead of configuration.
Hmm. Actually I can think of one more reason. Probably the most likely reason .. Your dovecot master binary is from 1.0rc5, but the imap binary is from some older Dovecot version which didn't yet understand the DUMP_CAPABILITY..
On Thu, Aug 10, 2006 at 09:31:54PM +0300, Timo Sirainen wrote:
On Fri, 2006-08-04 at 21:03 +1000, Jeff Turner wrote:
[root@redback root]# /etc/init.d/dovecot restart Shutting down IMAP daemon (/usr/local/sbin/dovecot1.0rc5): [ OK ] Starting IMAP daemon (/usr/local/sbin/dovecot1.0rc5): IEffective uid=65534, gid=65534 INamespace: type=private, prefix=, sep=/, inbox=yes, hidden=no, subscriptions=no Imaildir: data=/imap/mailboxes/dump-capability Imaildir: root=/imap/mailboxes/dump-capability, index=/imap/mailboxes/dump-capability, control=, inbox= INamespace: type=public, prefix=JiraSupport/, sep=/, inbox=no, hidden=no, subscriptions=no Imaildir: data=/imap/mailboxes/jira-support:CONTROL=/imap/mailboxes/dump-capability/shared-settings/jira-support/control:INDEX=/imap/mailboxes/dump-capability/shared-settings/jira-support/index Imaildir: root=/imap/mailboxes/jira-support, index=/imap/mailboxes/dump-capability/shared-settings/jira-support/index, control=/imap/mailboxes/dump-capability/shared-settings/jira-support/control, inbox= Elstat(/imap/mailboxes/jira-support/cur) failed: Permission denied [FAILED]
Well, this is a bit strange. When setting mail_plugins Dovecot executes imap binary as a dump-capability user so that it can check if the plugins added some IMAP capabilities. However it shouldn't get this far, it should have already printed the capability and exited. So it looks as if something removes DUMP_CAPABILITY environment variable.
Dovecot still fails to come up. When I strace the process on startup, this is what it looks like:
The strace is from the dovecot master process only. "strace -f dovecot" would show also what the child processes are doing.
You could also change mail_executable to be a script which does:
#!/bin/sh
set > /tmp/dovecot.sets exec /usr/local/libexec/dovecot/imap
And then check if dovecot.sets contains DUMP_CAPABILITY=1 line.
I've attached my dovecot.conf, stripped of comments.
I tested with this, but it worked fine with me. So the problem has something to do with your system instead of configuration.
Hmm. Actually I can think of one more reason. Probably the most likely reason .. Your dovecot master binary is from 1.0rc5, but the imap binary is from some older Dovecot version which didn't yet understand the DUMP_CAPABILITY..
I think you're right. I have always upgraded dovecot with './configure --program-suffix=... ; make install', then adjusting /etc/rc.d/dovecot to refer to the new binary. With the rc6 upgrade I see it won't even start:
==> /usr/local/logs/dovecot <== dovecot: Aug 14 09:19:02 Error: login: Protocol version mismatch (mixed old and new binaries?) dovecot: Aug 14 09:19:02 Error: Login process died too early - shutting down dovecot: Aug 14 09:19:02 Error: login: Protocol version mismatch (mixed old and new binaries?)
I shall revise my upgrade process and try again. Thanks!
--Jeff
participants (2)
-
Jeff Turner
-
Timo Sirainen