Ascfile is a module that can read Livingston-style clients, users,
realms, hints and huntgroups files and possibly many other ASCII tables
that use lines or paragraphs as records and whitespace- or comma separated
A/V pairs or bare values as fields. It uses a hash table to provide fast
lookups, even for large numbers of records.
Usage:
The module is to be run from OpenRADIUS using an interface definition
like this:
The 'Ascii' and 'Short-Attr' flags are required for any interface that
uses this module.
The module only uses the 'str' attribute from requests sent to it; the
sendattr ACL is specified for efficiency only.
All files specified on the comand line after the options are read into
memory at startup. Note however that all are read into the same data
structure, so the files are effectively concatenated.
Options:
The following command line options are provided:
-s
Read records as single lines. Without this flag, records are not
ended until the module sees an empty line (paragraph end).
[removed in 0.9.4; paragraphs are started by non-comment lines that
start in the first column instead of ended by empty lines.]
-d
Output debugging messages on standard error (fd 2, which can
be redirected by OpenRADIUS using '-o').
File format:
Comments are started by a # and ended by a newline.
A record consists of a key, followed by whitespace, followed by a series of
A/V items, each separated by a comma or whitespace; the record is ended
by a newline (-s flag) or when an empty line is encountered (without -s).
Multiple records having the same key are effectively concatenated.
An A/V item can either be a bare value or a full A/V pair. A bare value will
get the attribute 'int' if the value seems numeric, 'ip' if the value is an IP
address, and 'str' otherwise, to form complete pairs.
Strings that contain whitespace or commas must be quoted in double quotes.
Double quotes within quoted strings can be escaped by prepending a backslash.
All other characters and escape sequences in quoted strings are sent as-is and
are treated by OpenRADIUS according to the ASCII interface specification; see
the module interface, paragraph 3.2.
Operation:
The module uses the first 'str' attribute from the request as its key, and
*returns all pairs* associated with that key. That means it doesn't handle
check items the way you're used to; it doesn't match them to the request
but just returns them.
If you want to compare items, and use a different key such as 'DEFAULT' upon
mismatch, you can add a rule to do that in the behaviour file. If you have
a series of DEFAULT items, each with a check item that is the real key
Framed, etc., you should rewrite it as as keyed on that item. This is
much more efficient, and OpenRADIUS gives you the flexibility to have
'users' files keyed on anything, so why not take advantage of it?
This module could have been written to deal with check items the way you're
used to - but I feel that the type of logic that is needed there shouldn't
be placed outside the behaviour file in most cases. Also, most files will be
oriented on a single key anyway, so they can be easily rewritten.
If you'd really need to have two keys, a users-type of file isn't the best
solution anyway, because you end up with n x m entries that will probably all
be quite similar. It's probably better to split the information across two
tables. If you cannot, you can merge your check items into the key, like
steve:23555443:3, and call the module from the behaviour file like this:
Ascfile(str=User-Name . ":" . Calling-Station-Id . ":" . Service-Type)
After answering each request, the module checks if any of the files are
newer than when they were last read, and if so, it rereads all.
(Not implemented yet; just kill the module when you change any of its
files - OpenRADIUS will restart it automatically).
Distribution:
This standard module is included with the server and installed by default.