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.
signature.asc
Description: This is a digitally signed message part