Hello Dan -
It seems to me there is a fundamental problem in trying to design something that relies on an SQL database, but should keep working without problems if the database goes away?
Most operators that I have worked with tend to run their databases on large fault-tolerant SQL server machines designed for this purpose and they make sure the database is always available through replication or clustering of some form.
regards
Hugh
On Tuesday, Jul 1, 2003, at 15:09 Australia/Melbourne, Dan Melomedman wrote:
Hugh Irvine wrote:
Hello Dan -
It would be fairly simple to have Radiator write to a flat file for
accounting, and then have a cron job or similar load the data into the
database periodically. You will find a simple utility to do this in the
file "goodies/radimportacct".
regards
Hugh
A cron job is too dirty of a hack, some other trigger would be better.
What to do about sessions though? They need to find a way to the
database too, unless someone has some specialized (network) session
service written (which I would love to use instead of an SQL DB anyway).
===
Archive at http://www.open.com.au/archives/radiator/
Announcements on [EMAIL PROTECTED]
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.
NB: have you included a copy of your configuration file (no secrets), together with a trace 4 debug showing what is happening?
-- Radiator: the most portable, flexible and configurable RADIUS server anywhere. Available on *NIX, *BSD, Windows 95/98/2000, NT, MacOS X. - Nets: internetwork inventory and management - graphical, extensible, flexible with hardware, software, platform and database independence.
=== Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
