New subject: Bus error

13 Jun 2007


      I've updated the documentation for radiusd.conf, to document the new
"un-language".  Text is attached here for comment.

  Alan DeKok.
--
  http://deployingradius.com       - The web site of the book
  http://deployingradius.com/blog/ - The blog

unlang(5)              FreeRADIUS Processing un-language             unlang(5)


NAME
       unlang - FreeRADIUS Processing un-language

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  language  is similar to C in some respects, and is also similar to
       Unix shell scripts in other respects.  The keywords  for  the  language
       are  "if", "else", "elsif", "switch", "case", and "update".  Subject to
       some limitations below on "switch" and "case", any keyword  can  appear
       in any context.

KEYWORDS
       if
              Checks for a particular condition.  If true, the block after the
              condition is processed.  Otherwise, the block is ignored.

                   if (condition) {
                        ...
                   }

       else
              Define a block to be executed only if the previous  "if"  condi‐
              tion returned false.

                   else {
                        ...
                   }

       elsif
              Define  a  block to be executed only if the previous "if" condi‐
              tion returned false, and if the specified condition evaluates to
              true.

                   elsif (condition) {
                        ...
                   }

       switch
              Evaluate  the given string, and choose the first matching "case"
              statement inside of the current block.  No statement other  than
              "case" can appear in a "switch" block.

                   switch "string" {
                        ...
                   }

       case
              Define  a static string to match a parent "switch" statement.  A
              "case" statement cannot appear outside of a "switch" block.

                   case string {
                        ...
                   }

       update
              Update a particular attribute  list,  based  on  the  attributes
              given in the current block.

                   update <list> {
                        attribute = value
                        ...
                   }

              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 a detailed description of the contents of the "update"  sec‐
              tion, see the ATTRIBUTES section below.

CONDITIONS
       The  conditions  are  similar  to C conditions in syntax, though quoted
       strings are supported, as with the Unix shell.

       Simple conditions
                   (foo)

              Evalutes to true if ’foo’ is a non-empty string, or if ’foo’  is
              a non-zero number.

       Negation
                   (!foo)

              Evalutes to true if ’foo’ evaluates to false, and vice-versa.

       Short-circuit operators
                   (foo || bar)
                   (foo && bar)

              "&&"  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.

       Comparisons
                   (foo == bar)

              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 "=".

STRINGS AND NUMBERS
       Strings and numbers can appear as stand-alone conditions, 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.

       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.

       "strings"
              Double-quoted strings are expanded by inserting the value of any
              variables (see VARIABLES, below) before being evaluated.  If the
              result is a number it can be evaluated in a numerical context.

       ’strings’
              Single-quoted strings are evaluated as-is.

       ‘strings‘
              Back-quoted strings are evaluated by expanding the  contents  of
              the  string,  as described above for double-quoted strings.  The
              resulting command given inside of the string in a sub-shell, and
              taking  the  output as a string.  This behavior is much the same
              as that of Unix shells.

              Note that for security reasons, the input string is  split  into
              command and arguments before variable expansion is done.

              For  performance reasons, we suggest that the use of back-quoted
              strings be kept to a minimum.  Executing  external  programs  is
              relatively  expensive,  and executing a large number of programs
              for every request can quickly use all  of  the  CPU  time  in  a
              server.   If you believe that you need to execute many programs,
              we suggest finding alternative ways to achieve the same  result.
              In some cases, using a real language may be sufficient.

       /regex/i
              These strings are valid only on the right-hand side of a compar‐
              ison, and then only when the  comparison  operator  is  "=~"  or
              "!~".  They are regular expressions, as implemented by the local
              regular expression library on the system.  This is usually Posix
              regular expressions.

              The  trailing  ’i’  is  optional, and indicates that the regular
              expression match should be done in a case-insensitive fashion.

              If the comparison operator is "=~", then parantheses in the reg‐
              ular  expression  will  define variables containing the matching
              text, as described below in the VARIABLES section.

VARIABLES
       Run-time variables are referenced using the following syntax

            %{Variable-Name}

       Note that unlike C, there is no way to declare variables, or  to  refer
       to  them outside of a string context.  All references to variables MUST
       be contained inside of a double-quoted or back-quoted string.

       Many potential variables are defined in the dictionaries that accompany
       the  server.   These  definitions define only the name and type, and do
       not define the value of the  variable.   When  the  server  receives  a
       packet,  it  uses the packet contents to look up entries in the dictio‐
       nary, and instantiates variables with a name taken from the  dictionar‐
       ies,  and  a  value taken from the packet contents.  This process means
       that if a variable does not exist, it is usually  because  it  was  not
       mentioned in a packet that the server received.

       Once  the  variable  is  instantiated,  it  is  added to an appropriate
       attribute list, as described below.   In  many  cases,  attributes  and
       variables  are  inter-changeble,  and  are often talked about that way.
       However, variables can also refer to run-time calls to  modules,  which
       may  perform  operations  like  SQL  SELECTs,  and which may return the
       result as the value of the variable.

       Referencing attribute lists
              Attribute lists may be referenced via the following syntax

                   %{<list>:Attribute-Name}

              Where <list> is  one  of  "request",  "reply",  "proxy-request",
              "proxy-reply",  or "control", as described above in the documen‐
              tation for  the  "update"  section.   The  "<list>:"  prefix  is
              optional,  and  if omitted, is assumed to refer to the "request"
              list.

              When a variable is encountered, the given list is  examined  for
              an  attribute  of the given name.  If found, the variable refer‐
              ence in the string is replaced with the value of that attribute.
              Some examples are:

                   %{User-Name}
                   %{request:User-Name} # same as above
                   %{reply:User-Name}

       Results of regular expression matches
              If  a  regular  expression  match has previously been performed,
              then the special variable %{0} will contain a copy of the  input
              string.   The  variables %{1} through %{8} will contain the sub‐
              string matches, starting from  the  left-most  parantheses,  and
              onwards.   If  there are more than 8 parantheses, the additional
              results will not be placed into any variables.

       Obtaining results from databases
              It is useful to query a database for some  information,  and  to
              use the result in a condition.  The following syntax will call a
              module, pass it the given string, and replace the variable  ref‐
              erence with the resulting string returned from the module.

                   %{module: string ...}

              The  syntax  of  the string is module-specific.  Please read the
              module documentation for additional details.

       Conditional Syntax
              Conditional syntax similar to that used in Unix shells may  also
              be used.

              %{Foo:-bar}
                     When  attribute  Foo  is  set,  returns value of Foo When
                     attribute Foo is unset, returns literal string ’bar’


              %{Foo:-%{Bar}}
                     When attribute Foo is set, returns value of attribute Foo
                     When  attribute  Foo is unset, returns value of attribute
                     Bar (if any)


              %{Foo:-%{Bar:-baz}}
                     When attribute Foo is set, returns value of attribute Foo
                     When  attribute  Foo is unset, returns value of attribute
                     Bar (if any) When attribute Bar is unset, returns literal
                     string ’baz’

       String lengths and arrays
              Similar  to  a  Unix  shell,  there are ways to reference string
              lenths, and the second or more instance of  an  attribute  in  a
              list.  If you need this functionality, we recommend using a real
              language.

              %{#string}
                     The number of characters in %{string}.  If  %{string}  is
                     not set, then the length is not set.

                     e.g. %{#Junk-junk:-foo} will yeild the string "foo".

              %{Attribute-Name[index]}
                     Reference the N’th occurance of the given attribute.  The
                     syntax %{<list>:Attribute-Name[index]} may also be  used.
                     The indexes start at zero.  This feature is NOT available
                     for non-attribute dynamic translations, like  %{sql:...}.

                     For example, %{User-Name[0]} is the same as %{User-Name}

                     The  variable %{Cisco-AVPair[2]} will reference the value
                     of the THIRD Cisco-AVPair attribute (if it exists) in the
                     request packet,

              %{Attribute-Name[#]}
                     Returns  the  total  number of attributes of that name in
                     the relevant attribute list.  The number will usually  be
                     between 0 and 200.

                     For most requests, %{request:User-Name[#]} == 1

              %{Attribute-Name[*]}
                     Expands  to a single string, with the value of each array
                     member separated by a newline.

              %{#Attribute-Name[index]}
                     Expands  to  the  length  of  the   string   %{Attribute-
                     Name[index]}.

ATTRIBUTES
       The  attribute  lists  described  above may be edited by listing one or
       more attributes in an "update" section.  Once the attributes have  been
       defined,  they  may  be  referenced as described above in the VARIABLES
       section.

       The following syntax defines attributes in an "update"  section.   Each
       attribute  and  value  has  to  be all on one line in the configuration
       file.  There is no need for commas or semi-colons after the value.

            Attribute-Name = value

       Attribute names
              The Attribute-Name must be a name previously defined in  a  dic‐
              tionary.   If  an undefined name is used, the server will return
              an error, and will not start.

       Operators
              The operator used to assign the value of the  attribute  may  be
              one of the following, with the given meaning.

              =      Add  the  attribute  to  the  list,  if  and  only  if an
                     attribute of the same name is  already  present  in  that
                     list.

              :=     Add  the  attribute to the list.  If any attribute of the
                     same name is already present in that list, its  value  is
                     replaced with the value of the current attribute.

              +=     Add  the  attribute  to  the  tail  of  the list, even if
                     attributes of the same name are already  present  in  the
                     list.

              -=     Remove  all  matching attributes from the list.  Both the
                     attribute name and value have to match in order  for  the
                     attribute to be removed from the list.

       Values
              The  format of the value is attribute-specific, and is usually a
              string, integer, IP address, etc.  Prior to the attribute  being
              instantiated,  the  value  is  handled as described above in the
              STRINGS AND NUMBERS section.  This flexibility means  that,  for
              example,  you  can assign an IP address value to an attribute by
              specifying the IP address directly, or  by  having  the  address
              returned  from  a  database  query,  or  by  having  the address
              returned as the output of a program that is executed.

FILES
       /etc/raddb/vmpsd.conf, /etc/raddb/radiusd.conf

SEE ALSO
       radiusd.conf(5), vmpsd.conf(5), dictionary(5)

AUTHOR
       Alan DeKok <aland@deployingradius.com>


                                  12 Jun 2007                        unlang(5)

2.0.0 documentation for radiusd.conf.

Alan Dekok

Arran Cudbard-Bell

Alan Dekok

Arran Cudbard-Bell

Alan Dekok

Arran Cudbard-Bell

A.L.M.Buxey＠lboro.ac.uk

Alan Dekok

Arran Cudbard-Bell

Arran Cudbard-Bell

Arran Cudbard-Bell

Alan Dekok

Arran Cudbard-Bell

Alan Dekok

Alan Dekok

Arran Cudbard-Bell

A.L.M.Buxey＠lboro.ac.uk

Arran Cudbard-Bell

Arran Cudbard-Bell

Alan Dekok

Arran Cudbard-Bell

Arran Cudbard-Bell

Alan Dekok

tags

participants (3)