Re: (RADIATOR) Radiator Stopped Working
I think that Paul's problems here show a fundamental weakness in the design of Radiator -- the fact that if the *accounting* SQL server goes down, all your functionality for *authentication* is lost as well. I've personally worked around this by running two separate daemons. One for authentication and the other for accounting. This limits my exposure to a total network outage due to a glitch with my Oracle database (which is rare, but did happen once and that was enough for me). I love the Radiator product, but something should be done to separate the code from its heavy reliance on the remote database server. There should be a way to ignore errors. Instead of dumping core when accounting packets don't get written to the database, the system should generate an SNMP trap, write to the logs or something less dramatic than shutting down. Just my 2 cents worth. If anyone is interested in how I separated my authentication from my accounting, let me know. John At 09:23 AM 10/17/99 +1000, you wrote: I seem to have sorted the problem out now. There is a handy mysql program called isamchk which allowed me to check each of the tables, sure enough a couple of them had corrupted pointers. Used the repair option and now Radiator seems to be working ok again. Regards. Paul Hugh Irvine wrote: Hello Paul - On Fri, 15 Oct 1999, Paul Black wrote: I've found out where the problem is with my Radiator. When I commented out the Session Database section of my radius.cfg file, Radiator started to work again. I've noticed that a couple of my mysql processes are using up 99% of the cpu time. I'm fairly sure the problem lies in the Session Database. Could anyone tell me which table(s) to deleted and how to recreate it again? Have a look in the Radiator goodies directory - there is a mysqlCreate.sql script that does both, although it does all the other tables as well!! *** You will have to extract just the bit that drops and recreates the table called RADONLINE. Don't just run the script as it is, as it will destroy and recreate all your other tables as well*** You might also check in the RAdmin directory to verify the format that was created by the schema.pl module. I just had a look here and the RADONLINE tables in both places look identical, but you should check yourself. If you have any questions please don't hesitate to contact me. hth Hugh -- Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, TACACS+, PAM, external, etc etc on Unix, Win95/8, NT, Rhapsody === Archive at http://www.thesite.com.au/~radiator/ To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message. === Archive at http://www.thesite.com.au/~radiator/ To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message. === Archive at http://www.thesite.com.au/~radiator/ To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) Radiator Stopped Working
Hi John, thanks for your thoughtful remarks. On the topic of handling database problems, Radiator was designed to be tolerant of SQL server problems. It not _supposed_ to crash if there is an SQL problem. It might be good if we tried to get to the bottom of why your Radiator has problems with SQL server failures? Can you send details of your config, and DBD, DBI, perl and SQL database versions? Cheers. --- Mike McCauley [EMAIL PROTECTED] Open System Consultants +61 3 9598 0985 Mike is travelling right now, and there may be delays in our correspondence. -Original Message- From: John Coy [EMAIL PROTECTED] To: Paul Black [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] [EMAIL PROTECTED] Date: Monday, October 18, 1999 2:40 AM Subject: Re: (RADIATOR) Radiator Stopped Working I think that Paul's problems here show a fundamental weakness in the design of Radiator -- the fact that if the *accounting* SQL server goes down, all your functionality for *authentication* is lost as well. I've personally worked around this by running two separate daemons. One for authentication and the other for accounting. This limits my exposure to a total network outage due to a glitch with my Oracle database (which is rare, but did happen once and that was enough for me). I love the Radiator product, but something should be done to separate the code from its heavy reliance on the remote database server. There should be a way to ignore errors. Instead of dumping core when accounting packets don't get written to the database, the system should generate an SNMP trap, write to the logs or something less dramatic than shutting down. Just my 2 cents worth. If anyone is interested in how I separated my authentication from my accounting, let me know. John At 09:23 AM 10/17/99 +1000, you wrote: I seem to have sorted the problem out now. There is a handy mysql program called isamchk which allowed me to check each of the tables, sure enough a couple of them had corrupted pointers. Used the repair option and now Radiator seems to be working ok again. Regards. Paul Hugh Irvine wrote: Hello Paul - On Fri, 15 Oct 1999, Paul Black wrote: I've found out where the problem is with my Radiator. When I commented out the Session Database section of my radius.cfg file, Radiator started to work again. I've noticed that a couple of my mysql processes are using up 99% of the cpu time. I'm fairly sure the problem lies in the Session Database. Could anyone tell me which table(s) to deleted and how to recreate it again? Have a look in the Radiator goodies directory - there is a mysqlCreate.sql script that does both, although it does all the other tables as well!! *** You will have to extract just the bit that drops and recreates the table called RADONLINE. Don't just run the script as it is, as it will destroy and recreate all your other tables as well*** You might also check in the RAdmin directory to verify the format that was created by the schema.pl module. I just had a look here and the RADONLINE tables in both places look identical, but you should check yourself. If you have any questions please don't hesitate to contact me. hth Hugh -- Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, TACACS+, PAM, external, etc etc on Unix, Win95/8, NT, Rhapsody === Archive at http://www.thesite.com.au/~radiator/ To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message. === Archive at http://www.thesite.com.au/~radiator/ To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message. === Archive at http://www.thesite.com.au/~radiator/ To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message. === Archive at http://www.thesite.com.au/~radiator/ To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) Radiator Stopped Working
I seem to have sorted the problem out now. There is a handy mysql program called isamchk which allowed me to check each of the tables, sure enough a couple of them had corrupted pointers. Used the repair option and now Radiator seems to be working ok again. Regards. Paul Hugh Irvine wrote: Hello Paul - On Fri, 15 Oct 1999, Paul Black wrote: I've found out where the problem is with my Radiator. When I commented out the Session Database section of my radius.cfg file, Radiator started to work again. I've noticed that a couple of my mysql processes are using up 99% of the cpu time. I'm fairly sure the problem lies in the Session Database. Could anyone tell me which table(s) to deleted and how to recreate it again? Have a look in the Radiator goodies directory - there is a mysqlCreate.sql script that does both, although it does all the other tables as well!! *** You will have to extract just the bit that drops and recreates the table called RADONLINE. Don't just run the script as it is, as it will destroy and recreate all your other tables as well*** You might also check in the RAdmin directory to verify the format that was created by the schema.pl module. I just had a look here and the RADONLINE tables in both places look identical, but you should check yourself. If you have any questions please don't hesitate to contact me. hth Hugh -- Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, TACACS+, PAM, external, etc etc on Unix, Win95/8, NT, Rhapsody === Archive at http://www.thesite.com.au/~radiator/ To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message. === Archive at http://www.thesite.com.au/~radiator/ To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) Radiator Stopped Working
Hello Paul - On Fri, 15 Oct 1999, Paul Black wrote: I've found out where the problem is with my Radiator. When I commented out the Session Database section of my radius.cfg file, Radiator started to work again. I've noticed that a couple of my mysql processes are using up 99% of the cpu time. I'm fairly sure the problem lies in the Session Database. Could anyone tell me which table(s) to deleted and how to recreate it again? Have a look in the Radiator goodies directory - there is a mysqlCreate.sql script that does both, although it does all the other tables as well!! *** You will have to extract just the bit that drops and recreates the table called RADONLINE. Don't just run the script as it is, as it will destroy and recreate all your other tables as well*** You might also check in the RAdmin directory to verify the format that was created by the schema.pl module. I just had a look here and the RADONLINE tables in both places look identical, but you should check yourself. If you have any questions please don't hesitate to contact me. hth Hugh -- Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, TACACS+, PAM, external, etc etc on Unix, Win95/8, NT, Rhapsody === Archive at http://www.thesite.com.au/~radiator/ To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
