Subject: RE: (radius) Off-topic: Database vs textfile approach (Implementa tion Question )

From: "Beadles, Mark A." <[email-masked]>
Date: Wed, 15 Sep 1999 14:31:29 -0400

From: Varghese, Joe [mailto:[email-masked]]:
>Is the general norm to restart the Radius server whenver new users are
>added? I ask this because with a users textfile, the only way to add or
>delete users is to generate a new file and then restart the server.
>
>The alternative would be to have authentication requests go straight to
>whatever database you have running, but the disadvantage is that the Radius
>server is now tightly integrated with a database. 
>
>Based on your experiences, do you recommend one way over another? Or, is
>there a middle ground (maybe a textfile that contains only the incremental
>changes in the database with primitives like add or delete)?

I hesitate to answer the question about what the "norm" is, because the norm
may in fact be a bad thing to do.  So...

In a case where a RADIUS server is part of a mission-critical
high-availability service, there probably is a requirement that the RADIUS
server can run without interruption.  That is, normal operations should not
impact service availability.  Adding users is certainly a normal operation.
This requirement can be met in various ways, but IMO doing lookups to some
type of back-end database is a good solution.  

I don't see why integration with a database is a disadvantage.  Databases
usually have well-documented public protocol interfaces and standard APIs.
We have used RADIUS servers that talk to SQL databases and LDAP directories
in order to achieve this level of service, with good results and
performance.

There is certainly a trend in the industry for commercial RADIUS servers to
support various back-end databases and directories.

+ Mark Anthony Beadles +  UUNET Product Development  + 
+  [email-masked]   + http://networking.us.uu.net +
+  Voice 614.723.1941  +       Fax 614.723.8407      +

-
To unsubscribe, email [email-masked]' with
'unsubscribe ietf-radius' in the body of the message.