start tls

[Steffen Ries]

Michael Ströder <michael at stroeder.com> writes:

> Everything went well running (with web2ldap) against
> ldap.openldap.org but it failed when accessing www.nldap.com (Novell
> DS) or ldap.surfnet.nl (Netscape DS). I got segmentation faults.

Hmmmm. I don't have problems with it:

>>> import ldap
>>> s = ldap.open('ldap.surfnet.nl')
>>> s.simple_bind_s('','')
>>> s.search_s('', ldap.SCOPE_ONELEVEL, 'objectclass=*', ['objectclass'])
[('C=NL', {'objectclass': ['top',...

Can you run python inside gdb to get a traceback? Or give me more
details how you got the segfaults?

> The OpenLDAP 2.0-patches by Konstantin for python-ldap posted before
> on the mailing list worked. Maybe you already have a newer version
> of your patch?

No newer version, I can redo the diffs against CVS, but I'm not sure
whether this would help.

> I checked the shared libs. Seems ok to me.
> 
> $ ldd _ldap.so 
>         libldap.so.2 => /usr/local/openldap2/lib/libldap.so.2
> (0x40023000)
>         liblber.so.2 => /usr/local/openldap2/lib/liblber.so.2
> (0x4004e000)
>         libc.so.6 => /lib/libc.so.6 (0x40058000)
>         libsasl.so.7 => /usr/lib/libsasl.so.7 (0x4016b000)
>         libssl.so.0.9.6 => /usr/lib/libssl.so.0.9.6 (0x40176000)
>         libcrypto.so.0.9.6 => /usr/lib/libcrypto.so.0.9.6
> (0x4022e000)
>         /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)
>         libgdbm.so.2 => /usr/lib/libgdbm.so.2 (0x402f2000)
>         libdl.so.2 => /lib/libdl.so.2 (0x402fa000)
>         libcrypt.so.1 => /lib/libcrypt.so.1 (0x402fd000)
>         libpam.so.0 => /lib/libpam.so.0 (0x4032b000)
>         libresolv.so.2 => /lib/libresolv.so.2 (0x40333000)

looks fine. on my Redhat 7.1 system I get libssl.so.1 and
libcrypt.so.1 instead, but I don't think that would make a difference.

libldap.so.2 is symlinked to libldap.so.2.0.6 (same for liblber.so),
i.e. openldap-2.0.11

/steffen