Using configuration and run-time variables
Goal: To use run-time variable expansion.
Time: 15-30 minutes.
Files:
-
etc/raddb/radiusd.conf
-
etc/raddb/users
-
etc/raddb/mods-available/detail
man
page: radiusd.conf
documentation page: Dynamic expansions
There are two kinds of variables within the server. The first is within
radiusd.conf
and related files. These variables are referenced via the
$
character, which is used to define common terms (e.g. ${logdir}
so that
those terms do not have to be repeated multiple times in the
configuration files. These variables are used only when the server reads
the configuration files, and they cannot be updated or edited once the files
have been read.
The second kind of variable is a run-time variable, which is dynamically
expanded for each request received by the server. These variables are
referenced by the %
character, and they may be used to pull the values of
attributes from the request to be used by a module. These variables may
also be used by one module to obtain information from another module.
In this exercise, we cover configuration variables and some simple properties of the run-time variables. Later exercises cover additional properties of the run-time variables.
The main configuration file radiusd.conf
and the module configuration
files contains a number of examples of the use of variables. For example,
the detail
module (configured in etc/raddb/mods-enabled/detail
)
has a configuration entry named "filename", which by default has the
following value:
filename = ${radacctdir}/%{Net.Src.IP}/detail-%Y%m%d
The configuration entry is composed of two kinds of variable expansion.
One references the ${radacctdir}
configuration variable, which was
previously defined in radiusd.conf
. The following variables are
expanded at run time and depend on information in the request packet
and other dynamically calculated data.
Start the server in debugging mode (radiusd -X
).
In the server output, look for the detail
module and the filename
configuration entry for that module. Verify that the string printed
for the filename
does not print the reference to the ${radacctdir}
variable, but instead has substituted the value of that variable.
Verify also that the values of the run-time variables have not
been substituted and that they are still printed as variables.
If you don’t see any configuration printed for the detail
file module
ensure it is uncommented in the accounting {}
section of the
raddb/sites-available/default
virtual server.
Now read the
variables
documentation file to determine the meaning of the variables used in the filename
configuration entry.
Once you are done, send the server an accounting packet (e.g.,
bob-acct-stop.sh
), and go look for the detail file, which will be
dynamically created. Verify that the contents of the file are the
accounting packet you just sent.
In addition to being used in the configuration files, run-time variables may also be used to create values for reply attributes. Stop the server, and edit the users file to add the following entry at the top:
bob Password.Cleartext := "hello" Reply-Message = "Hello %{User-Name}, your NAS port is %{NAS-Port}", Reply-Message += "at time %T"
Start the server, and run the bob-login-one.sh
script. Verify that the
Reply-Message
attributes contain the user name, NAS port, time, and a
copy of the Class
attribute from the reply.
Questions
-
Why are run-time variables useful?
-
How would you configure that entry in the file to reply with the directory name where the
radiusd.conf
file is stored? Why is this a bad idea? -
How would you create an entry in the users file that matched users when their
Class
was the same as theirNAS-Port
?