problem with using rlm_sql for accounting only
Hi all- I've recently deployed freeradius at my employer to replace our old radius server which lacked native LDAP support which we've moved to for authentication and authorization. Thanks for a great application. I have one problem: I've configured freeradius to send accounting data to an SQL database for ease of reporting. It works fine, with one exception, which after extensive googling I don't find anyone else complaining about. If the SQL server is inaccessible (i.e. down, or locked), freeradius rejects all radius requests. In my case, since the SQL database is being used only for accounting, this is not desired behavior. I can see how it may have been to the designer given that rlm_sql can be used for auth. So my question is that: is that behavior by design, or is it due to some misconfiguration on my part? I figured I'd start with a simple question before I post configs/logging output. Thanks John
John Donagher wrote:
If the SQL server is inaccessible (i.e. down, or locked), freeradius rejects all radius requests. In my case, since the SQL database is being used only for accounting, this is not desired behavior.
The link below explains how to control the flow of modules in FreeRADIUS. http://www.freeradius.org/radiusd/doc/configurable_failover There is an example which looks like what you want to do for accounting. -- Nicolas Baradakis
On Tue, 2005-08-09 at 00:01 +0200, Nicolas Baradakis wrote:
John Donagher wrote:
If the SQL server is inaccessible (i.e. down, or locked), freeradius rejects all radius requests. In my case, since the SQL database is being used only for accounting, this is not desired behavior.
The link below explains how to control the flow of modules in FreeRADIUS. http://www.freeradius.org/radiusd/doc/configurable_failover
There is an example which looks like what you want to do for accounting.
Thanks, that was exactly what I was looking for! John
John Donagher <john@webmeta.com> wrote:
If the SQL server is inaccessible (i.e. down, or locked), freeradius rejects all radius requests. In my case, since the SQL database is being used only for accounting, this is not desired behavior.
See the log messages. What's probably happening is that all of the threads are blocked, waiting for SQl to respond. Therefore, there are no threads ready to service authentication requests, and they get discarded. The solution is to fix the SQL server so it doesn't go down. If it's a critical part of your infrastructure, I'm a little unsure as to why it would go down, or lock FreeRADIUS out for many seconds at a time. Alan DeKok.
On Mon, 2005-08-08 at 18:09 -0400, Alan DeKok wrote:
John Donagher <john@webmeta.com> wrote:
If the SQL server is inaccessible (i.e. down, or locked), freeradius rejects all radius requests. In my case, since the SQL database is being used only for accounting, this is not desired behavior.
See the log messages.
What's probably happening is that all of the threads are blocked, waiting for SQl to respond. Therefore, there are no threads ready to service authentication requests, and they get discarded.
The solution is to fix the SQL server so it doesn't go down. If it's a critical part of your infrastructure, I'm a little unsure as to why it would go down, or lock FreeRADIUS out for many seconds at a time.
Indeed.. under normal circumstances it wouldn't go down. My issue is that the SQL server is not a critical part of our infrastructure and I don't want it to be (at this point anyway). I'm using it for accounting trend reporting only.. in any event, Nicolas' suggestion was right on and works like a charm. Thanks John
John Donagher <john@webmeta.com> wrote:
Indeed.. under normal circumstances it wouldn't go down. My issue is that the SQL server is not a critical part of our infrastructure and I don't want it to be (at this point anyway). I'm using it for accounting trend reporting only.. in any event, Nicolas' suggestion was right on and works like a charm.
In the CVS head you can use the rlm_sql_log module, which dumps the queries to a file. The file can then be post-processed. This removes all run-time dependency on SQL, which is a better solution. Alan DeKok.
participants (3)
-
Alan DeKok -
John Donagher -
Nicolas Baradakis