|[ < ]||[ > ]||[ << ]||[ Up ]||[ >> ]||[Top]||[Contents]||[Index]||[ ? ]|
The main deficiencies are inherited with the traditional configuration
file suite. The rules for processing each request are split among
three files, each of which is processed differently, despite of their
external similarity. The administrator has to keep in mind a set of
exotic rules when configuring the system(9). When matching incoming
requests with configuration file entries (LHS, see section Matching Rule), some attributes are taken verbatim, whereas others are used
radiusd behavior and to pass additional data to
other rules (see section Radius Internal Attributes). The things become even
more complicated when RADIUS realms come into play (see section Proxy Service). Some attributes are meaningful only if used in a certain
part of a certain configuration file rule.
So, while being a lot more flexible than the approach used by other RADIUS implementations, the current system is quite difficult to maintain.
Another deficiency is little control over actions executed on
different events. For example, it is often asked how can one
block a user account after a predefined number of authentication
failures? Currently this can only be done by writing an external
authentication procedure (either in Scheme, using Guile, or as
a standalone executable, using
proper solution would be to have a set of user-defined triggers
for every RADIUS event (in this case, for authentication failure).
Another commonly asked question is how to make
execute several SQL queries when processing a request.
While GNU Radius is not supposed to compensate for deficiencies
of some SQL implementations that do not allow for
nested queries, such a feature could come quite handy.
This document was generated by Sergey Poznyakoff on December, 6 2008 using texi2html 1.78.