Hello,
Is anybody using the cyrus-sasl mysql backend on 4.3?
I have problems with it, it keeps segfaulting whenever the process enters sasl code.
Feizhou
Feizhou a écrit :
Hello,
Is anybody using the cyrus-sasl mysql backend on 4.3?
I have problems with it, it keeps segfaulting whenever the process enters sasl code.
Feizhou _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
I use these rpms: cyrus-sasl-md5-2.1.19-5.EL4 cyrus-sasl-2.1.19-5.EL4 cyrus-sasl-plain-2.1.19-5.EL4 cyrus-sasl-devel-2.1.19-5.EL4 cyrus-imapd-2.2.12-3.RHEL4.1 cyrus-imapd-utils-2.2.12-3.RHEL4.1 cyrus-sasl-sql-2.1.19-5.EL4
pam_mysql-0.7RC1-1gral
The "only" problem is to add in /etc/sysconfig/saslauthd FLAGS="-n 0" to avoid a memory leak.
Regards
jean-seb.
security wrote:
Feizhou a écrit :
Hello,
Is anybody using the cyrus-sasl mysql backend on 4.3?
I have problems with it, it keeps segfaulting whenever the process enters sasl code.
Feizhou _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
I use these rpms: cyrus-sasl-md5-2.1.19-5.EL4 cyrus-sasl-2.1.19-5.EL4 cyrus-sasl-plain-2.1.19-5.EL4 cyrus-sasl-devel-2.1.19-5.EL4 cyrus-imapd-2.2.12-3.RHEL4.1 cyrus-imapd-utils-2.2.12-3.RHEL4.1 cyrus-sasl-sql-2.1.19-5.EL4
pam_mysql-0.7RC1-1gral
that's not quite using the cyrus-sasl mysql code...that's using a pam backend that uses a mysql store...
The "only" problem is to add in /etc/sysconfig/saslauthd FLAGS="-n 0" to avoid a memory leak.
great...I remember that I had to recompile FC2 cyrus-sasl to get mysql support and that I had to add some option to the configure script...and that postfix + cyrus-sasl + mysql did work
regards,
feizhou
Feizhou wrote:
Hello,
Is anybody using the cyrus-sasl mysql backend on 4.3?
I have problems with it, it keeps segfaulting whenever the process enters sasl code.
Found the problem. I am using postfix 2.2.10 and when it was compiled...it used sasl v1 headers but linked against sasl v2...fixed by adding -I/usr/include/sasl to use sasl v2 headers...
regards.
feizhou
Feizhou wrote:
Feizhou wrote:
Hello,
Is anybody using the cyrus-sasl mysql backend on 4.3?
I have problems with it, it keeps segfaulting whenever the process enters sasl code.
Found the problem. I am using postfix 2.2.10 and when it was compiled...it used sasl v1 headers but linked against sasl v2...fixed by adding -I/usr/include/sasl to use sasl v2 headers...
argh...posted too soon.
Normal mail works now...but smtp auth which loads sasl code results in smtpd crashing...sigh
feizhou
guess what...RHEL4's postfix also crashes with using cyrus-sasl code with the sql plugin.
there must be something wrong with the way cyrus-sasl-sql was built...
On Tue, Jul 04, 2006 at 05:11:05PM +0800, Feizhou enlightened us:
guess what...RHEL4's postfix also crashes with using cyrus-sasl code with the sql plugin.
there must be something wrong with the way cyrus-sasl-sql was built...
You still haven't specified which version of cyrus-sasl-sql you're using, other than a mention that you once recompiled it from or on (not real clear) FC2.
It's tough for people to help if you don't provide the details and/or if you are bastardizing CentOS.
Matt
Matt Hyclak wrote:
On Tue, Jul 04, 2006 at 05:11:05PM +0800, Feizhou enlightened us:
guess what...RHEL4's postfix also crashes with using cyrus-sasl code with the sql plugin.
there must be something wrong with the way cyrus-sasl-sql was built...
You still haven't specified which version of cyrus-sasl-sql you're using, other than a mention that you once recompiled it from or on (not real clear) FC2.
Oh yeah, I better also mention that that was the x86-64 edition of FC2 on a dual Opteron box and to make it perfectly clear, that is a different box to what I have now which is just a P4 box running Centos 4 which I keep updated and therefore Centos 4.3.
It's tough for people to help if you don't provide the details and/or if you are bastardizing CentOS.
Sir, I stated the use of Centos 4.3, there are no updates for cyrus-sasl* available and you are naive to think that everything in RHEL4/Centos 4 works properly. Look at the mess Redhat made with their kernel vm patch for those who require performance in addition to stability.
I take offense at the notion that reporting problems with distribution provided software is equivalent to 'bastardizing CentOS' especially since I took pains to point out that the code comes from Redhat and not from the Centos project.
An attempt to get a backtrace gives these results:
-------------------------------------------------------------------------- GNU gdb Red Hat Linux (6.3.0.0-1.96rh) Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux-gnu"...Using host libthread_db library "/lib/tls/libthread_db.so.1".
Attaching to program: /usr/libexec/postfix/smtpd, process 29765 Reading symbols from /usr/lib/mysql/libmysqlclient.so.14...done. Loaded symbols for /usr/lib/mysql/libmysqlclient.so.14 Reading symbols from /usr/lib/libsasl2.so.2...done. Loaded symbols for /usr/lib/libsasl2.so.2 Reading symbols from /lib/libpcre.so.0...done. Loaded symbols for /lib/libpcre.so.0 Reading symbols from /lib/libssl.so.4...done. Loaded symbols for /lib/libssl.so.4 Reading symbols from /lib/libcrypto.so.4...done. Loaded symbols for /lib/libcrypto.so.4 Reading symbols from /lib/tls/i686/libdb-4.2.so...done. Loaded symbols for /lib/tls/i686/libdb-4.2.so Reading symbols from /lib/libnsl.so.1...done. Loaded symbols for /lib/libnsl.so.1 Reading symbols from /lib/libresolv.so.2...done. Loaded symbols for /lib/libresolv.so.2 Reading symbols from /lib/tls/libc.so.6...done. Loaded symbols for /lib/tls/libc.so.6 Reading symbols from /lib/libcrypt.so.1...done. Loaded symbols for /lib/libcrypt.so.1 Reading symbols from /lib/tls/libm.so.6...done. Loaded symbols for /lib/tls/libm.so.6 Reading symbols from /usr/lib/libz.so.1...done. Loaded symbols for /usr/lib/libz.so.1 Reading symbols from /lib/libdl.so.2...done. Loaded symbols for /lib/libdl.so.2 Reading symbols from /usr/lib/libgssapi_krb5.so.2...done. Loaded symbols for /usr/lib/libgssapi_krb5.so.2 Reading symbols from /usr/lib/libkrb5.so.3...done. Loaded symbols for /usr/lib/libkrb5.so.3 Reading symbols from /lib/libcom_err.so.2...done. Loaded symbols for /lib/libcom_err.so.2 Reading symbols from /usr/lib/libk5crypto.so.3...done. Loaded symbols for /usr/lib/libk5crypto.so.3 Reading symbols from /lib/tls/libpthread.so.0...done. [Thread debugging using libthread_db enabled] [New Thread -1208244544 (LWP 29765)] Loaded symbols for /lib/tls/libpthread.so.0 Reading symbols from /lib/ld-linux.so.2...done. Loaded symbols for /lib/ld-linux.so.2 Reading symbols from /lib/libnss_files.so.2...done. Loaded symbols for /lib/libnss_files.so.2 0x007f37a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 (gdb) Detaching from program: /usr/libexec/postfix/smtpd, process 29765 ------------------------------------------------------------------------
All traces show the crash in _dl_sysinfo_int80 for those who are interested in licking this one. Are there any debug rpms available?
On Wed, Jul 05, 2006 at 09:10:31AM +0800, Feizhou enlightened us:
Matt Hyclak wrote:
On Tue, Jul 04, 2006 at 05:11:05PM +0800, Feizhou enlightened us:
guess what...RHEL4's postfix also crashes with using cyrus-sasl code with the sql plugin.
there must be something wrong with the way cyrus-sasl-sql was built...
You still haven't specified which version of cyrus-sasl-sql you're using, other than a mention that you once recompiled it from or on (not real clear) FC2.
Oh yeah, I better also mention that that was the x86-64 edition of FC2 on a dual Opteron box and to make it perfectly clear, that is a different box to what I have now which is just a P4 box running Centos 4 which I keep updated and therefore Centos 4.3.
Thank you for clarifying, that was confusing in your first e-mail.
It's tough for people to help if you don't provide the details and/or if you are bastardizing CentOS.
Sir, I stated the use of Centos 4.3, there are no updates for cyrus-sasl* available and you are naive to think that everything in RHEL4/Centos 4 works properly. Look at the mess Redhat made with their kernel vm patch for those who require performance in addition to stability.
I take offense at the notion that reporting problems with distribution provided software is equivalent to 'bastardizing CentOS' especially since I took pains to point out that the code comes from Redhat and not from the Centos project.
I was merely pointing out the fact that recompiling an SRPM from a different distribution is not supported or recommended, and therefore 'bastardizing' the OS. It was unclear what you had done from your first mail, but it sounded awfully close to "I rebuilt the FC2 RPM on my CentOS box". If you were offended by my tone, I appologize, but I'd recommend getting some thicker skin in the future...I know perfectly well that RedHat doesn't ship bug free software, or even software that is compatible with other software in the distro. Reporting the problem is appreciated, but as I said, it was unclear if you were reporting a problem with CentOS's RPM or FC2's RPM.
An attempt to get a backtrace gives these results:
------------< snip <------< snip <------< snip <------------
All traces show the crash in _dl_sysinfo_int80 for those who are interested in licking this one. Are there any debug rpms available?
Unfortunately the backtrace isn't terribly useful.
The debug RPMs are stored at http://vault.centos.org/debuginfo *but* it appears that the cyrus-* rpms are missing.
Do you have access to a true RHEL 4 machine? Can this be replicated there? If so, reporting the issue upstream would be best, with an entry in CentOS's bug tracker with a pointer to the upstream bugzilla. If it can't be replicated there, filing a bug report with CentOS would be the best course of action.
Matt
I guess the references to my previous experience on FC2 do cloud things a bit.
I was merely pointing out the fact that recompiling an SRPM from a different distribution is not supported or recommended, and therefore 'bastardizing' the OS. It was unclear what you had done from your first mail, but it sounded awfully close to "I rebuilt the FC2 RPM on my CentOS box". If you were offended by my tone, I appologize, but I'd recommend getting some thicker skin in the future...I know perfectly well that RedHat doesn't ship bug free software, or even software that is compatible with other software in the distro. Reporting the problem is appreciated, but as I said, it was unclear if you were reporting a problem with CentOS's RPM or FC2's RPM.
Why would I use a source rpm from FC2? :)
It's Centos/RHEL 4's cyrus-sasl rpm. Specifically, the cyrus-sasl-sql rpm. It appears all other code seem to work except for the sql plugin. I am not sure if that is due to configuration error, which seems unlikely since i copied the configuration for smtpd.conf from the FC2/Opteron box, or due to threading /sasl initialization issues.
An attempt to get a backtrace gives these results:
------------< snip <------< snip <------< snip <------------
All traces show the crash in _dl_sysinfo_int80 for those who are interested in licking this one. Are there any debug rpms available?
Unfortunately the backtrace isn't terribly useful.
Nope. All I could find from searching on the '_dl_sysinfo_int80 ()' string was something about threading or hyper-threading being enabled causing crashes...does Pentium 4 2.8 Ghz cpus have hyper-threading?
The debug RPMs are stored at http://vault.centos.org/debuginfo *but* it appears that the cyrus-* rpms are missing.
Boo.
Do you have access to a true RHEL 4 machine? Can this be replicated there? If so, reporting the issue upstream would be best, with an entry in CentOS's bug tracker with a pointer to the upstream bugzilla. If it can't be replicated there, filing a bug report with CentOS would be the best course of action.
Wish I did have one...otherwise I would have just filed a bug report.
Anyway, I recompiled the cyrus-sasl source rpm after enabling another plugin that I could make use of and now things are working for me...the the rebuilt sql plugin still crashes but the other plugin allows me to make use of the mysql tables I have without doing pam_mysql.
I wonder what is it that is causing the crashes...the logs tell me that postfix initiated sasl initialization and then it crashes with no other information...but I guess I can drop it now...
regards,
feizhou
On Wed, Jul 05, 2006 at 01:48:40PM +0800, Feizhou enlightened us:
I guess the references to my previous experience on FC2 do cloud things a bit.
I was merely pointing out the fact that recompiling an SRPM from a different distribution is not supported or recommended, and therefore 'bastardizing' the OS. It was unclear what you had done from your first mail, but it sounded awfully close to "I rebuilt the FC2 RPM on my CentOS box". If you were offended by my tone, I appologize, but I'd recommend getting some thicker skin in the future...I know perfectly well that RedHat doesn't ship bug free software, or even software that is compatible with other software in the distro. Reporting the problem is appreciated, but as I said, it was unclear if you were reporting a problem with CentOS's RPM or FC2's RPM.
Why would I use a source rpm from FC2? :)
That's what I was trying to figure out ;-)
It's Centos/RHEL 4's cyrus-sasl rpm. Specifically, the cyrus-sasl-sql rpm. It appears all other code seem to work except for the sql plugin. I am not sure if that is due to configuration error, which seems unlikely since i copied the configuration for smtpd.conf from the FC2/Opteron box, or due to threading /sasl initialization issues.
You might be surprised. Sometimes a default setting is changed between versions that you don't expect, or wasn't explicitly defined...
An attempt to get a backtrace gives these results:
------------< snip <------< snip <------< snip <------------
All traces show the crash in _dl_sysinfo_int80 for those who are interested in licking this one. Are there any debug rpms available?
Unfortunately the backtrace isn't terribly useful.
Nope. All I could find from searching on the '_dl_sysinfo_int80 ()' string was something about threading or hyper-threading being enabled causing crashes...does Pentium 4 2.8 Ghz cpus have hyper-threading?
Most likely, yes. If you use the SMP kernel, you should see two processors. You might poke around in the BIOS if you have time and see if you can disable it and if that solves the problem. If so, it'd be handy to know for future reference in the list archives.
The debug RPMs are stored at http://vault.centos.org/debuginfo *but* it appears that the cyrus-* rpms are missing.
Boo.
Do you have access to a true RHEL 4 machine? Can this be replicated there? If so, reporting the issue upstream would be best, with an entry in CentOS's bug tracker with a pointer to the upstream bugzilla. If it can't be replicated there, filing a bug report with CentOS would be the best course of action.
Wish I did have one...otherwise I would have just filed a bug report.
Anyway, I recompiled the cyrus-sasl source rpm after enabling another plugin that I could make use of and now things are working for me...the the rebuilt sql plugin still crashes but the other plugin allows me to make use of the mysql tables I have without doing pam_mysql.
I wonder what is it that is causing the crashes...the logs tell me that postfix initiated sasl initialization and then it crashes with no other information...but I guess I can drop it now...
Glad you at least got it working. I hope that doesn't mean you have time to test without HT on, though ;-)
Matt
It's Centos/RHEL 4's cyrus-sasl rpm. Specifically, the cyrus-sasl-sql rpm. It appears all other code seem to work except for the sql plugin. I am not sure if that is due to configuration error, which seems unlikely since i copied the configuration for smtpd.conf from the FC2/Opteron box, or due to threading /sasl initialization issues.
You might be surprised. Sometimes a default setting is changed between versions that you don't expect, or wasn't explicitly defined...
Well, at most I'd expect a clear message in the logs about back settings but a crash?!
Nope. All I could find from searching on the '_dl_sysinfo_int80 ()' string was something about threading or hyper-threading being enabled causing crashes...does Pentium 4 2.8 Ghz cpus have hyper-threading?
Most likely, yes. If you use the SMP kernel, you should see two processors. You might poke around in the BIOS if you have time and see if you can disable it and if that solves the problem. If so, it'd be handy to know for future reference in the list archives.
What I did find on google was that there were cases where disabling hyper-threading 'solved' the problem...I wonder if I should be using a smp kernel...
Glad you at least got it working. I hope that doesn't mean you have time to test without HT on, though ;-)
Matt
Let me find a convenient time for that then. Man, what a time to be out of a test box...
-
Feizhou -
Matt Hyclak -
security