Quoting Rick Romero:

4. Config file gets overwritten on make install. Good thing I grew up

Huh? The only config file make install writes is dovecot-example.conf, which is a good thing, because you can easily diff it against your own config. If you use the example as your live config, you are lost of course. :)

On Thu, 2006-08-10 at 11:35 -0400, John Peacock wrote:

Rick Romero wrote:

...

4. Config file gets overwritten on make install.

No it doesn't. *dovecot-example.conf* gets overwritten on each install; very different thing. It is worthwhile to make a copy of the prior dovecot-example.conf so you can make a diff and see what has changed (this is very useful during the rc period).

John

Then I stand corrected.

Maybe I moved dovecot.conf to dovecot.conf.bak the first time instead of copied, which caused my upgraded dovecot to not fire up without copying the backed-up config file back..

On Thu, 2006-08-10 at 19:03 +0300, Timo Sirainen wrote:

On Thu, 2006-08-10 at 10:05 -0500, Rick Romero wrote:

...

I'm sure you're just kidding, but I kinda have to agree here. There are some improvements that could be made in the system.

1. The whole *BSD poll/kqueue issue. From what configure says, kqueue shouldn't ever show up.

I'm not sure what you mean by this.

Just to restate myself - I'm really loving dovecot, it just flies :)

Well the way I read configure --help is this:

--with-ioloop=IOLOOP Specify the I/O loop method to use (epoll, kqueue, poll; best for the fastest available; default is poll) --with-notify=IOLOOP Specify the file system notification method to use (dnotify, inotify, kqueue, none; default dnotify if compilable, otherwise none)

If I don't specify anything, I should get 'poll' and 'dnotify' - if FreeBSD supports it - or 'none', respectively.
On my FreeBSD box, I get kqueue and kqueue.

I don't know or understand what the differences are - but it seems to me if configure followed what was documented, there wouldn't be these kqueue issues on BSD. Changing configure to work as documented, would essentially fix that issue.

...

2. POP? It gets compiled in automatically, yet doesn't start. Doesn't bother me, as I'm just using IMAP, but it doesn't seem logical. If POP doesn't start by default, I wouldn't think it would be compiled in by default.

Well, I think compiling and using by default are different things. Compiling everything by default doesn't really hurt anything, but using all of them by default does.

The only reason I suggested selective compiling is to help with the config file. It has so much to it, if you were able to reduce the 'unnecessary' bits based on the configure line, it wouldn't be so overwhelming. Look at the last post where the user had about 12 'real' lines to his config file. My modified one (comments and extra stuff left in there) is 1000 lines. I bet for a 'vpopmail/maildir' setup, it could be under 100 and still be descriptive.

I can't really think of how this could be improved. I think no matter what change I do people will start complaining.

I agree :)

...

3. Config file. It flows well, but it's freaking huge.

Yea. For v2.0 I'm planning on splitting it up. I already once did such a split and asked people's suggestions about that (IIRC).

I think anyone who already has it setup shouldn't care too much, it would only affect people who haven't had to figure it out yet.

...

3a Quotas. Where are you told that to enable imap quotas, you need to say: mail_plugins = quota imap_quota Maybe I missed it, but I modified horde to manually get the quotas because I couldn't find or figure out how enable it in dovecot.

I'm hoping to get http://wiki.dovecot.org/NewIndex into a usable state some day and it should hopefully be easy enough to install Dovecot into a fully usable state. :)

Anyway there already is wiki -> Quota page.

Ahh I see now. I think I skipped 'Quota' and just read Quota/Maildir assuming that would be more 'accurate' instead of just 'specific'.

...

...

Sorry, one more .... courier-imap is easier to configure, no?

Yes on FreeBSD, you have IMAP/POP and SSL config files.

I think SSL certificates are generated by most Dovecot binary packages, so this is a FreeBSD port-issue I think..

Actually, I compiled from source. I was inferring that courier was easier to configure because the config files were split up. :)

Rick

On Thu, 2006-08-10 at 18:49 +0200, Geert Hendrickx wrote:

On Thu, Aug 10, 2006 at 11:23:05AM -0500, Rick Romero wrote:

...

Well the way I read configure --help is this:

--with-ioloop=IOLOOP Specify the I/O loop method to use (epoll, kqueue, poll; best for the fastest available; default is poll) --with-notify=IOLOOP Specify the file system notification method to use (dnotify, inotify, kqueue, none; default dnotify if compilable, otherwise none)

If I don't specify anything, I should get 'poll' and 'dnotify' - if FreeBSD supports it - or 'none', respectively.
On my FreeBSD box, I get kqueue and kqueue.

That's FreeBSD ports' behaviour. Just look at the port's Makefile:

.if !defined(WITHOUT_KQUEUE) CONFIGURE_ARGS+= --with-ioloop=kqueue --with-notify=kqueue .endif

Hence, set WITHOUT_KQUEUE if you don't want it.

That's definitely a solution, except I compiled from source on my own, I didn't use the port.

Otherwise I'd would let the port maintainer know that kqueue seems to be an issue and it probably should be changed..

Is that you? :)

Geert

On Thu, 2006-08-10 at 11:23 -0500, Rick Romero wrote:

...

...

1. The whole *BSD poll/kqueue issue. From what configure says, kqueue shouldn't ever show up.

I'm not sure what you mean by this.

Just to restate myself - I'm really loving dovecot, it just flies :)

Well the way I read configure --help is this:

--with-ioloop=IOLOOP Specify the I/O loop method to use (epoll, kqueue, poll; best for the fastest available; default is poll) --with-notify=IOLOOP Specify the file system notification method to use (dnotify, inotify, kqueue, none; default dnotify if compilable, otherwise none)

If I don't specify anything, I should get 'poll' and 'dnotify' - if FreeBSD supports it - or 'none', respectively.
On my FreeBSD box, I get kqueue and kqueue.

If you didn't use the port, then it really should have used poll. In 1.0rc1 version it could have used kqueue, but I don't see why it would happen with newer rcs.

Notify's description is wrong though. It uses inotify -> kqueue -> dnotify -> none ordering by default.

...

...

2. POP? It gets compiled in automatically, yet doesn't start. Doesn't bother me, as I'm just using IMAP, but it doesn't seem logical. If POP doesn't start by default, I wouldn't think it would be compiled in by default.

Well, I think compiling and using by default are different things. Compiling everything by default doesn't really hurt anything, but using all of them by default does.

The only reason I suggested selective compiling is to help with the config file. It has so much to it, if you were able to reduce the 'unnecessary' bits based on the configure line, it wouldn't be so overwhelming. Look at the last post where the user had about 12 'real' lines to his config file. My modified one (comments and extra stuff left in there) is 1000 lines. I bet for a 'vpopmail/maildir' setup, it could be under 100 and still be descriptive.

I think most of the parts that can be compiled off don't take all that much space in the config file. Here's the config file split that I was thinking about, probably missing some of the latest changes:

http://dovecot.org/tmp/newconf/

The dovecot-example.conf should also contain some include-directives for the other files.

On Thu, 2006-08-10 at 20:33 +0300, Timo Sirainen wrote:

On Thu, 2006-08-10 at 11:23 -0500, Rick Romero wrote:

...

...

...

2. POP? It gets compiled in automatically, yet doesn't start. Doesn't bother me, as I'm just using IMAP, but it doesn't seem logical. If POP doesn't start by default, I wouldn't think it would be compiled in by default.

Well, I think compiling and using by default are different things. Compiling everything by default doesn't really hurt anything, but using all of them by default does.

The only reason I suggested selective compiling is to help with the config file. It has so much to it, if you were able to reduce the 'unnecessary' bits based on the configure line, it wouldn't be so overwhelming. Look at the last post where the user had about 12 'real' lines to his config file. My modified one (comments and extra stuff left in there) is 1000 lines. I bet for a 'vpopmail/maildir' setup, it could be under 100 and still be descriptive.

I think most of the parts that can be compiled off don't take all that much space in the config file. Here's the config file split that I was thinking about, probably missing some of the latest changes:

http://dovecot.org/tmp/newconf/

The dovecot-example.conf should also contain some include-directives for the other files.

Oh, I don't know about anyone else, but I like that. Except for safety.conf (which I believe you need the login_user - maybe that's just me), it's pretty obvious what you really need to fill out to fire up dovecot and check it out.

I think the auth part is probably the worst section. It doesn't look so bad on a webpage, but in a terminal it's daunting.

• Maybe if the options were tagged with 'REQUIRED' or something.
• Or how about specifying 'select one passdb and one userdb' at the beginning of auth default { ?

I think just having passdb and userdb is initially confusing as well, but there's not much you can do about that, other that specifically saying what is required.

There's just so much data, and nothing really jumps out at you ;)

Rick

On Thursday 10 August 2006 17:03, Timo Sirainen wrote:

On Thu, 2006-08-10 at 10:05 -0500, Rick Romero wrote:

...

3. Config file. It flows well, but it's freaking huge.

Yea. For v2.0 I'm planning on splitting it up. I already once did such a split and asked people's suggestions about that (IIRC).

Maybe a good idea to install config's to /etc/dovecot instead of just /etc then - I'm planning to do this for Gentoo's dovecot ebuild as I've got an open bug for including sieve support and that needs an extra config file so it's down directory makes sense.

Thanks

-- Roy Marples uberlord@gentoo.org Gentoo/Linux Developer (baselayout, networking)

On 10/08/06, Odhiambo WASHINGTON odhiambo.raburu@wananchi.com wrote:

| Also, from a sysadmin perspective, so far, I find dovecot's config | rather complex | - I suppose that's what happens when one attempts to appease all | authentication methods... anyway, I digress.

There are two plausible solutions to this complexity problem:

1. Use a Windows Server with some click next-> next
2. Quit being Sysadmin

Jokes aside, I haven't touched MS for years, for good reason. I'm not into point-and-click, but really, computing should become simpler over time, not more complex and the simpler systems are inevitably better - http://en.wikipedia.org/wiki/Ockham%27s_razor

Currently using BincIMAP in production which is trivial to setup (I know, it was specifically designed to run in the qmail + checkpassword + daemontools environment) - however, it doesn't implement SORT.

All my services run under daemontools, so I have a fair amount of experience there.

Hi John

Thanks for responding. I've progressed somewhat - details follow.

On 10/08/06, John Peacock jpeacock@rowman.com wrote:

You aren't using the correct log_path; it should be:

log_path = /dev/stderr

I did have this option set, sorry - I pasted the previous config. The log process appears to be working since I changed a few other settings.

Google is your friend:

    http://www.thedjbway.org/imap/dovecot.html

This is the exact URL which I'd started from before I even started building Dovecot.

$ cat /service/dovecot-imapd/run #!/bin/sh exec 2>&1 echo "Starting dovecot IMAP service" exec envuidgid dovecot
/usr/sbin/dovecot
-F
-c /etc/dovecot.conf

$ cat /service/dovecot-imapd/log/run #!/bin/sh exec setuidgid log multilog t /var/log/dovecot-imapd

I'm now getting the following error in the logs - any idea? The error isn't terribly informative.

Fatal: sigaction(SIGRTMIN) failed: Invalid argument

---- My revised /etc/dovecot.conf is ----

base_dir = /var/run/dovecot/

protocols = imap protocol imap { listen = 127.0.0.1:143143 }

shutdown_clients = yes

log_path = /dev/stderr log_timestamp =

ssl_disable = yes

login_dir = /var/run/dovecot/login login_chroot = yes login_user = dovecot login_greeting = Dovecot ready.

maildir_copy_with_hardlinks = yes

auth default { mechanisms = plain passdb checkpassword { args = /var/qmail/bin/qmail-vauth } userdb prefetch { } user = auth }

---- Some more detail regarding permissions (if this is pertinent) ----

$ id dovecot uid=1016(dovecot) gid=211(dovecot) groups=211(dovecot)

$ id auth uid=1017(auth) gid=212(auth) groups=212(auth)

$ ls -la /var/qmail/users/ | grep vpasswd -rw-r----- 1 root auth 2814 Aug 3 11:03 vpasswd -rw-r----- 1 root auth 5621 Aug 3 11:04 vpasswd.cdb

$ ls -la /var/log | grep dove drwxr-x--- 2 log log 4096 Aug 10 14:51 dovecot-imapd

$ ls -la /var/qmail/bin | grep vauth -rws--s--x 1 root auth 10320 May 11 2005 qmail-vauth

On 10/08/06, John Peacock jpeacock@rowman.com wrote:

dale gallagher wrote:

...

I'm now getting the following error in the logs - any idea? The error isn't terribly informative.

Fatal: sigaction(SIGRTMIN) failed: Invalid argument

That would seem to suggest that you have a broken O/S. You may want to go with a more modern (i.e. 2.6.x kernel) installation.

The Dovecot docs specifically mention compatibility with Linux kernel 2.2and later. The host concerned is on a UML installation and 2.4 is currently more reliable for these VM's.

Thanks Timo.

On 10/08/06, Timo Sirainen tss@iki.fi wrote:

On Thu, 2006-08-10 at 17:29 +0200, dale gallagher wrote:

...

I'm now getting the following error in the logs - any idea? The error isn't terribly informative.

Fatal: sigaction(SIGRTMIN) failed: Invalid argument

configure --with-ioloop=none

I'll fix this anyway in next version to just silently not use dnotify.

Is this only pertinent to 2.4 kernels? Can I not simply use:

./configure --with-notify=none

or will this result in the same error on 2.4?

On 10/08/06, dale gallagher wrote:

On 10/08/06, Timo Sirainen wrote:

...

...

On Thu, 2006-08-10 at 17:29 +0200, dale gallagher wrote:

...

I'm now getting the following error in the logs - any idea? The error isn't terribly informative.

Fatal: sigaction(SIGRTMIN) failed: Invalid argument

configure --with-ioloop=none

I'll fix this anyway in next version to just silently not use dnotify.

I tried building with --with-ioloop=none alone, but that resulted in the same error, namely: Fatal: sigaction(SIGRTMIN) failed: Invalid argument

Then, I configured with both --with-ioloop=none and --with-notify=none and the original error has gone, but a new one has reared its head:

dovecot: Info: Dovecot v1.0.rc6 starting up dovecot: Error: Login process died too early - shutting down dovecot: Error: child 17320 (login) killed with signal 11 dovecot: Error: child 17319 (login) killed with signal 11

Where should I look for problems now? Could this be with my checkpassword binary?

I've tried various settings for the dovecot (login) user, without any change in the above errors.

Attempt 1: HOME=/bin/true, SHELL=/bin/true Attempt 2: HOME=/var/log/dovecot/login, SHELL=/bin/sh

Am I barking up the wrong tree with trying to tweak the login user's env?

Any ideas?

On Thu, 2006-08-10 at 18:37 +0200, dale gallagher wrote:

dovecot: Info: Dovecot v1.0.rc6 starting up dovecot: Error: Login process died too early - shutting down dovecot: Error: child 17320 (login) killed with signal 11 dovecot: Error: child 17319 (login) killed with signal 11

This is because I once again left something broken. ssl_disable=yes causes crashes. Fix here: http://dovecot.org/list/dovecot-cvs/2006-August/006209.html

Or wait for 1.0rc7 which I'll release in a few hours.

On Thu, 2006-08-10 at 18:08 +0200, dale gallagher wrote:

Thanks Timo.

On 10/08/06, Timo Sirainen tss@iki.fi wrote: On Thu, 2006-08-10 at 17:29 +0200, dale gallagher wrote: > I'm now getting the following error in the logs - any idea? The error > isn't terribly informative. > > Fatal: sigaction(SIGRTMIN) failed: Invalid argument configure --with-ioloop=none I'll fix this anyway in next version to just silently not use dnotify.

Is this only pertinent to 2.4 kernels? Can I not simply use:

./configure --with-notify=none

Oh, I meant exactly that instead of ioloop.