[dovecot] Unable to Log in on FreeBSD server?
Hello!
I recently compiled dovecot 0.99.7 on a FreeBSD 4.3 server, and have been having problems with logging in and password authentication.
a. I can't seem to get it to compile MD5 support -- it only seems to support plain, plain-file, and pam.
b. Whenever I try to log in, I always get something along the following lines in /var/log/messages ....
Jan 16 17:52:15 akira imap-login: close(master) failed: Bad file descriptor Jan 16 17:55:33 akira imap-auth: Userinfo pam doesn't support DIGEST-MD5 method Jan 16 18:08:28 akira imap-master: Login process died too early - shutting down
(I also included one about MD5 in there too! :-))
Basically, the imap-login process is dying every time I try to do a login from a remote machine (I've tried Evolution and Outlook Express ....) I've tried telling it to use port 143 and port 993 (where it correctly generates a warning about a certificate that it can't verify, since i created that certificate with mkcert.sh )
Is there something I haven't configured correctly? The only things I've changed in dovecot.conf are:
Any suggestions?
Thanks,
Marc.
On Fri, 2003-01-17 at 07:56, Mark wrote:
I recently compiled dovecot 0.99.7 on a FreeBSD 4.3 server, and have been having problems with logging in and password authentication.
a. I can't seem to get it to compile MD5 support -- it only seems to support plain, plain-file, and pam.
Do you mean Digest-MD5? That's an authentication mechanism, like plain. PAM and passwd-file are different things, they're used to check if password is correct.
b. Whenever I try to log in, I always get something along the following lines in /var/log/messages ....
Jan 16 17:55:33 akira imap-auth: Userinfo pam doesn't support DIGEST-MD5 method
PAM and Digest-MD5 can't work together, so it complains. Digest-MD5 requires that the passwords are stored in special format, currently supported only by passwd-file.
I was more just asking about the other problems (I can worry about MD5 later ...). Even with the 99.7-2 patch, I cannot get any logins to work to my server. I always get the
"Authentication process died" message on my client, and messages in my /var/log/mess such as:
Jan 16 17:52:15 akira imap-login: close(master) failed: Bad file descriptor Jan 16 18:08:28 akira imap-master: Login process died too early - shutting down
- I can only connect to port 993, not 143
- I have the following changes in my dovecot.conf:
default_mail_env = mbox:~/.imapmail:INBOX=~/Mailbox # (incoming mail is ~/Mailbox, I want mail in ~/.imapmail)
Any ideas at all?
Thanks much!
ciao, mark.
On Fri, 2003-01-17 at 04:06, Timo Sirainen wrote:
On Fri, 2003-01-17 at 07:56, Mark wrote:
I recently compiled dovecot 0.99.7 on a FreeBSD 4.3 server, and have been having problems with logging in and password authentication.
a. I can't seem to get it to compile MD5 support -- it only seems to support plain, plain-file, and pam.
Do you mean Digest-MD5? That's an authentication mechanism, like plain. PAM and passwd-file are different things, they're used to check if password is correct.
b. Whenever I try to log in, I always get something along the following lines in /var/log/messages ....
Jan 16 17:55:33 akira imap-auth: Userinfo pam doesn't support DIGEST-MD5 method
PAM and Digest-MD5 can't work together, so it complains. Digest-MD5 requires that the passwords are stored in special format, currently supported only by passwd-file.
On Sat, 2003-01-18 at 21:56, Mark wrote:
Jan 16 17:52:15 akira imap-login: close(master) failed: Bad file descriptor Jan 16 18:08:28 akira imap-master: Login process died too early - shutting down
Well, if those happen all the time, it's not because of the configuration. FreeBSD 4.3 is a bit old, but I'd think it supports everything that Dovecot wants. Hard to say, that'd require some debugging with the system..
"Authentication process died" message on my client, and messages in my /var/log/mess such as:
It doesn't say anything about auth process in log files?
I recently recompiled with --enable-asserts and --enable-debug, and I when trying to log in to either port 143 or port 993 using Outlook Express, the following happens:
- Outlook Express complains that the authentication failed with "Login
Process died unexpectedly" 2. The imap-master and all other processes die on my FreeBSD machine. 3. I see the following in the logs:
Jan 18 19:32:21 akira imap-master: Login process died too early - shutting down
That's it. Btw -- FreeBSD 4.3 isn't all that old -- perhaps 18 months. I've had uptimes longer than that !! :-)
ciao, mark.
On Sat, 2003-01-18 at 12:20, Timo Sirainen wrote:
On Sat, 2003-01-18 at 21:56, Mark wrote:
Jan 16 17:52:15 akira imap-login: close(master) failed: Bad file descriptor Jan 16 18:08:28 akira imap-master: Login process died too early - shutting down
Well, if those happen all the time, it's not because of the configuration. FreeBSD 4.3 is a bit old, but I'd think it supports everything that Dovecot wants. Hard to say, that'd require some debugging with the system..
"Authentication process died" message on my client, and messages in my /var/log/mess such as:
It doesn't say anything about auth process in log files?
On Sun, 2003-01-19 at 05:36, Mark wrote:
I recently recompiled with --enable-asserts and --enable-debug, and I when trying to log in to either port 143 or port 993 using Outlook Express, the following happens:
--enable-asserts is actually the default. --enable-debug does only some internal sanity checks and bad performance warnings.
- Outlook Express complains that the authentication failed with "Login
Process died unexpectedly" 2. The imap-master and all other processes die on my FreeBSD machine. 3. I see the following in the logs:
Jan 18 19:32:21 akira imap-master: Login process died too early - shutting down
That "close(master) failed: Bad file descriptor" you had in log is the only indicator that something wrong even happened. But it still should have logged something more.
Hmm. Looks like the new code that complains about auth/login process dying too soon doesn't tell the reason for it if the process crashed or exited without logging a failure.
See if the attached patch shows something more in the logs? It doesn't fix the problem, but at least I'll know if it crashes or something else.
participants (2)
-
Mark
-
Timo Sirainen