On Thu, Jan 21, 2021 at 09:58:30AM +0100, Ganael Laplanche wrote:
> On Wednesday, January 20, 2021 6:23:22 PM CET Curtis Maurand wrote:
> 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 :)
Postfix already rebuilds LDAP connections on error and retries the
search:
rc = search_st(dict_ldap->ld, vstring_str(base), dict_ldap->scope,
vstring_str(query), dict_ldap->result_attributes->argv,
dict_ldap->timeout, &res);
if (rc == LDAP_SERVER_DOWN) {
if (msg_verbose)
msg_info("%s: Lost connection for LDAP source %s, reopening",
myname, dict_ldap->parser->name);
dict_ldap_unbind(dict_ldap->ld);
dict_ldap->ld = DICT_LDAP_CONN(dict_ldap)->conn_ld = 0;
dict_ldap_connect(dict_ldap);
/*
* if dict_ldap_connect() set dict_ldap->dict.error, abort.
*/
if (dict_ldap->dict.error)
return (0);
rc = search_st(dict_ldap->ld, vstring_str(base), dict_ldap->scope,
vstring_str(query), dict_ldap->result_attributes->argv,
dict_ldap->timeout, &res);
}
If there's more than one LDAP server, and the one being used crashes,
the new connection will use a different server.
> 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 :)
Postfix already (as a matter of best-practice) supports proxymap(8)
between the smtpd(8), cleanup(8), ... and the LDAP server, just specify
the table as "proxy:ldap:..." instead of "ldap:..."
> 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!
A hash map after LDAP sounds reasonable, as a means to limit the amount
of lost email (1 hour of new user accounts) should LDAP start lying by
reporting "not found" for accounts that should exist. For the real
LDAP use "proxy:" and configure multiple servers.
--
Viktor.
