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.