Alan DeKok wrote:
On Oct 16, 2017, at 11:21 AM, Doug Wussler <doug.wussler@fsu.edu> wrote:
The motivation for looking into this is that I have occasions where freeradius reports “Could not start TLS: Can't contact LDAP server” which seems to only occur when a new thread fires up and tries to start TLS to the LDAP server.
Because the OpenLDAP API is crappy. There's no explicit "initialize" routine, so the OpenLDAP code has to guess, and can get it wrong.
What do you mean by "initialize" and "has to guess"? Disclaimer: I did not look at FreeRADIUS code. No news that OpenLDAP API (with its roots in RFC 1823) has real deficiencies. Everybody involved agrees on that. But most issues developers experience are caused by the lazy connect in libldap: ldap_initialize() and friends do *not* to the LDAP server. You have send the first LDAP operation to really connect and handle connection errors *after* that. In multi-threaded software with a persistent connection (pool) I usually use a lock to ensure that ldap_initialize() and bind (simple or SASL) were successfully done before the connection can be used by another thread. That's also the reason why I usually avoid a code path with anon-search-without-bind because I want to provoke a connect error with an explicit bind right from the beginning. This also might get tricky when the OpenLDAP server drops idle connections or was simply restarted and your multi-threaded LDAP client has to re-connect. Ciao, Michael.