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

Phil Freed url-radiator at freed.com
Sun Jul 11 09:01:14 CDT 2004


At 03:03 AM 7/10/2004, Hugh Irvine wrote:
>Another technique you can use is to set up a Monitor clause and connect
>to it and issue a RESTART command.

This is a better answer to Tariq's question -- it provides a way to learn 
the results after a remote restart.

We have a section on many of our restart scripts -- such as DNS and 
Radiator -- that monitors the log files and notifies us in various ways of 
any errors that occur.  I see that I didn't mention any of this in my 
response -- sorry.

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

Thanks.

>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.


More information about the radiator mailing list