[Dovecot] Three oddities

[Bob Hall]

Timo, first of all I want to say how grateful I am for the time 
you spent helping to me.

On Wed, Aug 20, 2003 at 07:47:36PM +0300, Timo Sirainen wrote:
> On Wednesday, Aug 20, 2003, at 11:29 Europe/Helsinki, Bob Hall wrote:
> 
> >So I'm assuming that imap-master and the
> >main dovecot process (/usr/local/sbin/dovecot) are the same.
> 
> yep.
> 
> >All of the mail accounts run under a Unix
> >account, and they all have the Unix account home directory in their 
> >LDAP
> >homeDirectory records. I'm guessing that Dovecot isn't pulling this 
> >info
> >from the LDAP registry, and therefore can't post inside dovecot.rawlog.
> 
> With Linux you could check what home directory imap process really used 
> by looking at /proc/pid/pwd symlink. I don't know if FreeBSD has 
> anything similiar.

I'm clueless on this. What does /proc/pid/pwd symlink do? Can you give 
an example from the command line? 
 
> >I think I've found a another bug. In dovecot-ldap.conf it says:
> ># You can use same UID and GID for all user accounts if you really 
> >want to.
> ># If the UID/GID is still found from LDAP reply, it overrides these 
> >values.
> >This is ambiguous. I took it to mean
> >	it (LDAP entry) overrides these (global) values
> >What it actually means, or at least what actually happens, is
> >	it (global) overrides these (LDAP entry) values
> 
> Oh? It's a bug then.

Thank god. I finally found something that *I* didn't screw up. :)
As I said, it doesn't interfere with my present set up, but in 
other situation your LDAP users will want more flexibility. 

> >Furthermore, if user_global_uid isn't explicitly set, it defaults to
> >0. If I set the uid number not equal to 0 in the LDAP entry, but don't 
> >set
> >user_global_uid, then login fails. From maillog:
> >Aug 20 03:15:15 kongemord dovecot: Logins with UID 0 not permitted 
> >(user rjhjr)
> 
> Yes, the error message could be better.

Actually, that error message was fine. In combination with the 
documentation, it made it clear what the problem was. That's what 
error messages are supposed to do; point you to something that is 
covered in the documentation. My problems with interpreting other 
error messages had mostly to do with lack of documentation. I did 
a lot of googling while I was setting Dovecot up, and while I 
didn't get much helpful info, I did find comments along the lines of 
"interesting, but poorly documented". That "poorly documented" may 
kill your project. People aren't going to be attracted to your 
software if it has a reputation for being poorly documented and 
hard to configure. Error messages by themselves are no good. You 
have to think of error messages as a part of your overall 
documentation.

I want to second the people in other threads who suggested 
setting up some sort of collaborative documentation project. My 
reasons:
1) The people who know best what documentation is needed are the 
   people using the software. They also tend to have a better idea 
   how to express things in ways that make sense to users.
2) Doing an installation and setup is kind of exciting, and users 
   tend to be a little hyped when it's over. I want to talk about 
   what I've done, so I feel motivated to write about it. The 
   developer is caught up in coding, and also has to talk to users, 
   debug, and various administrative tasks. Writing documentation 
   is just another task, so the developer doesn't have the motivation 
   that some users have. 
3) Even though I feel motivated to write, I don't have the time to 
   write a complete description of Dovecot/LDAP installation. (That's 
   why they put a clock on the Leaning Tower of Piza; there's no point 
   in having the inclination if you haven't got the time.) If the basic 
   document already existed, I could just add the missing bits that were
   relevant to my experience, which would take a lot less time and be 
   a lot more feasable for busy people.
4) Because the work is spread among many people, collaborative 
   documentation tends to happen faster. 
5) People who collaborate with your project help spread the word. They 
   tend to spend time telling other people why they're putting in the 
   effort, which means telling people what they like about your project. 

Bob Hall