python-ldap-dev — discussion among developers

Re: Implementation of LDAPControls

[Hans A. <Han...@ep...>]

On Monday 20 December 2004 10:01, Michael Str=F6der wrote:

> 1.b Implement a pure Python BER module. Maybe we could get one from a
> SNMP implementation implemented in Python?

I did some research on this topic some time ago. That's the results, as far=
 as=20
I remember:

To me, pySNMP looks fine (feature and license-wise). It is a pure-python=20
package, and the ASN.1 package can be used independently from the rest of t=
he=20
pySNMP package, and it has a reasonable size (~100 k). They also implement=
=20
(as far as I understand it) not only the snmp-parts of ASN.1 (or their BER=
=20
encodings), but try to be generic. On the other hand, I have never tried th=
is=20
package...

The package and docs are located on sourceforge:

http://pysnmp.sourceforge.net/docs/3.4.x/asn1/index.html

BTW. pysnmp is also used in twisted...

Hans

Re: Implementation of LDAPControls

[<mi...@st...>]

Ingo Steuwer wrote:
> 
> To fulfill our upcomming goals we need to use LDAPControls, but the
> latest released version of python-ldap doesn't support them. 

Yes, you'll find a hint in file TODO.

> We did some experimental implementations in the C-backend (for "proof of
> concept") and would now like to define a general approach. This should
> be done in coordination with you to see our work in upcoming versions of
> python-ldap.

Since I'm not a C programmer (David wrote the C code) I'd be really glad 
if someone would jump on in and contribute code for LDAP controls and 
extended operations.

I already tried to wrap the arguments whereever appropriate. Please 
review this.

> My attempt would defining a python-class LDAPControl (containing OID,
> iscritcal and value (dictionary)) and implement a correspondig wrapper
> to *LDAPControl.

But value can be a complex ASN.1 structure as well.

> I think the most diffcult part will be the
> representation of berval/berelement in python.

Yes.

> - is there somebody else implementing this (I didn't look at the cvs) ?

No. And I'm currently rather short on time. I'd highly appreciate your 
contributions. But note that you should give away copyright for your 
contributed code. Make sure that your legal department agrees on that.

> - are there already thoughts, definitions or an approach I should know ?

There are several approaches.

1. Python classes for controls with a method berencode(). This method 
would be called before passing the controls as argument to the functions 
in _ldap. This would be the most flexible approach and independent of 
the underlying OpenLDAP API. Drawbacks are that you need a BER module 
for this and it's much work for complex controls.

1.a Wrap libber.

1.b Implement a pure Python BER module. Maybe we could get one from a 
SNMP implementation implemented in Python?

2. We could also wrap the helper functions in libldap (see controls.c, 
vlvctrl.c, sortctrl.c). But this would add another strong dependency on 
the OpenLDAP libs.

> - do you know about wrappers between berval/berelement and python ?

No. You could try to wrap OpenLDAP's libber.

Ciao, Michael.

Re: undefined symbol

[<mi...@st...>]

Paul Casteels wrote:
 > Michael Str=F6der wrote:
 >
 >> Hmm, you might have several versions of the OpenLDAP libs hanging
 >> around on your system.
 >
 > Thanks for your reply Michael. I tried python-ldap-2.0.6 with the same=

 > result. Compiling and linking goes without problems. I suppose I could=

 > not have _ldap.so if it failed ?

I don't know your system. There are many possibilities how things can go =

wrong with a library mix.

Please compare the time-stamp of the installed file=20
/usr/lib/python2.2/site-packages/_ldap.so with your build time.

Ciao, Michael.

P.S.: Please stay on pyt...@li... that others=20
can answer as well.

Re: Connections established using SASL die after search

[<mi...@st...>]

Mark Roach wrote:
 >
 > In order to test where in the ldap/sasl/python stack the problem is
 > coming from, I also patched ldapsearch.c to run the same queries. It
 > seems to work just fine. The patch is attached.

Because I don't experience any problems at all I still suspect your 
local installation has a library mix.

Ciao, Michael.

Re: Connections established using SASL die after search

[<mi...@st...>]

Mark Roach wrote:
> 
> OK, I promise this will be my last message on the subject.
 > [..]
 > Thanks again. And sorry for all the noise on this list.

Let me clearly state that you're welcome to mention your problems here. 
I do not consider this noise.

I'm currently a little short on time. That's why I didn't answer to your 
recent posts yet. And although I did some tests myself I can't reproduce 
your problem on my system.

> I am currently using ReconnectLDAPObject as a workaround, and it seems fine

That's what I'd have suggested although it is just a work-around.

 > I just wanted to post one last test
 > case. It doesn't get much smaller than this :-)

I ran your script with little modifications against a W2K3 Active 
Directory using SASL/GSSAPI with no problems at all. Maybe I should run 
the test with OpenLDAP slapd and heimdal KDC. But this will take me a 
while because I have to setup my KDC again.

import ldap, ldap.sasl
l = ldap.initialize('ldap://xxxxxx.vmtestnetz.xxx.xx')
l.sasl_interactive_bind_s('', ldap.sasl.gssapi())

# Here's the real work. The use of multiple search bases is key
for i in range(2000):
   try:
     for ou in ['Users','Computers','System']:
       dn = 'CN=%s,DC=VMTESTNETZ,DC=XXX,DC=XX' % ou
       res = l.search_s(dn, ldap.SCOPE_ONELEVEL, '(objectClass=*)')
   except ldap.SERVER_DOWN:
     print 'Aborted after %d searches' % i
     break

Ciao, Michael.

Re: Connections established using SASL die after search

[Mark R. <mr...@ok...>]

On Tue, 2004-12-14 at 10:55 -0500, Mark Roach wrote:
> On Tue, 2004-12-14 at 08:59 +0100, Michael Str=F6der wrote:
> > Mark Roach wrote:
> > >     except:
> > >         print "Died on iteration %d" % (i)
> > >         print out
> > >         break
> >=20
> > You're catching all LDAP error exceptions here without printing them.

> In order to test where in the ldap/sasl/python stack the problem is
> coming from, I also patched ldapsearch.c to run the same queries. It
> seems to work just fine. The patch is attached.

OK, I promise this will be my last message on the subject. I am
currently using ReconnectLDAPObject as a workaround, and it seems fine
(if not the purist's approach). I just wanted to post one last test
case. It doesn't get much smaller than this :-)



import ldap, ldap.sasl
l =3D initialize('ldap://my.ldap.server')
l.sasl_interactive_bind_s('', ldap.sasl.gssapi())

# Here's the real work. The use of multiple search bases is key
for i in range(20):=20
    [l.search_s('ou=3D%s,dc=3Dokmaybe,dc=3Dcom' % ou, ldap.SCOPE_ONELEVEL, =
'(objectClass=3D*)') \
            for ou in ['system','people','groups']]

Thanks again. And sorry for all the noise on this list.

-Mark

Implementation of LDAPControls

[Ingo S. <st...@un...>]

Hello

we are using python-ldap in some of our main projects and are glad to
have this great tool.

To fulfill our upcomming goals we need to use LDAPControls, but the
latest released version of python-ldap doesn't support them. 

We did some experimental implementations in the C-backend (for "proof of
concept") and would now like to define a general approach. This should
be done in coordination with you to see our work in upcoming versions of
python-ldap.

At the moment we need no "complete" implementation, only support for
sending an arbitrary OID and the "iscritcal"-Flag. But the
implementation should be prepared for optional values and parsing of
client-controls.

My attempt would defining a python-class LDAPControl (containing OID,
iscritcal and value (dictionary)) and implement a correspondig wrapper
to *LDAPControl. I think the most diffcult part will be the
representation of berval/berelement in python.

So, some questions before going further:

- is there somebody else implementing this (I didn't look at the cvs) ?
- are there already thoughts, definitions or an approach I should know ?
- do you know about wrappers between berval/berelement and python ?

I'd be glad to get some hints, opinions and feedback.


Regards
Ingo Steuwer



-- 
Ingo Steuwer       st...@un...         fon: +49 421 22 232- 0
Entwicklung        Linux for Your Business       
Univention GmbH    http://www.univention.de/     fax: +49 421 22 232-99

Re: undefined symbol

[<mi...@st...>]

Paul Casteels wrote:
 >
 > ImportError: /usr/lib/python2.2/site-packages/_ldap.so: undefined
 > symbol: ldap_passwd

What does

ldd /usr/lib/python2.2/site-packages/_ldap.so

display?

Does it really link the right OpenLDAP libs? I suspect the function 
ldap_passwd is not available in OpenLDAP 2.0.x libs. But then I wonder 
how you managed to compile from source. Did you?

Hmm, you might have several versions of the OpenLDAP libs hanging around 
on your system.

Ciao, Michael.

Re: Connections established using SASL die after search

[Mark R. <mr...@ok...>]

On Tue, 2004-12-14 at 08:59 +0100, Michael Str=F6der wrote:
> Mark Roach wrote:
> >     except:
> >         print "Died on iteration %d" % (i)
> >         print out
> >         break
>=20
> You're catching all LDAP error exceptions here without printing them.

Good point. I made some modifications (attached). I have attached the
output from a few iterations.


In order to test where in the ldap/sasl/python stack the problem is
coming from, I also patched ldapsearch.c to run the same queries. It
seems to work just fine. The patch is attached.

Thanks again,

Mark

Re: Connections established using SASL die after search

[<mi...@st...>]

Mark Roach wrote:
>     except:
>         print "Died on iteration %d" % (i)
>         print out
>         break

You're catching all LDAP error exceptions here without printing them.

To avoid information loss either solely catch with

     except ldap.SERVER_DOWN:
         print "Died on iteration %d" % (i)
         print out
         break

or explicitly print out the LDAPError exception:

     except ldap.LDAPError,e:
         print "LDAPError on iteration %d: %s" % (i,e)
         print out
         break

Ciao, Michael.

Re: Connections established using SASL die after search

[Mark R. <mr...@ok...>]

On Sun, 2004-12-12 at 01:28 +0100, Michael Str=F6der wrote:

> Upgrading would be good. AFAIK the MIT Kerberos implementation is not=20
> thread-safe. This can lead to very weird effects depending how=20
> OpenLDAP's slapd is built. Use a recent heimdal release instead.

Hi, Michael. Thanks for your assistance with this. I have upgraded my
openldap server to 2.2.19 and replaced the mit kerberos sasl module with
the heimdal one and the problem seems to be the same.

I have no idea if it's useful, but I am including the tail of the debug
output of slapd process while causing a failure.

Any additional suggestions are much appreciated.

Thanks,

Mark Roach



        Slapd debug info:
-----------------------------------
=3D> access_allowed: search access granted by read(=3Drscx)
<=3D test_filter 5
<=3D test_filter_and 5
<=3D test_filter 5
bdb_search: 110 does not match filter
send_ldap_result: conn=3D6 op=3D2 p=3D3
send_ldap_result: err=3D0 matched=3D"" text=3D""
send_ldap_response: msgid=3D3 tag=3D101 err=3D0
ber_flush: 14 bytes to sd 10
  0000:  30 0c 02 01 03 65 07 0a  01 00 04 00 04 00
0....e........
ldap_write: want=3D14, written=3D14
  0000:  30 0c 02 01 03 65 07 0a  01 00 04 00 04 00
0....e........
conn=3D6 op=3D2 SEARCH RESULT tag=3D101 err=3D0 nentries=3D0 text=3D
daemon: activity on 1 descriptors
daemon: activity on: 10r
daemon: read activity on 10
connection_get(10)
connection_get(10): got connid=3D6
connection_read(10): checking for input on id=3D6
ber_get_next
ldap_read: want=3D8, got=3D0

ber_get_next on fd 10 failed errno=3D0 (Success)
connection_read(10): input error=3D-2 id=3D6, closing.
connection_closing: readying conn=3D6 sd=3D10 for close
connection_close: conn=3D6 sd=3D10
daemon: removing 10
conn=3D6 fd=3D10 closed
daemon: select: listen=3D6 active_threads=3D0 tvp=3DNULL
daemon: select: listen=3D7 active_threads=3D0 tvp=3DNULL
daemon: activity on 1 descriptors
daemon: select: listen=3D6 active_threads=3D0 tvp=3DNULL
daemon: select: listen=3D7 active_threads=3D0 tvp=3DNULL

[Fwd: ANN: PSF Licensing FAQ]

[<mi...@st...>]

I think it's worth to take note of...

Ciao, Michael.

-------- Original Message --------
Subject: ANN: PSF Licensing FAQ
Date: Sat, 11 Dec 2004 15:53:48 -0500 (EST)
From: Stephan Deibel <sd...@wi...>
To: pyt...@py...
Newsgroups: comp.lang.python

Hi,

The Python Software Foundation (PSF) board recently wrote up a licensing
FAQ that we hope will help to clear up some of the confusion that has
surrounded the PSF License.  There are quite a few projects out there (on
Source Forge and otherwise) that misuse this license in ways potentially
detrimental to those projects.

If you are the author or maintainer of a project that uses the PSF
License, please read this:

http://www.python.org/cgi-bin/moinmoin/PythonSoftwareFoundationLicenseFaq

In short:  The PSF License was originally developed specifically and only
for Python itself (and its standard library).  It can be reused but not
verbatim without modifying the copyright and product name in the license.
Also, the entire "license stack" that comes with Python is irrelevant to
3rd party projects and should not be reproduced outside of Python.

The above document also covers contribution of code to the PSF, which is
only an issue if your code will become part of the Python distribution.
The contribution process is still being set up, so this part of the
document is subject to change.

Please cc me on any replies, as I can't currently keep up with CLP.

Thanks!

Stephan Deibel
Chairman of the Board
Python Software Foundation

http://python.org/psf

Re: Connections established using SASL die after search

[<mi...@st...>]

Mark Roach wrote:
> 
> I'm on Ubuntu. Relevant versions of software are:
> 
> SERVER:
>     slapd: 2.1.30
>     libkrb53: 1.3.4
>     libsasl2: 2.1.19
>     libsasl2-gssapi-mit: 2.1.18
> 
> CLIENT:
>     libsasl2: 2.1.19
>     libsasl2-gssapi-mit: 2.1.18
>     python-ldap: 2.0.4
> 
> I guess I'll have to try upgrading my openldap stuff,

Upgrading would be good. AFAIK the MIT Kerberos implementation is not 
thread-safe. This can lead to very weird effects depending how 
OpenLDAP's slapd is built. Use a recent heimdal release instead.

Ciao, Michael.

Re: Connections established using SASL die after search

[Mark R. <mr...@ok...>]

On Sat, 2004-12-11 at 13:36 +0100, Michael Str=F6der wrote:
> >=20
> > Are you sure that the code and python-ldap causes the problem?
> >=20
> > Which LDAP server and which version is it?
>=20
> It'd be also useful to know which versions of OpenLDAP libs, cyrus-sasl=20
> and heimdal are used with python-ldap.
>=20
> Note that this combination is rather fragile. Please use current=20
> versions of all these...

Hi, Michael. I'm not sure how to test outside of python-ldap. I guess I
could try duplicating the code in C, but that would take me some time as
I'm not much of a C hacker.

I'm on Ubuntu. Relevant versions of software are:

SERVER:
    slapd: 2.1.30
    libkrb53: 1.3.4
    libsasl2: 2.1.19
    libsasl2-gssapi-mit: 2.1.18

CLIENT:
    libsasl2: 2.1.19
    libsasl2-gssapi-mit: 2.1.18
    python-ldap: 2.0.4

I guess I'll have to try upgrading my openldap stuff, but I am hoping to
be able to deploy this app on debian systems where this is the latest
version (due to their patch to use gnutls instead of openssl not having
been ported yet).

Can anyone else maybe try to run the example code I provided and see if
it causes problems for them?

Thanks,

Mark Roach

Re: Connections established using SASL die after search

[<mi...@st...>]

Michael Str=F6der wrote:
> Mark Roach wrote:
>=20
>> Hello, all. I've been trying to figure out the cause of a strange bug
>> and have traced it down to a small example. It seems that searching wi=
th
>> wildcards or using the ! operator cause the ldap connection to die, bu=
t
>> only when using gssapi (possibly other sasl mechanisms, that's the onl=
y
>> one I've tried).
>>
>> Here is the code that causes the problem, you should be able to cut n'=

>> paste into an interactive interpreter.
>=20
> Are you sure that the code and python-ldap causes the problem?
>=20
> Which LDAP server and which version is it?

It'd be also useful to know which versions of OpenLDAP libs, cyrus-sasl=20
and heimdal are used with python-ldap.

Note that this combination is rather fragile. Please use current=20
versions of all these...

Ciao, Michael.

Re: Connections established using SASL die after search

[<mi...@st...>]

Mark Roach wrote:
> Hello, all. I've been trying to figure out the cause of a strange bug
> and have traced it down to a small example. It seems that searching with
> wildcards or using the ! operator cause the ldap connection to die, but
> only when using gssapi (possibly other sasl mechanisms, that's the only
> one I've tried).
> 
> Here is the code that causes the problem, you should be able to cut n'
> paste into an interactive interpreter.

Are you sure that the code and python-ldap causes the problem?

Which LDAP server and which version is it?

Ciao, Michael.

Connections established using SASL die after search

[Mark R. <mr...@ok...>]

Hello, all. I've been trying to figure out the cause of a strange bug
and have traced it down to a small example. It seems that searching with
wildcards or using the ! operator cause the ldap connection to die, but
only when using gssapi (possibly other sasl mechanisms, that's the only
one I've tried).

Here is the code that causes the problem, you should be able to cut n'
paste into an interactive interpreter.

Thanks for any suggestions.

Mark Roach

#----------------------------

import ldap
import ldap.sasl

URI = 'ldap://cujo.okmaybe.com'
BASEDN = 'dc=okmaybe,dc=com'
BINDDN = 'cn=admin,dc=okmaybe,dc=com'
PASS = 'mypassword'

def printTree(conn, dn, out, indent=0, run_extra_search=False):
    "recursively prints ou objects to a list"
    # This is the extra bit of searching that kills the ldap connection
    if (run_extra_search):
        resid = conn.search(dn, ldap.SCOPE_ONELEVEL, \
                '(objectClass=*)')
        rescode, res = conn.result(resid, timeout=10)
    # Search for organizationalUnits recursively
    resid = conn.search(dn, ldap.SCOPE_ONELEVEL, \
            '(objectClass=organizationalUnit)', ['ou'])
    rescode, res = conn.result(resid, timeout=10)
    out.append( "    " * indent + dn)
    for c in res: 
        if c[1].has_key('ou'):
            printTree(conn, c[0], out, indent + 1, run_extra_search)

### Try a connection with simple bind (This works fine)
l = ldap.initialize(URI)

l.bind_s(BINDDN, PASS)

for i in xrange(50):
    out = []
    printTree(l, BASEDN, out)

for i in xrange(50):
    out = []
    printTree(l, BASEDN, out, run_extra_search = True)


### Now try a gssapi connection
g = ldap.sasl.gssapi()
l = ldap.initialize(URI)
l.sasl_interactive_bind_s('', g)

# This one works
for i in xrange(50):
    out = []
    try:
        printTree(l, BASEDN, out)
    except:
        print "Died on iteration %d" % (i)
        print out
        break

# Maybe dies, maybe succeeds (mostly dies)
for i in xrange(50):
    out = []
    try:
        printTree(l, BASEDN, out, run_extra_search = True)
    except:
        print "Died on iteration %d" % (i)
        print out
        break

Re: LDAP search segfaults on RH FC3

[Tessa L. <tla...@tl...>]

On Thu, Dec 09, 2004 at 03:30:00AM +0100, Michael Stroeder wrote:
> ldd /usr/lib/python2.3/site-packages/_ldap.so
        libldap_r-2.2.so.7 => /usr/lib/libldap_r-2.2.so.7 (0xf6f9e000)
        liblber-2.2.so.7 => /usr/lib/liblber-2.2.so.7 (0xf6f91000)
        libsasl2.so.2 => /usr/lib/libsasl2.so.2 (0xf6f7d000)
        libssl.so.4 => /lib/libssl.so.4 (0xf6f49000)
        libcrypto.so.4 => /lib/libcrypto.so.4 (0xf6e61000)
        libpthread.so.0 => /lib/tls/libpthread.so.0 (0xf6e4f000)
        libc.so.6 => /lib/tls/libc.so.6 (0xf6d28000)
        libresolv.so.2 => /lib/libresolv.so.2 (0xf6d13000)
        libdl.so.2 => /lib/libdl.so.2 (0xf6d0f000)
        libcrypt.so.1 => /lib/libcrypt.so.1 (0xf6ce1000)
        libgssapi_krb5.so.2 => /usr/lib/libgssapi_krb5.so.2 (0xf6ccd000)
        libkrb5.so.3 => /usr/lib/libkrb5.so.3 (0xf6c68000)
        libcom_err.so.2 => /lib/libcom_err.so.2 (0xf6c65000)
        libk5crypto.so.3 => /usr/lib/libk5crypto.so.3 (0xf6c43000)
        libz.so.1 => /usr/lib/libz.so.1 (0xf6c33000)
        /lib/ld-linux.so.2 (0xf6feb000)

> Do all the RPMs come from Fedora?

Yes.  This is a fresh install of FC3 direct from the ISOs.

> Does the current version of python-ldap compiled from source also segfault?

Yep.  I checked out the latest python-ldap from anonymous CVS, compiled,
and ran my test against it.  Same result.

--Tessa

Re: LDAP search segfaults on RH FC3

[<mi...@st...>]

Tessa Lau wrote:
> 
> I'm finding that Python-LDAP on Fedora Core 3 segfaults when doing an
> LDAP search.

I'm pasting the RPM list from your bug report here as quotation:

> Python and LDAP RPMs installed:
> 
> python-2.3.4-11
> nss_ldap-220-3
> python-ldap-2.0.1-2
> openldap-2.2.13-2
> openldap-devel-2.2.13-2
> openldap-clients-2.2.13-2
> openldap-servers-2.2.13-2
> [..]
> cyrus-sasl-2.1.19-3
> cyrus-sasl-plain-2.1.19-3
> cyrus-sasl-md5-2.1.19-3
> cyrus-sasl-devel-2.1.19-3

nss_ldap is not relevant here. Maybe some mix of the used libraries 
though. What's the output of:

ldd /usr/lib/python2.3/site-packages/_ldap.so

Do all the RPMs come from Fedora?

Does the current version of python-ldap compiled from source also segfault?

Ciao, Michael.

Re: LDAP search segfaults on RH FC3

[David M. <dma...@re...>]

On Wed, 2004-12-08 at 17:52 -0500, Tessa Lau wrote:
> Hi,
> 
> I'm finding that Python-LDAP on Fedora Core 3 segfaults when doing an
> LDAP search.  The same code works without crashing on a Debian system.
> The gdb backtrace indicates that the crash happens while processing an
> error from the LDAP server.  I submitted the bug to Python sourceforge,
> but they told me to post it here instead.  Here's the URL:
> 
> http://sourceforge.net/tracker/index.php?func=detail&aid=1081633&group_id=5470&atid=105470
> 
> The RPM versions are listed in the bug report.  Since the backtrace also
> references SASL, here are the versions of Cyrus SASL installed:
> 
> cyrus-sasl-2.1.19-3
> cyrus-sasl-plain-2.1.19-3
> cyrus-sasl-md5-2.1.19-3
> cyrus-sasl-devel-2.1.19-3
> 
> Any ideas?

If the crash seems to be specific to Fedora, please can you file a bug
for it in Red Hat's bugzilla please.

Thanks
Dave Malcolm

LDAP search segfaults on RH FC3

[Tessa L. <tla...@tl...>]

Hi,

I'm finding that Python-LDAP on Fedora Core 3 segfaults when doing an
LDAP search.  The same code works without crashing on a Debian system.
The gdb backtrace indicates that the crash happens while processing an
error from the LDAP server.  I submitted the bug to Python sourceforge,
but they told me to post it here instead.  Here's the URL:

http://sourceforge.net/tracker/index.php?func=detail&aid=1081633&group_id=5470&atid=105470

The RPM versions are listed in the bug report.  Since the backtrace also
references SASL, here are the versions of Cyrus SASL installed:

cyrus-sasl-2.1.19-3
cyrus-sasl-plain-2.1.19-3
cyrus-sasl-md5-2.1.19-3
cyrus-sasl-devel-2.1.19-3

Any ideas?

Thanks,
--Tessa

=================
Tessa Lau, PhD
http://tlau.org/

LDAP search segfaults on RH FC3

[Tessa L. <tl...@tl...>]

Hi,

I'm finding that Python-LDAP on Fedora Core 3 segfaults when doing an
LDAP search.  The same code works without crashing on a Debian system.
The gdb backtrace indicates that the crash happens while processing an
error from the LDAP server.  I submitted the bug to Python sourceforge,
but they told me to post it here instead.  Here's the URL:

http://sourceforge.net/tracker/index.php?func=detail&aid=1081633&group_id=5470&atid=105470

The RPM versions are listed in the bug report.  Since the backtrace also
references SASL, here are the versions of Cyrus SASL installed:

cyrus-sasl-2.1.19-3
cyrus-sasl-plain-2.1.19-3
cyrus-sasl-md5-2.1.19-3
cyrus-sasl-devel-2.1.19-3

Any ideas?

Thanks,
--Tessa

=================
Tessa Lau, PhD
http://tlau.org/

ANN: python-ldap-2.0.6

[<mi...@st...>]

Find a new release of python-ldap:

   http://python-ldap.sourceforge.net/

python-ldap provides an object-oriented API to access LDAP directory
servers from Python programs. It mainly wraps the OpenLDAP 2.x libs for
that purpose. Additionally it contains modules for other LDAP-related
stuff (e.g. processing LDIF, LDAPURLs and LDAPv3 schema).

----------------------------------------------------------------
Released 2.0.6 2004-12-03

Changes since 2.0.5:

Lib/:
* Added sub-module ldap.dn
* Added function ldap.dn.escape_dn_chars()
* Special check when implicitly setting SUP 'top' to
   structural object classes without SUP defined to avoid
   a loop in the super class chain.

Re: escape_dn_chars

[<mi...@st...>]

Bertrand Croq wrote:
>   I wasn't able to find a function to escape chars in DN strings, so I
> wrote this one (based on escape_filter_chars):
> 
> def escape_dn_chars(s):
> 	s = s.replace('\\', r'\5C')
> 	s = s.replace(',', r'\2C')
> 	s = s.replace('=', r'\3D')
> 	s = s.replace('+', r'\2B')
> 	return s
> 
> Feel free to use/modify it in python-ldap (license: PSFL, as
> python-ldap)

Thanks for contributing it. I've added a new function 
ldap.dn.escape_dn_chars() in a new sub-module ldap.dn to CVS. It was 
taken from web2ldap which also handles two special cases with # as first 
char and a trailing space.

Please test!

Ciao, Michael.

undefined symbol

[Paul C. <Pau...@ua...>]

Hi,

  I have python-2.2.3-5, cyrus-sasl-2.1.15-10 and openldap-2.0.27-17 
installed.
  Builing and installing python-ldap-2.0.5 went fine but when I try to 
start I have :

Python 2.2.3 (#1, Aug  8 2003, 08:44:02)
[GCC 3.2.3 20030502 (Red Hat Linux 3.2.3-13)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
 >>> import ldap
Traceback (most recent call last):
   File "<stdin>", line 1, in ?
   File "/usr/lib/python2.2/site-packages/ldap/__init__.py", line 21, in ?
     from _ldap import *
ImportError: /usr/lib/python2.2/site-packages/_ldap.so: undefined 
symbol: ldap_passwd
 >>>

  Are there any suggestions to fix this ?

Best regards and thanks,

	Paul Casteels