Adding run-time-access (RTA) to FreeRadius

[Bob Smith]

Alan DeKok wrote:

>   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.
OK.  RTA offers the ability to store configuration as a series of
SQL statements.  This ability is an option, not a requirement.


>   Does RTA provide secure access to the SQL interface?  I'm not sure I'd
> want to re-invent the administrator authorization interface.
Of itself, no.  The UI program talk to your daemon using PostgreSQL
client bindings.  These use either TCP or Unix sockets.  Security
or encryption would have to be provided by stunnel or some other
external means.


>> 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.
OK.


>> 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.
Yeah, it would be for me too.


>> 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".
Adding INSERT and DELETE is not that difficult.  The yacc/lex code will
pretty simple and the actual work will have to be done in callbacks
attached to the table definition.