Hi,
After removing all softlinks which where pointed to berkley-db version
4.1.25 from the system and recompiling
it works with berkley-db version 4.2.52 also.
It seems that at least the imad checks different directories like
/usr/lokal/lib for berkley-db libs and headers also if you configure
Günter Zimmermann wrote:
Hi people,
The problem is solved.
It was because of different versions od berkley-db in sasl and imapd.
It found this information in the trace.
Another Point is that its only works with berkley-db version 4.1.25.
Version 4.2.52 did not work.
We use 4.2.52. Had major slowdo
Hi people,
The problem is solved.
It was because of different versions od berkley-db in sasl and imapd.
It found this information in the trace.
Another Point is that its only works with berkley-db version 4.1.25.
Version 4.2.52 did not work.
thx for your help.
strace was a really good hint:-
> Hi,
>
> I have an cyrus imapd 2.2.2 Beta running.
>
> Now i tried to update to 2.2.5.
>
> Startcommand:
> /opt/cyrus-imapd-2.2.5/service/master -C
> /etc/cyrus-imapd-2.2.5/imapd.conf -M /etc/cyrus-imapd-2.2.5/cyrus.conf
> If try to logon i get this error and the master process dies
What your da
On Wed, 26 Mar 2003, Jeremy Rumpf wrote:
> Actually, I think someone a while ago had come up with a solution. I'm not
> sure how proper it is, you can decide. Here's a copy of the post from Fritz
> Test <[EMAIL PROTECTED]> :
[snip]
Hmmm, I probably should have looked at it then... but I don't thi
On Wednesday 26 March 2003 08:57 am, Oliver Pitzeier wrote:
> Jeremy Rumpf wrote:
> > This has been on this list in the past, this post is on an
> > older release, but is the problem is the same. The imap server
> > dumps when a message from Outlook or Outlook Express is copied
> > to it. Machine i
Jeremy Rumpf wrote:
> This has been on this list in the past, this post is on an
> older release, but is the problem is the same. The imap server
> dumps when a message from Outlook or Outlook Express is copied
> to it. Machine is an older alpha ev5.6. Here's a recap:
[ ... ]
Thanks a lot Jeremy
On Wednesday 26 March 2003 05:35 am, Oliver Pitzeier wrote:
> Oliver Pitzeier wrote:
> > > Rob Siemborski wrote:
> > > > > Copying mails between two imap-servers is normally no
> > > > > problem and works with all my servers, except this one...
> > > > >
> > > > > Any ideas?
> > > >
> > > > Do you
Oliver Pitzeier wrote:
> Now I'll dig into tmcomp(atmp, btmp) :-)
OK... I solved the problem... It's not OK to do it this way - I know, but it
actually helps for the moment...
--- mkgmtime.c.orig Wed Mar 26 14:03:34 2003
+++ mkgmtime.c Wed Mar 26 14:04:19 2003
@@ -100,6 +100,8 @@
{
> In <[EMAIL PROTECTED]>
> Christian Schulte <[EMAIL PROTECTED]> wrote:
> Oliver Pitzeier wrote:
[...]
> Hhm! No real answers to my questions for now... I now know how to debug
> a cyrus installation but I really need to know how to upgrade from db3.2
> to db4.1 !
Do ./configure --
Oliver Pitzeier wrote:
> > Rob Siemborski wrote:
> > > > Copying mails between two imap-servers is normally no
> > > > problem and works with all my servers, except this one...
> > > >
> > > > Any ideas?
> > >
> > > Do you have a protocol trace of what outlook is feeding cyrus?
> > > Alternative
Oliver Pitzeier wrote:
Hi volks!
I thankfull for ANY help!
I'm currently debugging a signal 11 problem... I located it in getdatetime
(imapd.c) and have to trace it down to the final "killer line" I'm working
on an Compaq Alpha DS10...
If anyone has similar problems, or if any developer can
Rob Siemborski wrote:
> > Here some stuff I logged via syslog:
> > Mar 25 16:34:29 mail imapd[14859]: tm.tm_mday: 25
> > Mar 25 16:34:29 mail imapd[14859]: tm.tm_mon: 2
> > Mar 25 16:34:29 mail imapd[14859]: month: mar
> > Mar 25 16:34:30 mail imapd[14859]: year: 103
> > Mar 25 16:34:30 mail imapd[
> Rob Siemborski wrote:
> > > Copying mails between two imap-servers is normally no problem and
> > > works with all my servers, except this one...
> > >
> > > Any ideas?
> >
> > Do you have a protocol trace of what outlook is feeding
> > cyrus? Alternatively, do you have a backtrace of the core d
On Tue, 25 Mar 2003, Oliver Pitzeier wrote:
> Here some stuff I logged via syslog:
> Mar 25 16:34:29 mail imapd[14859]: tm.tm_mday: 25
> Mar 25 16:34:29 mail imapd[14859]: tm.tm_mon: 2
> Mar 25 16:34:29 mail imapd[14859]: month: mar
> Mar 25 16:34:30 mail imapd[14859]: year: 103
> Mar 25 16:34:30
Rob Siemborski wrote:
> > is invoked it dies... You can also said syslog(LOG_ERR, dir) and it
> > will also die. So it seems for me, that it has something to do with
> > "dir", which is a "register int"...
>
> This isn't terribly surprising, since syslog is expecting a
> const char * as its sec
Rob Siemborski wrote:
> > Copying mails between two imap-servers is normally no problem and
> > works with all my servers, except this one...
> >
> > Any ideas?
>
> Do you have a protocol trace of what outlook is feeding
> cyrus? Alternatively, do you have a backtrace of the core dump?
No, I ha
On Tue, 25 Mar 2003, Oliver Pitzeier wrote:
> is invoked it dies... You can also said syslog(LOG_ERR, dir) and it will also
> die. So it seems for me, that it has something to do with "dir", which is a
> "register int"...
This isn't terribly surprising, since syslog is expecting a const char *
as
On Tue, 25 Mar 2003, Oliver Pitzeier wrote:
> OK. Kick my ass for this now... :-(
>
> I tried to copy some mails from one imap server to this new one (using Outlook
> XP and Outlook Express 6)... This is where the error occurs...
>
> BUT(!): I tried it now with Evolution; I copied the same mail. I
Henrique de Moraes Holschuh wrote:
[ ... ]
> > I tried to copy some mails from one imap server to this new
> > one (using
> > Outlook XP and Outlook Express 6)... This is where the
> > error occurs...
>
> It is still a real bug. Cyrus should be resilient to fucked
> up input data (as long as y
On Tue, 25 Mar 2003, Oliver Pitzeier wrote:
> > > I'm currently debugging a signal 11 problem... I located it
> > > in getdatetime
> > > (imapd.c) and have to trace it down to the final "killer
> > > line" I'm working on an Compaq Alpha DS10...
> > >
> > > Version of cyrus-imapd 2.1.12.
>
>
[ ... ]
> > I'm currently debugging a signal 11 problem... I located it
> > in getdatetime
> > (imapd.c) and have to trace it down to the final "killer
> > line" I'm working on an Compaq Alpha DS10...
> >
> > If anyone has similar problems, or if any developer can help
> > me trace it down...
[ ... ]
> I'm currently debugging a signal 11 problem... I located it
> in getdatetime
> (imapd.c) and have to trace it down to the final "killer
> line" I'm working on an Compaq Alpha DS10...
>
> If anyone has similar problems, or if any developer can help
> me trace it down I'd be
Rob:
> DIGEST-MD5 with LDAP won't work with out an LDAP auxprop plugin, since it
> needs the plaintext password (or DIGEST secret). (i.e. it won't work with
> saslauthd).
This is making since - Thanks. I'm assuming that the auxprop plugin method
doesn't use PAM and thus the LDAP authentication
On Sun, 24 Mar 2002, OCNS Consulting wrote:
> > DIGEST-MD5 with LDAP won't work with out an LDAP auxprop plugin, since it
> > needs the plaintext password (or DIGEST secret). (i.e. it won't work with
> > saslauthd).
>
> This is making since - Thanks. I'm assuming that the auxprop plugin method
>
On Sun, 24 Mar 2002, OCNS Consulting wrote:
> Okay. Then what plugin is expected to perform LDAP authentication?
No plugins supplied by the Cyrus SASL Distribution currently perform LDAP
authentication.
There is one third-party auxprop plugin that we're looking at including in
the distribution
Okay. Then what plugin is expected to perform LDAP authentication?
RB
> Every plugin that supports a client-side SASL negotiation should export
> this (which is basically all of the included ones, except for libsasldb).
> -Rob
Also, have any idea what is causing the following error?
unable to get entry point sasl_client_plug_init in
/usr/lib/sasl/libsasldb.so:
/usr/local/lib/libsasl.so.7: undefined symbol: sasl_client_plug_init
RB
> Every plugin that supports a client-side SASL negotiation should ex
On Sun, 24 Mar 2002, OCNS Consulting wrote:
> Interesting. Have any ideas of what SASL V2 library the module
> "sasl_client_plug_init"
> resides? I look via "nm" and "ar" and found nothing.
Every plugin that supports a client-side SASL negotiation should export
this (which is basically all o
Ken:
>>Just to insure that Cyrus IMAP
>> was not
>> experiencing the same bdb issue as SASL V2, I recompiled IMAP 2.1.3 -
here
>> are the
>> "configure script" options selected ->
>>
>> ./configure \
>> --enable-fulldirhash \
>> --with-sasl=/usr/lib/sasl2 \
>> --wi
OCNS Consulting wrote:
>
> Ken:
>
> I finally determined the issue with BerkeleyDB. The SASL configure script
> looks for "/usr/include/db3" which is found and contains (as expected) bdb3
> headers. Of course I compile SASL against bdb4 which is specified by
> including
> the options ->
>
>
Ken:
I finally determined the issue with BerkeleyDB. The SASL configure script
looks for "/usr/include/db3" which is found and contains (as expected) bdb3
headers. Of course I compile SASL against bdb4 which is specified by
including
the options ->
--with-bdb-libdir=/usr/local/BerkeleyDB
u know of a more exact method to obtain the traceback information,
please forward.
Thanks for your assistance.
RB
-Original Message-
From: Rob Siemborski [mailto:[EMAIL PROTECTED]]
Sent: Thursday, March 21, 2002 10:44 AM
To: OCNS Consulting
Cc: Ken Murchison
Subject: RE: Signaled to Death by 1
_end=0xbfffedec) at
../sysdeps/generic/libc-start.c:129
(gdb)
-Original Message-
From: Ken Murchison [mailto:[EMAIL PROTECTED]]
Sent: Thursday, March 21, 2002 9:45 AM
To: OCNS Consulting
Cc: [EMAIL PROTECTED]
Subject: Re: Signaled to Death by 11 - Again - bdb issue?
OCNS Consulting wrot
ink
the binaries.
Ken
> -Original Message-
> From: Ken Murchison [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, March 20, 2002 7:54 PM
> To: OCNS Consulting
> Cc: [EMAIL PROTECTED]
> Subject: Re: Signaled to Death by 11 - Again - bdb issue?
>
> In your debugger outputs,
20, 2002 7:54 PM
To: OCNS Consulting
Cc: [EMAIL PROTECTED]
Subject: Re: Signaled to Death by 11 - Again - bdb issue?
In your debugger outputs, both lib/libdb-4.0.so and /usr/lib/libdb.so.3
are being loaded. What is /usr/lib/libdb.so.3? Is this a BDB 3.x
library? If so, this is probably your
one.
> Loaded symbols for /usr/lib/libdb.so.3
> #0 0x in ?? ()
> (gdb) bt
> #0 0x in ?? ()
> #1 0x08048bf0 in ?? ()
> #2 0x08048c84 in ?? ()
> #3 0x08048fd0 in ?? ()
> #4 0x40102627 in __libc_start_main (main=0x8048ee0, argc=3,
> ubp_av=0xb1f4, i
-Original Message-
From: Ken Murchison [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, March 20, 2002 5:16 PM
To: OCNS Consulting
Cc: [EMAIL PROTECTED]
Subject: Re: Signaled to Death by 11 - Again -
Are you _sure_ that SASL and IMAP and linked against the same version of
BDB? Do a 'ldd /us
Are you _sure_ that SASL and IMAP and linked against the same version of
BDB? Do a 'ldd /usr/cyrus/bin/imapd' and make sure you're not linked
against multiple versions of BDB.
Was the /etc/sasldb2 file created with the same version?
OCNS Consulting wrote:
>
> Ken:
>
> Here's the traceback r
Ken:
Here's the traceback results you requested.
Let me know how I can help
RB
=
# gdb -core=core -e /usr/cyrus/bin/imapd
GNU gdb Red Hat Linux (5.1-1)
Copyright 2001 Free Software Foundation, Inc.
GDB is
You need to feed the binary into gdb as well. Try something like:
gdb /usr/cyrus/bin/imapd
Ken
OCNS Consulting wrote:
>
> Ken:
>
> As per your request, below is the traceback from a core file generated by
> "imapd"
> causing the "signaled by death 11" error.
>
> I look forward to your re
Ken:
As per your request, below is the traceback from a core file generated by
"imapd"
causing the "signaled by death 11" error.
I look forward to your response.
RB
==
# gdb -core=core
GNU gdb Red Hat Linux (5.1-1)
C
My idea about cyrus getting sig11'ed is because of berkeley DB.
OCNS Consulting wrote:
>
> David:
>
> I re-compiled LDAP without SASL support and re-linked pam_ldap with the new
> LDAP libraries, as suggested. Restarted both LDAP and master; LDAP access
> successful;
> attempted IMAP access and as before Death by 11. Here's log file excerpt (SA
> B4):
>
>
David:
I re-compiled LDAP without SASL support and re-linked pam_ldap with the new
LDAP libraries, as suggested. Restarted both LDAP and master; LDAP access
successful;
attempted IMAP access and as before Death by 11. Here's log file excerpt (SA
B4):
Mar 19 10:50:11 mailsrv imapd[24376]: acce
>>Anything look familiar or obvious? Suggestions?
Look familiar, anyway. It looks like the inevitable SASL reentrancy
problem. Try rebuilding your LDAP libs --without-sasl and then linking
pam_ldap to the new libs.
>>Anything look familiar or obvious? Suggestions?
Familiar, anyway. Looks like the old SASL re-entrancy problem to be. Try
rebuilding your OpenLDAP libs --without-sasl and linking pam_ldap to them.
OCNS Consulting wrote:
>
> We migrated to IMAP 2.1.3 and SASL Libraries 2.1.1
>
> LDAP authentication via PAM is utilized.
>
> Environment:
>
> - Linux kernel 2.4.9-31
> - PAM 0.75-19
> - LDAP 2.0.23
> - BerkeleyDB 4.0.14
>
> LDAP access such as: ldapsearch,
ke my rpm-spec files for sasl and imap, I will be glad to
post them or send them directly.
Vernon Fort
-Original Message-
From: Vernon A.. Fort
Sent: Thursday, January 31, 2002 3:49 PM
To: [EMAIL PROTECTED]
Subject: RE: Signaled to Death by 11
I had another thought.
1.
ke my rpm-spec files for sasl and imap, I will be glad to
post them or send them directly.
Vernon Fort
-Original Message-
From: Vernon A.. Fort
Sent: Thursday, January 31, 2002 3:49 PM
To: [EMAIL PROTECTED]
Subject: RE: Signaled to Death by 11
I had another thought.
1.
:[EMAIL PROTECTED]]
Sent: Thursday, January 31, 2002 12:55 PM
To: Vernon A.. Fort; [EMAIL PROTECTED]
Subject: Re: Signaled to Death by 11
Just a shot in the dark, but is Postfix using
Berkeley DB for anything?
LMTP is shared among both applications and if
either needs to access the same DB then one
the problem do to all the posts I see concerning the vm stuff.
Any thoughts.
Vernon A. Fort
-Original Message-
From: Michael Fair [mailto:[EMAIL PROTECTED]]
Sent: Thursday, January 31, 2002 12:55 PM
To: Vernon A.. Fort; [EMAIL PROTECTED]
Subject: Re: Signaled to Death by 11
Just a shot
Just a shot in the dark, but is Postfix using
Berkeley DB for anything?
LMTP is shared among both applications and if
either needs to access the same DB then one or
the other will surely choke
If master is dying then perhaps it is accessing
a DB from Postfix and Postfix is using an older
Berk
Vernon,
Maybe your first 128 MB memory modules are defective?
If they are the same in both test you reported (that is you added
256 MB to get 384 MB) and your hardware allowd try making
another test without them installed.
On 25 Jan 2002 at 12:14, Vernon A.. Fort wrote about "Signaled to De
Fred Kastl schrieb am Thu, Nov 15, 2001 at 08:27:15PM +0100:
* Hi,
*
* Anybody know something abaut this error message ?
* when i try to connect to my cyrus imap server this message appears:
* i have nothing changed expect of sending some E-Mails without receiver
* (can this cash the imap server
On Mon, Aug 06, 2001 at 02:03:20PM -0400, [EMAIL PROTECTED] wrote:
> On a related note, different versions of Berkley DB versions
> on RH systems were resulting in signal 11 death problems
> earlier. A simple "ldd" check on the imapd built, will reveal
> these problems.
Not neccessarily. If the
Earlier versions of OpenLdap had reentry issues with its
version of SASL clashing with IMAPD. One of the developers
from openldap acknowledged this on this list and tried to
work out a solution. Although he never updated the list,
the latest version seems to work fine and has exhibited
no signs of
On 05 Aug 2001 13:21:16 -0700, David Wright wrote:
> Can we PLEASE produce a version of cyrus-imap imap WITHOUT SASL? PAM
may
> be a smidgeon less flexible, but it is simplier, more widely used and
> supports many more authentication methods. Eliminating SASL might make
> life harder for the
Lawrence Greenfield wrote:
>
>Date: Sun, 05 Aug 2001 21:20:55 -0700
>From: David Wright <[EMAIL PROTECTED]>
>
> [...]
>Now when _do_authentication is run against a correct password, it
>returns success and pam_ldap returns success, but imapd dies. If I
>comment out the call
Date: Mon, 06 Aug 2001 09:32:33 -0400
From: Ken Murchison <[EMAIL PROTECTED]>
[...]
Could this be a simple problem of OpenLDAP and Cyrus-imapd being linked
against different version SASL libraries, or worse yet different
databases libraries?
I'm fairly sure this is due to re-entran
Date: Sun, 05 Aug 2001 21:20:55 -0700
From: David Wright <[EMAIL PROTECTED]>
[...]
Now when _do_authentication is run against a correct password, it
returns success and pam_ldap returns success, but imapd dies. If I
comment out the call to _do_authentication and just return succe
On Sun, Aug 05, 2001 at 09:20:55PM -0700, David Wright wrote:
> I have spent more time investigating the interaction of pam_ldap and
> SASL, and have narrowed down the problem considerably, but still not
> quite "got it".
I think you have been hit by the bug that was discussed on the OpenLDAP
I have spent more time investigating the interaction of pam_ldap and
SASL, and have narrowed down the problem considerably, but still not
quite "got it".
The TLS options seem also to be the wrong direction; I can eliminate
TLS/SSL and the problem persists. By inserting lots of debug code, I
Hi,
I know configuring all this isn't so easy. In fact it's almost a lack of
documentation, I think.
Once it's compiled and configured it work preatty fine, and then you
have all features enabled for future uses or modifications (especialy
about cryptography and security).
Maybe most users sh
> Can we PLEASE produce a version of cyrus-imap imap WITHOUT SASL? PAM may
This is why I still use 1.5.mumble, with pwcheck for authentication.
Anything later was just "interesting" to get installed, and it was going
to take more interest than I as able to afford with my RealLife(tm).
> What's wrong with having both PAM and SASL in the implementation? And
> isn't this the case? I'm still using Cyrus IMAP 2.0.13 so maybe PAM
> has been removed since, but I would be surprised.
PAM has never been in the distribution. SASL is in the distribution and
PAM is supported by SASL. T
> BTW, what is the fastest route?
> imap -> sasl -> pam-ldap -> ldap server
> imap -> sasl -> ldap server
The fastest route to me seems to be:
imap -> pam_ldap -> ldap sever
Can we PLEASE produce a version of cyrus-imap imap WITHOUT SASL? PAM may
be a smidgeon less flexible, but it is simp
David Wright wrote:
>
> I am faced with the same "signaled to death by 11" problem on RH 7.1
> that has been reported in this list several times before. I think I
> understand the problem, but I need a little coaching to implement a
> solution.
>
> Here's the problem: whenever I login correctl
Use the sasl-ldap patch and bypass the problem alltogether.
BTW, what is the fastest route?
imap -> sasl -> pam-ldap -> ldap server
imap -> sasl -> ldap server
I know the last seems to be the fastest, but I thought I'd ask.
> I am using
>sasl_pwcheck_method: PAM
Yes, I have had the same pro
3f000)
-Original Message-
From: Tarjei Huse [mailto:[EMAIL PROTECTED]]
Sent: Monday, July 30, 2001 4:41 AM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: Signaled to death by 11 - Don't know what else to try
Hi,
> I w
On Mon, 30 Jul 2001, Tarjei Huse wrote:
> Hi,
>
> > I would sugges to have only one valid berkeley db version in your
> > system (either 3.1 or 3.2), because otherwise you might encounter
> > errors of the third art ;-) Especially on building cyrus imap I already
> > found out, that it is better
Hi,
> I would sugges to have only one valid berkeley db version in your
> system (either 3.1 or 3.2), because otherwise you might encounter
> errors of the third art ;-) Especially on building cyrus imap I already
> found out, that it is better to have only one (and the most actual one)
Also, mak
On Mon, 30 Jul 2001, Daryl Tester wrote:
> Levent G|ndogdu wrote:
>
> >>> [root@vmsurfrider bin]# ldd master
> >>> libdb-3.1.so => /lib/libdb-3.1.so (0x4010d000)
> >>
> >>> [root@vmsurfrider bin]# ldd imapd
> >>> libdb-3.1.so => /lib/libdb-3.1.so (0x401af000)
> >>
> >>> [root@vms
Levent G|ndogdu wrote:
>>> [root@vmsurfrider bin]# ldd master
>>> libdb-3.1.so => /lib/libdb-3.1.so (0x4010d000)
>>
>>> [root@vmsurfrider bin]# ldd imapd
>>> libdb-3.1.so => /lib/libdb-3.1.so (0x401af000)
>>
>>> [root@vmsurfrider bin]# ldd pop3d
>>> libdb-3.1.so => /lib/li
John Riganati wrote:
Not sure if this is significant or not, but ...
> My ld.so.conf file looks like this:
> [root@vmsurfrider Docs]# more /etc/ld.so.conf
> /usr/local/BerkeleyDB.3.2/lib
[...]
> [root@vmsurfrider bin]# ldd master
> libdb-3.1.so => /lib/libdb-3.1.so (0x4010d000)
> [root
Hi,
Your problem sounds familiar. Not being an experienced C programmer I
didn't attempt to understand and locate the problem. Instead I dropped
the pam_ldap authentication and instead applied the mysql_ldap patch. I
don't have the link for the patch handy, but I have source rpms and RedHat
binar
from scratch helped.
-Kiran
-Original Message-
From: Ross Golder [mailto:[EMAIL PROTECTED]]
Sent: Friday, January 26, 2001 5:04 AM
To: Ramineni, Kiran
Subject: Re: signaled to death by 11
"Ramineni, Kiran" wrote:
>
> I have installed cyrus-imapd-2.0.9 and cyrus-sasl-1
77 matches
Mail list logo
