HUP handling: a thought

[inverse]

> > I remember vaguely that HUPing was at least once used to re-read updated
> > CRLs and probably also re-reading the list/directory of trusted client-CA
> > certificates for all the EAP-(T)TLS/PEAP stuff.
>
>   Yes.

that was me, so to the list of 'other things' other than re-read
clients, realms and the users files I'd like to add re-read of CRLs
(and certificates).

The reason for me being so boring is that a proper implementation of
EAP-(T)TLS requires the server to handle all the CA chain and CRL
updates crap.
CRLs unfortunately DO expire. Expired  CRL  == the properly
implemented EAP-TLS structure falls apart and everybody gets a reject
due to 'expired' certs.
Therefore, if you release a CRL because you have a properly
implemented CA and TLS infrastructure you must also reload it to the
radiusd or everything breaks and you get a VERY poor uptime ~_~.
If there's no chance to realod a CRL without an /etc/init.d/radiusd
restart then I'll stick to restarting the process during offpeak
hours. Not using a CRL at all is not an option when a major amount of
users enter and/or leave your organization each year and you use TLS.
As a side note, I know this sucks. Maybe I'm one othe few around the
world fool enough to go all the way down to CRLs.

As a foot note: I suppport Alan's idea. Let's forget about HUP.
Experience shows HUP is clearly not suited for something with a system
state and personally I don't accept a solution that makes an otherwise
perfectly stable daemon to occasionally crater. If HUP is not going to
work, let's do it another way. SQL sounds good to me. As long as it
reloads a CRL too ^_-


>   HUP does something in 1.x.  It will cause the server to re-read the
> configuration files.  It *may* also cause the server to die unexpectedly.

Too bad my test server dies with excellent consistency when I HUP it :P