python-ldap-dev — discussion among developers

Re: Commit new-style docs to CVS?

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

Since there were no major objections I've committed new docs.

Ciao, Michael.

Michael Ströder wrote:
> 
> Waldemar Osuch contributed the converted new-style docs for python-ldap 
> based on the latest latex-based docs. You can view/browse the PDF and 
> HTML builds here:
> 
> http://python-ldap.sourceforge.net/new-style-doc/
> 
> The PDF index does not look too good at the moment but I'm not sure how 
> important PDF docs are today.
> 
> Please review and comment. Especially I'd like to have feedback whether 
> this should be committed to CVS and the old latex-based stuff removed 
> from CVS.
> 
> Also see:
> http://sourceforge.net/tracker/index.php?func=detail&aid=1926469&group_id=2072&atid=352072 
> 
> 
> Ciao, Michael.

Re: Commit new-style docs to CVS?

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

Ryan Lovett wrote:
> On Sun, Mar 30, 2008 at 05:03:49PM +0200, Michael Str?der wrote:
>> Please review and comment.
> 
> The new HTML docs look very nice and the search facility is wonderful.

> Perhaps "Front Matter" on /index.html could be changed to "Overview" or
> "Introduction"? "Front Matter" is better suited to labotomists. :)

Well the start of the documentation was IMO overkill from the very 
beginning.

----------------------- snip -----------------------
LDAP programming with Python
Author:	python-ldap project
Front Matter

Abstract

This document describes the package python-ldap with its various modules 
This manual assumes basic knowledge about the Python language and the 
LDAP standard.
python-ldap package

Contents:
[..]
----------------------- snip -----------------------

Glancing at the Python new-style docs this should be probably trimmed to:

----------------------- snip -----------------------
python-ldap Documentation

This document describes the package python-ldap with its various modules 
This manual assumes basic knowledge about the Python language and the 
LDAP standard.

Contents:
[..]
----------------------- snip -----------------------

Not sure how a PDF document looks like then.

> Also, is the floating red paragraph symbol necessary? It is somewhat
> distracting.

Hmm, I guess it comes from a standard CSS which I don't like to change. 
Same behaviour in Python 2.6 docs. The pop-up of this symbol shows the 
text "Permalink to this definition".

Ciao, Michael.

Re: Commit new-style docs to CVS?

[Ryan L. <ry...@st...>]

On Sun, Mar 30, 2008 at 05:03:49PM +0200, Michael Str?der wrote:
> Please review and comment.

The new HTML docs look very nice and the search facility is wonderful.
Perhaps "Front Matter" on /index.html could be changed to "Overview" or
"Introduction"? "Front Matter" is better suited to labotomists. :)

Also, is the floating red paragraph symbol necessary? It is somewhat
distracting.

Ryan

Re: Commit new-style docs to CVS?

[Jens V. <je...@da...>]

On Mar 30, 2008, at 17:03 , Michael Ströder wrote:
> HI!
>
> Waldemar Osuch contributed the converted new-style docs for python- 
> ldap
> based on the latest latex-based docs. You can view/browse the PDF and
> HTML builds here:
>
> http://python-ldap.sourceforge.net/new-style-doc/
>
> The PDF index does not look too good at the moment but I'm not sure  
> how
> important PDF docs are today.
>
> Please review and comment. Especially I'd like to have feedback  
> whether
> this should be committed to CVS and the old latex-based stuff removed
> from CVS.

Looks good enough to me...

jens

Commit new-style docs to CVS?

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

HI!

Waldemar Osuch contributed the converted new-style docs for python-ldap 
based on the latest latex-based docs. You can view/browse the PDF and 
HTML builds here:

http://python-ldap.sourceforge.net/new-style-doc/

The PDF index does not look too good at the moment but I'm not sure how 
important PDF docs are today.

Please review and comment. Especially I'd like to have feedback whether 
this should be committed to CVS and the old latex-based stuff removed 
from CVS.

Also see:
http://sourceforge.net/tracker/index.php?func=detail&aid=1926469&group_id=2072&atid=352072

Ciao, Michael.

Re: ANN: python-ldap-2.3.4

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

On 2:20:18 pm 2008-03-29 Torsten Kurbad <pyt...@tk...> wrote:
> On Saturday, March 29, 2008 at 13:25 Michael Ströder wrote:
> >  Released 2.3.4 2008-03-29
>
> Wow, Michael, that was fast!

Seg faults are urgent issues although in this case nobody ever reported it.
Special thanks to Matej for his quick fix.

Ciao, Michael.

Re: ANN: python-ldap-2.3.4

[Torsten K. <pyt...@tk...>]

On Saturday, March 29, 2008 at 13:25 Michael Ströder wrote:
> Released 2.3.4 2008-03-29

Wow, Michael, that was fast!

I'm gonna build new eggs for different platforms on monday and put them
on our site.

Regards,
Torsten
-- 
Never make anything simple and efficient when a way can be found to
make it complex and wonderful.              - Murphy's Law No. 13 -

ANN: python-ldap-2.3.4

[Michael S. <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.3.4 2008-03-29

Changes since 2.3.3:

Modules/
* Fixed seg fault when calling LDAPObject.get_option()
   (see SF#1926507, thanks to Matej)

----------------------------------------------------------------
Released 2.3.3 2008-03-26

Changes since 2.3.2:

Fixed backward-compability when building with OpenLDAP 2.3.x libs.

Re: Leaving a connection open

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

Ron Teitelbaum wrote:
> 
> I'm getting
> can't-contact-ldap-server errors that I thought this would help with.  Note,
> I believe this is different from the server down error you are mentioning.  

Believe me it's not different. ldap.SERVER_DOWN is the exact exception class 
which you have to catch with except ldap.SERVER_DOWN. "Can't contact LDAP 
server" is the descriptive text (diagnostic message) for that. Note that 
this very same exception is raised if anything goes wrong with SSL/TLS and 
cert checking but with another descriptive text coming from the underlying 
SSL lib.

 > How can I create the server_down error for testing?

Example for a connect to a non-existing server:

 >>> l=ldap.initialize('ldap://localhost:1234')
 >>> l.simple_bind_s('cn=root','blurb')
Traceback (most recent call last):
   File "<stdin>", line 1, in <module>
   File "/usr/lib/python2.6/site-packages/ldap/ldapobject.py", line 201, in 
simple_bind_s
     msgid = self.simple_bind(who,cred,serverctrls,clientctrls)
   File "/usr/lib/python2.6/site-packages/ldap/ldapobject.py", line 195, in 
simple_bind
     return 
self._ldap_call(self._l.simple_bind,who,cred,EncodeControlTuples(serverctrls),EncodeControlTuples(clientctrls))
   File "/usr/lib/python2.6/site-packages/ldap/ldapobject.py", line 96, in 
_ldap_call
     result = func(*args,**kwargs)
ldap.SERVER_DOWN: {'desc': "Can't contact LDAP server"}
 >>>

> Would shutting off slapd cause this error (I assume),

Yes. That's how ReconnectLDAPObject was tested.

> We are assessing our production environment.  For now we are staying with
> Python2.4.4, is python-ldap 2.3.1 stable with Python-2.4.4?

Provided python-ldap 2.3.1 was built from source it's stable. If you're 
using a binary package for which the package maintainer applied a patch set 
you have to ask the package maintainer.

Also note that stable means it has to be linked to stable OpenLDAP libs 
(mainly without bugs in libldap) which in turn has to be linked to stable 
versions of OpenSSL (not gnu-tls like in Debian), cyrus-sasl and Kerberos 
libs. Well, that's the caveat of "standing on the shoulders of giants".

>> Please also note that always unbind_s() should be called. 
> 
> I thought unbind and unbind_s called the same method internally.  Do I need
> to change my calls to unbind_s?  Is that for clarity or is there an
> implementation difference?

You have to grab the result() for unbind(). AFAIK unbind_s() should not 
block. So you should try using it.

Ciao, Michael.

RE: Leaving a connection open

[Ron T. <Ro...@US...>]

> From: Michael Ströder
> 
> Ron Teitelbaum wrote:
> > I have a few questions about leaving a bound connection open for sharing
> > (python 2.4.4, python-ldap 2.2.1 - openldap 2.3-2.3.30 on Ubuntu 7.04).
> >
> > I'm using Async messages is there any benefit to using
> ReconnectLdapObject?
> 
> No. If you're solely using the async methods you have to implement your
> own
> try-except block catching ldap.SERVER_DOWN and re-initiate whatever LDAP
> operation(s) seems appropriate in your application.

Ok I'll switch it back out.  Thanks.
> 
> Please elaborate on why you're using the async methods. There are only
> rare
> cases where this really makes sense (e.g. bulk data processing with
> ldap.async or resiter, high-performance proxying with many outstanding
> search requests). If you have a threaded application you might want to
> think
> about using several pooled connections.

I'm calling out from smalltalk to python and our vm is hung whenever we are
waiting on python.  The async methods were just what we needed to allow
processing.  We are handling a large number of connections and multiple
threads and we are doing some pretty intensive processing on the app so
having the vm die for a call out is not an option. 

> 
> > I noticed that the comments
> > http://vmspython.dyndns.org/pyhtmldoc/ldap.ldapobject.html said that the
> > class was intended for synchronous calls.
> 
> Yupp. How else should it catch the ldap.SERVER_DOWN exception and do the
> re-connect without the application noticing it?

Yeah, I'm starting to understand that.  I'm getting
can't-contact-ldap-server errors that I thought this would help with.  Note,
I believe this is different from the server down error you are mentioning.  

How can I create the server_down error for testing?  Would shutting off
slapd cause this error (I assume), or would that cause other problems in
python-ldap, is there an easier way?

> 
> > Is it ok to leave the connection open for long periods like a month?  Is
> it
> > realistic to believe that the connection would remain stable and be
> useable
> > for production if left open?
> 
> This also depends on your server's configuration. There are server
> configuration directives to shorten the life-time of LDAP connections. I'd
> recommend to always implement an appropriate re-connect functionality
> within
> your application.
> 
> > Is there a way to tell if the connection died so that I can reconnect a
> > shared connection if the connection dropped off?
> 
> I'd recommend to send the operation and re-connect and re-send the
> operation
> if needed. Testing the connecting with a LDAP request will also result in
> a
> ldap.SERVER_DOWN exception to be raised and it's an extra LDAP request
> sent
> => extra roundtrip time.
> 
> > I tried unbind and whoami_s but got a very nasty memory error after a
> > very long delay.
> 
> Note that this shouldn't happen in python-ldap 2.3.1+ built from source
> against OpenLDAP 2.3 libs straigt built with OpenSSL (not gnu-tls). But
> please report memory errors providing more details. We're tracking down
> some
> issues in recent CVS but not sure if you're hitting these bugs.

We are assessing our production environment.  For now we are staying with
Python2.4.4, is python-ldap 2.3.1 stable with Python-2.4.4?

> 
> Please also note that always unbind_s() should be called. 

I thought unbind and unbind_s called the same method internally.  Do I need
to change my calls to unbind_s?  Is that for clarity or is there an
implementation difference?

> The unbind call
> is
> synchronous by nature and closes the connection. Calling whoami_s() only
> make sense if the LDAP server supports this particular extended operation.
> Not many LDAP server do this though.

Thank you very much for your help,

Ron

Re: Leaving a connection open

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

Ron Teitelbaum wrote:
> I have a few questions about leaving a bound connection open for sharing
> (python 2.4.4, python-ldap 2.2.1 - openldap 2.3-2.3.30 on Ubuntu 7.04).
> 
> I'm using Async messages is there any benefit to using ReconnectLdapObject?

No. If you're solely using the async methods you have to implement your own
try-except block catching ldap.SERVER_DOWN and re-initiate whatever LDAP
operation(s) seems appropriate in your application.

Please elaborate on why you're using the async methods. There are only rare
cases where this really makes sense (e.g. bulk data processing with
ldap.async or resiter, high-performance proxying with many outstanding
search requests). If you have a threaded application you might want to think
about using several pooled connections.

> I noticed that the comments
> http://vmspython.dyndns.org/pyhtmldoc/ldap.ldapobject.html said that the
> class was intended for synchronous calls.

Yupp. How else should it catch the ldap.SERVER_DOWN exception and do the
re-connect without the application noticing it?

> Is it ok to leave the connection open for long periods like a month?  Is it
> realistic to believe that the connection would remain stable and be useable
> for production if left open?

This also depends on your server's configuration. There are server
configuration directives to shorten the life-time of LDAP connections. I'd
recommend to always implement an appropriate re-connect functionality within
your application.

> Is there a way to tell if the connection died so that I can reconnect a
> shared connection if the connection dropped off?

I'd recommend to send the operation and re-connect and re-send the operation
if needed. Testing the connecting with a LDAP request will also result in a
ldap.SERVER_DOWN exception to be raised and it's an extra LDAP request sent
=> extra roundtrip time.

> I tried unbind and whoami_s but got a very nasty memory error after a
> very long delay.

Note that this shouldn't happen in python-ldap 2.3.1+ built from source
against OpenLDAP 2.3 libs straigt built with OpenSSL (not gnu-tls). But
please report memory errors providing more details. We're tracking down some
issues in recent CVS but not sure if you're hitting these bugs.

Please also note that always unbind_s() should be called. The unbind call is
synchronous by nature and closes the connection. Calling whoami_s() only
make sense if the LDAP server supports this particular extended operation.
Not many LDAP server do this though.

Ciao, Michael.

Leaving a connection open

[Ron T. <Ro...@US...>]

Hi,

I have a few questions about leaving a bound connection open for sharing
(python 2.4.4, python-ldap 2.2.1 - openldap 2.3-2.3.30 on Ubuntu 7.04).

I'm using Async messages is there any benefit to using ReconnectLdapObject?
I noticed that the comments
http://vmspython.dyndns.org/pyhtmldoc/ldap.ldapobject.html said that the
class was intended for synchronous calls.

Is it ok to leave the connection open for long periods like a month?  Is it
realistic to believe that the connection would remain stable and be useable
for production if left open?

Is there a way to tell if the connection died so that I can reconnect a
shared connection if the connection dropped off?  I tried unbind and
whoami_s but got a very nasty memory error after a very long delay.

Thanks for your help!
Ron Teitelbaum

Re: cvs link

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

HI!

please send messages like this to the mailing list 
pyt...@li... (Cc:-ed) so others can answer and 
learn as well. Thanks.

meldra wrote:
> 
> I've been trying the past few days to easy_install
> python-ldap, but found out a few minutes ago that the CVS
> link that pypi gets from the web page is incorrect. error:
> Download error for
> http://cvs.sourceforge.net/cvstarballs/python-ldap-cvsroot.tar.gz:
> (113, 'No route to host')

Frankly I don't know anything about easy_install.

> Is there any way you can fix this?
> Here is the information I was given on the sourceforge forums:
> Posted 16 hours ago by silverfang
> Thats the old way with the cvs, svn browse.
> Try projectname.cvs.sourceforge.net/projectname/ 

Yes, it's an old URL. But where exactly does it come from? The only pypi 
entry for python-ldap I know of is

http://pypi.python.org/pypi/python-ldap/

And this is the one I'm still maintaining. I might have missed something though.

Ciao, Michael.

[ 1926507 ] Calling get_option(ldap.OPT_DIAGNOSTIC_MESSAGE) seg faults

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

HI!

Anyone out there with C programming skills willing to look
into issue tracker item #1926507 ?

http://sourceforge.net/tracker/index.php?func=detail&aid=1926507&group_id=2072&atid=102072

Seems to be a long-lasting bug....

Ciao, Michael.

Re: any luck with downloaded virtual machines running preconfigured ldap server

[Noah G. <noa...@gm...>]

On Mar 26, 2008, at 12:49 PM, Michael Ströder wrote:

> Noah Gift wrote:
>> I was wondering if anyone had a pointer to a virtual machine they   
>> could recommend that I could download and test some python-ldap code.
>
> How about searching for an openSUSE 10.3 VM and, if python-ldap is  
> not already installed, just invoke "yast -i python-ldap" as root on  
> the command-line.

another good idea...thanks!  I have been a bit spoiled with the super  
tiny rpath zenoss virtual machines.  Getting one of those for a test  
ldap environment would be nice!
>
>
> Ciao, Michael.

Noah Gift / http://noahgift.com

Re: any luck with downloaded virtual machines running preconfigured ldap server

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

Noah Gift wrote:
> I was wondering if anyone had a pointer to a virtual machine they  
> could recommend that I could download and test some python-ldap code.

How about searching for an openSUSE 10.3 VM and, if python-ldap is not 
already installed, just invoke "yast -i python-ldap" as root on the 
command-line.

Ciao, Michael.

Re: ANN: python-ldap-2.3.2

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

Torsten Kurbad wrote:
> But I ran into a problem while trying to build on my x86_64 Linux box:
> 
> Modules/constants.c: In function 'LDAPinit_constants':
> Modules/constants.c:152: error: 'LDAP_OPT_DIAGNOSTIC_MESSAGE'

Sorry for that. This constant is available since OpenLDAP 2.4.x. Thanks for
reporting it so quickly.

ldap.h of OpenLDAP 2.4:

#define LDAP_OPT_DIAGNOSTIC_MESSAGE             0x0032
#define LDAP_OPT_ERROR_STRING                   LDAP_OPT_DIAGNOSTIC_MESSAGE

Renaming was probably done to reflect a name change in the revised LDAPv3 RFCs.

I'll release 2.3.3 tested with OpenLDAP 2.3.x libs.

Ciao, Michael.

any luck with downloaded virtual machines running preconfigured ldap server

[Noah G. <noa...@gm...>]

I was wondering if anyone had a pointer to a virtual machine they  
could recommend that I could download and test some python-ldap code.   
Additionally, it would be nice if I could find something that could  
pre-populate LDAP with test records, although, I suppose that is being  
too lazy even for me :)

Noah Gift

Re: CLOSE_WAIT sessions

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

Ron,

Ron Teitelbaum wrote:
> Yes python-ldap.  I'm using a smalltalk -> python-ldap 2.2.1 -> openLDAP
> 2.3-2.3.30 on Ubuntu 7.04 (GNU/Linux 2.6.20-16-generic)

There has been important fixes for Python 2.5 and also ReconnectLDAPObject 
in 2.3.0. So I'd recommend to build python-ldap 2.3.2 (released today).

>>> I'm doing a bind->call->unbind on every
>>> call.
>> Is that really necessary?
> 
> When I started writing this code I assumed that I needed some sort of
> connection pooling.  When bind->call->unbind turned out to be very fast I
> figured the pool was a premature optimization.  Maybe I should have stuck
> with my gut feeling.

A connection pool and making a new connection all the time are very extreme 
variants. I don't know your application's needs though.

>>>  I am also using the ReconnectLdapObject to try to help with "can not
>>> connect" problems,
>> Well, using ReconnectLdapObject and doing bind-search-unbind all the time
>> is
>> somewhat contradictory since ReconnectLdapObject is for keeping long-
>> lasting
>> connections alive. But this should not be the problem.
> 
> That's interesting.  I thought ReconnectLdapObject's primary purpose was to
> help with can-not-connect issues.

Yes, but mainly for long-lasting connections.

>  Very often we get can-not-connect errors.
> Sometimes we get them even when things worked.  We wrote some handlers to
> retry and to ignore errors associated with duplicate processing.  Any idea
> why we would be getting can-not-connect errors?  (we get them sporadically
> with bind, write, search ...) 

You mean ldap.SERVER_DOWN exceptions? Yes, you could ReconnectLdapObject to 
make things a litte easier within your application. If you're solely using 
the synchronous methods you don't have to catch the exceptions yourself. But 
if you experience this to happen very often you should try to solve the 
problem causing this.

>>> The server died the first time we tried to put a significant load on it.
>> What server (vendor and version) is this? Which version of python-ldap and
>> which version OpenLDAP libs are used?
> 
> python-ldap 2.2.1 -> openLDAP 2.3-2.3.30 on Ubuntu 7.04 (GNU/Linux
> 2.6.20-16-generic)
> 
> The older releases above are to stay inline with the Debian release.

I see several problems with Debian packages:

1. Some Debian packages of python-ldap were heavily patched to work with 
ancient OpenLDAP 2.1 libs. I refuse to give support for those. Don't know 
about the particular version you're using though.

2. OpenLDAP debian packages are linked against gnu-tls which causes all 
sorts of problems when LDAP over SSL (LDAPS) or StartTLS ext.op. is used. 
This could lead to ldap.SERVER_DOWN to be raised if anything goes wrong at 
SSL/TLS level

Ciao, Michael.

Re: ANN: python-ldap-2.3.2

[Torsten K. <pyt...@tk...>]

Hi Michael,

> Released 2.3.2 2008-03-26

neat! :o)

But I ran into a problem while trying to build on my x86_64 Linux box:

Modules/constants.c: In function 'LDAPinit_constants':
Modules/constants.c:152: error: 'LDAP_OPT_DIAGNOSTIC_MESSAGE'
undeclared (first use in this function) Modules/constants.c:152: error:
(Each undeclared identifier is reported only once
Modules/constants.c:152: error: for each function it appears in.)

OpenLDAP version is 2.3.41, gcc 4.2.3, glibc 2.7.

Any clues?

Regards,
Torsten
-- 
Weekend, where are you?

CLOSE_WAIT sessions (was: Too many established connections)

[Ron T. <Ro...@US...>]

Hi Michael,

> -----Original Message-----
> From: Michael Ströder 
> 
> Ron Teitelbaum wrote:
> >
> > I'm running into a problem with python open ldap connections.
>                                    ^^^^^^^^^^^^^^^^
> Do you mean python-ldap connections or connections to an OpenLDAP server
> from Python?

Yes python-ldap.  I'm using a smalltalk -> python-ldap 2.2.1 -> openLDAP
2.3-2.3.30 on Ubuntu 7.04 (GNU/Linux 2.6.20-16-generic)

> 
> Can you check in the server's log whether unbind is processed?

I went through and found that there was some exception handling in my code
that caused the unbind to be skipped.  I fixed that and things are
significantly better now.  Thank you!

I am still having a problem but it looks like we had ldap hang up.  There
were some connections with CLOSE_WAIT that caused everything to get hung up.
It looked like we were not able to bind after that.  Have you seen that
problem before?  I rebooted the system and have not seen the error again, so
things are currently stable, we are going to try a load test in about an
hour or so.

> 
> > I'm doing a bind->call->unbind on every
> > call.
> 
> Is that really necessary?

When I started writing this code I assumed that I needed some sort of
connection pooling.  When bind->call->unbind turned out to be very fast I
figured the pool was a premature optimization.  Maybe I should have stuck
with my gut feeling.

> 
> >  I am also using the ReconnectLdapObject to try to help with "can not
> > connect" problems,
> 
> Well, using ReconnectLdapObject and doing bind-search-unbind all the time
> is
> somewhat contradictory since ReconnectLdapObject is for keeping long-
> lasting
> connections alive. But this should not be the problem.

That's interesting.  I thought ReconnectLdapObject's primary purpose was to
help with can-not-connect issues.  Very often we get can-not-connect errors.
Sometimes we get them even when things worked.  We wrote some handlers to
retry and to ignore errors associated with duplicate processing.  Any idea
why we would be getting can-not-connect errors?  (we get them sporadically
with bind, write, search ...) 

> 
> > although I still get a significant number of can not
> > connect problems that I handle with a retry.
> 
> Any network problems in between?

No for right now we are running OpenLdap and Python-ldap and Smalltalk all
on the same box.
 
> 
> > The server died the first time we tried to put a significant load on it.
> 
> What server (vendor and version) is this? Which version of python-ldap and
> which version OpenLDAP libs are used?

python-ldap 2.2.1 -> openLDAP 2.3-2.3.30 on Ubuntu 7.04 (GNU/Linux
2.6.20-16-generic)

The older releases above are to stay inline with the Debian release.  Also
we are currently locked into python 2.4.4.  Upgrading python is not
currently an option for this system.

> 
> Ciao, Michael.

Thank you very much for your help!

Ron Teitelbaum

ANN: python-ldap-2.3.2

[Michael S. <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.3.2 2008-03-26

Changes since 2.3.1:

Lib/
* ldap.dn.escape_dn_chars() now really adheres to
   RFC 4514 section 2.4 by escaping null characters and a
   space occurring at the beginning of the string
* New method ldap.cidict.cidict.__contains__()
* ldap.dn.explode_dn() and ldap.dn.explode_rdn()
   have a new optional key-word argument flags which is
   passed to ldap.dn.str2dn().

Modules/
* Removed unused OPT_PRIVATE_EXTENSION_BASE from constants.c

Doc/
* Various additions, updates, polishing (thanks to James).

Re: Too many established connections

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

Ron Teitelbaum wrote:
> 
> I'm running into a problem with python open ldap connections. 
                                   ^^^^^^^^^^^^^^^^
Do you mean python-ldap connections or connections to an OpenLDAP server 
from Python?

> It appears that they are not closing properly.

Can you check in the server's log whether unbind is processed?

> I'm doing a bind->call->unbind on every
> call.

Is that really necessary?

>  I am also using the ReconnectLdapObject to try to help with "can not
> connect" problems,

Well, using ReconnectLdapObject and doing bind-search-unbind all the time is 
somewhat contradictory since ReconnectLdapObject is for keeping long-lasting 
connections alive. But this should not be the problem.

> although I still get a significant number of can not
> connect problems that I handle with a retry.

Any network problems in between?

> The server died the first time we tried to put a significant load on it.

What server (vendor and version) is this? Which version of python-ldap and 
which version OpenLDAP libs are used?

Ciao, Michael.

Too many established connections

[Ron T. <Ro...@US...>]

Hello,

I'm running into a problem with python open ldap connections.  It appears
that they are not closing properly.  I'm doing a bind->call->unbind on every
call.  I am also using the ReconnectLdapObject to try to help with "can not
connect" problems, although I still get a significant number of can not
connect problems that I handle with a retry.

The server died the first time we tried to put a significant load on it.

Does anyone have suggestions for fixing this problem or figuring out what is
leaving connections open?

Thanks,

Ron Teitelbaum

Re: Removing person names in python-ldap's source files

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

David Leonard wrote:
> Michael Ströder wrote:
>>
>> inspired by a presentation the Subversion guys gave (as Google tech 
>> talk) I'd like to remove all person names from the source code files. 
>> Instead authors/contributors are all listed in README.
>>
>> I already removed *my* name from all the python modules it appeared 
>> in. Now I'd like to ask for the permission, especially by David, to 
>> remove all other person names from the files Modules/*.
> 
> Is the tech talk presentation online?

"How Open Source Projects Survive Poisonous People (And You Can Too)"

http://video.google.nl/videoplay?docid=-4216011961522818645

Fortunately we didn't have this kind of problems in the past. But I wanted 
to avoid discussions about when a personal name on source or documentation 
is mentioned.

> It sounds like a good idea; please 
> move my name out of source files.: you have my permission.

Ok, done. Also in Doc/.

> The commit 
> info is probably going to be sufficient :)

Yes. And the contributors are and will be listed in README.

Ciao, Michael.