Adding run-time-access (RTA) to FreeRadius
aland at deployingradius.com
Tue Jul 31 17:28:22 CEST 2007
Bob Smith wrote:
> EXECUTIVE SUMMARY
> I believe it will be straightforward but somewhat tedious to add RTA to
> the FreeRADIUS server. There are two issues to be resolve up front -
> updates to the data in FreeRADIUS are not thread safe, and if you have
> UI driven configuration changes, you can not keep the human readable file
> formats now in use.
I think there is a possibility to keep the old configuration files.
Asking people to switch from a known and familiar system to an
unfamiliar one can seriously slow down adoption of a new system.
> 2) Would root access and 'vi' still be required?
> The hope is that FreeRADIUS would become an appliance without ever requiring
> root access or vi after the initial installation. To do this, every config
> parameter in FreeRADIUS would have to be mapped to an RTA accessible table.
> (straightforward but tedious)
Does RTA provide secure access to the SQL interface? I'm not sure I'd
want to re-invent the administrator authorization interface.
> 4) RTA is not thread safe!
> While true, I don't think this is the issue. RTA is an API for other programs
> to access your data. Would you ask that the Hayes AT command set be thread
> safe? Of course not. I think the real issue is that FreeRADIUS is not thread
> safe for configuration updates.
The only daemon I know of that can handle dynamic updates is OpenLDAP.
Everyone else just re-starts.
> 7) We've put too much effort into our config file syntax to give them up.
> This is not really an RTA issue; it is an issue for any scheme to allow dynamic
> configuration updates. Yes, you _could_ have the server try to write the config
> back to disk int the same human-readable format, but you'd be crazy to try.
There are other ways to obtain the same effect. Asking people to use
the existing system OR RTA exclusively is a non-starter.
> 9) RTA is useless without INSERT and DELETE.
> This has long been a criticism of RTA. While there are simple ways around this
> most people still expect INSERT and DELETE for tables where the data is stored
> as a linked-list or other editable structure. I've had a difficult time getting
> people to see RTA as an API and *not* as a database.
Object API's include methods for "new" and "destroy".
Overall, I'm very interested in this. I'll take a look at doing
something similar for 2.x. If we could have a Django and/or RoR
interface to the FreeRADIUS configuration, that would be extremely cool.
More information about the Freeradius-Devel