[Dovecot] Getting rid of the common newbie problems

[Udo Rader]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
Url : http://dovecot.org/pipermail/dovecot/attachments/20070516/7fe12f69/attachment.pgp