Section 5. Details on starting Radiator during system start-up

5. Details on starting Radiator during system start-up

Radiator AAA server is very reliable but it is possible that it is accidentally killed, or that a system problem causes it to exit. In a Unix environment, the preferred method is to use Linux deb or PKG packages and start and restart radiusd automatically with the systemd command. On Windows, you can run Radiator as a system service that will automatically start and restart.

For source code, custom and other advanced installations on Unix systems, see the subtopics in this chapter. There are a number of ways to make Radiator to start at system start-up and make it restart in case of problems.

Sometimes you may need to update Radiator start-up, for example, to enable advanced debugging. See the subtopics for more details on how to do this.

Attention

The commands to set up the different start-up methods vary between systems. Most likely you need to customise the methods for your system.

5.1. Systemd service unit file

The Radiator deb and RPM distributions are designed to use systemd service unit files. The default installation and its systemd configuration is described in installation section. Copies of the service unit files are also available in directory /opt/radiator/radiator/goodies/

When you need to locally customise the unit file settings, do not directly edit Radiator's files in /usr/lib/systemd/system. The local customisations, also called drop-in files, should go into /etc/systemd/system/radiator.service.d/ directory. For example:

% cat /etc/systemd/system/radiator.service.d/stdout-stderr.conf
[Service]
# Standard output and error can be connected (redirected) to a file
# instead the usual default of journal
StandardOutput=file:/var/log/radiator/radiator-stdout.log
StandardError=file:/var/log/radiator/radiator-stderr.log

The above changes systemd behaviour to capture stdout and stderr and write them to separate files in the log directory. This allows for easier capture of LDAP level debugging that is not visible for Radiator, as described in Section 3.9.11. Debug and Section 3.9.12. DebugTLS

The locally created drop-in file must end with the suffix .conf. Before using a new drop-in file, systemd likely requires '

systemctl
                     daemon-reload

' command.

See the copies of service unit files in directory /opt/radiator/radiator/goodies/ for additional customisation options, such as allowing Radiator to access the privileged winbidd socket for

AuthBy
                     NTLM

5.2. System Service on Windows

On Windows you can configure Radiator to run as a Windows Service. It is automatically started at boot time, and you can start, stop, and pause it is the Services window, also know as the MMC Services snap-in. This is the preferred way to get Radiator to run automatically every time the Windows server is started.

Review the Windows Perl and Radiator installation instructions. Make sure you have Win32::Daemon Perl module installed.
Start a Command Prompt window. Adjust the paths below for your Perl installation. Create the Radiator service with:
```
perl c:\perl64\bin\radiusd -install
```
This installs Radiator as a Windows Service so that it uses the default configuration file in C:\Program Files\Radiator\radius.cfg
Open the Services snap-in. You see Radiator Radius Server as one of the available services. Using the Services window you can start, stop, pause, and disable the Radiator service.
Start the Service.
Test that the Service is running correctly by sending a test request with
```
perl c:\perl64\bin\radpwtst -user mikem -password fred
```
Edit and test the configuration in C:\Program Files\Radiator\radius.cfg. You need to restart the Radiator service using the Services control panel after making any changes to the configuration file in order for the change to take effect.
Next time the computer reboots, the Radiator Service starts automatically.

Tip

Radiator runs successfully as a service if it runs properly using the same command line that you used during the installation testing. Try running Radiator from the root directory of the C: drive with something like perl c:\perl64\bin\radiusd. Since a Windows service has no “current directory” or “Current drive”, you must be very sure that your Radiator configuration file contains no relative file names. Every file name mentioned must be a fully qualified path name, including the drive name, such as.:

DbDir       C:\Program Files\Radiator

Tip

A Windows Service usually runs as the System User, not as a logged-in user. To run as a Service, configure your Radiator so that it does not rely on remote shares and other things that may not be accessible to the System User. Generally, this means that all Radiator configuration files, the Radiator program, and the like must be on the local disk.

5.3. Unix SYSV startup script

The Radiator distribution contains a Unix/Linux SYSV compatible startup script in goodies/linux-radiator.init.

To use this script to start and stop Radiator by hand or automatically at boot time, on Linux as root. Note that the exact location and command to enable the script may vary between different systems:

cp goodies/linux-radiator.init /etc/init.d/radiator
chmod 755 /etc/init.d/radiator
chkconfig -add radiator

This startup script responds to the following commands:

/etc/init.d/radiator start
Starts the Radiator server running in the background as a service. This is the default command which will be used to start Radiator automatically at boot time when the startup script is automatically run.
/etc/init.d/radiator stop
Stop the Radiator server.
/etc/init.d/radiator restart
Stop then restart the Radiator server.
/etc/init.d/radiator reload
Forces the Radiator server to reread its configuration file. It does this by sending a HUP signal to the server.
/etc/init.d/radiator status
Prints the current status of the Radiator server process.
/etc/init.d/radiator traceup
Increases the current Radiator server Trace level by one. It does this by sending a USR1 signal to the server.
/etc/init.d/radiator tracedown
Decreases the current Radiator server Trace level by one. It does this by sending a USR2 signal to the server.

5.4. Using restartWrapper

In a Unix environment, you can arrange for radiusd to be restarted automatically if it exits unexpectedly by using the restartWrapper script. restartWrapper is included in the goodies/ directory of the Radiator distribution. It is not installed automatically, so if you want to use it, you will probably want to copy it to your local binaries directory. Radiator must be run in the foreground with the Foreground parameter or the -foreground argument. For more information, see Section 3.7.1. Foreground.

restartWrapper never terminates, so you will probably want to run it in the background with an ampersand (&), especially if you are calling it from a system boot script.

You will probably want to put a call to restartWrapper in your Unix system boot script so that radiusd is started automatically at boot time by restartWrapper. This will usually involve modifying /etc/rc.local or adding a new script to /etc/rc2.d, depending on what type of Unix you are running. See your system documentation for more details about system start-up scripts.

The arguments are:

restartWrapper [-h] [-delay n] [-mail address] 
      [-min_interval n (default: 0)]
      [-sendmail path-to-sendmail] 
      [-syslog facility.level (default: user.err)]
      [-logger path-to-logger (default: /usr/bin/logger)]
      "command to run"

-h
Print usage help message.
-delay n
Number of seconds to wait before restarting the command. Defaults to 10 seconds.
-min_interval n
Minimum interval in seconds between successive restart. Defaults to 0 seconds.
-mail address
The email address to send a message to when the command exits. By default, no email is sent.
-sendmail path-to-sendmail
Specifies an alternate path to the sendmail program which will be used to send email if the -mail argument is specified. Defaults to /usr/lib/sendmail.
-syslog facility.level
Specifies an optional syslog facility and level to be used to log messages using syslog. If this is not specified, syslog will not be used to log messages.
-logger path-to-logger
Specifies the syslog logger program which will be used to log syslog messages. Defaults to /usr/bin/logger.
"command to run"
This is the complete command that is to be run, including arguments if any. You should enclose the entire command in double quotes, especially if the command contains arguments that might be mistaken for arguments to restartWrapper. You will probably want to specify the full path to the command.

Example

Run radiusd with a specified config file. If it stops, send email to mikem@open.com.au and wait 2 seconds before restarting it.

restartWrapper -mail mikem@open.com.au -delay 2 \
      "/bin/radiusd -config_file /etc/radius.cfg \
      -foreground" &

Tip

Make sure that Radiator is running in “foreground” mode, either with -foreground in the command line arguments, or with Foreground the configuration file.

Tip

If you are starting restartWrapper from inside a Unix startup script, you will need to follow the command line with an ampersand (&), otherwise the unix startup script will never complete.

5.5. Using inetd

If you do not wish to use restartWrapper or init, you can instead arrange for the Unix inetd(1) super server to start radiusd the first time it is required (and to restart it if it stops unexpectedly). In order to do this, you must add a new line to the inetd configuration file (usually /etc/inetd.conf). You must also ensure that the radius port number you wish to use is configured into the /etc/services file. You must also ensure that Radiator is configured to run in the foreground with the Foreground parameter or the -foreground argument. For more information, see Section 3.7.1. Foreground.

The inetd line you add will look something like this (the line has been wrapped due to its length in this example):

# Start Radiator on demand
radius dgram udp wait root /bin/radiusd radiusd 
      -config_file /etc/radius.cfg
      -foreground

After changing /etc/inetd.conf, you will need to tell inetd to reread its configuration file by sending it a HUP signal with something like

kill -HUP pid-of-inetd

Whenever a radius request is received and radiusd is not already running, inetd will automatically start radiusd. If radiusd stops some time later, inetd will restart it when the next request arrives. For more details on using and configuring inetd, consult your Unix vendor's documentation.

Tip