Before upgrading I had a prefect virual mail system setup after the gentoo guide, using Postfix 2.0.16-r1 and cyrus-sasl-2.1.15. After update to postfix 2.0.18 and cyrus-sasl-2.1.17 I couldn't send mail anymore, recieving worked fine. Rolling back to cyrus-sasl-2.1.15 solved the problem. What happen seam to be that sasl doesn't play well with pam (or pam_mysql) anymore. I got those errors in my auht.log: Jan 26 20:13:43 merc saslauthd[27289]: pam_mysql: select returned more than one result Jan 26 20:13:43 merc saslauthd[27289]: DEBUG: auth_pam: pam_authenticate failed: Permission denied Jan 26 20:13:43 merc saslauthd[27289]: do_auth : auth failure: [user=me] [service=smtp] [realm=mydomain.com] [mech=pam] [reason=PAM auth error] ------ The [user=me] should really have been [user=me@mydomain.com] so the last part seam to get "cut off" somewere. In mail.log this was pruduced when trying to send from Outlook 2003: Jan 26 18:31:11 merc postfix/smtpd[27444]: TLS connection established from ip-213-226-226-190.ji.cz[213.226.226.190]: TLSv1 with cipher RC4-MD5 (128/128 bits) Jan 26 18:31:11 merc postfix/smtpd[27444]: warning: ip-213-226-226-190.ji.cz[213.226.226.190]: SASL LOGIN authentication failed Jan 26 18:31:12 merc postfix/smtpd[27444]: warning: Read failed in network_biopair_interop with errno=0: num_read=0, want_read=5 Jan 26 18:31:12 merc postfix/smtpd[27444]: lost connection after AUTH from ip-213-226-226-190.ji.cz[213.226.226.190] Reproducible: Always Steps to Reproduce: 1. 2. 3. Other thing noticed is I doubt it really made Pam use my /etc/pam.d/smtp file triggering pam_mysql, because it really should have produced an entry in auth.log like: Jan 26 21:04:28 merc saslauthd[10722]: pam_mysql: error: sqllog set but logtable not set due to a bug in pam_mysql, were some debug code is left triggering this. It can be stopped by adding sqllog=0 to pam.d/smtp but I came across this solution only when trying to solve this issue. After rolling back the above log entry is coming back. merc postfix # emerge info Portage 2.0.50_pre20 (default-x86-1.4, gcc-3.3.2, glibc-2.3.3_pre20040117-r0, 2.4.22-gentoo-r5) ================================================================= System uname: 2.4.22-gentoo-r5 i586 AMD-K6(tm) 3D+ Processor Gentoo Base System version 1.4.3.12 Autoconf: sys-devel/autoconf-2.59 Automake: sys-devel/automake-1.7.8 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CFLAGS="-march=k6-3 -O3 -pipe" CHOST="i586-pc-linux-gnu" COMPILER="gcc3" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/share /config /var/bind /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/env.d" CXXFLAGS="-march=k6-3 -O3 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs ccache sandbox" GENTOO_MIRRORS="ftp://ftp.easynet.nl/mirror/gentoo// http://ftp.easynet.nl/mirror/gentoo//" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" USE="aalib apache2 avi berkdb crypt encode foomaticdb gd gdbm ggi gif gpm gtk2 imap imlib jpeg libg++ libwww mad maildir mpeg mysql ncurses nls pam pdflib png python quicktime readline sasl sdl slang spell ssl tcpd truetype usb wmf x86 xml xml2 zeo zlib"
Yeah I really saw this this delicate balance all falling down when Max announced for testing on these newer versions of key components... I've refused to upgrade my systems, as both are live. If Max doesnt have anything, I might work w/ Spyderous on finding a safe upgrade path.
btw im assuming you got this daemon spagetti setup from the virtual mail howto w/o deviation? This would help me in duplicating the situation.
Not quite: user is supposed to be "me" because the realm is "mydomain.com". I'm not sure where, but somehow pam_mysql needs to concat user and realm. Just curious... why do you auth using postfix->sasl->saslauthd->pam->mysql. Why not directly postfix->sasl->mysql? Tseng, I don't know what the howto says, but I have two servers running postfix 2.0.18, sasl 2.1.17, and mysql-4.0.16. I do all authentication directly from sasl to mysql. This is the cyrus recommended setup and has the added bonus of allowing cram-md5 and digest-md5 mechanisms. Maybe we need to update the howto to reflect this kind of setup? If you need the steps, I'll be happy to provide.
Max: this would be excellent. I am aware that the setup is the guide is largely unnessecary and just silly, and I've worked on your method and had a bit of success, but not enough to put back into production. This is a very frustrating issue for me, likely because of the over complicated setup. Myself (and many others I've helped w/ this setup) would be very grateful if you could provide a more sane revision to the current document. Thanks!
>From Brandon Hale 2004-01-26 16:27 PST ------- >btw im assuming you got this daemon spagetti setup from the virtual mail >howto w/o deviation? This would help me in duplicating the situation. Well I set it up some time ago and the howto may have changed, but the only thing I remember I changed was I created subdirs or each domain under /home/vmail and then added the extra bits in the path also in mysql, so basicly it shouldn't change anything, except it keps things a bit more organized :-) >From Max Kalika 2004-01-26 17:57 PST ------- >Not quite: user is supposed to be "me" because the realm is "mydomain.com". >I'm not sure where, but somehow pam_mysql needs to concat user and realm. According to the setup the user is the "me@domain.com" format, at least this is what been needed to auth the passwd with. The split must take place somewere else BUT I think this split it what causes the problem. >Just curious... why do you auth using postfix->sasl->saslauthd->pam->mysql. Why not directly postfix->sasl->mysql? Because the howto was setup that way and at the time I didn't have the experience or the time to restructure it, just need the mail to work. Although I aggree I find it circumstancial, but I down't know if there is any special reason behind it, more then possible the original creators own limitations. >Maybe we need to update the howto to reflect this kind of setup? If you need the steps, I'll be happy to provide. Yes a very good idea, lot's of people seam to want this kind of setup but most of them seam to have problems to get it to work following the howto, at least according to forum posts. I sure would find it easier and more efficiant to go straith to mysql just via sasl, just as long it works both with POP3 and IMAP (including Squirrelmail).
I've been hitting this same problem with 2.1.17. As described previously, saslauthd rips domain names from logins, providing the authentication method with a 'realm', which right now PAM auth does not use. I suppose this will soon change, but meanwhile for those that want bleeding edge I've written a patch against 2.1.17 to revert to previous behaviour with PAM _only_ so that it works in my servers. So far it's working without a hitch, although I cannot make any guarantees. I'll add the patch as an attachment. Hope it helps.
Oops, Konqueror is joking on me. Attached the patch to #39508 instead of this one. :S Anyway, attachment with patch is #25832. http://bugs.gentoo.org/attachment.cgi?id=25832&action=view
I have setup my home server follow the Virtual Mailhosting System with Postfix Guide. Upgraded to cyrus-2.1.17 broke my postfix smtp auth. After reading comment #3, I decided to replace pam_sql. Went through the cyprus-sasl mailing list give me some lead to auth as postfix --> sasl ---> mysql. I have to `USE="mysql" emerge cyrus-sasl and edit the file /etc/sasl2/smtpd.conf # cat /etc/sasl2/smtpd.conf pwcheck_method: auxprop auxprop_plugin: sql sql_engine: mysql mech_list: LOGIN PLAIN sql_user: mailsql sql_passwd: password sql_database: maisql sql_hostnames: localhost sql_select: SELECT clear FROM users WHERE email = '%u@%r' sql_verbose: yes For pop3 and imap, I don't think courier-imap uses pam to auth either. I deleted all files mentioned in code listing 10.1, and I still be able to login. Maybe the guide need to be revised? I don't think we need to patch postfix, we just need to change the postfix auth with mysql.
*** Bug 42244 has been marked as a duplicate of this bug. ***
Can we please get this patch into portage ASAP? It's causing a lot of breakage without it. (My mailserver included.) The patch worked for me, the config modifications as specified by Lang Thang did not.
Oh, btw, this patch applies and works sucessfully for .18 - I can confirm that.
Eh, I realized that there was a typo in the config (maisql as the table instead of mailsql) and the config changes *do* work. I understand that the cyrus-sasl devs would like to see pam as authentication deprecated ASAP, so I've switched sides of the fence here and would like to see the virtual mailhost guide changed. I am also under the impression that the new method with the config changes uses less resources. Can anyone confirm/deny this to give further reason to supporting the config changes?
After trying: "Comment #8 From Lang Thang 2004-03-26 20:55 PST" On a system running: - postfix-2.0.19 - mysql-4.0.18-r1 - cyrus-sasl-2.1.18 my smtpd.conf contains: pwcheck_method: auxprop auxprop_plugin: sql sql_engine: mysql mech_list: LOGIN PLAIN sql_user: mail sql_passwd: PASSWORD sql_database: mail sql_hostnames: localhost sql_select: SELECT clear FROM users WHERE email = '%u' sql_verbose: true produces the following in /var/log/auth.log: May 11 11:50:33 smtp01 postfix/smtpd[17762]: sql plugin could not connect to host localhost Also in my mysql.log I get: Connect mail@localhost on mail Now I've tried adding a user to mysql of "mail@localhost" which works from the shell, but still fails through sasl. Any help would be much appreciated.
you say you tried adding a user to mysql. how did you do this? working from shell and not working from sasl doesn't make sense in this context. does the mysql "mail" user exist? does this user have the password properly set up. is this user allowed to this database/table/column?
Let me try to clear any confusion up... Everything worked fine when it was running the older pam_mysql and sasl 2.1.15 When I updated everything broke. I found this page and tried auxprop That then didn't work either and I checked the logs which I presented earlier. The logs showed the user although set as just "mail" was connecting as "mail@localhost" so I added the user "mail@localhost" to the mysql user and db tables with the proper permissions. I can manually login to mysql as both "mail" and "mail@localhost"; however sasl is failing to connect using the exact login info that I manually typed. I've read all over the internet and numerous other people are posting with this exact same error.
try "sql_select: SELECT clear FROM users WHERE email = '%u@%r'" in your smtpd.conf . Make sure that mysql user 'mail' can connect to the database and table.
The user's don't have a realm so @%r would cause any lookup to fail. But that isn't even the issue, sasl is failing to even connect to the mysql server in the first place. And as I said both times before, the users can all connect just fine manually, and also used to work on the older version..
could you please post the output of `cat /etc/mysql/my.cnf | grep socket`. Could it be that you change it to something else other than the default '/var/run/mysqld/mysqld.sock'?
socket = /tmp/mysql.sock But the socket shouldn't matter no? Since sasl is connecting to a host(localhost), and not the sock. Esp. since the db _could_ be on a remote box in which case the sock would definately not even be used.
read this http://asg.web.cmu.edu/archive/message.php?mailbox=archive.cyrus-sasl&msg=5024
I had already viewed that yesterday and there's no solution behind that link.. Results of 'mysql> status': mysql> status -------------- mysql Ver 12.22 Distrib 4.0.18, for pc-linux-gnu (i686) Connection id: 3199 Current database: mail Current user: mail@localhost SSL: Not in use Current pager: /usr/bin/less Using outfile: '' Server version: 4.0.18 Protocol version: 10 Connection: Localhost via UNIX socket Client characterset: latin1 Server characterset: latin1 UNIX socket: /tmp/mysql.sock Uptime: 4 hours 22 min 22 sec Threads: 233 Questions: 1151529 Slow queries: 0 Opens: 21 Flush tables: 1 Open tables: 15 Queries per second avg: 73.150 -------------- Uses the sock in /tmp just as postfix does when checking virtual maps. I have also tried putting the database on another server and connecting to it. This worked just as everything else: worked manually, didn't work through sasl.
IMHO, you have a couple choice: 1. fall back to the older cyrus-sasl, and bug upstream ;). Good luck. 2. change 'socket = /var/run/mysqld/mysqld.sock' in '/etc/mysql/my.cnf' 3. If your mail server on the same machine as your mysql server and listen TCP change '/etc/sasl2/smtpd.conf' line 'sql_hostnames: 127.0.0.1' to connect to mysql use TCP instead of UNIX socket. 4. If your mail sevrer is not on the same machine with mysql server then 'sql_hostnames: <mysql_server_ip>. I assume that you know howto setup mysql so it accept connection from other machine than 'localhost'. Hint: mysql> GRANT SELECT,INSERT,UPDATE,DELETE -> ON mailsql.* -> TO mailsql@'%' -> IDENTIFIED BY '$password'; if you emerge mysql with USE="tcpd", don't forget to add mysqld entry in /etc/hosts.allow
1. I was trying to avoid that. 2. That did't work, I'd already tried it before. 3. I'd already tried that and it failed. 4. If you read what I'd previously posted entirely you'd find that I already did this too... So what you're telling me then is to basically go back to an older version because the last few releases are faulty?
I didn't say that "the last few releases are faulty". AFAIK, cyrus-sasl dev dicided to split user@domain to "user" "realm" starting from cyrus-sasl-2.1.18 that broke pam_mysql. That is the way I understand following this thread: http://asg.web.cmu.edu/archive/message.php?mailbox=archive.cyrus-sasl&msg=5419
Yeah well I've fallen back to the older release for now, I'll try again with the next release. Thanks.
This bug is ridiculous and should (and can) be resolved quickly. Here is my summary of and recommendation for the situation: - cyrus-sasl-2.1.17 changes the behavior of PAM authentication, in that it now splits user@domain to user and realm. - pam_mysql is not actively maintained and does not support the PAM key "realm"; it expects the full username in the "user" key. A patch to include this additional support is not trivial. - cyrus-sasl can talk directly to mysql and does not need to use PAM (although it could be useful for other reasons). This setup has been tested with success by at least two users who reported above. - Chris Landegent is experiencing a connection problem between cyrus-sasl and his mysql database that is not related to this bug. Chris, I suggest you seek assistance on the Gentoo forums or IRC channels. My recommendation is to warn users installing cyrus-sasl-2.1.17 and above about the changed behavior, and suggest a downgrade if they do not want to change their config. In addition, the HOWTO should be changed ASAP to not recommend the use of pam_mysql. As long as the HOWTO says to use pam_mysql, we will continue to get bug reports and forum posts about the issue. At the very least, we should put a warning at the top of the current HOWTO stating that "this setup requires cyrus-sasl-2.1.15 or below" (cyrus-sasl-2.1.16 is not recommended by the cyrus-sasl dev team). Attached is a patch to add a warning.
Created attachment 33257 [details, diff] cyrus-sasl-2.1.17.ebuild.diff This applies cleanly to cyrus-sasl-2.1.18.ebuild.diff as well.
Created attachment 33263 [details, diff] virt-mail-howto.xml.diff Here's a patch to add a warning to the existing Howto. Sorry I couldn't update the whole thing; I do not have a test setup.
This link http://asg.web.cmu.edu/archive/message.php?mailbox=archive.cyrus-sasl&searchterm=patch&msg=4669 provides a simple patch I used to work around the problem. The previous comments about changing the smtp auth approach may have merit. The simple patch restores the old behavior.
How about I implement a local USE flag to turn on "old" behavior using David's patch?
pam-mysql flag and patch now in portage as cyrus-sasl-2.1.18-r1. Incidently, there are some other important fixes and hopefully everyone can upgrade to 2.1.18 now. We'll try to get a new HOWTO and announcement out ASAP.
Well this is great news, now I finally can go ahead and update Postfix and Cyrus-sasl, however... I would really like to see the Howto updated to use the new more direct auth postfix->sasl->mysql and what about the postfixadmin package? A request for it (http://bugs.gentoo.org/show_bug.cgi?id=50035) was done months ago, and even an ebuild submitted, but still not in portage :-( I'm not sure if there is a problem with that package though, regarding sasl and mysql and MD5 auths. The homepage says sasl doesn't support MD5 with mysql but maybe this is old news?
Hi, Thanks, it is mandatory for me to use pam_mysql. I want to have real and virtual users. So I need something like that in my pam files: auth sufficient pam_mysql.so server=localhost db=mailsql user=mailsql passwd=xxxxxxxxxxxxxxxxxxxxx table=users usercolumn=email passwdcolumn=crypt crypt=1 sqllog=0 account sufficient pam_mysql.so server=localhost db=mailsql user=mailsql passwd=xxxxxxxxxxxxxxxxxxxxx table=users usercolumn=email passwdcolumn=crypt crypt=1 sqllog=0 auth sufficient /lib/security/pam_unix.so nullok shadow account sufficient /lib/security/pam_unix.so If somebody has a good idea to make the same things with postfix->sasl->mysql I will be happy. Maybe some postfix trick to have 2 auth sceme. Thanks
*** Bug 57496 has been marked as a duplicate of this bug. ***
*** Bug 52602 has been marked as a duplicate of this bug. ***
Bug #57496 is NO duplicate of this bug. this bug is about cyrus-sasl not being able to use pam_mysql correctly doe to the introduction of the new realm entities which are not yet in pam_mysql bug #57496 is about the direct cyrus-sasl -> mysql not being able to connect to the mysql server at all, as mentioned above by some post and causing much confusion so I'd say we have definitely 2 bugs and forcing this into one doesnt help at all.
