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.
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?".
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?
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?
-Danny
===
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.
