[python-ldap] Strange network problems?

[Aigars Grins]

Hi!

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.

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>

> Which version of python-ldap is this?

It's version 2.4.39.

> When opening new connections via libldap a module-wide lock is used in 
> module-wide ldap to serialize the calls to libldap's function 
> ldap_initialize() but which only initializes the struct in libldap. Or 
> course this affects reconnecting in ReconnectLDAPObject. So if your LDAP 
> server is restarted reconnecting hits the module-wide locking and 
> reconnecting a connection pool will be serialized.
> 
> If you set ldap._trace_level = 3 then you should see whether global or 
> connection-specific lock is used.

Interesting. I'll set up some kind of logging for this, but since I only 
see this behaviour in PROD and not in DEV, it will take me some time to 
get results back.

> 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.

--
Aigars Grins