RE: (RADIATOR) Database support fault tolerance
Hey Dan, I don't want to step on toes.It seems like the root problem here is to fix the communication between the Radius server and the SQL server. Is it some sort of remote link? Regards, Craig. === 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.
Re: (RADIATOR) Database support fault tolerance
Hello Tony -
There is already an AcctFailedLogFileName available in the AuthBy SQL
clause that you can use to store the accounting records if the database
is unreachable.
See section 6.28.19 in the Radiator 3.6 reference manual
("doc/ref.html").
regards
Hugh
On Tuesday, Jul 1, 2003, at 14:50 Australia/Melbourne, Tony Bunce wrote:
I'm going to have to agree that some sort of non-blocking queuing
system
would be a very nice feature.
Should your data source ever fail, radiator could continue to operate
while losing very little function and no loss of accounting records.
This may also speed radiator up, as it would just hand the data to the
middleware without ever having to wait on the sql server.
Thanks,
Tony B, CCNA, Network+
Systems Administration
GO Concepts, Inc. / www.go-concepts.com
Are you on the GO yet?
What about those you know, are they on the GO?
513.934.2800
1.888.ON.GO.YET
-Original Message-
From: Dan Melomedman [mailto:[EMAIL PROTECTED]
Sent: Monday, June 30, 2003 9:44 PM
To: [EMAIL PROTECTED]
Subject: Fwd: Re: (RADIATOR) Database support fault tolerance
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".
I was hoping more for something like this included in Radiator's
design.
Would benefit many, really.
===
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.
===
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.
Re: (RADIATOR) Database support fault tolerance
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.
Re: (RADIATOR) Database support fault tolerance
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.
Re: (RADIATOR) Database support fault tolerance
Hello Dan - We try to make Radiator good at dealing with radius requests, while at the same time providing you with a wide range of facilities allowing you to interface with other systems. As mentioned previously there are alternatives available if database access cannot be assured. regards Hugh On Tuesday, Jul 1, 2003, at 11:43 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". I was hoping more for something like this included in Radiator's design. Would benefit many, really. === 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.
RE: Re: (RADIATOR) Database support fault tolerance
I'm going to have to agree that some sort of non-blocking queuing system would be a very nice feature. Should your data source ever fail, radiator could continue to operate while losing very little function and no loss of accounting records. This may also speed radiator up, as it would just hand the data to the middleware without ever having to wait on the sql server. Thanks, Tony B, CCNA, Network+ Systems Administration GO Concepts, Inc. / www.go-concepts.com Are you on the GO yet? What about those you know, are they on the GO? 513.934.2800 1.888.ON.GO.YET -Original Message- From: Dan Melomedman [mailto:[EMAIL PROTECTED] Sent: Monday, June 30, 2003 9:44 PM To: [EMAIL PROTECTED] Subject: Fwd: Re: (RADIATOR) Database support fault tolerance 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". I was hoping more for something like this included in Radiator's design. Would benefit many, really. === 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. === 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.
Fwd: Re: (RADIATOR) Database support fault tolerance
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". I was hoping more for something like this included in Radiator's design. Would benefit many, really. === 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.
Re: (RADIATOR) Database support fault tolerance
Why not just use a redundant authenticator, most DBs including LDAP engines can sync between multiple servers, then just point radiator at each one and if it can not talk to the first it will fail over to the next... Or better yet, just use a Foundry Server Iron (Layer 7 switch) to sit between Radiator and the Database Farm. Then all the connections to the database servers are VIPs (virtual IPs) and the switch will handle all the fail over and load balancing for you. Bret Dan Melomedman wrote: Our users are getting sick and tired due to RADIUS service unavailability every time something happens to the network where the database server sits, or the database server itself. To remind, we use LDAP for authentication, and SQL Server for sessions/logging. LDAP has been great, where database connectivity has been problematic, and a major pain in the arse in general. In some cases, Radiator would hang if there are database connection failures. A failure with the unixODBC client translates into Radiator process failure. Right now Radiator's availability is directly dependent on the quality of the Perl libraries, including the database libraries/clients. Our service could be much more available if SQL was handled by an outside process with a queue in the middle. If something happens to this SQL helper process, the network, or the database server, then the queue simply grows in size, and Radiator continues running happily, authenticating users. When the problems are fixed, the queue is relayed to the SQL server, and no logging records are lost. If we want to be fancy, this extra process may even be temporarily handling sessions in place of RADONLINE (instead of simply ignoring them returning OK back to Radiator), and notifying system administrators when it can't talk to the SQL database. This system is not only a more resilient design, but more scalable too since Radiator will return as soon as it writes to the queue, not waiting for the database server. Please let me know your thoughts; let's discuss this idea further. Thanks. === 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. -- ~~~ Bret Jordan Dean's Office Computer Administrator College of Engineering 801.585.3765 University of Utah [EMAIL PROTECTED] ~~~ === 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.
Re: (RADIATOR) Database support fault tolerance
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 On Tuesday, Jul 1, 2003, at 09:19 Australia/Melbourne, Dan Melomedman wrote: Our users are getting sick and tired due to RADIUS service unavailability every time something happens to the network where the database server sits, or the database server itself. To remind, we use LDAP for authentication, and SQL Server for sessions/logging. LDAP has been great, where database connectivity has been problematic, and a major pain in the arse in general. In some cases, Radiator would hang if there are database connection failures. A failure with the unixODBC client translates into Radiator process failure. Right now Radiator's availability is directly dependent on the quality of the Perl libraries, including the database libraries/clients. Our service could be much more available if SQL was handled by an outside process with a queue in the middle. If something happens to this SQL helper process, the network, or the database server, then the queue simply grows in size, and Radiator continues running happily, authenticating users. When the problems are fixed, the queue is relayed to the SQL server, and no logging records are lost. If we want to be fancy, this extra process may even be temporarily handling sessions in place of RADONLINE (instead of simply ignoring them returning OK back to Radiator), and notifying system administrators when it can't talk to the SQL database. This system is not only a more resilient design, but more scalable too since Radiator will return as soon as it writes to the queue, not waiting for the database server. Please let me know your thoughts; let's discuss this idea further. Thanks. === 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.
