(RADIATOR) recommended method to "event notify" radiator to a restart/reread

[Hugh Irvine]

Hello Phil, Hello Tariq -

Another technique you can use is to set up a Monitor clause and connect  
to it and issue a RESTART command.

See sections 6.62 and 23 in the Radiator 3.9 reference manual.

regards

Hugh


On 10 Jul 2004, at 05:07, Phil Freed wrote:

> The question was -- how to force a reload of Radiator when the config  
> file or config DB changes.
>
> I like and use the SSH method recommended by Stefan.  But there are  
> times when you want someone who doesn't have adequate permissions to  
> start/stop Radiator to be able to signal a reload.  A web server  
> process is probably the most common example of this.  Here are some  
> tricks you can use:
>
> 1)  If a particular file exists in a particular directory, I will  
> reload the server.  That means that a reload can even be triggered via  
> ftp or scp.  A simple cron script will do the job:
>
>    FILE=/var/tmp/reload.now
>    if [ -f $FILE ]; then
>
>       # keep a record of restarts, if you like
>       mv $FILE $FILE.`date '+%y%m%d-%H%M%S'`
>
>       # Check the config file integrity, then....
>       pkill -HUP radiator
>    fi
>
> (For more notes about pkill, see the script below.)  This
>
>
> 2)  A cron script that watches the relevant configuration files, and  
> automatically signals Radiator.  With a little more tweaking (I wanted  
> to keep this script simple), you could change this script to only send  
> the signal if the changes are more than (say) 60 minutes old.  Or, it  
> could just send a reminder email.
>
> This script is long -- but it's mostly documentation.  And you can use  
> it to monitor for changes in any files for any purpose.
>
>
> #!/sbin/sh
> #
> # radhup.sh -- send HUP signal to radiator if any files have changed
> #
> # This script will see if any files have been changed since the last  
> time
> # it was run.  It does this by:
> #   1) creating flag file each time the script is run
> #   2) checking to see if any files are newer than the
> #      flag file that was created the last time the script was run
> #
> # If you want to monitor a DB for changes (as opposed to flat files),  
> you
> # will something slightly fancier, though the priniciple is the same.   
> Just
> # keep a timestamp-of-last-change on each record, and create some
> # special flag records to indicate the time of last review (or time of  
> last
> # restart).
> #
> #
> # If you want to force a restart, run this script with a "-f" flag
> #
> #
> # This script should work under ksh, bash, or sh.  If you are using
> # an old shell, you may need to redefine TEST as noted below.
> #
>
> # Created by Phil Freed
> #
> # Modification history
> # 2004-07-09 ptf  Initial revision
> #
>
> ####################################################################### 
> ###
>
> ###
> #
> # Location of the flag files
> #
> FLAGFILE=/var/tmp/radreset.flag
> TEMPFLAG=$FLAGFILE.tmp
>
> ###
> #
> # Did user specify "-f" ?
> #
> FORCE=no
> [ "$1" = -f ] && FORCE=yes
>
> ###
> #
> # List of files to check
> #
> FILES="/usr/local/etc/someinclude.inc /etc/radiator.conf  
> /some/other/file"
>
>
> ###
> #
> # On many Unix boxes, there's a util called pkill which lets you
> # send signals to a process by its name.  If you don't have this,
> # you'll want to define PIDFILE here.
> #
> # PIDFILE=/where/is/my/radiator/pidfile
>
>
> ###
> #
> # Many systems have a test executable that is smarter than the
> # test built into their shell.  If you get something like
> #    test: unknown operator -nt
> # when you run this script, change the line below to something like
> #    TEST=/usr/bin/test
> #
> TEST=test
>
>
> ###
> #
> # Just in case this is the first time we have run this script:
> #
> [ ! -f $FLAGFILE ] && touch $FLAGFILE
>
>
> #################################################################
> #################################################################
> #
> # Now to get down to business.
> #
>
> ##
> #
> # 1) Force a reload?
> #
> RELOAD=no
> [ $FORCE = yes ] && RELOAD=yes
>
>
> ##
> #
> # 2) create a flag file.  We do this at the beginning instead of the  
> end, to
> #     ensure that we don't miss any changes that might be made while  
> the
> #     script is running.
> #
> touch $TEMPFLAG
>
> ##
> #
> # 3) Anything changed since the last time?
> #
> for f in $FILES
> do
>   $TEST $f -nt $FLAGFILE && RELOAD=yes
> done
>
>
> ##
> #
> # 4) Save the new flag file for the next time we run
> #
> mv $TEMPFLAG $FLAGFILE
>
>
> ##
> #
> # Finally -- this is the purpose of the whole script.
> #
> # If you don't have pkill on your system (or the equivalent),
> # you can build it in the shell.  (You'll probably find examples
> # in your init.d directory).  Or, you can just use the classic
> #   kill -HUP `cat /where/is/my/pidfile`
> #
> # You could also send an email notification that radius needs to be
> # restarted:
> #
> # if [ $FORCE = no ]; then
> #   # send mail unless the user is running this script manually with  
> "-f"
> #   echo Do it now | mail -s "Restart radiator" radadmin at mydomain.com
> # fi
> #
>
> if [ $RELOAD = yes ]; then
>    # Just in case the file is being written while the script is  
> running --
>    # we pause a bit to allow the write to finish.
>    sleep 2
>
>    # Check the config file integrity, then:
>    pkill -HUP radiator
> fi
>
>
>
>
> At 06:49 PM 7/7/2004, Hugh Irvine wrote:
>
>> Hello Tariq -
>>
>> Interesting question - can anyone else on the list offer any  
>> suggestions?
>>
>> And in answer to your question, no there is no configuration file  
>> watching in Radiator.
>>
>> regards
>>
>> Hugh
>>
>>
>> On 7 Jul 2004, at 20:50, Tariq Rashid wrote:
>>
>>>
>>> hi - i'm sire many of you have come across this issue before, and  
>>> its not
>>> unique to radiator either.
>>>
>>> the radius clients can be kept in the radius.cfg file (as <Client,  
>>> 1.2.3.4>
>>> for example) or in a database, and i'm sure they can be kept in other
>>> locations too ...
>>>
>>> however, when an external system updates this list, either by  
>>> rewritring the
>>> radius.cfg file, or updating an included file, or by adding entries  
>>> to or
>>> removing entries from an sqlclientlist database ... a running  
>>> radiator does
>>> not take account of the changes until the radiator server instances  
>>> if
>>> restarted or sent a -HUP signal.
>>>
>>> is there a recommended way to do this from remote locations? that  
>>> is, these
>>> event notification originate on different machines to those which are
>>> actually running the server instances.
>>>
>>> i want to avoid additional custom written "event notification and  
>>> restart"
>>> software as it adds points of weakness into an otherwise solid  
>>> system, and
>>> also requires additional support. (its is for this reason that i  
>>> want to
>>> avoid external sql databases too, as that requires additional  
>>> support and a
>>> more complex set of failure points)
>>>
>>> a not-so-good solution is to perhaps ask radiator to restart/reHUP
>>> periodically. i don't think there is a "file-watching" mechanism in
>>> radiator?
>>>
>>> tariq
>
> --
> Archive at http://www.open.com.au/archives/radiator/
> Announcements on radiator-announce at open.com.au
> To unsubscribe, email 'majordomo at open.com.au' with
> 'unsubscribe radiator' in the body of the message.
>
>

NB: have you included a copy of your configuration file (no secrets),
together with a trace 4 debug showing what is happening?

-- 
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. Available on *NIX, *BSD, Windows, MacOS X.
-
Nets: internetwork inventory and management - graphical, extensible,
flexible with hardware, software, platform and database independence.
-
CATool: Private Certificate Authority for Unix and Unix-like systems.

--
Archive at http://www.open.com.au/archives/radiator/
Announcements on radiator-announce at open.com.au
To unsubscribe, email 'majordomo at open.com.au' with
'unsubscribe radiator' in the body of the message.