On 15.02.2016 17:26, Wietse Venema wrote:
> Lutz J?nicke:
>> Hi!
>>
>> We have just been experiencing a power outage in the result of which our
>> mail server with postfix did come back up fine but our LDAP server did
>> not come back up. As a result emails to valid users (administrated via
>> LDAP) was rejected with a permanent "User unknown" error.
> If the LDAP server came back from power failure in a broken state,
> then it is very well possible that it returns "not found" replies.
> Are you sure that LDAP lookups were timing out?
Yes. The LDAP server is running in a virtual machine the host of which
did not come back up so it definitely was down.
> For non-system user lookups, the Postfix LDAP client should distinguish
> between "server down" and "not found". It is a very basic check that
> must have been present from 1999 when the first Postfix LDAP client
> was implemented
>
> For system user lookups Postfix depends on getpwnam_r() which
> promises to return an error status instead of "not found". Again,
> it's a basic check that has been in place for a very long time.
>
> But the basic check after getpwnam_r() works only if everything
> else in the chain returns an error status instead of "not found".
> That may include nsswitch.conf, pam_ldap, pam_sss, sssd, sssd.conf,
> and so on. It is very easy for something to lose the distinction
> between "error status" and "not found".
>
> For example, with the default nsswitch.conf action of "unavail=continue",
> the library will continue with the next source, instead of reporting
> the error condition immediately. There may be similar fesatures with sssd.
It seems that nsswitch.conf may be the reason for the effect. It indeed
reads
passwd: compat ldap
group: ...
and therefore should with "unavail=continue" would lead to failure as
experienced.
As all other lookups are implemented directly in postfix via ldap: maps.
If I understand nsswitch.conf correctly, unavail=return would not make a
difference here. We rather would have to modify local_recipient_maps to
start with an LDAP lookup to fail "safe" if LDAP is not available, don't we?
Best regards,
Lutz
