Failed oracle db connection kills the freeradius service

[Nathan Ward]

> On 9/07/2019, at 11:08 PM, R3DNano <r3dnano at 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