Dickon Newman wrote:
Again, I've tried to search the archives without much luck.We used to use the following script (before migrating to MySQL):
I have multiple radius boxes (FreeBSD), and currently use rsync to update the users file (and others). However, I need to restart radiusd to notice the changes in the files. I can make a script that sends a kill -9 locally, but what about remotely? Root cannot ssh, and normal users cannot send a kill -9 to a root process?
Has anyone else had this problem?
I understand that proxying may be a better approach, however, I have to work within certain constraints :-/
Dickon...
#!/bin/bash
#
# A simple script to see if we need to restart radius because of
# a change in the user file.
#
# should be called from a cron job... oh say every 5 min
#
# 3/19/01 by RAP
FLAGFILE="/etc/raddb/radius_timestamp";
USERFILE="/etc/raddb/users";
if [ $USERFILE -nt $FLAGFILE ]; then
# echo "reloading RADIUS";
builddbm
/etc/init.d/radiusd reload;
touch $FLAGFILE;
fi;
This one only restarts radiusd if the users file has changed since the last restart. There is a race condition where a change won't trigger a reload (if you change the users file just after a reload) so maybe something like ! $FLAGFILE -nt $USERFILE would be better, but it didn't present much problems for us.
I put that script on my primary and my secondary radius server. We had the following cron.d entry on the primary:
rpuhek@terrance:/etc/cron.d$ more radius_update
MAILTO=""
PATH="/bin:/usr/bin:/sbin:/usr/sbin:/usr/local/bin"
0-55/2 * * * * root /usr/local/sbin/radius_reload
0-55/2 * * * * radius /usr/local/bin/sync_radius
One other note: the sync_radius script does rudimentary locking, and excludes the timestamp file. That way, the secondary server manages it's own timestamp file:
more /usr/local/bin/sync_radius
#!/bin/bash
#
# Script to rsync radius files on this server with backup server
#
#
BACKUP="<backupserver>";
BACKUP_LOC="/etc/raddb/";
FILE_LOC="/etc/raddb/*";
EXCLUDE="--exclude radius_timestamp --exclude backup_sync.lock";
if [ -a /etc/raddb/backup_sync.lock ]; then
echo "lock file present... is another sync process running?";
exit 1;
fi;
touch /etc/raddb/backup_sync.lock;
rsync -t -e ssh $EXCLUDE $FILE_LOC $BACKUP:$BACKUP_LOC
rm /etc/raddb/backup_sync.lock;
Overall result of the above scripts was high-availablility of our RADIUS servers, plus fairly rapid synchronization of the user databases. As a bonus, I only had to maintain the servers file on one radius servers, since the rsync would take care of that as well.
--Rich
_________________________________________________________
Rich Puhek
ETN Systems Inc.
2125 1st Ave East
Hibbing MN 55746
tel: 218.262.1130
email: [EMAIL PROTECTED]
_________________________________________________________
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
