mail-mta/postfix-2.1.3 worked fine with the previous version of dev-libs/cyrus-sasl (2.1.14 IIRC). after the upgrade to 2.1.18 I get this error (tried to remerge both postfix and cyrus-sasl): --8<-- Jul 8 00:23:35 prometheus postfix/smtpd[15110]: sql_select option missing Jul 8 00:23:35 prometheus postfix/smtpd[15110]: auxpropfunc error no mechanism available Jul 8 00:23:35 prometheus postfix/smtpd[15110]: _sasl_plugin_load failed on sasl_auxprop_plug_init for plugin: sql Jul 8 00:23:35 prometheus postfix/smtpd[15110]: connect from localhost[127.0.0.1] Jul 8 00:23:35 prometheus postfix/smtpd[15110]: 4CBB12C10E: client=localhost[127.0.0.1] --8<-- Then I noticed this: --8<-- Jul 8 00:22:25 prometheus saslpasswd2: sql_select option missing Jul 8 00:22:25 prometheus saslpasswd2: auxpropfunc error no mechanism available Jul 8 00:22:25 prometheus saslpasswd2: _sasl_plugin_load failed on sasl_auxprop_plug_init for plugin: sql Jul 8 00:22:25 prometheus saslpasswd2: setpass succeeded for login Jul 8 00:22:25 prometheus saslpasswd2: Couldn't delete entry in /var/tmp/portage/cyrus-sasl-2.1.18-r1/image//etc/sasl2/sasldb2: gdbm_errno=15 --8<-- So it's not a Postfix problem - it already happened during the merge of cyrus-sasl. The packages are compiled with the following USE flags enabled: --8<-- [ebuild R ] mail-mta/postfix-2.1.3 +ipv6 +ldap +mailwrapper +mbox +mysql +pam +postgres +sasl +ssl +vda 0 kB [ebuild R ] dev-libs/cyrus-sasl-2.1.18-r1 +gdbm +java +kerberos +ldap +mysql +pam +pam-mysql +postgres +ssl -static 0 kB --8<-- It happened on both machines I tried it on.
I believe that if you have the USE flag pam-mysql turned on, auxprop authentication will no longer work, since it expects user and realm separately. Please also see Bug 56314 to make sure that isn't the same problem. David, can you please take a look at this, since you suggested the patch. Thank you!
Well, at first I had pam-mysql turned off. I only turned it on after I saw those failures. I can also confirm that #56314 is unrelated to my problem.
@reporter and Wolfram Schlich: `emerge cyrus-sasl -pv`, `emerge postfix -pv`, /etc/sasl2/smtpd.conf please.
Ok, another mistake in the patch. Fixed patch is in CVS. I bumped the revision to -r2 so everyone gets the fix.
@comment #3 --8<--[ emerge -pv postfix cyrus-sasl ]--8<-- [ebuild R ] mail-mta/postfix-2.1.3 +ipv6 +ldap +mailwrapper +mbox +mysql +pam +postgres +sasl +ssl +vda 0 kB [ebuild U ] dev-libs/cyrus-sasl-2.1.18-r2 [2.1.18-r1] +gdbm +java +kerberos +ldap +mysql +pam +pam-mysql +postgres +ssl -static 0 kB --8<-- --8<--[ /etc/sasl2.smtpd.conf ]--8<-- pwcheck_method:pam --8<-- @comment #4 so... what got fixed now? the pam-mysql patch? _but_ I had those errors even when not having merged cyrus-sasl with the pam-mysql USE flag enabled... will try now though.
I still get the error during merge: --8<-- Jul 8 08:57:36 chiron saslpasswd2: sql_select option missing Jul 8 08:57:36 chiron saslpasswd2: auxpropfunc error no mechanism available Jul 8 08:57:36 chiron saslpasswd2: _sasl_plugin_load failed on sasl_auxprop_plug_init for plugin: sql Jul 8 08:57:37 chiron saslpasswd2: setpass succeeded for login Jul 8 08:57:37 chiron saslpasswd2: Couldn't delete entry in /var/tmp/portage/cyrus-sasl-2.1.18-r2/image//etc/sasl2/sasldb2: g dbm_errno=15 --8<-- postfix behaves the same (after a restart): --8<-- Jul 8 08:58:58 chiron postfix/smtpd[18368]: sql_select option missing Jul 8 08:58:58 chiron postfix/smtpd[18368]: auxpropfunc error no mechanism available Jul 8 08:58:58 chiron postfix/smtpd[18368]: _sasl_plugin_load failed on sasl_auxprop_plug_init for plugin: sql Jul 8 08:58:58 chiron postfix/smtpd[18368]: connect from localhost[127.0.0.1] --8<-- should I remerge postfix?!
remerging postfix didn't help -- I guess that's due to the fact that postfix is dynamically linked to cyrus-sasl :> so, we can forget postfix here. running "sasldblistusers2" results in the same error: --8<-- Jul 8 09:47:08 prometheus sasldblistusers2: sql_select option missing Jul 8 09:47:08 prometheus sasldblistusers2: auxpropfunc error no mechanism available Jul 8 09:47:08 prometheus sasldblistusers2: _sasl_plugin_load failed on sasl_auxprop_plug_init for plugin: sql Jul 8 09:47:08 prometheus sasldblistusers2: Could not open /etc/sasl2/sasldb2: gdbm_errno=7 Jul 8 09:47:08 prometheus sasldblistusers2: _sasldb_getkeyhandle has failed --8<-- it might be interesting that /etc/sasl2/sasldb2 _is_ existing _and_ readable _and_ contains sane data.
problem persists with -r2 -- reopening
There was a problem with the sasl-path.patch that I was able to reproduce with Joker <joker@gentoo.org> which exhibited identical behavior to what you showed below, fix that problem, and reliably test authentication with the new patch. I will need an strace of saslauthd failing the auth request to determine what is going on here. Does your configuration use the environment variable SASL_PATH? Thanks.
we're not talking about saslauthd here. the problem happens when running "sasldblistusers2" and "saslpasswd2". and no, I'm not using SASL_PATH. also the problem only affects the *sql* plugin, but no other plugin (see /usr/lib/sasl2/lib*.so).
Ok, I cannot really tell anything from the log output. Can you get me any additional error messages, debug or otherwise? Also, I could really use an strace output for either of the programs failing. Thank you for continuing to investigate this issue.
I also do not understand why sasl_plugin would be using auxprop at all, let alone the sql plugin. You clearly have the authentication method configured for pam. Also, why do you have data in /etc/sasl2/sasldb2 if you are using the pam auth method? A brief overview of your setup would be very helpful.
Ok, another thing... all the output you have pasted is log messages. When you run sasldblistusers2 what output goes to the console? Does the program actually fail? Do actual authentication attempts fail? Is the error the same for when actual authentication attempts fail? If not, please post that error.
@comment #13 I haven't even _tried_ to _authenticate_ :-) Here's the output of sasldblistusers2 (yes, it fails): --8<-- [wschlich@prometheus(pts/131):wschlich]$ sudo sasldblistusers2 listusers failed [wschlich@prometheus(pts/131):wschlich]$ --8<-- During the same time I get those syslog messages.
@comment #11 here's an strace log of sasldblistusers2: http://dev.gentoo.org/~wschlich/tmp/sasldblistusers2.strace.log
Can you try to authenticate as well, please?
ok, I merged cyrus-sasl with USE="-mysql -postgres" so the SQL support got dropped. now everything works fine and I don't get any error messages. can anyone investigate what problem that sql plugin has? I will also try to merge cyrus-sasl with USE="-mysql postgres" and USE="mysql -postgres" so see whether the problem is maybe related to generic-sql-plugin + <specific-db-plugin> or _only_ specific to the generic-sql-plugin.
> --8<--[ /etc/sasl2.smtpd.conf ]--8<-- > pwcheck_method:pam > --8<-- Wolfram, it looks like you don't use "auxprop" at all. You are getting these errors in message log is because you have the sql plugins installed (+mysql +postgres) and the SASL library tries to initialize each auxprop plugin that it finds and confused with both sql plugins installed on your system. This is an upstream behavior. If you wish to use sql plugin, please specify which one to use: some_app_use_sasl2.conf: pwcheck_method: auxprop auxprop_plugin: sql sql_engine: mysql _or_one_of_your_favorite_ ... So the solution for you would be: a. -mysql -postgres as you already did. b. use auxprop. Please see bug #39497 for the correct syntax/format to use with the auxprop_plugin. Good read for SASL options: http://asg.web.cmu.edu/cyrus/download/sasl/options.html
I have the same problem. However, I explicitely ask to not load sql. ------ pwcheck_method:saslauthd mech_list:plain login auxprop_plugin:plain login ------ It worked fine with the previous version (2.1.14). I can also see that libsql is indeed loaded by smtpd. However, it's not listed with ldd. Actually, all the libraries in /usr/lib/sasl2/ are loaded, not just libplain and liblogin (i.e libanonymous, libcrammd5, libdigestmd5, libntlm, libsql. libsasldb is also but I assume this one is mandatory) [ebuild R ] dev-libs/cyrus-sasl-2.1.18-r2 +gdbm -java -kerberos +ldap +mysql +pam -pam-mysql -postgres +ssl -static 0 kB [ebuild R ] mail-mta/postfix-2.0.19 -ipv6 +ldap +maildir -mbox +mysql +pam -postgres +sasl +ssl 321 kB
Nahor, please try with: pwcheck_method:saslauthd mech_list:plain login only use "auxprop_plugin:..." in combine with "pwcheck_method: auxprop"
Tuan, no help there, it doesn't work either.
Nahor, if the problem is the errors appeared messages log, please read my comment #18 above. You need `echo "dev-libs/cyrus-sasl -mysql -postgres" >> /etc/portage/package.use && emerge cyrus-sasl`. Note: create /etc/portage as needed. you are using "pwcheck_method:saslauthd", you don't need sql support.
Yes, I can do that. And did and it works :). But still, it's only a workaround, I shouldn't have had to do it. I didn't do it before and it was working fine. So the bug should not be resolved fixed. The problem is still there (or it should be closed as INVALID/WONTFIX if you think the bug is in cyrus-sasl and not in Gentoo).
As Cory mentioned in comment #1, the pam_mysql workaround breaks auxprop, but since Nahor didn't have pam_mysql in USE, I agree with him: this is still a bug. Indeed, you should be able to link in all of the backend options (kerberos, ldap, mysql, pam, AND postgres) and choose from them arbitrarily at runtime. Keep in mind that this is not academic: what if a user is using different both auxprop and saslauthd for different applications? SASL is supposed to allow that. So is this an upstream bug, or is it introduced in one of the patches applied by the Gentoo ebuild?
Nahor, it is an upstream bug/feature depend on where you stand ;). By default, sasl try to be 'smart' and load all the plugins. (Why? because if you take time to compile the plugins, it mean you want to use it, right?.) When it comes to load the sql plugin, sasl doesn't see the sql_select statement, it try to be 'smart' again telling you that. The bug should be resolved as UPSTREAM. for a good read: http://asg.web.cmu.edu/archive/message.php?mailbox=archive.cyrus-sasl&msg=5526 google is your friend. :) Regards, Tuan
resolved UPSTREAM.
> it is an upstream bug I don't have UPSTREAM on my own bugzilla installation and nor does bugzilla.mozilla.org and I never had any reason to check if Gentoo customized its list so I didn't know about it. Everyday we learn a new thing :) > sasl try to be 'smart' and load all the plugins. (Why? because if you take time to compile the plugins, it mean you want to use it, right?.) I would say that sasl is actually stupid given the number of distribution offering precompiled packages which usually compiles all the features. It it was 'smart', it would not try to initialized a plugin unless it is actually needed ;) > google is your friend Yeah, I know, but only if you make to good request. It gave me a link for the auxprop_plugin trick a few month ago. It gave the link to a post in gentoo-user which gave me a link to this bug. Bug it didn't give your link. :( But thanks for the link (and your help), I learn several new things today :):)
I don't know what the ultimate answer is, but as a generic user with a generic server this hurts. I had followed the gentoo doc for setting up a virtual mail server about a year ago and the natural 'emerge -u world' picked up the cyrus-sasl upgrade recently but without the specialized USE variables and broke my email setup. So I end up spending several hours tracking the problem down and fixing it. It could be argued that I should know this up front, but I have hundreds of packages on my system, the email setup is infrastructure, not primary focus. Once I spend the time getting email functioning I expect it to basically work through upgrades. I'm re-emergeing with -mysql -postgres cyrus-sasl now and hoping that fixes sasl.
More constructive than my last post ... http://archives.neohapsis.com/archives/postfix/current/0103.html describes what is biting me now. I assume this is what is referred to as the pam-mysql problem in this bug report. I believe postfix->sasl->saslauthd->pam->mysql with the domain being stripped from the userid. According to the above url this will be fixed shortly ... ? BTW, if anyone else traces these comments trying to puzzle this out, what happens is that blat@something.com gets searched for in your mysql (others as well) as just 'blat' with the '@something.com' stripped off. Turn on mysql logging to see it. Does anyone know if there is a simple configuration fix in sasl/pam that automatically glues these two pieces back together before the query.
(Apologize for thrashing the comments) If your problem is the domain being stripped from the full username (blat@something.com becoming blat) and if you only have a few users a short term fix until the 2.1.19 version comes out (which is supposed to fix this problem) is to add a duplicate entry in the mysql users db for each user, so you end up picking up just 'blat' with a password. Hope this short term fix is useful.
Heitzso, did you miss this warning when you upgraded: * * Starting with version 2.1.17 of cyrus-sasl, the cyrus-sasl team has switched * to an authentication style that BREAKS pam_mysql. * * If you are using pam_mysql, it is recommended you convert to cyrus-sasl's * auxprop sql authentication support using smtpd.conf. * * If you do not wish to change your configuration, you may put "pam-mysql" * in your USE flags to revert to the old (deprecated) authentication behavior. *
hi, i tried also cyrus-sasl-2.1.18-r2 and it breaks my setup :-( I have a running web-cyradm installation with some domains. webcyradm has this way: Cyrus -> saslauthd -> PAM -> mysql (shadow compa. passwords) I used the pam_mysql USE key, but it didn't helps :-/ so i switched back to 2.1.5. Are there any admins with same problems?
@Denny Schierz: If you don't my using ~x86, unmask and try cyrus-sasl-2.1.19.
@comment #33 well, currently ~x86 is supposed to be more "stable" than x86 regarding this package, right? :) IMHO it should *never* have been happened the way it did -- cyrus-sasl is a component far too important to not test it more... We won't get further into the corporate area with Gentoo that way, really :-( I mean, if Mutt breaks -- well, almost nobody's supposed to run critical services based on Mutt... but things like Apache, PHP, MySQL, Postfix/Sendmail/Exim/QMail, they are core service components. Of course, one should always test new packages on a staging machine, but the world's just a bit suboptimal here :]
@comment #34: > well, currently ~x86 is supposed to be more "stable" than x86 regarding this package, right? :) Do you get that from my comment? The reason I asked Denny to try .19 because they has bug fix, including an option to revert back to the pre .17 versions that bite so many of us. If you follow the cyrus-sasl mailing list, you already know that cyrus suprise a lot of people when they made that change, it is not only affected Gentoo. You are one of the developer, please feel free to jump in and help cyrus-sasl x86 stable as it should.
Wolfram, I think your comment about testing was a bit harsh. Upstream changed how cyrus-sasl works, and merlin and langthang not only tested the new behavior, they added a notice about the new behavior _and_ wrote a brand new patch to help people use the old behavior. I do agree with you that cyrus-sasl is a critical component of a _lot_ of systems, but as far as being more "enterprise" goes, no self-respecting enterprise user would upgrade core services w/o testing them w/ their own configuration. We don't guarantee that a configuration that worked for version x.y will work with x.z because upstream generally does not guarantee it.
yes, you're right -- my apologies to merlin and langthang :-( New try: I simply believe we should do more testing and think about new ways to communicate important changes to our users. Simply using "einfo" or "ewarn" inside ebuilds IMHO isn't enough. Any thoughts about this? :)
In response to:> Simply using "einfo" or "ewarn" inside > ebuilds IMHO isn't enough. > Any thoughts about this?Would it make sense to add "einfo" and "ewarn" output to the emerge -pv switches? Maybe another switch?
