[Dovecot] Three oddities

[Bob Hall]

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:
1) 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.
2) 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. 
3) 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