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,
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, ldapadd work and the
LDAP Browser from U.M. communic
26 matches
Mail list logo
