HUP handling: a thought

[Chris Parker]

On May 3, 2007, at 9:28 PM, Alan DeKok wrote:

> Frank Cusack wrote:
>> 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.
>
>   Exactly.  The benefit, however, is to avoid writing yet another
> api/tool to modify a running configuration.

Yes, though there may not be anything out there that fits what we need.

>   After spending some time on this, there isn't a ready-made solution
> that I've found.  Looking on the net, few servers other than OpenLDAP
> support dynamic run-time changes to the config.  And they all do so  
> via
> a DB interface.

Not all.  :)

ser/openser for instance takes commands via a pipe.

My thoughts were to be able to send commands to FR in a similar fashion.

"reload clients"     <-- only reloads clients structure
"reload full"        <-- full reload
"reload proxy"       <-- only reloads proxy/realms structure

The problem with HUP handling as it stands today is it causes a  
reload of
"everything".  For a highly available service like RADIUS, where  
state is
important, being able to only selectively reload the clients.conf  
without
stepping on all of the aaa sessions "in flight" would be huge.

Ultimately, it'd be awesome to manipulate individual elements of the  
clients/realms
structs, aka:

"reload client somenas.foo.com"  <--- reads clients, builds struct  
for somenas, pops current
                                       struct entry out, pops new  
struct entry in.  fails if
                                       there are errors in parsing  
clients entry, and doesn't
                                       alter the live in memory struct.

"reload realm foo.com"           <--- same as above.

That type of granularity would indeed step on the state for "in  
flight" sessions of the
affected realm/client, but that would be acceptable since we are in  
fact changing it.
All unaffected realms/clients would *not* have their state affected.   
This is very very
useful in large environments where you have several thousand client  
and realm entries.

-Chris
--
Chris Parker
Director, Systems
StarNet - US LEC, now a PAETEC Company

(888)212-0099   Fax (847)963-1302
Wholesale Internet and VoIP Services     http://www.megapop.net

NOTICE: Message is sent IN CONFIDENCE to addressees. It may contain  
information that is privileged, proprietary or confidential.