On Wednesday, January 20, 2021 6:23:22 PM CET Curtis Maurand wrote: Hello,
Natan> Or use two ldap - master- slave and use haproxy like Natan> [...] Natan> tcp-check send-binary 04008000 # name, simple authentication Natan> tcp-check expect binary 0a0100 # bind response + result code: success Natan> tcp-check send-binary 30050201034200 # unbind request Interesting, thanks. Making LDAP not failing is one way of handling the problem, right :) Jaroslaw> Searching the web for "LDAP proxy", this is one of the first results Jaroslaw> I found: Jaroslaw> https://ldaptor.readthedocs.io/en/latest/cookbook/ldap-proxy.html . Jaroslaw> It's a Python library for LDAP, and this documentation presents some Jaroslaw> example code for creating LDAP proxies using this library. I didn't know Ldaptor, thanks for the link. That would be quite easy to develop indeed. Curtis> A thought would be to have a separate process that checks for ldap Curtis> availability. if not, issue a postconf command to change the setting Curtis> on the fly. when the ldap server comes back, issue a new postconf Curtis> command to reverse the process to go back to the ldap server. Yes, I understand the watchdog idea :) Wietse> Instead, query the hash map BEFORE ldap, and dump ldap periodically Wietse> (hourly?) to hash. 'New' users will still be found most of the time. Wietse> Just do it carefully. Hmmmm... If we put the dump before, we will loose our 7-days window to react. What could be done maybe is have 2 hash maps and not use LDAP at all : 1 file generated every hour and our 7-days old dump as a second choice. But this is not perfect neither as we will have a 1-hour lag regarding new info coming from LDAP. Well, I don't know what solution will finally be chosen but all that gives us plenty to think about. Thanks to you all! Best regards, -- Ganael Laplanche <ganael.laplan...@centralesupelec.fr> Unix Systems Engineer @CentraleSupelec Rennes
