On Feb 3, 2017, at 12:21 PM, Zenon Mousmoulas <zmousm@noc.grnet.gr> 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 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. 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. 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. Alan DeKok.