>>> That will be fixed on another commit.
>>>   It turns out the easiest way to fix that was to remove the multiple
>>> places that called "Post-Auth-Type Reject", and move it to one central
>>> location.  Simpler, less code, does exactly the same thing as before,
>>> and adds the call to "Post-Auth-Type Reject" when the home servers fail
>>> to respond.
>>>   We should probably have a "Post-Proxy-Type = Fail", that gets called
>>> when a home server fails to respond to a request.
That would make sense, then you can trigger a script to email admins ... 

And well done :)

Coincidently started testing the 2.00 pre code in a proper environment 
today instead of just using
radclient. All seems to stand up pretty well, no random crashes or 
weirdness... apart from of course the dreaded HUP
which results in a segfault.

The main things that will change on our implementation will be the SQL 
based client list (which could change hourly).
as we have a well used equipment database which the NAS list is being 
derived from.
Techs will also want to test switches in new installs , and they won't 
like waiting a day for configuration changes to take effect.... like 
users won't like the service
going down every hour , although we could stagger the server restarts....

What would be really useful, is to be able to force the server to reload 
any of the 'file' based configuration files ... like users huntgroups files.
...and the sql based clients list, and the easiest way to do this would 
be via snmp.

I think this would satisfy most users requirements... if they need any 
more than this then they either have very strange requirements or
a very poorly configured server :S.

Other options would be a cron like function, than reloads selected 
things periodically, or automatic change detection (which would be the 

List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Reply via email to