Some of my auth sources are oracle databases via linux odbc. At some point, those databases might become unreachable for some external reason, freeradius then enters and stays in a failed state, trying to stablish the connection. Is there a way to just reject the authentication if the source is unavailable and prevent the server failure? Is this working as intended?
On Apr 4, 2019, at 3:50 PM, R3DNano <r3dnano@gmail.com> wrote:
Some of my auth sources are oracle databases via linux odbc. At some point, those databases might become unreachable for some external reason, freeradius then enters and stays in a failed state, trying to stablish the connection.
That's the way the server is supposed to work.
Is there a way to just reject the authentication if the source is unavailable and prevent the server failure? Is this working as intended?
If you don't want the server to use a module, then you can remove that module from the server configuration. If you want the server to use a module, then you should ensure that the module works. And for SQL, ensure that the SQL database stays up. It doesn't make any sense to configure FreeRADIUS to use SQL, and then leave SQL down for days. Alan DeKok.
Thanks for your reply, Alan. Downtime could happen sometimes and I understand I can just comment out a module when the SQL server goes down, but sometimes it could be out of our control, a database can fail for hours and I thought there might be a way freeradius can just "deal" with failed mysql connections by rejecting if the source is unavailable.... I don't mean that freeradius "should" deal with it, by any means, just to have the option of rejecting if the auth source is unreachable. Does this mean the same behavior can be expected if I'm authenticating against LDAP and the LDAP server goes temporarily down? Thanks again On Thu, Apr 4, 2019 at 9:55 PM Alan DeKok <aland@deployingradius.com> wrote:
On Apr 4, 2019, at 3:50 PM, R3DNano <r3dnano@gmail.com> wrote:
Some of my auth sources are oracle databases via linux odbc. At some point, those databases might become unreachable for some external reason, freeradius then enters and stays in a failed state, trying to stablish the connection.
That's the way the server is supposed to work.
Is there a way to just reject the authentication if the source is unavailable and prevent the server failure? Is this working as intended?
If you don't want the server to use a module, then you can remove that module from the server configuration.
If you want the server to use a module, then you should ensure that the module works. And for SQL, ensure that the SQL database stays up.
It doesn't make any sense to configure FreeRADIUS to use SQL, and then leave SQL down for days.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Apr 4, 2019, at 4:01 PM, R3DNano <r3dnano@gmail.com> wrote:
Downtime could happen sometimes and I understand I can just comment out a module when the SQL server goes down, but sometimes it could be out of our control, a database can fail for hours
Then it isn't a database you need, is it?
and I thought there might be a way freeradius can just "deal" with failed mysql connections by rejecting if the source is unavailable.... I don't mean that freeradius "should" deal with it, by any means, just to have the option of rejecting if the auth source is unreachable.
The issue is how does FreeRADIUS know that the database is down *permanently*? i.e. any failure lasting more than a second or two is permanent. FreeRADIUS retries connections because you told it to use the DB, and it's really important that it uses the DB. FreeRADIUS doesn't just give up for *hours* if the database is down. Look, what you want isn't trivial. *You* may know what you want FreeRADIUS to do. But FreeRADIUS can't read your mind. It has to implement decisions, in C, using only information it knows. That means it's not trivial.
Does this mean the same behavior can be expected if I'm authenticating against LDAP and the LDAP server goes temporarily down?
Yes. Both LDAP and SQL have "pool" configurations. So they both operate largely the same way. Don't take your databases down. And if you do take them down, expect FreeRADIUS to fail, too. Alan DeKok.
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. Cheers! On Thu, Apr 4, 2019 at 10:17 PM Alan DeKok <aland@deployingradius.com> wrote:
On Apr 4, 2019, at 4:01 PM, R3DNano <r3dnano@gmail.com> wrote:
Downtime could happen sometimes and I understand I can just comment out a module when the SQL server goes down, but sometimes it could be out of our control, a database can fail for hours
Then it isn't a database you need, is it?
and I thought there might be a way freeradius can just "deal" with failed mysql connections by rejecting if the source is unavailable.... I don't mean that freeradius "should" deal with it, by any means, just to have the option of rejecting if the auth source is unreachable.
The issue is how does FreeRADIUS know that the database is down *permanently*? i.e. any failure lasting more than a second or two is permanent.
FreeRADIUS retries connections because you told it to use the DB, and it's really important that it uses the DB. FreeRADIUS doesn't just give up for *hours* if the database is down.
Look, what you want isn't trivial. *You* may know what you want FreeRADIUS to do. But FreeRADIUS can't read your mind. It has to implement decisions, in C, using only information it knows. That means it's not trivial.
Does this mean the same behavior can be expected if I'm authenticating against LDAP and the LDAP server goes temporarily down?
Yes. Both LDAP and SQL have "pool" configurations. So they both operate largely the same way.
Don't take your databases down. And if you do take them down, expect FreeRADIUS to fail, too.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Jul 9, 2019, at 1:08 PM, R3DNano <r3dnano@gmail.com> wrote:
I really appreciate this reply and after some time, I still can't figure out how to work around this issue.
Keep the database up. There's just no reason to take a critical DB down for hours.
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.
We bring the DB back up.
Maybe there's some kind of script/solution to automagically detect the sql server failure and modify the server logic on the go?
No. We bring the DB back up.
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.
If the DB is not local to the RADIUS server, then create a local slave. And make sure that the slave stays up. Alan DeKok.
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
participants (3)
-
Alan DeKok -
Nathan Ward -
R3DNano