On Wed, Aug 20, 2003 at 06:11:59AM +0300, Timo Sirainen wrote:
On Wed, 2003-08-20 at 00:11, Bob Hall wrote:
What userdb are you using? Dovecot gets the uid/gid for users from
The userdb is ldap. What are the uid and gid supposed to do?
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 thought they were being used to set permissions, but you explain
otherwise below.
I have the default uid in dovecot-ldap.conf and the individual uidNumber and values in the LDAP registry set to the mail account (the one I want to own the mail files). The default gid and the individual gidNumbers are set to the mail group, which is the group assigned to all files in /var/mail.
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.
If the mail account owns the files, users can't access them. If I own the files, everthing works fine, but my uid and gid numbers are not listed anywhere that dovecot has access to.
Well, that sounds weird. It's sounds like it's still running the imap processes under your uid?
Yea. How do I check that, if imap never shows up in ps?
I know that imap-master checks uids and gids for validity, but aside from that I don't know what they're used for.
They're just extra checks.
Just validity checks? OK, that makes sense.
I thought that maybe the fact that I'm a wheel and the mail user is not had something to do with it,
No, and actually Dovecot drops the wheel group permissions if you happen to belong to it :)
I think you're at a point where you need to think about how you are going to explain Dovecot to users.
Yea .. I should write some simple to read installation manual.
- The Macs have Eudora 4.2 installed, and the Win boxes have Eudora 5.1. The Macs can delete mail, put it in the trash, and empty the trash. The Win clients can mark mail deleted, but they can't remove it. The mail stays in the IMAP folder until the same user accesses their mail from a Mac and deletes it. If a user drags a message to another folder, a copy is created in the new folder but the old copy remains in the original folder. I'm not having this problem with Mutt, so it the problem seems to be specific to the Windows verson of Eudora. Is there a fix?
Are there error messages in log file? /var/log/maillog probably. I can't think of any reason why it does that..
No. Nothing in maillog,
But there's "Dovecot starting up" message anyway?
Yes.
and nothing in dovecot.rawlog. That's something else I'm confused about: When exactly does Dovecot write to the raw logs? I've got a boatload of entries from 20030814, and nothing before or since.
They're written to immediately. If you're not seeing them, there's two possibilities: dovecot.rawlog isn't located in user's home directory (or the home directory isn't given at all), or it doesn't have permissions to write there.
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.
Also, I get the following in the output from "ps waux | grep dovecot":
dovecot 1004 0.0 0.9 2208 536 ?? S 7:58AM 0:01.48 imap-login: imap-login [IP address] (imap-login)
The machine at [IP address] is physically shut down. Should there still be an imap-login process for it?
Hmm. Not really. Check with strace -p what it's doing?
I'll try that as soon as I un-hose Dovecot.
Bob Hall