[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Help-gnu-radius] checkrad (Simultaneous-Use) with multiple gnu-radI
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>
Tue, 22 Apr 2003 09:01:55 -0400
> 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
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.