CentOS 5.3, postfix with virtual users (mysql): problemi con smtp-auth (cyrus sasl)

[darkbasic]

Sostanzialmente ho seguito questa guida:
http://www.how2forge.com/virtual_use..._clamav_centos

Da /var/log/maillog:

Jan  2 12:48:35 darkbasic postfix/smtpd[14133]: connect from [...]
Jan  2 12:48:36 darkbasic postfix/smtpd[14133]: setting up TLS connection from [...]
Jan  2 12:48:36 darkbasic postfix/smtpd[14133]: TLS connection established from [...]: TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)
Jan  2 12:48:36 darkbasic postfix/smtpd[14133]: warning: SASL authentication problem: unable to open Berkeley db /etc/sasldb2: No such file or directory
Jan  2 12:48:36 darkbasic postfix/smtpd[14133]: warning: SASL authentication problem: unable to open Berkeley db /etc/sasldb2: No such file or directory
Jan  2 12:48:36 darkbasic postfix/smtpd[14133]: warning: SASL authentication failure: Password verification failed
Jan  2 12:48:36 darkbasic postfix/smtpd[14133]: warning: [...]: SASL PLAIN authentication failed: authentication failure
Jan  2 12:48:36 darkbasic postfix/smtpd[14133]: lost connection after AUTH from [...]
Jan  2 12:48:36 darkbasic postfix/smtpd[14133]: disconnect from [...]

Da /var/log/messages:

Jan  2 12:48:16 darkbasic postfix/smtpd[14133]: sql_select option missing
Jan  2 12:48:16 darkbasic postfix/smtpd[14133]: auxpropfunc error no mechanism available

Ecco /usr/lib/sasl2/smtpd.conf:

log_level: 3
pwcheck_method: auxprop
auxprop_plugin: sql
sql_engine: mysql
sql_hostnames: localhost
sql_database: postfix
sql_user: postfix
sql_passwd: my_password
sql_select: SELECT username, password FROM mailbox WHERE username = '%u'
sql_usessl: no

Inoltre ho modificato anche /etc/pam.d/smtp e /etc/pam.d/smtp.postfix:

#%PAM-1.0
#auth required pam_stack.so service=system-auth
#account required pam_stack.so service=system-auth
# Comment : SMTP AUTH with MySQL
# This is the first line
auth required pam_mysql.so user=postfix passwd=my_password host=127.0.0.1 db=postfix table=mailbox usercolumn=username passwdcolumn=password crypt=1
# This is a second line
account sufficient pam_mysql.so user=postfix passwd=my_password host=127.0.0.1 db=postfix table=mailbox usercolumn=username passwdcolumn=password crypt=1

/etc/postfix/main.cf è sostanzialmente quello delle guida.
Riporto anche una entry della tabella mailbox del database:

username 	password 	name 	maildir 	quota 	local_part 	domain 	created 	modified 	active
[email protected] 	$2$c40acac4$b.cdjROxeoKDD81QBa8hc0  	  	darkbasic.homelinux.com/darkbasic/ 	0 	darkbasic 	darkbasic.homelinux.com 	2002-01-01 10:40:59 	2002-01-01 10:40:59 	1

Non funziona una beneamata mazza e io non so più dove sbattere la testa..
Suggerimenti?

P.S.
Ovviamente postfix l'ho preso da centosplus in modo che avesse il supporto a mysql (2:2.3.3-2.1.centos.mysql_pgsql)

P.P.S.
Postfix non è chrootato in CentOS 5.3 vero?

[darkbasic]

Sarebbero molto utili anche informazioni su come debuggare il problema..

[darkbasic]

Auguro con tutto il cuore la cagarella a fischio a chi ha avuto la brillante idea di cambiare il comportamento di default da una versione all'altra di sasl
Dopo aver bestemmiato per giorni su questa cosa oggi ho notato per puro caso un [user:darkbasic], che compare in /var/log/messages SOLO ed esclusivamente quando si usa saslauthd in pwcheck_method (eh già, li ho provati tutti...). Avete capito dov'era il problema!? Le fottutissime nuove versioni di sasl troncano l'username cancellando il dominio
E questo è diventato il comportamento di default!!!
E' bastato avviare il demone con un -r per risolvere il problema.

[eclissi83]

Originariamente inviato da darkbasic

Auguro con tutto il cuore la cagarella a fischio a chi ha avuto la brillante idea di cambiare il comportamento di default da una versione all'altra di sasl

questa della cagarella la riutilizzo e ti prometto il "(cit. darkbasic)" alla fine.

Le fottutissime nuove versioni di sasl troncano l'username cancellando il dominio
E questo è diventato il comportamento di default!!!

scusassero la mia ignoranzita', ma come cappero gli e' venuto in mente di troncare i domini quando solitamente si fa un uso dei domini virtuali?

E' bastato avviare il demone con un -r per risolvere il problema.

il -r che sarebbe "utilizza il demone alla vecchia maniera che pero' non ti promettiamo potrai utilizzarlo nelle future versioni"?

[darkbasic]

Originariamente inviato da eclissi83

il -r che sarebbe "utilizza il demone alla vecchia maniera che pero' non ti promettiamo potrai utilizzarlo nelle future versioni"?

Dal bug tracking debian:

I second this. Upstream changed realm behaviour, which breaks pam_mysql
for example (if your username has form login@domain, saslauthd uses
only username part. If you use pam, the realm part gets lost on the
way).

In CVS, there's a fix to add -r switch, which allows to use the
compatible behaviour. However, I believe, -r should be default (and the
patch applied in Debian), so people who upgrade don't get these
problems.

Non solo hanno cambiato il comportamento di default da una versione all'altra (e tral'altro mi sfugge il motivo che ha portato a questo cambio), ma hanno avuto anche la bellissima idea di NON implementare uno switch che permettesse di ripristinare il vecchio comportamento
Soltanto di fronte alle richieste incazzate degli utenti e dei mantainer hanno aggiunto l'opzione "compatible behaviour", che in debian è diventata subito default (e infatti avendo lavorato sempre su debian non mi sono mai accorto di questa cosa).

Originariamente inviato da eclissi83

scusassero la mia ignoranzita', ma come cappero gli e' venuto in mente di troncare i domini quando solitamente si fa un uso dei domini virtuali?

La motivazione sfugge anche a me...

Originariamente inviato da eclissi83

questa della cagarella la riutilizzo e ti prometto il "(cit. darkbasic)" alla fine.

[iscka]

salve! ho lo stesso problema e non riesco a venirne fuori...
potresti gentilmente postarmi la tua conf di postfix?

Grazie!!

[darkbasic]

Adesso non ho accesso a quel server, la settimana prossima vedo di tirarti giu i config.