On 2017-02-03 19:38, Alan DeKok wrote:
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 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. Z.