buffered-sql, radsqlrelay and fault resilience
Hi all, First a good day to you, since this is my first mail in this list. I am trying to build a multi-server setup, where each server uses a local user database (replicated from a central management server) and buffers its accounting data before pushing it back to the management server. I have tried two different methods, but none fully satisfied me so far. - First method uses "buffered-sql" and two sql modules: the first one points to local database and is used for auth, the other points to management server and is used by buffered-sql for accounting. This works very well except for one thing - by design, if the management sql server is unavailable for some reason, freeradius will refuse to launch. It should not be an issue in 99% of the cases but still bugs me a little bit. - Second method uses a cron'd "radsqlrelay" and "sql_log". It will accept to launch regardless of the status of management server, but in return it is much less smarter on the SQL part due to its inability get feedback from the sql server at the time the query is written (it basically cant fallback on an INSERT should an UPDATE fail due to non-existing record). On many aspects method #1 is better, but I would like to find a way to make the connection to management server optional at start-up, as I in my case accounting is secondary and should not be interfering with auth. Thanks in advance for your help, Yann
On 10/06/13 16:14, Yann Belin wrote:
On many aspects method #1 is better, but I would like to find a way to make the connection to management server optional at start-up, as I in my case accounting is secondary and should not be interfering with auth.
Which version are you on? This might be better/possible in 3.0, as the connection pool stuff might let you set "0" as the number of initial server connections.
On Mon, Jun 10, 2013 at 05:14:16PM +0200, Yann Belin wrote:
I am trying to build a multi-server setup, where each server uses a local user database (replicated from a central management server) and buffers its accounting data before pushing it back to the management server. I have tried two different methods, but none fully satisfied me so far.
In case it's useful: Our "front-end" RADIUS servers[0] write a 'detail' log file to disc. We then have a detail reader (see "copy-acct-to-home-server" virtual server) that reads this file and relays it to the management RADIUS server for centralised logging. If the management server goes down, the files on disc just grow until it comes back again and then the logs are relayed over. It works well, and means that there are no dependencies on the management server for service to be operational. HTH, Matthew [0] recent 2.x from git -- Matthew Newton, Ph.D. <mcn4@le.ac.uk> Systems Specialist, Infrastructure Services, I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom For IT help contact helpdesk extn. 2253, <ithelp@le.ac.uk>
We then have a detail reader (see "copy-acct-to-home-server" virtual server) that reads this file and relays it to the management RADIUS server for centralised logging.
If the management server goes down, the files on disc just grow until it comes back again and then the logs are relayed over.
It works well, and means that there are no dependencies on the management server for service to be operational.
Checking that now. I'd rather avoid having a radius server instance running on management server, but I don't think I have much other options here.
We then have a detail reader (see "copy-acct-to-home-server" virtual server) that reads this file and relays it to the management RADIUS server for centralised logging.
If the management server goes down, the files on disc just grow until it comes back again and then the logs are relayed over.
It works well, and means that there are no dependencies on the management server for service to be operational.
Checking that now. I'd rather avoid having a radius server instance running on management server, but I don't think I have much other options here.
Seems that running additional radius server on management server will be a no-go for me. I'm reverting back to first idea and trying to find a workaround to get freeradius to start even if accounting/management DB is unreachable... Any ideas welcome.
On 11/06/13 13:12, Yann Belin wrote:
We then have a detail reader (see "copy-acct-to-home-server" virtual server) that reads this file and relays it to the management RADIUS server for centralised logging.
If the management server goes down, the files on disc just grow until it comes back again and then the logs are relayed over.
It works well, and means that there are no dependencies on the management server for service to be operational.
Checking that now. I'd rather avoid having a radius server instance running on management server, but I don't think I have much other options here.
Seems that running additional radius server on management server will be a no-go for me. I'm reverting back to first idea and trying to find a workaround to get freeradius to start even if accounting/management DB is unreachable... Any ideas welcome.
Run the detail reader in a separate FreeRADIUS process on the local machine, and wrap it in a sleep/restart watchdog?
Seems that running additional radius server on management server will be a no-go for me. I'm reverting back to first idea and trying to find a workaround to get freeradius to start even if accounting/management DB is unreachable... Any ideas welcome.
Run the detail reader in a separate FreeRADIUS process on the local machine, and wrap it in a sleep/restart watchdog?
Thanks Phil your suggestion put me on the right track. Instead of running two daemons at the same time, I modified init.d script in order to detect start failure and - if it happens - try to start alternate daemon/config (without management SQL server). With a bit of scripting for check & recovery on the management server I should be on track.
participants (3)
-
Matthew Newton -
Phil Mayers -
Yann Belin