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.
