HUP handling: a thought

[Frank Cusack]

On May 3, 2007 8:16:37 AM +0200 Alan DeKok <aland at deployingradius.com> 
wrote:
> Frank Cusack wrote:
>> I hate the idea of requiring SQL to configure the server.  It's another
>> dependency, one that is complex.  It makes inspection of the current
>> config difficult, and complicates config mgmt.
>
>   I agree.  I have issues with SQL myself.  However, the page I pointed
> to is ~1k LoC, and has no external dependencies.
>
>   Or, try this:  The server starts, reads *no* configuration, and just
> listens on an SQL port for configuration.  Then, a separate program
> groks the humanly-reading *conf files, and turns them into SQL nonsense
> for feeding to the server.  Once that's done, the admin doesn't need to
> know SQL.
>
>   HUP could be handled by having the separate program read the new
> config, and do "diff"s of the SQL statements.  It could then feed the
> appropriate changes to the server.

I don't see any special advantage then for SQL.  It's not like you're
going to do specialized config queries against freeradius.  You're not
going to write your config in SQL statements.

Additionally, computing a SQL "diff" sounds error prone to me.

>> Now then, if the config is dynamic via SQL, how's that different than
>> having it dynamic via a signal?
>
>   Dynamic config via "edit structure X value Y to value Z" is *nothing*
> like the current "kick the server in the head, and have it re-read
> everything on the planet" that's done for HUP.
>
>   Small, targeted changes are easier to manage.

I'm not suggesting that the current method of handling the config is
all that's needed.

>>  You will have to do all the same setup,
>> teardown and run all current transactions to completion while starting
>> new transactions under a new configuration anyway.
>
>   Yes.  The problem is simplified by having almost everything tied to a
> REQUEST.  So anything "live" is either a thread handling a REQUEST, or a
> REQUEST waiting for something.  And REQUESTs point to clients & home
> servers via one pointer, which is easy to manage.

Easily done without SQL.

-frank