[Dovecot] Getting rid of the common newbie problems
I think the most common Dovecot newbie problems are:
- Not looking at the (correct) logs for errors
- Authentication problems
- Mail location problems
- Mail permission problems
Below are some of my ideas how I could stop people from asking these questions with future Dovecot (v1.1+) releases. Suggestions welcome. Distribution people especially should say if they're against some change.
- Logging
The log file problem is the most annoying one, because a lot of the other problems can be solved once the admin figures out that Dovecot is actually giving useful error messages. Often the admin is only looking at the log file where "info" messages go (eg mail.log) because Dovecot logs its startup message and login messages there, but not where the errors go (eg mail.err). This has happened even with people who in general are experienced sysadmins.
Logging to eg. /var/log/dovecot.log by default would be helpful here, but it's probably better to log via syslog by default. Cyrus logs to "local6" by default. Perhaps for Dovecot v1.1 I should make that the default too? Looks like in my Debian system the info messages then go to both /var/log/messages and /var/log/syslog. Error messages only go to /var/log/syslog. So there still isn't by default a single log file where the errors are logged, but it might help a bit.
- Authentication
Authentication problems can usually be solved by telling the user to set auth_debug_passwords=yes and looking at the logs. I'm not sure if there's anything that can be helped in here. Except the logging message could be updated a bit:
"Aborted login: user=<asdga>, method=PLAIN, rip=127.0.0.1, lip=127.0.0.1, secured, 1 failed authentications"
So the last "n failed authentications" could be added, where n could also be 0.
Another possibility would be to make Dovecot remember if there have been any successful logins (/var/lib/dovecot/success file) and if not, give a bit more helpful error messages:
- Client gets: "NO Authentication failed. Refer to server log for more information." instead of the normal "NO Authentication failed."
- Log contains: "Aborted login: user=<asdga>, method=PLAIN, rip=127.0.0.1, lip=127.0.0.1, secured, 1 failed authentications (set auth_debug_passwords=yes to debug the problem)"
I'm not sure if this is a good idea.
- Mail location
It seems to be difficult for some people to set mail_location. I don't know if anything can be done before Dovecot v2.0 where I'll split it to multiple settings, such as:
driver = maildir root_dir = ~/Maildir index_dir = /var/indexes/%u
Another problem that seems to be difficult to understand is why the mail directory contains "HOME_DIRECTORY_USED_BUT_NOT_GIVEN_BY_USERDB". The whole userdb concept appears to be weird. This could anyway be fixed by giving an error message earlier and failing the login with internal error.
Probably the best place to give the error message would be already in the userdb lookup in dovecot-auth, but that would require that doveoct-auth knows if the home directory is really needed, and to give a useful error message it would also need to tell where it's tried to be used (mail_location, or some namespace's location, or ..). Probably too much trouble to be worth it. So the next best thing is to give the error when it's used:
"Home directory is used in mail_location, but userdb didn't return a home directory"
It would be nice if it didn't say userdb, but rather the userdb's name. I guess that would be possible if dovecot-auth told master (or deliver) which userdb was used, but that would normally be just extra overhead.
- Mail permissions
If mail location is difficult for some, then the concept of UIDs are how they're used in Dovecot is pretty much impossible for some to understand.
One of the problems is that there exists "dovecot" user. So people think that their mails should be owned by the dovecot user. Although I've mentioned in everywhere I can think of that this should not be done, it won't help because either people won't read the pages or even if they do, they somehow still fail to ignore it even though it's written in bold.
So unless people (and most importantly, distributions) are against it, I think the "dovecot" user should be renamed. "dovelogin" perhaps. In future I might split dovecot-auth even more, and then I would like to create a "doveauth" user as well.
Another possibility would be to drop the dovecot user completely and instead use "nobody". That would mean that other nobody processes could kill Dovecot's login processes, but that's pretty much it.
Once people understand that "dovecot" isn't the right user, they hit the next problem: "How do I tell Dovecot to run as vmail user?" I can paste links to wiki pages or tell them to "make userdb return uid=vmail", but that just doesn't seem to get through. There needs to be an easier way, and I think I figured out what it is:
Add new "mail_uid" and "mail_gid" settings to dovecot.conf. Deprecate user_global_uid/gid in dovecot-ldap.conf and make all the userdbs mention that the uid/gid returned by userdb can be used to override the global mail_uid/gid. Perhaps also add "mail_home" template. This change makes it unnecessary to have a userdb configured at all.
- "How do I tell Dovecot to run as vmail user?"
- "Set mail_uid = vmail" in dovecot.conf
- "Thanks"
Timo,
In general, the better the docs are and the better the error messages are the less support they will need. If the log message said "Failure XXX, check YYY to see if it is set" giving the user as much help as possible. You could have a number of sanity checks at startup where dovecot checks out the environment verifying that directories exist and perhaps do some write testing to make sure areas that need to be writable actually are.
You could have a number of sanity checks at startup where dovecot checks out the environment verifying that directories exist and perhaps do some write testing to make sure areas that need to be writable actually are.
And even if it has write access to areas it shouldn't...
I like the idea of test suites (Samba has one) - but I also realize that it means someone has to code it... and honestly, I'd rather Timo spent his time on 1.1/2.0 things instead. This can wait until after 2.0...
I'm trying to get up to speed enough so that I am confident enough to answer more questions... I think that would help more than anything (people helping him out here on the list)...
--
Best regards,
Charles
I'm trying to get up to speed enough so that I am confident enough to answer more questions... I think that would help more than anything (people helping him out here on the list)...
That, and, of course, adding more well written, targeted articles to the wiki...
--
Best regards,
Charles
Tried today to use Dovecot's DELIVER LDA. I'm running Postfix 2.1.5. I simply added the line...
mailbox_command = /usr/local/libexec/dovecot/deliver
to main.cf and made no other changes. First email resulted in this
in mail.log:
May 16 06:29:56 G518X2 deliver(bb): open(/var/mail/bb.lock) failed:
Permission denied
May 16 06:29:56 G518X2 deliver(bb): file_lock_dotlock() failed with
mbox file /var/mail/bb: Permission denied
May 16 06:29:56 G518X2 deliver(bb):
msgid=7e0d81210705160329n76c784d1m84571d33af7389b4@mail.gmail.com:
save failed to INBOX
May 16 06:29:56 G518X2 deliver(bb): open(/var/mail/bb.lock) failed:
Permission denied
May 16 06:29:56 G518X2 deliver(bb): file_lock_dotlock() failed with
mbox file /var/mail/bb: Permission denied
Permissions on all inbox files in /var/mail was 600. Owned by
<username>:mail I tried changing to 660 but got the same result.
Dovecot user is member of mail group.
Any ideas?
Thanks in advance.
On Wed, 2007-05-16 at 06:58 -0400, Bruce Bodger wrote:
May 16 06:29:56 G518X2 deliver(bb): file_lock_dotlock() failed with
mbox file /var/mail/bb: Permission denied
On Wed, 2007-05-16 at 14:53 +0300, Timo Sirainen wrote:
On Wed, 2007-05-16 at 06:58 -0400, Bruce Bodger wrote:
May 16 06:29:56 G518X2 deliver(bb): file_lock_dotlock() failed with
mbox file /var/mail/bb: Permission denied
Hmm. Actually with deliver the mail_extra_groups doesn't work. So I think you have two possibilities:
- Set /var/mail sticky
- Don't use dotlocks (but if you use other programs to access the mboxes make sure they don't break)
Dovecot user is member of mail group.
Don't do that. http://wiki.dovecot.org/UserIds
On May 16, 2007, at 7:58 AM, Timo Sirainen wrote:
On Wed, 2007-05-16 at 14:53 +0300, Timo Sirainen wrote:
On Wed, 2007-05-16 at 06:58 -0400, Bruce Bodger wrote:
May 16 06:29:56 G518X2 deliver(bb): file_lock_dotlock() failed with mbox file /var/mail/bb: Permission denied
Hmm. Actually with deliver the mail_extra_groups doesn't work. So I think you have two possibilities:
- Set /var/mail sticky
- Don't use dotlocks (but if you use other programs to access the mboxes make sure they don't break)
Set dovecot user back to its own group.
I set /var/mail to sticky...
drwxrwxr-t 10 root mail 340 May 16 08:11 mail
Still get this:
May 16 08:11:31 G518X2 deliver(bb): open(/var/mail/bb.lock) failed:
Permission denied
May 16 08:11:31 G518X2 deliver(bb): file_lock_dotlock() failed with
mbox file /var/mail/bb: Permission denied
May 16 08:11:31 G518X2 deliver(bb):
msgid=7e0d81210705160511o3567917yb65b77e91e3cc13a@mail.gmail.com:
save failed to INBOX
May 16 08:11:31 G518X2 deliver(bb): open(/var/mail/bb.lock) failed:
Permission denied
May 16 08:11:31 G518X2 deliver(bb): file_lock_dotlock() failed with
mbox file /var/mail/bb: Permission denied
Bruce
On May 16, 2007, at 8:24 AM, Timo Sirainen wrote:
On Wed, 2007-05-16 at 08:14 -0400, Bruce Bodger wrote:
I set /var/mail to sticky...
drwxrwxr-t 10 root mail 340 May 16 08:11 mail
You have to make it world-writable also. I'll update the wiki to
mention that too.
That may present a problem, Timo, as postfix's "local" LDA wants
exclusivity on the files in /var/mail.
May 16 08:34:11 G518X2 postfix/local[26583]: 7E613630295:
to=me@example.com, orig_to=me@example.com, relay=local,
delay=581, status=deferred (cannot access mailbox /var/mail/bb for
user bb. unable to lock for exclusive access: Resource temporarily
unavailable)
I realize that the intent here is to have Dovecot's LDA replace
Postfix's but it would seem logical if their behaviors (and
expectations regarding directories) were in sync.
Bruce
On May 16, 2007, at 8:44 AM, Bruce Bodger wrote:
On Wed, 2007-05-16 at 08:14 -0400, Bruce Bodger wrote:
I set /var/mail to sticky...
drwxrwxr-t 10 root mail 340 May 16 08:11 mail
You have to make it world-writable also. I'll update the wiki to
mention that too.That may present a problem, Timo, as postfix's "local" LDA wants
exclusivity on the files in /var/mail.May 16 08:34:11 G518X2 postfix/local[26583]: 7E613630295:
to=me@example.com, orig_to=me@example.com, relay=local,
delay=581, status=deferred (cannot access mailbox /var/mail/bb for
user bb. unable to lock for exclusive access: Resource temporarily
unavailable)I realize that the intent here is to have Dovecot's LDA replace
Postfix's but it would seem logical if their behaviors (and
expectations regarding directories) were in sync.
Never mind. The contention (above) was due to an earlier failed
attempt. I have made /var/mail world writable and sticky and now all
is well.
Thank you, Timo.
On May 16, 2007, at 7:53 AM, Timo Sirainen wrote:
On Wed, 2007-05-16 at 06:58 -0400, Bruce Bodger wrote:
May 16 06:29:56 G518X2 deliver(bb): file_lock_dotlock() failed with mbox file /var/mail/bb: Permission denied
Thank you, Timo.
I have followed the directions in the wiki. The user dovecot belongs
to group mail and I gave the mbox 660 permissions. I also have
mail_extra_groups = mail set in dovecot.conf. Am I missing something?
Thank you again.
Am Dienstag, den 15.05.2007, 19:40 +0300 schrieb Timo Sirainen:
I think the most common Dovecot newbie problems are:
- Not looking at the (correct) logs for errors
- Authentication problems
- Mail location problems
- Mail permission problems
Below are some of my ideas how I could stop people from asking these questions with future Dovecot (v1.1+) releases. Suggestions welcome. Distribution people especially should say if they're against some change.
- Logging
The log file problem is the most annoying one, because a lot of the other problems can be solved once the admin figures out that Dovecot is actually giving useful error messages. Often the admin is only looking at the log file where "info" messages go (eg mail.log) because Dovecot logs its startup message and login messages there, but not where the errors go (eg mail.err). This has happened even with people who in general are experienced sysadmins.
Logging to eg. /var/log/dovecot.log by default would be helpful here, but it's probably better to log via syslog by default. Cyrus logs to "local6" by default. Perhaps for Dovecot v1.1 I should make that the default too? Looks like in my Debian system the info messages then go to both /var/log/messages and /var/log/syslog. Error messages only go to /var/log/syslog. So there still isn't by default a single log file where the errors are logged, but it might help a bit.
Logging is always a special issue. No matter where and how much is logged, you can bet that either not all is read or it is misinterpreted. I say this as a first hand prove for that, there are many times when I saw an error message but did not actually read it :-)
Getting people to actually read _and_ understand what a log message means is very difficult on a very psychological level :-)
But of course, good logging is vital in any circumstance and logging to an own facility would be a good idea anyhow.
- Authentication
Authentication problems can usually be solved by telling the user to set auth_debug_passwords=yes and looking at the logs. I'm not sure if there's anything that can be helped in here. Except the logging message could be updated a bit:
"Aborted login: user=<asdga>, method=PLAIN, rip=127.0.0.1, lip=127.0.0.1, secured, 1 failed authentications"
So the last "n failed authentications" could be added, where n could also be 0.
Another possibility would be to make Dovecot remember if there have been any successful logins (/var/lib/dovecot/success file) and if not, give a bit more helpful error messages:
- Client gets: "NO Authentication failed. Refer to server log for more information." instead of the normal "NO Authentication failed."
- Log contains: "Aborted login: user=<asdga>, method=PLAIN, rip=127.0.0.1, lip=127.0.0.1, secured, 1 failed authentications (set auth_debug_passwords=yes to debug the problem)"
I'm not sure if this is a good idea.
The overhead for this on heavily loaded systems would be quite significant, IMHO. This feature should only be active when explicitly activated in the configuration, so that would not be much of a change to the current situation :-)
- Mail location
It seems to be difficult for some people to set mail_location. I don't know if anything can be done before Dovecot v2.0 where I'll split it to multiple settings, such as:
driver = maildir root_dir = ~/Maildir index_dir = /var/indexes/%u
Another problem that seems to be difficult to understand is why the mail directory contains "HOME_DIRECTORY_USED_BUT_NOT_GIVEN_BY_USERDB". The whole userdb concept appears to be weird. This could anyway be fixed by giving an error message earlier and failing the login with internal error.
Probably the best place to give the error message would be already in the userdb lookup in dovecot-auth, but that would require that doveoct-auth knows if the home directory is really needed, and to give a useful error message it would also need to tell where it's tried to be used (mail_location, or some namespace's location, or ..). Probably too much trouble to be worth it. So the next best thing is to give the error when it's used:
"Home directory is used in mail_location, but userdb didn't return a home directory"
It would be nice if it didn't say userdb, but rather the userdb's name. I guess that would be possible if dovecot-auth told master (or deliver) which userdb was used, but that would normally be just extra overhead.
- Mail permissions
If mail location is difficult for some, then the concept of UIDs are how they're used in Dovecot is pretty much impossible for some to understand.
One of the problems is that there exists "dovecot" user. So people think that their mails should be owned by the dovecot user. Although I've mentioned in everywhere I can think of that this should not be done, it won't help because either people won't read the pages or even if they do, they somehow still fail to ignore it even though it's written in bold.
So unless people (and most importantly, distributions) are against it, I think the "dovecot" user should be renamed. "dovelogin" perhaps. In future I might split dovecot-auth even more, and then I would like to create a "doveauth" user as well.
Another possibility would be to drop the dovecot user completely and instead use "nobody". That would mean that other nobody processes could kill Dovecot's login processes, but that's pretty much it.
Once people understand that "dovecot" isn't the right user, they hit the next problem: "How do I tell Dovecot to run as vmail user?" I can paste links to wiki pages or tell them to "make userdb return uid=vmail", but that just doesn't seem to get through. There needs to be an easier way, and I think I figured out what it is:
Add new "mail_uid" and "mail_gid" settings to dovecot.conf. Deprecate user_global_uid/gid in dovecot-ldap.conf and make all the userdbs mention that the uid/gid returned by userdb can be used to override the global mail_uid/gid. Perhaps also add "mail_home" template. This change makes it unnecessary to have a userdb configured at all.
- "How do I tell Dovecot to run as vmail user?"
- "Set mail_uid = vmail" in dovecot.conf
- "Thanks"
IMO the best way to prevent basic errors and basic questions is to provide as many sample configurations as possible (eg. in the wiki), maybe organized as some kind of recipes.
In the end most setups boil down to say 4 or 5 basic types, probably differing mostly between authentication settings.
I've upgraded our and come clients' dovecot installations multiple times, and to be honest I did not like the extensive documentation provided in the default configuration files. Saying 'I did not like it' does not mean that the information was useless, on the contrary, the amount was just overwhelming ...
Sometimes too much information is ... too much :-)
Major drawback for sample configurations is that they need to be maintained in order to keep up with the latest and greatest settings.
But talking about documentation, what I really miss are manual or info pages for dovecot/dovecot.conf but of course, somebody has to write them ...
-- Udo Rader
bestsolution.at EDV Systemhaus GmbH http://www.bestsolution.at
On Wed, 2007-05-16 at 02:15 +0200, Udo Rader wrote:
Getting people to actually read _and_ understand what a log message means is very difficult on a very psychological level :-)
A good example would be this error that I've changed 2 times already:
"Set pop3_uidl_format setting in config file" "pop3_uidl_format setting is missing from config file" "Set pop3_uidl_format in config file"
Looks like the first one actually was the best one. I'm not sure why I changed it to the second one, and when changing it again to the 3rd one I seem to have dropped "setting" word. Maybe I should add it back. :)
Anyway, with all of these 3 messages people have still copy&pasted logs and asked "How do I fix this?" I just don't know how to make it any more clearer. Except a few times people have asked "What config file?" so changing that to dovecot.conf could help a bit.
Another possibility would be to make Dovecot remember if there have been any successful logins (/var/lib/dovecot/success file) and if not, give a bit more helpful error messages:
- Client gets: "NO Authentication failed. Refer to server log for more information." instead of the normal "NO Authentication failed."
- Log contains: "Aborted login: user=<asdga>, method=PLAIN, rip=127.0.0.1, lip=127.0.0.1, secured, 1 failed authentications (set auth_debug_passwords=yes to debug the problem)"
I'm not sure if this is a good idea.
The overhead for this on heavily loaded systems would be quite significant, IMHO. This feature should only be active when explicitly activated in the configuration, so that would not be much of a change to the current situation :-)
No, it wouldn't add much overhead. That file's existence could be checked only at startup, and after that it's just a variable that needs to be checked/updated and the for the first successful login the file would have to be created.
IMO the best way to prevent basic errors and basic questions is to provide as many sample configurations as possible (eg. in the wiki), maybe organized as some kind of recipes.
Yea, that would be useful. Especially adding configurations that worked with other user managing software such as Postfixadmin.
I've upgraded our and come clients' dovecot installations multiple times, and to be honest I did not like the extensive documentation provided in the default configuration files. Saying 'I did not like it' does not mean that the information was useless, on the contrary, the amount was just overwhelming ...
Sometimes too much information is ... too much :-)
For Dovecot v2.0 I'm planning on splitting dovecot.conf to multiple files. The main dovecot.conf would then contain only the most important settings.
On 5/16/2007 Timo Sirainen (tss@iki.fi) wrote:
Anyway, with all of these 3 messages people have still copy&pasted logs and asked "How do I fix this?" I just don't know how to make it any more clearer.
I don't think you can... I really respect your desire to make things as easy/simple for people new to dovecot,
Except a few times people have asked "What config file?" so changing that to dovecot.conf could help a bit.
No amount of effort can help someone who is unwilling to learn the bare minimum about a new program they want to use - and if they aren't even aware that dovecot has a config file (as does every other server app I've ever used), or what it is named or where it is - well, I don't think I need to say anything more.
--
Best regards,
Charles
No amount of effort can help someone who is unwilling to learn the bare minimum about a new program they want to use - and if they aren't even aware that dovecot has a config file (as does every other server app I've ever used), or what it is named or where it is - well, I don't think I need to say anything more. I would have to agree. Dovecot is not an end-user program, so a person needs to read a few pages of docs and plan his install. That is why network admins and IT people go to school and/or buy soo many technical manuals. Do scalpels come with the book "Surgery for Dummies"?
--
MailScanner is like deodorant... You hope everybody uses it, and you notice quickly if they don't!!!!
Timo Sirainen writes:
"Set pop3_uidl_format setting in config file" "pop3_uidl_format setting is missing from config file" "Set pop3_uidl_format in config file"
How about: You have choosen to run POP3. The setting pop3_uidl_format needs to be set in the dovecot.conf file for the POP3 server to work. See examples in configuration file.
If that is too long.. then: You have choosen to run POP3. Setting pop3_uidl_format needed in dovecot.conf
Francisco Reyes spake the following on 5/20/2007 5:21 PM:
Timo Sirainen writes:
"Set pop3_uidl_format setting in config file" "pop3_uidl_format setting is missing from config file" "Set pop3_uidl_format in config file"
How about: You have choosen to run POP3. The setting pop3_uidl_format needs to be set in the dovecot.conf file for the POP3 server to work. See examples in configuration file.
If that is too long.. then: You have choosen to run POP3. Setting pop3_uidl_format needed in dovecot.conf
I don't see any problem in understanding "pop3_uidl_format setting is missing from config file".
--
MailScanner is like deodorant... You hope everybody uses it, and you notice quickly if they don't!!!!
On Sun, 2007-05-20 at 20:21 -0400, Francisco Reyes wrote:
Timo Sirainen writes:
"Set pop3_uidl_format setting in config file" "pop3_uidl_format setting is missing from config file" "Set pop3_uidl_format in config file"
How about: You have choosen to run POP3. The setting pop3_uidl_format needs to be set in the dovecot.conf file for the POP3 server to work. See examples in configuration file.
If that is too long.. then: You have choosen to run POP3. Setting pop3_uidl_format needed in dovecot.conf
Lets try this: You must configure pop3_uidl_format in dovecot.conf
This happens only when the user is logging in with pop3 so it should be obvious that the problem is related to pop3.
On Tue, 2007-05-22 at 02:10 +0300, Timo Sirainen wrote:
On Sun, 2007-05-20 at 20:21 -0400, Francisco Reyes wrote:
Timo Sirainen writes:
"Set pop3_uidl_format setting in config file" "pop3_uidl_format setting is missing from config file" "Set pop3_uidl_format in config file"
How about: You have choosen to run POP3. The setting pop3_uidl_format needs to be set in the dovecot.conf file for the POP3 server to work. See examples in configuration file.
If that is too long.. then: You have choosen to run POP3. Setting pop3_uidl_format needed in dovecot.conf
Lets try this: You must configure pop3_uidl_format in dovecot.conf
This happens only when the user is logging in with pop3 so it should be obvious that the problem is related to pop3.
Except why am I not checking it at startup? That would probably get rid of this problem once and for all. People are better at fixing problems at startup then when seeing them in the middle of log messages.
This should be enough:
# dovecot
Error: POP3 enabled but pop3_uidl_format not set
Udo Rader wrote:
I've upgraded our and come clients' dovecot installations multiple times, and to be honest I did not like the extensive documentation provided in the default configuration files. Saying 'I did not like it' does not mean that the information was useless, on the contrary, the amount was just overwhelming ...
Sometimes too much information is ... too much :-)
I see what you're getting at, but personally i really like having plenty of documentation in the config files. That way when you're editing the config file, you can know exactly what you're doing and have good descriptions right in front of you....
Of course this is no substitute for other documentation like manual/wiki etc
MT
I see what you're getting at, but personally i really like having plenty of documentation in the config files. That way when you're editing the config file, you can know exactly what you're doing and have good descriptions right in front of you....
Of course this is no substitute for other documentation like manual/wiki etc
Maybe the answer is to have two .conf files - one, the example, that contains the comments as it is now, and the other, the basic config file, with bare minimum comments.
Of course, this means twice as much work for Timo, unless he can do this with his IDE somehow (have two different 'comment' fields, one for the .example.conf, and one for the minimal version)? Since I'm not a programmer and never used an IDE or cvs, not sure how dumb this sounds... ;)
--
Best regards,
Charles
On Wed, 2007-05-16 at 09:29 -0400, Charles Marcus wrote:
I see what you're getting at, but personally i really like having plenty of documentation in the config files. That way when you're editing the config file, you can know exactly what you're doing and have good descriptions right in front of you....
Of course this is no substitute for other documentation like manual/wiki etc
Maybe the answer is to have two .conf files - one, the example, that contains the comments as it is now, and the other, the basic config file, with bare minimum comments.
Of course, this means twice as much work for Timo, unless he can do this with his IDE somehow (have two different 'comment' fields, one for the .example.conf, and one for the minimal version)? Since I'm not a programmer and never used an IDE or cvs, not sure how dumb this sounds... ;)
I think my plan is to
Split the config files, so the less used settings are separate files
Remove some of the settings completely from dovecot-example.conf, although they could still exist (mail_cache_fields, mail_never_cache_fields at least)
Make the comments smaller and add more pointers to docs/wiki/ files.
Timo Sirainen writes:
- Split the config files, so the less used settings are separate files
I think that would be good. Specially if you could have a tool chain that would produce both files from one source.
- Remove some of the settings completely from dovecot-example.conf, although they could still exist (mail_cache_fields, mail_never_cache_fields at least)
Are these settings only needed for debugging? Would they be documented anywhere?
- Make the comments smaller and add more pointers to docs/wiki/ files.
Good.
On Sun, 2007-05-20 at 20:35 -0400, Francisco Reyes wrote:
Timo Sirainen writes:
- Split the config files, so the less used settings are separate files
I think that would be good. Specially if you could have a tool chain that would produce both files from one source.
Is there a need to have both? I was thinking about just splitting the current dovecot-example.conf to example/*.conf or something, which distributions could then maybe install to /etc/dovecot/example/.
- Remove some of the settings completely from dovecot-example.conf, although they could still exist (mail_cache_fields, mail_never_cache_fields at least)
Are these settings only needed for debugging?
They're some micro-optimization settings and the only time when they might be useful is when you know exactly what IMAP clients are used and even then only for newly created mailboxes. In general Dovecot figures out itself what it should cache and there's no need to override them manually.
Would they be documented anywhere?
dovecot-example.conf has something about them but there's no other documentation.
Timo Sirainen writes:
Is there a need to have both? I was thinking about just splitting the current dovecot-example.conf to example/*.conf or something
I think this may be somewhat a matter of preference, but I would find it easier to have a "simple" file.. and a complete file. I would find it more difficult to have to look at two files, to combine them.
On May 16, 2007, at 9:29 AM, Charles Marcus wrote:
I see what you're getting at, but personally i really like having
plenty of documentation in the config files. That way when you're
editing the config file, you can know exactly what you're doing
and have good descriptions right in front of you.... Of course this is no substitute for other documentation like
manual/wiki etc
On the subject of newbie questions...
The dovecot-example.conf file, under Mailbox locations and
namespaces, states,
"If you're using mbox, giving a path to the INBOX file (eg. /var/mail/
%u) isn't enough. You'll also need to tell Dovecot where the other
mailboxes are and where Dovecot can place its index files. This is
called the "root mail directory", and it must be the first path given
in the mail_location setting."
Yet both mbox examples describe otherwise. The first example,
"mail_location = mbox:~/mail:INBOX=/var/mail/%u" has no INDEX
definition and the second example, "mail_location = mbox:/var/mail/%d/
%1n/%n:INDEX=/var/indexes/%d/%1n/%n" shows the INDEX definition last
when the instructions state that it must be first.
I happen to be using (under OS X),
"mail_location = mbox:~/Library/Mail/IMAP:INBOX=/var/mail/%u:INDEX=%h/ Library/Mail/DOVECOT.indexes "
...without any problems so basically, I find the instructions a bit
confusing.
B. Bodger New York, NY
On Wed, 2007-05-16 at 10:09 -0400, Bruce Bodger wrote:
"If you're using mbox, giving a path to the INBOX file (eg. /var/mail/ %u) isn't enough. You'll also need to tell Dovecot where the other
mailboxes are and where Dovecot can place its index files. This is
called the "root mail directory", and it must be the first path given
in the mail_location setting."Yet both mbox examples describe otherwise. The first example,
"mail_location = mbox:~/mail:INBOX=/var/mail/%u" has no INDEX
definition and the second example, "mail_location = mbox:/var/mail/%d/ %1n/%n:INDEX=/var/indexes/%d/%1n/%n" shows the INDEX definition last
when the instructions state that it must be first.
I meant that the index files are also under the root mail directory. But this doesn't really matter, so I updated the comment:
# If you're using mbox, giving a path to the INBOX file (eg. /var/mail/%u) # isn't enough. You'll also need to tell Dovecot where the other mailboxes are # kept. This is called the "root mail directory", and it must be the first # path given in the mail_location setting.
Charles Marcus writes:
Maybe the answer is to have two .conf files - one, the example, that contains the comments as it is now, and the other, the basic config file, with bare minimum comments.
I think one single file with basic defaults uncommented is best. As someone else mentioned, anyone trying to learn a new software needs to spend a little bit of time and try and learn.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Tue, 15 May 2007, Timo Sirainen wrote:
- Logging
Logging to eg. /var/log/dovecot.log by default would be helpful here,
Personally, I found logging to a separate file helpful during setting up Dovecot, because you can focus on Dovecot that way.
- Authentication
So the last "n failed authentications" could be added, where n could also be 0.
This message is user-specific, isn't it? How about a login-statistics of the last 10 or so attempts? Maybe one can use the utmp/wtmp service.
rip=127.0.0.1, lip=127.0.0.1, secured, 1 failed authentications (set auth_debug_passwords=yes to debug the problem)"
It usually is not enough to set the option, I think. Shouldn't it be: "read doc/debug_auth_problems.txt" with one of the first text therein "set auth_debug_passwords=yes"
- Mail location
It seems to be difficult for some people to set mail_location. I don't
IMHO: It looks wierd first, but the doc is OK. The most problem for myself was that it's spelled maildir:%h/maildir rather than maildir=%h/maildir, I mean anything else is in key=value format.
"Home directory is used in mail_location, but userdb didn't return a home directory"
It would be nice if it didn't say userdb, but rather the userdb's name.
When the userdb is logged, you could add a note that the particular userdb is user-specific, but mentioned in the logs.
- Mail permissions
Another possibility would be to drop the dovecot user completely and instead use "nobody". That would mean that other nobody processes could kill Dovecot's login processes, but that's pretty much it.
I would say no :-) Stick with a specific user. Otherwise, if it is still possible to run Dovecot with a specific user, ... . I like to see in ps or top, which process belongs to which "package" at easy glancing.
Add new "mail_uid" and "mail_gid" settings to dovecot.conf. Deprecate user_global_uid/gid in dovecot-ldap.conf and make all the userdbs mention that the uid/gid returned by userdb can be used to override the global mail_uid/gid. Perhaps also add "mail_home" template. This change makes it unnecessary to have a userdb configured at all.
- "How do I tell Dovecot to run as vmail user?"
- "Set mail_uid = vmail" in dovecot.conf
- "Thanks"
As long as this is transparent, I mean, one need no "mail_uid" in the LDAP backends, this might solve lots of vmail support requests. If I see it correct, this effectively makes userdb static the default - without explizit userdb { } block. BTW: Is mail_home the same as mail_location then?
Bye,
Steffen Kaiser -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux)
iQEVAwUBRkqxGC9SORjhbDpvAQJFJggAs9M4K9V/cYHccUlW76WWOSgmQVoMYVDV EyVPUQelNcOo0FLYt+OxBmMhbtr1Hd4DxgkiHL1PIofpDlusSQ30D+kGVwBLIvj4 ZQJk8AzhWaiqVfHk6BXzDE+MA4Bi3f6dl8lQBntDCbJ9THtX2wOoGcWoQLIngjPp gBHgzHmffJQAQLwbUrgrI5BPhaGa4fXTXOd1ZtON+2Key4K6bqAvMfvElgdWk4Z1 7tdVB2MciIrUvSe7qzlA3dgQlpYCIWrYPAq9Dswnogj/0ApQbxccpa0+YZ4OdGe5 FlM6a1PaOI2oNXwafhjwD0+TOH3YmDRVeqPAasS66jBsddYGa78/uw== =5ZOg -----END PGP SIGNATURE-----
Hi,
there's no easy way to get rid of newbie problems: right now dovecot is quite a complex software, so configuration is complex. Even more, all the userdb/passdb thing is really powerfull, but also a bit diferent of anything I was used to, so it's normal that people is a bit confused in the begining.
Anyway, I'm quite sure that in apache's, postfix's or sendmail's mailing lists there are far more newbie questions than here, and that isn't necesary bad.
For me, the easier solution would be an entry in the wiki with well documented common configs:
- system users (using pam/passwd)
- ldap (with a common conf)
- mysql
- postgresql
There is something similar in
http://wiki.dovecot.org/DovecotServerInstallations
but there the main goal seems to be the hardware.
I have to document my current config in spanish for my job, and it wouldn't be a hard job to translate it to english a upload it somewhere.
Aaaaaaaaaagur.
El Martes, 15 de Mayo de 2007 18:40, Timo Sirainen escribió:
I think the most common Dovecot newbie problems are:
- Not looking at the (correct) logs for errors
- Authentication problems
- Mail location problems
- Mail permission problems
Below are some of my ideas how I could stop people from asking these questions with future Dovecot (v1.1+) releases. Suggestions welcome. Distribution people especially should say if they're against some change.
-- Joseba Torre. CIDIR Bizkaia.
On 5/16/2007 Joseba Torre (joseba.torre@ehu.es) wrote:
For me, the easier solution would be an entry in the wiki with well documented common configs:
- system users (using pam/passwd)
- ldap (with a common conf)
- mysql
- postgresql
I agree completely... also, explanations for what is required to convert from, say, cyrus-sasl to dovecot-sasl (I want to do that someday soon), from common LDA (ie postfix's) to the dovecot LDA (want to do that as well), etc...
Wish I was fluent in all of these, I'd do it myself... if no one has by the time I get around to it, I'll document what I do and add it to the wiki...
--
Best regards,
Charles
Joseba Torre writes:
there's no easy way to get rid of newbie problems: right now dovecot is quite a complex software
I tried Cyrus once, and have been working with Courier for nearly 2 years before I tried Dovecot. In my opinion Dovecot is much simpler than Cyrus, but perhaps more complex than Courier. However I found the dovecot documentation to be very helpfull.
The problem is how to make the documentation friendlier to people with little or no exprience managing a pop/imap server.
common configs:
- system users (using pam/passwd)
- ldap (with a common conf)
- mysql
- postgresql
Agree. Having samples and sections for those different configurations will go a long way to help new users.
Timo Sirainen writes:
actually giving useful error messages. Often the admin is only looking at the log file where "info" messages go (eg mail.log) because Dovecot logs its startup message and login messages there, but not where the errors go (eg mail.err). This has happened even with people who in general are experienced sysadmins.
I had problems with Dovecot because of it's logs when I first started. think that syslog should be default and to point it to "mail.info" level. If the user tries to setup the log variables errors should be sent to syslog "mail.crit".
I don't recall exact details, but I recall that when I first tried to use the log files I made a mistake and dovecot did not help me find the error.
Logging to eg. /var/log/dovecot.log by default would be helpful here, but it's probably better to log via syslog by default.
I agree on syslog as default.
Cyrus logs to "local6" by default.
I think "mail.info" may be a better choice, although this may be somewhat OS dependant. Many people may not even know where their syslog configuration file is or even how to configure it. Because of this whatever is the most commonly used syslog call may be the best choice. In FreeBSD there is a default "mail.info". Anyone familiar with Linux Distros and/or other BSDs know how common is an entry for ""mail.info"" in syslog.conf.
On Sun, 2007-05-20 at 20:15 -0400, Francisco Reyes wrote:
I think "mail.info" may be a better choice, although this may be somewhat OS dependant. Many people may not even know where their syslog configuration file is or even how to configure it. Because of this whatever is the most commonly used syslog call may be the best choice. In FreeBSD there is a default "mail.info". Anyone familiar with Linux Distros and/or other BSDs know how common is an entry for ""mail.info"" in syslog.conf.
But are you saying that Dovecot should log errors also with "info" level by default? That might be newbie-friendly but I'm not sure if it's otherwise such a good idea.
Looks like Dovecot currently uses "info" for info/debug messages, "err" for errors and "crit" for fatals/panics.
Timo Sirainen writes:
But are you saying that Dovecot should log errors also with "info" level by default?
No.
Looks like Dovecot currently uses "info" for info/debug messages, "err" for errors and "crit" for fatals/panics.
That is good. So I guess, just make syslog the default and write to "crit" if the error is that the user tried to setup the log viles and dovecot could not write to them.
participants (10)
-
Bruce Bodger
-
Charles Marcus
-
Francisco Reyes
-
Joseba Torre
-
Marc Perkel
-
Mick T
-
Scott Silva
-
Steffen Kaiser
-
Timo Sirainen
-
Udo Rader