On 9/07/2019, at 11:08 PM, R3DNano <r3dnano@gmail.com> wrote:
Hi, Alan and everyone on the m.l. I really appreciate this reply and after some time, I still can't figure out how to work around this issue.
While, I of course won't/can't blame it on freeradius, I'd like to ask if any of you guys deal in any way with sql server failures in any way, of course, externally.
Maybe there's some kind of script/solution to automagically detect the sql server failure and modify the server logic on the go?
I really can't think of a way and perhaps what I'm asking is impossible. Just wanting to check up with you guys before completely discarding the option.
It’s a very odd use case. FreeRADIUS operates like it does (i.e. no reply if the DB is unreachable/times out/something) so that the clients can choose a different (functioning) RADIUS server. This is why clients have the option to configure multiple RADIUS servers. This is of course what you want to happen almost all of the time - if the authentication database is down, try authentication elsewhere. If a RADIUS client gets an auth reject it won’t try and authenticate elsewhere, it’ll reject - that’s not what you want in case of a database failure. Perhaps you can do some sort of RADIUS auth proxy back on itself, and set it to reject after a proxy timeout. There was a flag to do this, but of course it isn’t a very good idea, and it’s not there anymore. Perhaps you can catch the module failure and make it a reject: https://freeradius.org/radiusd/man/unlang.html#lbAK <https://freeradius.org/radiusd/man/unlang.html#lbAK> I’m not sure if you get a fail when your sql DB is down though - it’s never something I’ve cared to investigate, if my DB server is down I expect to not reply. There’s some thoughts here about how you might achieve it - but of course, this smells like a bad solution design, and I urge you to reconsider it rather than making FreeRADIUS implement a poor design. -- Nathan Ward