[Dovecot] child 29480 (auth) returned error 89, FC5, Postfix, MySql, mbox....arghhhh

[Kent Iverson]

Hi all,

I have been putting a small (simple?)dedicated email server together 
to (ultimately) host a couple of domains.  I am currently getting the 
configuration to work with one domain w/local mbox users and then 
plan to extend it to virtual users and an additional domain.  Dovecot 
has been a problem to integrate in the configuration.

The basic pieces are FC5, Postfix, Dovecot, with Cyrus-sasl and MySql 
user/password databases.  I have installed, configured, and verified 
Postfix, Cyrus-sasl, and MySql both separately and working 
together.  All applications are standard Yum sourced FC5 
binaries.  Dovecot, however, stubbornly refuses to join the party.

I have searched for clues on-line and have not found anything that 
has helped, thus this message.  The problem seems to be tied tightly 
to using mySQL as an access mechanism for passdb/userdb information 
since if I remove that access mechanism Dovecot runs fine.  The 
reason I am looking to use mySQL is that it seemed an easy way to 
have a common database for user name and domain identification with a 
single common FQDN login authentication format for current local 
users and future virtual users.  As I understand it, the default PAM 
passwd doesn't support FQDN user names.

The symptom:
===========
Dovecot starts and immediately exits.

Maillog shows the following immediately after executing /sbin/service 
dovecot start

Oct 12 21:36:24 Playtime dovecot: Dovecot v1.0.beta8 starting up
Oct 12 21:36:25 Playtime dovecot: child 29479 (auth) returned error 89
Oct 12 21:36:25 Playtime dovecot: child 29480 (auth) returned error 89
Oct 12 21:36:25 Playtime dovecot: Auth process died too early - shutting down
Oct 12 21:36:25 Playtime dovecot: auth(default): 
net_connect_unix(/var/run/dovecot/auth-worker.29480) failed: Permission denied
Oct 12 21:36:25 Playtime dovecot: auth(default): 
net_connect_unix(/var/run/dovecot/auth-worker.29479) failed: Permission denied

It appears that the dovecot-auth process is immediately exiting with 
a non-specific error (89) and no collateral info.  There are two sets 
of error 89's because the process count is set to 2 in dovecot.conf 
(see below).

Looking at the messages log, you find a line reflecting the empty 
sockets as below:

Oct 12 21:36:25 Playtime kernel: audit(1160714185.460:373): 
avc:  denied  { write } for  pid=29479 comm="dovecot-auth" 
name="auth-worker.29479" dev=dm-0 ino=692358 
scontext=user_u:system_r:dovecot_auth_t:s0 
tcontext=user_u:object_r:dovecot_var_run_t:s0 tclass=sock_file

There is nothing in the auth log other than happy noises from Postfix 
about its mySQL accesses.  I am unaware of any other logs that might 
shed some light.

Troubleshooting:
=============
---  I have been using standard FC5 compiled binaries sourced through 
YUM for all applications.  To the best of my knowledge, the package 
that Yum pulled for Dovecot is built --with-mysql and thus should 
support mysql access.  I found this tidbit of info in the 
/usr/src/redhat/SPECS/dovecot.spec document.

--   I have rolled back the dovecot.conf to remove the mysql 
passwd/userdb configuration leaving the default PAM configuration and 
found that Dovecot behaves correctly and joins the 
party.   However,  since Postfix is using mySQL data, the client FQDN 
login user names it uses don't match up with the simple UNIX user 
names that Dovecot's default PAM password mechanism is supporting 
(thus my attempt to get them both to use the mySql database.)  So 
from this I know that the problem appears to be basic to startup of 
dovecot-auth and the mysql configuration.

--  I have verified the location of the dovecot-sql.conf file as 
configured in dovecot.conf
--  I have verified that the   'connect' parameters in the 
dovecot-sql.conf.work from a command line and the password_query 
syntax from inside mysql.

Configuration details:

dovecot.conf:
=======================================================================
# things uncommented from defaults:
base_dir = /var/run/dovecot
protocols = imap imaps pop3 pop3s
listen = *
shutdown_clients = yes

#for debug...seems to have made no difference.
mail_debug = yes

mbox_very_dirty_syncs = yes

# authentication section
# this next was left at default and I checked the ownership and it is correct.
#auth_executable = /usr/libexec/dovecot/dovecot-auth

#more debug
auth_verbose = yes
auth_debug = yes
auth_debug_passwords = no

# auth-worker process limit
auth_worker_max_count = 30

#and into auth default:

auth default {
   	mechanisms = plain
# default PAM
  	passdb pam {
  	}	
# SQL
	passdb sql {
  	args = /etc/dovecot-sql.conf
	}

# userdb

	userdb static {
	args = uid=690 gid=768 home=/var/mail/%n
	}

#note there is no SQL userdb access defined.  We will always use 
userdb static for now

	user = root
	count = 2
}
=============================
dovecot-sql.conf
==============================================================================
# Our mysql table actually is: (defined to support postfix password db)
# CREATE TABLE users (
#       id int(11) unsigned NOT NULL auto_increment,            #table index
#       username varchar(255) NOT NULL default '0',             #user 
part in user at userrealm
#       userrealm varchar(255) NOT NULL default 'firstdomain.com', 
#domain part in user at userrealm
#       userpassword varchar(255) NOT NULL default 
'94go283xc',  #email password
#       auth tinyint(1) default 
'1',                            #Relay authority 1 = yes
#       active char(1) NOT NULL default 'y'              #active Dovecot user?
#};

driver = mysql
connect = host=127.0.0.1 dbname=user_db user=dovecot password=xxxyy0x0
default_pass_scheme = PLAIN
password_query = SELECT password FROM users WHERE username='%n' AND 
userrealm='%d' AND active='y'

# there is no userdb sql access mechanism defined so this is left null
user_query =
=========================================================================================

Thats about it. I'm stumped....any thoughts or debug suggestions 
would be appreciated.

Thanks

-Kent I.