[python-ldap] Strange network problems?
aigars.grins at sentor.se
Wed Sep 20 04:11:40 EDT 2017
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  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?
> 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
During burst activity it's good in general to have readily available
connections and to be able to process data in paralell.
More information about the python-ldap