unlang.5

使用最广泛的radius的linux的源码

.\"     # DS - begin display
.de DS
.RS
.nf
.sp
..
.\"     # DE - end display
.de DE
.fi
.RE
.sp
..
.TH unlang 5 "16 Jan 2008" "" "FreeRADIUS Processing un-language"
.SH NAME
unlang \- FreeRADIUS Processing un\-language
.SH DESCRIPTION
FreeRADIUS supports a simple processing language in its configuration
files.  We call it an "un-language" because the intention is NOT to
create yet another programming language.  If you need something more
complicated than what is described here, we suggest using the Perl or
Python modules rlm_perl, or rlm_python.

The goal of the language is to allow simple policies to be written
with minimal effort.  Those policies are then applied when a request
is being processed.
.SH KEYWORDS
The keywords for the language are a combination of pre-defined
keywords, and references to loadable module names.  We document only
the pre-defined keywords here.

Subject to a few limitations described below, any keyword can appear
in any context.  The language consists of a series of entries, each
one one line.  Each entry begins with a keyword.  Entries are
organized into lists.  Processing of the language is line by line,
from the start of the list to the end.  Actions are executed
per-keyword.
.IP module-name
A reference to the named module.  When processing reaches this point,
the pre-compiled module is called.  The module may succeed or fail,
and will return a status to "unlang" if so.  This status can be tested
in a condition.  See the "Simple Conditions" text in the CONDITIONS
section, and MODULE RETURN CODES, below.

.DS
	chap  # call the CHAP module
.br
	sql   # call the SQL module
.br
	...
.DE
.IP if
.br
Checks for a particular condition.  If true, the block after the
condition is processed.  Otherwise, the block is ignored.  See
CONDITIONS, below, for documentation on the format of the conditions.

.DS
	if (condition) {
.br
		...
.br
	}
.DE
.IP else
.br
Define a block to be executed only if the previous "if" condition
returned false.

.DS
	else {
.br
		...
.br
	}
.DE
.IP elsif
.br
Define a block to be executed only if the previous "if" condition
returned false, and if the specified condition evaluates to true.

.DS
	elsif (condition) {
.br
		...
.br
	}
.DE
.IP switch
.br
Evaluate the given string, and choose the first matching "case"
statement inside of the current block.  If the string is surrounded by
double quotes, it is expanded as described in the DATA TYPES section,
below.

No statement other than "case" can appear in a "switch" block.

.DS
	switch "string" {
.br
		...
.br
	}
.DE
.IP case
.br
Define a static string to match a parent "switch" statement.  The
strings given here are not expanded as is done with the parent
"switch" statement.

A "case" statement cannot appear outside of a "switch" block.

.DS
	case string {
.br
		...
.br
	}
.DE

A default entry can be defined by omitting the static string.  This
entry will be used if no other "case" entry matches.  Only one default
entry can exist in a "switch" section.

.DS
	case {
.br
		...
.br
	}
.DE
.IP update
.br
Update a particular attribute list, based on the attributes given in
the current block.

.DS
	update <list> {
.br
		attribute = value
.br
		...
.br
	}
.DE

The <list> can be one of "request", "reply", "proxy-request",
"proxy-reply", or "control".  The "control" list is the list of
attributes maintainted internally by the server that controls how the
server processes the request.  Any attribute that does not go in a
packet on the network will generally be placed in the "control" list.

For backwards compatibility with older versions, "check" is accepted
as a synonym for "control".  The use of "check" is deprecated, and
will be removed in a future release.

For EAP methods with tunneled authentication sessions (i.e. PEAP and
EAP-TTLS), the inner tunnel session can also reference
"outer.request", "outer.reply", and "outer.control".  Those references
allow you to address the relevant list in the outer tunnel session.

The only contents permitted in an "update" section are attributes and
values.  The contents of the "update" section are described in the
ATTRIBUTES section below.
.IP redundant
This section contains a simple list of modules.  The first module is
called when the section is being processed.  If the first module
succeeds in its operation, then the server stops processing the
section, and returns to the parent section.

If, however, the module fails, then the next module in the list is
tried, as described above.  The processing continues until one module
succeeds, or until the list has been exhausted.

Redundant sections can contain only a list of modules, and cannot
contain keywords that perform conditional operations (if, else, etc)
or update an attribute list.

.DS
	redundant {
.br
		sql1	# try this
.br
		sql2	# try this only if sql1 fails.
.br
		...
.br
	}
.DE
.IP load-balance
This section contains a simple list of modules.  When the section is
entered, one module is chosen at random to process the request.  All
of the modules in the list should be the same type (e.g. ldap or sql).
All of the modules in the list should behave identically, otherwise
the load-balance section will return different results for the same
request.

Load-balance sections can contain only a list of modules, and cannot
contain keywords that perform conditional operations (if, else, etc)
or update an attribute list.

.DS
	load-balance {
.br
		ldap1	# 50% of requests go here
.br
		ldap2	# 50% of requests go here
.br
	}
.DE

In general, we recommend using "redundant-load-balance" instead of
"load-balance".
.IP redundant-load-balance
This section contains a simple list of modules.  When the section is
entered, one module is chosen at random to process the request.  If
that module succeeds, then the server stops processing the section.
If, however, the module fails, then one of the remaining modules is
chosen at random to process the request.  This process repeats until
one module succeeds, or until the list has been exhausted.

All of the modules in the list should be the same type (e.g. ldap or
sql).  All of the modules in the list should behave identically,
otherwise the load-balance section will return different results for
the same request.

Load-balance sections can contain only a list of modules, and cannot
contain keywords that perform conditional operations (if, else, etc)
or update an attribute list.

.DS
	redundant-load-balance {
.br
		ldap1	# 50%, unless ldap2 is down, then 100%
.br
		ldap2	# 50%, unless ldap1 is down, then 100%
.br
	}
.DE
.SH CONDITIONS
The conditions are similar to C conditions in syntax, though
quoted strings are supported, as with the Unix shell.
.IP Simple
conditions
.br
.DS
	(foo)
.DE

Evalutes to true if 'foo' is a non-empty string (single quotes, double
quotes, or back-quoted).  Also evaluates to true if 'foo' is a
non-zero number.  Note that the language is poorly typed, so the
string "0000" can be interpreted as a numerical zero.  This issue can
be avoided by comparings strings to an empty string, rather than by
evaluating the string by itself.

If the word 'foo' is not a quoted string, then it can be taken as a
reference to a named attribute.  See "Referencing attribute lists",
below, for examples of attribute references.  The condition evaluates
to true if the named attribute exists.

Otherwise, if the word 'foo' is not a quoted string, and is not an
attribute reference, then it is interpreted as a reference to a module
return code.  The condition evaluates to true if the most recent
module return code matches the name given here.  Valid module return
codes are given in MODULE RETURN CODES, below.
.IP Negation
.DS
	(!foo)
.DE

Evalutes to true if 'foo' evaluates to false, and vice-versa.
.PP
Short-circuit operators
.RS
.br
.DS
	(foo || bar)
.br
	(foo && bar)
.DE

"&&" and "||" are short-circuit operators.  "&&" evaluates the first
condition, and evaluates the second condition if and only if the
result of the first condition is true.  "||" is similar, but executes
the second command if and only if the result of the first condition is
false.
.RE
.IP Comparisons
.DS
	(foo == bar)
.DE

Compares 'foo' to 'bar', and evaluates to true if the comparison holds
true.  Valid comparison operators are "==", "!=", "<", "<=", ">",
">=", "=~", and "!~", all with their usual meanings.  Invalid
comparison operators are ":=" and "=".
.PP
Conditions may be nested to any depth, subject only to line length
limitations (8192 bytes).
.SH DATA TYPES
There are only a few data types supported in the language.  Reference
to attributes, numbers, and strings.  Any data type can appear in
stand-alone condition, in which case they are evaluated as described
in "Simple conditions", above.  They can also appear (with some
exceptions noted below) on the left-hand or on the right-hand side of
a comparison.
.IP Numbers
Numbers are composed of decimal digits.  Floating point, hex, and
octal numbers are not supported.  The maximum value for a number is
machine-dependent, but is usually 32-bits, including one bit for a
sign value.
.PP
word
.RS
Text that is not enclosed in quotes is interpreted differently
depending on where it occurs in a condition.  On the left hand side of
a condition, it is interpreted as a reference to an attribute.  On the
right hand side, it is interpreted as a simple string, in the same
manner as a single-quoted string.

Using attribute references permits limited type-specific comparisons,
as seen in the examples below.

.DS