O/H Alan DeKok έγραψε:
> Milan Holub wrote:
>
>> - we are keeping NAS entries in DB.
>>
>
> Then the server should re-load them via reading the DB.
>
>
>> - these entries are edited by operation guys via web interface
>> - when a new NAS entry is added then we need to reload/restart
>
inverse wrote:
> Going back to the subject, a useful feature would be a periodical
> reload of certificate revocation lists and the users list. These two
> lists are prone to changing frequently in production environments: a
> production server usually has an otherwise stable configuration.
That
Milan Holub wrote:
> - we are keeping NAS entries in DB.
Then the server should re-load them via reading the DB.
> - these entries are edited by operation guys via web interface
> - when a new NAS entry is added then we need to reload/restart
> freeradius
> - we reload freeradius using SNMP
Milan Holub wrote:
> ==> I've found really useful the idea of telling freeradius
> to reload via snmp - could be such functionality easily kept when using
> your proposed approach?
Reloading via SNMP is exactly the same as HUP.
Configuring a server by doing SNMP writes is very hard.
Alan D
Hi Alan,
On Wed, Apr 11, 2007 at 04:02:15PM +0200, Alan DeKok wrote:
> > Do you have in mind a favorite technique for signaling daemons that
> > the config files have changed? HUP is a common way to do it, but I'm
> > sure there are other ways.
>
> A command-line tool that uses some other meth
> > Maybe we can add features that prevent the need for the HUP, and then
> > remove support for HUP. That would be best, I think.
>
> Do you have in mind a favorite technique for signaling daemons that
> the config files have changed? HUP is a common way to do it, but I'm
> sure there are othe
Hi Alan,
On Wed, Apr 11, 2007 at 03:45:18PM +0200, Alan DeKok wrote:
> Milan Holub wrote:
> > somewhere in this list there was already mentioned that current CVS
> > version causes segmentation fault when received HUP signal(kill -HUP pid) -
> > depending on
> > the configuration it may survive
Ethan Dicks wrote:
> On 4/11/07, Alan DeKok <[EMAIL PROTECTED]> wrote:
>> To back up a bit, *why* are you HUPing the server?
>
> I usually HUP servers to force them to re-read their configuration
> without forcing the server to restart.
Well, yes. But *what* are you changing? Clients? Real
On 4/11/07, Alan DeKok <[EMAIL PROTECTED]> wrote:
> To back up a bit, *why* are you HUPing the server?
I usually HUP servers to force them to re-read their configuration
without forcing the server to restart. I'm glad I found the earlier
commentary that HUPping radiusd is considered harmful. I
Milan Holub wrote:
> somewhere in this list there was already mentioned that current CVS
> version causes segmentation fault when received HUP signal(kill -HUP pid) -
> depending on
> the configuration it may survive 1st HUP and then it dies with 1st
> radius request/2nd HUP).
To back up a bit
Hi all,
somewhere in this list there was already mentioned that current CVS
version causes segmentation fault when received HUP signal(kill -HUP pid) -
depending on
the configuration it may survive 1st HUP and then it dies with 1st
radius request/2nd HUP).
Reason is also known: wrong freeing of
11 matches
Mail list logo