On Wed, Aug 20, 2003 at 08:51:32AM +0300, Timo Sirainen wrote:
On Wed, 2003-08-20 at 08:19, Bob Hall wrote:
imap process is run under them. Actually after reading your mail, it feels like you haven't even noticed their existence? :)
In the paragraph you quote below, I described setting the global and individual uids and gids, so I must have been aware of their existence.
I meant the imap processes actually.
Then you're right. They didn't show up in ps, so I wasn't aware of them, except knowing from the documentation that imap-master begat imap and most of the work is done in imap. So I'm assuming that imap-master and the main dovecot process (/usr/local/sbin/dovecot) are the same. I knew, in a general sort of way, that they had to be lurking somewhere, but out of sight and out of mind.
Sounds correct then. Did you verify with ps that the imap processes are also running under that user? Are you sure the full /var/mail/etc path is accessible to that user?
The main dovecot process runs under root. If I understand correctly, it forks subprocesses (imap) that run under the user. These never show up in ps. Is there a way to capture a transitory process in ps? My Dovecot installation is currently hosed, so the imap processes may not be spawning.
Try logging in manually?
telnet localhost imap2 x login user pass
Then you should have imap process.
No, the problem was my stupidity, not my ignorance. I was using telnet localhost 143 which is the same, but I was grepping ps for dovecot, not imap. Now that I can see the imap processes, things are a lot clearer.
I've got it in my home directory, and it's listed in homeDirectory in the ldap registry. I made dovecot.rawlog world writable. Nothing is showing up.
Oh and third thing. You had to configure dovecot with --with-rawlog. Actually that's probably the problem, otherwise it would print some permission denied errors in log file.
I did that back when I first started having problems, so raw logging has been enabled the whole time. So far, I've gotten records in dovecot.rawlog only with a test account where the mail user name matched the Unix account name and I was using passwd instead of LDAP. None of the actual mail user names match a Unix account name. 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.
At this point, after grepping ps for imap, I've got a much better understanding of what's going on. Everthing makes sense, and everything works the way I want, except raw logging.
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 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) Aug 20 03:15:15 kongemord imap-login: Internal login failure: rjhjr [127.0.0.1]
The bug is this; since user_global_uid overrides LDAP entries, and since user_global_uid has a built-in default value of 0, you have to set user_global_uid, and consequently you can only use one uid setting if you use LDAP. That's exactly what I want to do, but I can think of situations where I might want to use different uid numbers for different mail accounts. I think it would be better to do things in the opposite way:
- LDAP entries override user_global_uid. This would allow multiple uid numbers, but also allow you to specify a default value for LDAP entries with no uid number.
- There's no default value for user_global_uid. If it isn't explicitly set, then it isn't set. That way, you don't have to have a default value.
- If the uid isn't set in either the LDAP entry or user_global_uid, then the user gets a login error saying that there's no uid.
Bob Hall