limiting fail timeout for an LDAP module

Zenon Mousmoulas zmousm at
Mon Feb 6 08:10:00 CET 2017

On 2017-02-03 19:38, Alan DeKok wrote:
> On Feb 3, 2017, at 12:21 PM, Zenon Mousmoulas <zmousm at> 
> wrote:
>> I am working with a peculiar LDAP backend which, from time to time, 
>> will take upwards of 10 seconds to respond to a search request. I know 
>> that is what needs fixing, but let's say I have to live with it for 
>> now. There is a second LDAP backend which I can use a backup when the 
>> first one goes nuts. So I'm thinking let's setup two LDAP module 
>> instances and use them in a redundant group.
>   That will help a bit, but not a lot.  The server doesn't track
> status across multiple modules.  So each time a request is passed
> through a "redundant" group, it will try all modules in order.

I expected that; and even if it were possible for the particular LDAP 
module to fail persistently, I'm not sure how that could be detected in 
this case (no on/off connection or bind issues).

>> I am wondering if this is as good as it gets or if there are other 
>> things to tweak or to try, to get a shorter timeout in this particular 
>> case, perhaps avoiding the side effect of start=0 documented therein 
>> (Set to 0 to allow the server to start without the directory being 
>> available).
>   That's probably as good as it gets for now.  We're looking at ways
> to fix this in v4, where architectural updates make this kind of
> tracking easier to do.

Thanks, good to know.

>   Another alternative is to set up a local LDAP replica of the "bad"
> database.  Since no one else uses it, it should be highly available.

It is actually sort of like that: the second LDAP backend reflects the 
contents of the first database, minus the password attributes however, 
so it is not an exact replica; this explains why I'd be tempted to try 
the first backend even in this case.

>   But the short answer is that if FreeRADIUS needs a back-end
> database.. .make sure that the database is available.  If the database
> goes down, no amount of poking FreeRADIUS will make the database work.

Understood, thanks.


More information about the Freeradius-Users mailing list