[python-ldap] Strange network problems?

Michael Ströder michael at stroeder.com
Wed Sep 20 04:49:25 EDT 2017


Aigars Grins wrote:
> On 2017-09-18 18:35, Michael Ströder wrote:
>> libldap on Debian is linked against GnuTLS. Maybe there's an issue
>> with that? Sure there's enough entropy? Does GnuTLS do OCSP queries,
>> CRL lookups or similar under the hood?
>
> I really don't know. The connection string does start with "ldaps://"
> so I guess some TLS-functionality is used at least. I don't see any
> special settings in e.g. /etc/ldap/ldap.conf, so I guess that the
> "default behaviour" is used. Whatever that is.

The problem is that this default behaviour has nothing to do with 
configuration of python-ldap or libldap.

You could try to find out by observing the network traffic, DNS queries etc.

> With regards to "errors in the randomness device", the internet tells
> me that some other projects [1] switched over to bind against
> OpenSSL instead. Would it be possible to do that for python-ldap as
> well? Some kind of compiler flag I could set?
>
> [1] <https://bugs.launchpad.net/ubuntu/+source/nzbget/+bug/1427486>

The Debian developers, with their infinite wisdom and anti-OpenSSL 
licensing paranoia, decided to link libldap against GnuTLS. This causes 
nothing than grief but they are pretty much ignorant to change that.

If you want to change that you have to compile the whole stack [1] 
yourself and take care of not mixing dynamic linking with OS-installed 
libldap:

[1] https://www.python-ldap.org/doc/html/installing.html#prerequisites

Maybe you could try to build a statically linked python-ldap with all 
the issues with that solution (updates etc.).

>> BTW: Do you really need a connection pool for parallel long-running
>> LDAP queries?
>
> During burst activity it's good in general to have readily available
> connections and to be able to process data in paralell.

If the burst queries are (partially) the same it might be better to have 
a single LDAP connection and a cache with short TTL. Hard to tell 
without knowing the details though.

Ciao, Michael.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3829 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.python.org/pipermail/python-ldap/attachments/20170920/8d0fb4aa/attachment.bin>


More information about the python-ldap mailing list