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:
- 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.
- 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.
- 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.
- Because the work is spread among many people, collaborative documentation tends to happen faster.
- 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