Re: [Help-gnu-radius] checkrad (Simultaneous-Use) with multiple gnu-radIn-reply-to: Your message of Mon, 21 Apr 2003 10:32:50 -0400 <address@hidden>

[Andrew Kohlsmith]

> Some time ago Andrew Kohlsmith was solving the similar
> problem. Andrew, could you share your experience with Mark, please?

I am still testing my solution but it seems simple enough:

I wrote a patch for gnu-radiusd which adds a 'log_only' option to the 
radacct functions.  The authentication comes from Postgres as usual, but 
accounting logs are only written to an SQL log file.

Every minute, I move that log file and then use fuser to wait until the file 
is closed by the daemon.  Then I gzip it and queue it up for sending to a 
master server.

The master server collects these logfiles and "plays them back" into a 
master calls table.  Some software was written to generate a radutmp from 
SQL, and that master radutmp is sent back to all the RADIUS servers.

Currently the accounting records are collected and added to the master DB 
every minute, and the master radutmp is generated every 5.  I was using scp 
to copy this data around but now am using NFS over IPSec as it's much 
easier to use.

I went through several iterations of this idea before settling on this 
method.  Originally I'd done the calls table replication (many to one) 
similar to how I describe what I'm doing for auth below and that worked, 
but this was much cleaner.

The best part of this is that if a POP falls off the internet, its 
accounting logs just accumulate and when connectivity is restored, they're 
played back in order and nothing goes strange on me.  :-)

Authentication is handled a little differently.  As I mentioned earlier, all 
RADIUS boxes have their postgres passwd database for RADIUS.  One of the 
design goals was to have new users propagate within 5 minutes so there is a 
two-stage system in place.  I have a set of triggers on the master auth 
database which logs all changes to a 'diff' table.  That table is dumped 
and sent to all the RADIUS servers once every 5 minutes.  Then, at 3am 
every day the entire passwd table is sent over just to keep things in 
absolute sync.  I didn't want to truncate/insert the entire table every 5 
minutes because that would have calls rejected far more often than I'd 
like.  If there's a method to have RADIUS wait x seconds and spin while the 
table is locked, I could get rid of that "poor man's replication" idea.  
:-)

As I am still testing, this has not seen real-world use yet.  I have one 
"real" RADIUS server and I have it logging to what will become the master 
DB.  I am having some issues with the will-be-master server not seeing 
disconnections properly but I think it's an issue due to differences in the 
software.  Right now they are versions 0.95-pre and 0.96.4 for the actual 
server and the test master, respectively.  For some reason I don't think 
that 0.95-pre is writing stop records as often as it should be.

Regards,
Andrew