core dump - but email is delivered
As I described in my previous email a core dump is produced by deliver. I now discovered, that every delivery causes a core dump. Before I used a procmail script like :0 w | $DELIVERMAIL -a $LOGNAME -m user.$LOGNAME ($DELIVERMAIL is /usr/local/bin/deliver -r $SENDER) Since I checked the exit status of this recipe with the w flag a following recipe was executed sending a warning message that the mail couldn't be delivered. This caused a mail loop with a bad configured mailing list. I removed the w flag but that's of course not a solution if each message causes deliver to throw a core. As I wrote, these problems occur since the upgrade 1.6.24 - 2.0.13 Any hints greatly appreciated. Werner -- Werner Reisberger pgp-public-key available: Viktoriastr. 15http://www.pure.ch/mypubkey.txt CH-8057 Zurich
signaled to death by 11
Guys, I've installed Cyrus IMAP 2.0.13, Cyrus SASL 1.5.24,BerkeleyDB 3.2, pam_mysql and postfix on my RH 6.2 box. Started /usr/cyrus/bin/master and tried to telnet both pop3d and imap but i don't get any prompt... looking at my imapd.log... here's what it says... any idea? TYI! [imapd.log] May 8 00:08:29 mail master[1323]: about to exec /usr/cyrus/bin/lmtpd May 8 00:08:30 mail service-lmtpunix[1323]: executed May 8 00:08:30 mail master[1318]: process 1323 exited, signaled to death by 11 May 8 00:08:34 mail master[1327]: about to exec /usr/cyrus/bin/pop3d May 8 00:08:34 mail service-pop3[1327]: executed May 8 00:08:34 mail master[1318]: process 1327 exited, signaled to death by 11 May 8 00:08:54 mail master[1329]: about to exec /usr/cyrus/bin/imapd May 8 00:08:54 mail service-imap[1329]: executed May 8 00:08:54 mail master[1318]: process 1329 exited, signaled to death by 11 Get 250 color business cards for FREE! http://businesscards.lycos.com/vp/fastpath/
Re: Compilation fails under Red Hat 7.1 - libucdmibs.so undefined reference
Hans Deragon [EMAIL PROTECTED] writes: I tried to compile cyrus under Red Hat 7.1, but the following errors occured: undefined reference to `rpmdbClose' Looks familiar. :-\ I suspected that it might be a compiler issue (2.96 is I believe still experimental) so I compiled with kgcc: No, it's not gcc. (read below) Since it refers to rpm* stuff, I do not suspect that Cyrus itself is broken, but Red Hat 7.1. I could not imagine why Cyrus would want to have anything to Yes, Red Hat *is* broken. do with rpms, unless this acronym stands for something else than the usual binary packaging system. Any help would be appreciated. I have no clue what libucdmibs.so's function is and how to correct this. Is it possible that library is missing on the compiler's command line? Uninstall snmp package, autoconfigure from cyrus-imapd will find this libraries, and include support for snmp. This libraries are somehow linked with rpm libraries (!?). Just hide or temporary deinstall snmp-devel and snmp (rpm -qa | grep snmp - don't remember full name of package) and rerun ./configure (remove config.cache before, or extract source again). Maybe you can add --without-snmp to cyrus-imapd, but it's safer ti just remove/hide snmp from RedHat. Another error during compilation will be previous declaration of some extern char from malloc.h (or stdio.h?). Just somment out that line in cyru code and rerun make. Sorry, this are nasty workarounds, but I don't know better. :-( -- This signature intentionally left blank
PAM authentication does not work with latest .tar.gz files ...
Okay, either I'm losing it, or there is a bug here somewhere :( I removed the ports I had installed, for FreeBSD, and built fresh from source, using the following configure settings: =[ sasl ] #!/bin/tcsh setenv CFLAGS -I/usr/local/include/db3 #setenv CPPFLAGS -I/usr/local/include/db3 ./configure \ --with-prefix=/usr/local \ --with-dbpath=/usr/local/etc/sasldb \ --with-pwcheck=/usr/local/var/pwcheck \ --with-pam \ --disable-krb4 \ --disable-gssapi \ --disable-anon \ --enable-login ==[ imap ]= #!/bin/tcsh setenv CFLAGS -I/usr/local/include/db3 ./configure \ --prefix=/usr/local \ --with-cyrus-user=cyrus \ --with-cyrus-group=cyrus \ --with-dbdir=/usr/local \ --with-openssl \ --with-sasl=/usr/local \ --without-krb \ --with-auth=unix \ --enable-debug \ --with-perl=/usr/bin/perl = Builds clean, installs clean and runs ... as long as I have a passwd in sasldb file, I'm find, but as soon as I try to use PAM to authenticate to an NT server, it fails ... My /etc/imapd.conf file looks like: = configdirectory: /var/spool/imap partition-default: /var/spool/mail admins: cyrus sieveusehomedir: false sievedir: /var/spool/sieve hashimapspool: true sasl_pwcheck_method: PAM If I do an 'saslpasswd -d marc' to remove myself from the sasldb file, then try and re-connect with pine, I get the following error: May 7 13:21:00 new-relay imapd[66067]: badlogin: atelier.acadiau.ca[131.162.138.223] CRAM-MD5 authentication failure [no secret in database] now, I know the PAM module/authentication itself is working, as if I use the same settings, same user and same passwd for ftpd, and it authenticates fine ... so its as if, even with sasl_pwcheck_method set, it isn't using PAM properly ... Am I missing something in my configure? My imapd.conf file? Some known reason why PAM doesn't work with FreeBSD? Thanks ... Marc G. Fournier [EMAIL PROTECTED] Senior Systems AdministratorAcadia University These are my opinions, which are not necessarily shared by my employer
Re: PAM authentication does not work with latest .tar.gz files ...
Date: Mon, 7 May 2001 13:37:42 -0300 (ADT) From: Marc G. Fournier [EMAIL PROTECTED] [...] If I do an 'saslpasswd -d marc' to remove myself from the sasldb file, then try and re-connect with pine, I get the following error: May 7 13:21:00 new-relay imapd[66067]: badlogin: atelier.acadiau.ca[131.162.138.223] CRAM-MD5 authentication failure [no secret in database] Cyrus is advertising CRAM-MD5, which always uses /etc/sasldb, because the file exists. However, since there's no secret for the user marc in /etc/sasldb, Pine can't use CRAM-MD5. Either remove the CRAM-MD5 plugin, remove /etc/sasldb, or configure Pine to not use CRAM-MD5. Larry
Re: Problems with 2.0.13 on FreeBSD
Date: Mon, 07 May 2001 11:06:18 -0700 From: Nick Sayer [EMAIL PROTECTED] Cc: Hajimu UMEMOTO [EMAIL PROTECTED], [EMAIL PROTECTED] Lawrence Greenfield wrote: I've applied this patch against imapd.c. pop3d doesn't currently have this problem since it never services more than one connection. Au Contraire, pop3d does indeed have the same problem. To duplicate it, you connect to the pop3s port with 'openssl s_client', QUIT, then quickly telnet into the pop3s port. You will get a non-SSL pop3 service response because argv got trashed by setproctitle(). I'm extremely confused how this could happen. I just tried it against my test server to be sure, and couldn't reproduce this. pop3d doesn't reuse processes, so after the first connection (with openssl s_client) exits, it doesn't respond to the 2nd connection (with telnet). A different process is fork'd and exec'd, so the argv is brand new. Have you actually done this and seen this happen? Larry
Re: Problems with 2.0.13 on FreeBSD
Hajimu UMEMOTO wrote: nsayer 2. imapd loses its -s argument the 2nd time around. I suspect this is a nsayer setproctitle issue, but I haven't tried to prove it. If I do nsayer 'openssl s_client -connect localhost:imaps', then '. logout' and then nsayer very quickly 'telnet localhost imaps', I get a non-SSLed imapd. nsayer Further research shows that when this happens the 'imaps' variable in the nsayer code is set to 0, which can only be because the argv[][] given to nsayer service_main() does not have a -s in it. How about this patch? It seems fixed the problem here. What I've done is moving option parsing from service_main() to service_init(). I believe option parsing is good enough to be done only one time. I think there is same problem in pop3d. The patch to imapd appears to be both safe and effective. I have duplicated the problem with pop3d, however, so a similar patch would need to be applied.
Re[2]: signalled to death by 11?
Hey Seva, This could also be due to an overheating system. -- Kevin Friday, March 23, 2001, 11:48:29 AM, you wrote: SA This probably should be a FAQ item by now! One of the most SA common reasons for signal 11 (on Redhat systems) with cyrus SA is mismatch with the shared libraries. Often times it is the SA Berkeley db versions that come with the Redhat distribution SA coming in the way. SA You may want to do an ldd imapd, to check the libraries that SA the compiled version of your programs are picking, if they SA are not the same as the one that you built them with, then most SA likely, that is your problem. If the shared libraries look ok SA then you would have to deal with the logs and see if they have SA anything to offer and if they don't reveal anything, then you SA will probably have to deal with core itself by going into gdb SA and looking at the trace and see where it bombed! SA __ SA Seva SA Andreas Rogge wrote: --On Thursday, March 22, 2001 23:26:38 -0700 Cory Waddingham [EMAIL PROTECTED] wrote: I recently installed Cyrus 2.0.12 on a RedHat 6.2 system. When I start up the server and attempt to connect, I get the following error in my log: process pid exited, signaled to death by 11 The signals are described in man 7 signals. Signal 11 (aka SIGSEGV) means a segmentation fault (i.e. the program tried to write to ram it didn't own) this generally means a programming error or hardware failure or something like this (maybe OS-error?). -- Andreas Rogge [EMAIL PROTECTED] Available on IRCnet:#linux.de as Dyson
Re: PAM authentication does not work with latest .tar.gz files ...
On Mon, 7 May 2001, Lawrence Greenfield wrote: Date: Mon, 7 May 2001 13:37:42 -0300 (ADT) From: Marc G. Fournier [EMAIL PROTECTED] [...] If I do an 'saslpasswd -d marc' to remove myself from the sasldb file, then try and re-connect with pine, I get the following error: May 7 13:21:00 new-relay imapd[66067]: badlogin: atelier.acadiau.ca[131.162.138.223] CRAM-MD5 authentication failure [no secret in database] Cyrus is advertising CRAM-MD5, which always uses /etc/sasldb, because the file exists. However, since there's no secret for the user marc in /etc/sasldb, Pine can't use CRAM-MD5. Either remove the CRAM-MD5 plugin, remove /etc/sasldb, or configure Pine to not use CRAM-MD5. Okay, is there any way of setting it up so that, if someone logs in, they issue their passwd, the system checks: /etc/sasldb - that fails, check through PAM - that succeeds, add/update entry to sasldb so that their first login might be insecure, but subsequent ones will use a more secure encryption? I thought the 'sasl_auto_transition' was *supposed* to do that, but have never succeeded in getting that to work ... Thanks ...
Re: PAM authentication does not work with latest .tar.gz files ...
On Mon, 7 May 2001, Lawrence Greenfield wrote: Date: Mon, 7 May 2001 13:37:42 -0300 (ADT) From: Marc G. Fournier [EMAIL PROTECTED] [...] If I do an 'saslpasswd -d marc' to remove myself from the sasldb file, then try and re-connect with pine, I get the following error: May 7 13:21:00 new-relay imapd[66067]: badlogin: atelier.acadiau.ca[131.162.138.223] CRAM-MD5 authentication failure [no secret in database] Cyrus is advertising CRAM-MD5, which always uses /etc/sasldb, because the file exists. However, since there's no secret for the user marc in /etc/sasldb, Pine can't use CRAM-MD5. Either remove the CRAM-MD5 plugin, remove /etc/sasldb, or configure Pine to not use CRAM-MD5. Woo hoo ... got one of the other guys to try it using kmail, and it appears to go to PAM (auth still fails, but at least now I know its going there) ... Has anyone here had any experience with pam_smb for authenticating? I'm using the same pam_smb module that I tested with ftpd, and it authenticated, but with POP3, I'm getting the error below: May 7 15:44:57 new-relay pop3d[66043]: pamsmbd : msg_snd problem May 7 15:45:05 new-relay pop3d[66046]: pamsmbd : msg_snd problem Its soo close, I can taste it :(
rlimit and linux 2.2.x
Ramiro noted in his cyrus-imap RPM release for 2.0.11: - Add patch from Lawrence Greenfield for bad file descriptor ordering and rlimit type portability. I still see rlimit problems in linux 2.2.x with cyrus-imap-2.0.13. Did this patch make it into that release? Has anyone else seen problems with rlimit in master.c? Thanks. Chris
Re: PAM authentication does not work with latest .tar.gz files ...
On Mon, 7 May 2001 [EMAIL PROTECTED] wrote: Larry Greenfield writes: However, since there's no secret for the user marc in /etc/sasldb, Pine can't use CRAM-MD5. This is a generic problem with c-client. If the server advertizes CRAM-MD5, the client will try only CRAM-MD5, and will not fall back to less secure authentication methods. The author states that this is correct behavior. My experience with 'the author' is that anything he does is right, everyone else is wrong :( That's why I use Cyrus IMAPd vs UofW ... but, pine is, so far as I've experienced, one of the better command line readers, and c-client is used in a fair number of other mailers :(
Re: PAM authentication does not work with latest .tar.gz files ...
On Mon, 7 May 2001 13:37:42 -0300 (ADT)
Marc G. Fournier [EMAIL PROTECTED] said:
marc.fournier If I do an 'saslpasswd -d marc' to remove myself from the sasldb file,
marc.fournier then try and re-connect with pine, I get the following error:
marc.fournier May 7 13:21:00 new-relay imapd[66067]: badlogin:
atelier.acadiau.ca[131.162.138.223] CRAM-MD5 authentication failure [no secret in
database]
I believe CRAM-MD5 authentication requires sasldb. You need to
change pine setting to use plain password.
--
Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan
[EMAIL PROTECTED] [EMAIL PROTECTED] ume@{,jp.}FreeBSD.org
http://www.imasy.org/~ume/
Re: PAM authentication does not work with latest .tar.gz files ...
On Tue, 8 May 2001, Hajimu UMEMOTO wrote: On Mon, 7 May 2001 13:37:42 -0300 (ADT) Marc G. Fournier [EMAIL PROTECTED] said: marc.fournier If I do an 'saslpasswd -d marc' to remove myself from the sasldb file, marc.fournier then try and re-connect with pine, I get the following error: marc.fournier May 7 13:21:00 new-relay imapd[66067]: badlogin: atelier.acadiau.ca[131.162.138.223] CRAM-MD5 authentication failure [no secret in database] I believe CRAM-MD5 authentication requires sasldb. You need to change pine setting to use plain password. Any idea how?
Re: PAM authentication does not work with latest .tar.gz files ...
On Mon, 7 May 2001 16:33:46 -0300 (ADT)
The Hermit Hacker [EMAIL PROTECTED] said:
scrappy On Tue, 8 May 2001, Hajimu UMEMOTO wrote:
On Mon, 7 May 2001 13:37:42 -0300 (ADT)
Marc G. Fournier [EMAIL PROTECTED] said:
marc.fournier If I do an 'saslpasswd -d marc' to remove myself from the sasldb file,
marc.fournier then try and re-connect with pine, I get the following error:
marc.fournier May 7 13:21:00 new-relay imapd[66067]: badlogin:
atelier.acadiau.ca[131.162.138.223] CRAM-MD5 authentication failure [no secret in
database]
I believe CRAM-MD5 authentication requires sasldb. You need to
change pine setting to use plain password.
scrappy Any idea how?
Though I have no experience with pine, doesn't pine have the
configuration for the authentication method? LOGIN should work.
--
Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan
[EMAIL PROTECTED] [EMAIL PROTECTED] ume@{,jp.}FreeBSD.org
http://www.imasy.org/~ume/
Re: PAM authentication does not work with latest .tar.gz files ...
On Tue, 8 May 2001, Hajimu UMEMOTO wrote: On Mon, 7 May 2001 16:33:46 -0300 (ADT) The Hermit Hacker [EMAIL PROTECTED] said: scrappy On Tue, 8 May 2001, Hajimu UMEMOTO wrote: On Mon, 7 May 2001 13:37:42 -0300 (ADT) Marc G. Fournier [EMAIL PROTECTED] said: marc.fournier If I do an 'saslpasswd -d marc' to remove myself from the sasldb file, marc.fournier then try and re-connect with pine, I get the following error: marc.fournier May 7 13:21:00 new-relay imapd[66067]: badlogin: atelier.acadiau.ca[131.162.138.223] CRAM-MD5 authentication failure [no secret in database] I believe CRAM-MD5 authentication requires sasldb. You need to change pine setting to use plain password. scrappy Any idea how? Though I have no experience with pine, doesn't pine have the configuration for the authentication method? LOGIN should work. you are correct ... they have a 'disable method' feature, which will do it ... thanks ...
No Subject
Hi, When I do a ./configure for cyrus-imapd-2.0.13 on my Linux box with Mandrake 8.0 ./configure --with-auth=unix --with-dbdir=/usr/lib/ The compiling script complains with an error message, configure: error: this version requires Berkeley DB 3.x. I checked my system for Berkeley DB 3.x with slocate libdb and I get /usr/lib/liddb_cxx_3.1.so /usr/lib/libdb_so.2 /usr/lib/libdb1.so.2 /usr/lib/libdb.so.3 /usr/lib/libdb2.so.3 /usr/X11R6/lib/modules/extensions/libdbe.a /lib/libdb-3.1.so Would someone please tell me what I am doing wrong here? Regards, Norman
Re: Problems with 2.0.13 on FreeBSD
Lawrence Greenfield wrote: [snip...] I'm extremely confused how this could happen. I just tried it against my test server to be sure, and couldn't reproduce this. pop3d doesn't reuse processes, so after the first connection (with openssl s_client) exits, it doesn't respond to the 2nd connection (with telnet). A different process is fork'd and exec'd, so the argv is brand new. I think the problem is in master and not pop3d... Maybe that's the confusion? Regards, Nuno Silva
Re: configure error
It looks like you haven't installed the db3 development package, which contains the header files needed to compile. Install db3-devel-3.1.17-1mdk.i586.rpm, that should solve this problem. Good Luck! On Mon, 7 May 2001, Norman Zhang wrote: Hi, When I do a ./configure for cyrus-imapd-2.0.13 on my Linux box with Mandrake 8.0 ./configure --with-auth=unix --with-dbdir=/usr/lib/ The compiling script complains with an error message, configure: error: this version requires Berkeley DB 3.x. I checked my system for Berkeley DB 3.x with slocate libdb and I get /usr/lib/liddb_cxx_3.1.so /usr/lib/libdb_so.2 /usr/lib/libdb1.so.2 /usr/lib/libdb.so.3 /usr/lib/libdb2.so.3 /usr/X11R6/lib/modules/extensions/libdbe.a /lib/libdb-3.1.so Would someone please tell me what I am doing wrong here? Regards, Norman
Re: signalled to death by 11?
Could you elaborate the reason for this observation. Why would an over heated system be discriminating imap server process and not the master process or for that matter any other process on the system? __ Seva Kevin J. Menard, Jr. wrote: Hey Seva, This could also be due to an overheating system. -- Kevin Friday, March 23, 2001, 11:48:29 AM, you wrote: SA This probably should be a FAQ item by now! One of the most SA common reasons for signal 11 (on Redhat systems) with cyrus SA is mismatch with the shared libraries. Often times it is the SA Berkeley db versions that come with the Redhat distribution SA coming in the way. SA You may want to do an ldd imapd, to check the libraries that SA the compiled version of your programs are picking, if they SA are not the same as the one that you built them with, then most SA likely, that is your problem. If the shared libraries look ok SA then you would have to deal with the logs and see if they have SA anything to offer and if they don't reveal anything, then you SA will probably have to deal with core itself by going into gdb SA and looking at the trace and see where it bombed! SA __ SA Seva SA Andreas Rogge wrote: --On Thursday, March 22, 2001 23:26:38 -0700 Cory Waddingham [EMAIL PROTECTED] wrote: I recently installed Cyrus 2.0.12 on a RedHat 6.2 system. When I start up the server and attempt to connect, I get the following error in my log: process pid exited, signaled to death by 11 The signals are described in man 7 signals. Signal 11 (aka SIGSEGV) means a segmentation fault (i.e. the program tried to write to ram it didn't own) this generally means a programming error or hardware failure or something like this (maybe OS-error?). -- Andreas Rogge [EMAIL PROTECTED] Available on IRCnet:#linux.de as Dyson
