Hello Danny -
On Tue, 02 May 2000, Danny Whitesel wrote:
> Last Friday, the server that houses our Rodopi database had a massive
> hardware failure. As of yet, I am not 100% sure just what the extents of the
> damage is. Most of the server was replaced just to get it back online as
> quick as possible. To make a long story short, it was down for 6 days.
>
Ouch!
> Our Radiator Radius server reports accounting data to the aformentioned
> Rodopi database. Authentication is pulled off of a Linux MySQL server, so
> our users were still able to connect. Ironically enough, even though Rodopi
> has provisions for serving up Radius right from it's own database, I chose
> to serve Radius from a seperate out of concern for "What if the Rodopi
> machine goes down?".
>
Nice when it goes in your favor isn't it?
> Once the Rodopi machine got back online, one of the NT admins noticed that
> radiusd was no longer connecting and reporting accounting data. I sent
> a -HUP to radiusd...nothing. Only after completely killing and restarting
> radiusd, did it resume reporting accounting data to the Rodopi database.
>
> I'm just curious what the timeouts and/or agressiveness of the accounting
> database
> connectivity is?
>
The default is to wait 10 minutes before trying another connection. Check
sections 6.24.4 Timeout and 6.24.5 FailureBackoffTime in the Radiator 2.15
reference manual.
> Also...While I'm on the subject of database connectivity, this same NT admin
> noticed and commented on how radiusd connects and stays connected to the
> Rodopi database constantly. He is of the opinion that radiusd(and any other
> clients, for that matter) should connect and disconnect for every
> query/write. He feels that performance is not an issue since database
> servers are designed to, and expect to, take rapid connects, queries/writes
> and disconnects. "That's their job.", he says.
>
> Though I have an opinion on the subject, I promised I would just pose the
> question to the list and see what you guys had to say. What you about you,
> Hugh? What is the official word from the development team on this issue?
>
Radiator opens a connection to the SQL server and keeps it open for as long as
possible. If the connection goes down, Radiator will reopen the connection
according to the aforementioned timeouts and again keeps the connection open for
as long as possible.
Mike's view tends to be that Radiator should be handling radius requests first
and foremost, rather than wasting time trying to contact SQL hosts.
hth
Hugh
--
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
Platypus, Freeside, Interbiller, TACACS+, PAM, external, etc, etc.
Available on Unix, Linux, FreeBSD, Windows 95/98/2000, NT, MacOS X.
===
Archive at http://www.starport.net/~radiator/
Announcements on [EMAIL PROTECTED]
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.
