Re: Failover for ldapdb doesn't work when packets are dropped by iptables

--On 15. Mai 2017 um 08:38:09 -0500 Dan White <[email protected]> wrote:

> On 05/15/17 14:30 +0200, Sebastian Hagedorn wrote:
>> we're trying to move from auxprop sasldb to ldapdb. Everything is
>> working fine with both cyrus-imapd and sendmail. Even failover seems
>> to be working (with multiple entries for ldapdb_uri), but only if the
>> client gets a reject of some sort. Initially I tried to simulate the
>> failure of the primary LDAP server with an iptables rule that dropped
>> the packets. That led to a 30 second timeout and no failover taking
>> place:
>>
>> ~> AUTH DIGEST-MD5
>> <~  334 xxx
>> ~> xxx
>> <~* Timeout (30 secs) waiting for server response
>> *** No authentication type succeeded
>>
>> Only when I changed the DROP to a REJECT in the iptables rule did the
>> failover work as expected. I realize that a server that's down usually
>> behaves like a REJECT rule, but I still would think that there should
>> be a configurable timeout after which a failover takes place in the
>> DROP scenario as well. In my 15+ years as a sysadmin there have been
>> several occasions where servers were nominally running but didn't
>> reply anymore, which would be just like that scenario.
>
> You can limit the network timeout functionality of the ldapdb plugin using
> the ldapdb_rc sasl option:
>
> http://www.sendmail.org/~ca/email/cyrus2/options.html
>
> See ldap.conf(5) and it's TIMEOUT/TIMELIMIT options.

Thanks, but that doesn't seem to work either. I added the following line to 
Sendmail.conf:

ldapdb_rc: /etc/sasl2/ldap.rc

$ cat /etc/sasl2/ldap.rc
TIMEOUT 2
TIMELIMIT 2
NETWORK_TIMEOUT 2

I restarted sendmail, but I still get the 30 second timeout.
-- 
    .:.Sebastian Hagedorn - Weyertal 121 (Gebäude 133), Zimmer 2.02.:.
                 .:.Regionales Rechenzentrum (RRZK).:.
   .:.Universität zu Köln / Cologne University - ✆ +49-221-470-89578.:.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0

iEYEARECAAYFAlkZvxYACgkQGXsGmU0QW0WrGQCdEyXiQK0wJJ4pcIxb14j96F4D
SKoAn3Y1e8pPfS/BFm8JLps9a7ea8mdD
=7ZNL
-----END PGP SIGNATURE-----