help-gnu-radius
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Help-gnu-radius] multiple radius servers feeding in to one postgres


From: Andrew Kohlsmith
Subject: Re: [Help-gnu-radius] multiple radius servers feeding in to one postgres db
Date: Fri, 22 Nov 2002 08:33:40 -0500
User-agent: KMail/1.4.7

> Currently they do, but I plan to introduce the possibility to keep
> these data in the SQL database as soon as possible. This will solve the
> problem with several servers checking for the multiple logins.

Hmm..  If I could help, how would you like me to try and do this?  Are there 
any other roadblocks that I am perhaps not seeing?

e.g. if I simply take the radutmp and radstat files from the main radius 
server and copy them over to this new one, radping, radwho and radlast will 
show the same information as the main radius server did at the time of the 
snapshot?

And, just as a proof-of-concept, if I wrote a cron script which ran on each 
radius server and simply queried the accounting database for a list of 
current users and *generated* radutmp and radstat files, everything would 
appear correctly?

If this is true, then I (at least in theory) should be able to link these 
utilities to the radacct database.  :-)

> > Are there any plans on putting the users and rewrite configuration files
> > in the database?

> That's a bit harder to implement. However I like the idea and will try
> to figure out something.

It *could* be as simple as two two-column tables: "radius_srv" and 
"users_line" in the raduser table, and "radius_srv" and "rewrite_line" in the 
radius_rewrite" table.  On startup, the server would select all rows from 
each table with radius_srv = 'GLOBAL' and then select all rows from each 
table with radius_srv = `hostname` (or some other unique name)...  That would 
give the ability to have a global configuration and a per-server 
configuration as well.  If the database changes, the radius servers must be 
sent a HUP signal, just as they must be now.. that would minimize traffic to 
the database server since those rules do not change very often.

I dunno...  it's a start I guess.  :-)

Regards,
Andrew




reply via email to

[Prev in Thread] Current Thread [Next in Thread]