1unlang(5) FreeRADIUS Processing un-language unlang(5)
2
6 unlang - FreeRADIUS Processing un-language
7
9 FreeRADIUS supports a simple processing language in its configuration
10 files. We call it an "un-language" because the intention is NOT to
11 create yet another programming language. If you need something more
12 complicated than what is described here, we suggest using the Perl or
13 Python modules rlm_perl, or rlm_python.
14 The goal of the language is to allow simple policies to be written with
16 minimal effort. Those policies are then applied when a request is
17 being processed. Requests are processed through virtual servers
18 (including the default one), in the sections titled "authorize",
19 "authenticate", "post-auth", "preacct", "accounting", "pre-proxy",
20 "post-proxy", and "session".
21 These policies cannot be used in any other part of the configuration
23 files, such as module or client configuration.
24
26 The keywords for the language are a combination of pre-defined key‐
27 words, and references to loadable module names. We document only the
28 pre-defined keywords here.
29 Subject to a few limitations described below, any keyword can appear in
31 any context. The language consists of a series of entries, each one
32 one line. Each entry begins with a keyword. Entries are organized
33 into lists. Processing of the language is line by line, from the start
34 of the list to the end. Actions are executed per-keyword.
35 module-name[.section-name]
37 A reference to the named module. When processing reaches this
38 point, the pre-compiled module is called. The module may suc‐
39 ceed or fail, and will return a status to "unlang" if so. This
40 status can be tested in a condition. See the "Simple Condi‐
41 tions" text in the CONDITIONS section, and MODULE RETURN CODES,
42 below. If a section-name is provided, it will cause the module
43 to execute as if it were listed in the named section.
44 chap # call the CHAP module
46 sql # call the SQL module
47 ...
48 if
50 Checks for a particular condition. If true, the block after the
51 condition is processed. Otherwise, the block is ignored. See
52 CONDITIONS, below, for documentation on the format of the condi‐
53 tions.
54 if (condition) {
56 ...
57 }
58 else
60 Define a block to be executed only if the previous "if" condi‐
61 tion returned false.
62 else {
64 ...
65 }
66 elsif
68 Define a block to be executed only if the previous "if" condi‐
69 tion returned false, and if the specified condition evaluates to
70 true.
71 elsif (condition) {
73 ...
74 }
75 foreach
77 Loops over values of an attribute, running the block for each
78 value. The return value of the block is the return value of the
79 last statement executed. The loop can be exited early by using
80 the "break" keyword. Unlike other languages, "break" here means
81 "exit the loop at the next iteration", not "exit the loop now".
82 The result is that any statements after the "break" keyword will
83 still be executed. We recommend using "break" only when it is
84 the last statement in a "foreach" block.
85 Inside of the "foreach" block, the attribute which is being
87 looped over can be referenced as "Foreach-Variable-#". Where
88 "#" is the depth of the loop, starting at "0". e.g. "Foreach-
89 Variable-0". The loops can be nested up to eight (8) deep,
90 though this is not recommended.
91 foreach &Attribute-Reference {
93 ...
94 }
95 switch
97 A "switch" statement takes one argument, and contains a series
98 of "case" statements. When a "switch" statement is encountered,
99 the argument from the "switch" is evaluated in turn against the
100 argument from each "case" statement. The first "case" statement
101 which matches is executed. All other "case" statements are
102 ignored. A default "case" statement can be defined, by omitting
103 its argument.
104 If the argument is a double quoted string (e.g. "%{exec:1 + 2}",
106 it is expanded as described in the DATA TYPES section, below.
107 The match is then performed on the string returned from the
108 expansion. If the argument is an attribute reference (e.g.
109 &User-Name), then the match is performed on the value of that
110 attribute. Otherwise, the argument is taken to be a literal
111 string, and and matching is done via simple comparison.
112 No statement other than "case" can appear in a "switch" block.
114 switch <argument> {
116 ...
117 }
118 case
120 Provides a place-holder which matches the argument of a parent
121 "switch" statment.
122 A "case" statement cannot appear outside of a "switch" block.
124 If the argument is a double quoted string (e.g. "%{exec:1 + 2}",
126 it is expanded as described in the DATA TYPES section, below.
127 The match is then performed on the string returned from the
128 expansion. If the argument is an attribute reference (e.g.
129 &User-Name), then the match is performed on the value of that
130 attribute. Otherwise, the argument is taken to be a literal
131 string, and and matching is done via simple comparison.
132 case <argument> {
134 ...
135 }
136 A default entry can be defined by omitting the argument, as
138 given below. This entry will be used if no other "case" entry
139 matches. Only one default entry can exist in a "switch" sec‐
140 tion.
141 case {
143 ...
144 }
145 update
147 Update a particular attribute list, based on the attributes
148 given in the current block.
149 update <list> {
151 &Attribute-Reference = value
152 ...
153 }
154 The <list> can be one of "request", "reply", "proxy-request",
156 "proxy-reply", "coa", "disconnect", "session-state", or "con‐
157 trol". As of Version 3, the <list> can be omitted, in which
158 case "request" is assumed.
159 The "control" list is the list of attributes maintainted inter‐
161 nally by the server that controls how the server processes the
162 request. Any attribute that does not go in a packet on the net‐
163 work will generally be placed in the "control" list.
164 For EAP methods with tunneled authentication sessions (i.e. PEAP
166 and EAP-TTLS), the inner tunnel session can also reference
167 "outer.request", "outer.reply", and "outer.control". Those ref‐
168 erences allow you to address the relevant list in the outer tun‐
169 nel session.
170 The "coa" and "disconnect" sections can only be used when the
172 server receives an Access-Request or Accounting-Request. Use
173 "request" and "reply" instead of "coa" when the server receives
174 a CoA-Request or Disconnect-Request packet.
175 Adding one or more attributes to either of the "coa" or "discon‐
177 nect" list causes server to originate a CoA-Request or Discon‐
178 nect-Request packet. That packet is sent when the current
179 Access-Request or Accounting-Request has been finished, and a
180 reply sent to the NAS. See raddb/sites-available/originate-coa
181 for additional information.
182 The "session-state" list is primarily used for EAP. Attributes
184 put into the "session-state" list are saved for the next packet
185 in the session. They are automatically retrieved when the next
186 packet is received.
187 The only contents permitted in an "update" section are
189 attributes and values. The contents of the "update" section are
190 described in the ATTRIBUTE REFERENCE and ATTRIBUTE ASSIGNMENT
191 sections below.
192 redundant
194 This section contains a simple list of modules. The first mod‐
195 ule is called when the section is being processed. If the first
196 module succeeds in its operation, then the server stops process‐
197 ing the section, and returns to the parent section.
198 If, however, the module fails, then the next module in the list
200 is tried, as described above. The processing continues until
201 one module succeeds, or until the list has been exhausted.
202 Redundant sections can contain only a list of modules, and can‐
204 not contain keywords that perform conditional operations (if,
205 else, etc) or update an attribute list.
206 redundant {
208 sql1 # try this
209 sql2 # try this only if sql1 fails.
210 ...
211 }
212 load-balance
214 This section contains a simple list of modules. When the sec‐
215 tion is entered, one module is chosen at random to process the
216 request. All of the modules in the list should be the same type
217 (e.g. ldap or sql). All of the modules in the list should
218 behave identically, otherwise the load-balance section will
219 return different results for the same request.
220 Load-balance sections can contain only a list of modules, and
222 cannot contain keywords that perform conditional operations (if,
223 else, etc) or update an attribute list.
224 load-balance {
226 ldap1 # 50% of requests go here
227 ldap2 # 50% of requests go here
228 }
229 In general, we recommend using "redundant-load-balance" instead
231 of "load-balance".
232 redundant-load-balance
234 This section contains a simple list of modules. When the sec‐
235 tion is entered, one module is chosen at random to process the
236 request. If that module succeeds, then the server stops pro‐
237 cessing the section. If, however, the module fails, then one of
238 the remaining modules is chosen at random to process the
239 request. This process repeats until one module succeeds, or
240 until the list has been exhausted.
241 All of the modules in the list should be the same type (e.g.
243 ldap or sql). All of the modules in the list should behave
244 identically, otherwise the load-balance section will return dif‐
245 ferent results for the same request.
246 Load-balance sections can contain only a list of modules, and
248 cannot contain keywords that perform conditional operations (if,
249 else, etc) or update an attribute list. Please see
250 raddb/radiusd.conf "instantiate" section for more configuration
251 examples.
252 redundant-load-balance {
254 ldap1 # 50%, unless ldap2 is down, then 100%
255 ldap2 # 50%, unless ldap1 is down, then 100%
256 }
257 return
260 Returns from the current top-level section, e.g. "authorize" or
261 "authenticate". This keyword is mainly used to avoid layers of
262 nested "if" and "else" statements.
263 authorize {
265 if (...) {
266 ...
267 return
268 }
269 ... # this is never reached when the "if"
270 ... # statement is executed
271 }
272
274 Attributes may be referenced via the following syntax: &Attribute-
275 Name &Attribute-Name:TAG &Attribute-Name[NUM]
276 &<list>:Attribute-Name &<list>:Attribute-Name:TAG[NUM] Where
277 <list> is one of "request", "reply", "control", "proxy-request",
278 "proxy-reply", or "outer.request", "outer.reply", "outer.control",
279 "outer.proxy-request", or "outer.proxy-reply". just as with the
280 "update" section, above. The "<list>:" prefix is optional, and if
281 omitted, is assumed to refer to the "request" list.
282 The TAG portion is a decimal integer between 1 and 31. Please see RFC
284 2868 for more information about tags. Tags can only be used for
285 attributes which are marked in the dictionary as "has_tag".
286 The NUM portion is used when there are multiple attributes of the same
288 name in a list. The "Attribute-Name" reference will return the first
289 attribute. Using an array offset allows the policy to refer to the
290 second and subsequent attributes.
291 If '*' is used in the NUM portion, it evaluates to all instances of the
293 attribute in the request.
294 If 'n' is used in the NUM portion, it evaluates to the last instance of
296 the attribute in the request.
297 When an attribute name is encountered, the given list is examined for
299 an attribute of the given name. Some examples are: User-Name
300 request:User-Name # same as above
301 reply:User-Name
302 Tunnel-Password:1
303 Cisco-AVPAir[2]
304 outer.request:User-Name # from inside of a TTLS/PEAP tunnel Note
305 that unlike C, there is no way to define new attributes at run-time.
306 They MUST be declared in a dictionary file, and loaded when the server
307 starts.
308 All attributes are defined in the dictionaries that accompany the
310 server. These definitions define only the name and type, and do not
311 define the value of the attribute. When the server receives a packet,
312 it uses the packet contents to look up entries in the dictionary, and
313 instantiates attributes with a name taken from the dictionaries, and a
314 value taken from the packet contents. This process means that if an
315 attribute does not exist, it is usually because it was not contained in
316 a packet that the server received.
317 Once the attribute is instantiated, it is added to a list. It can then
319 be referenced, updated, replaced, etc.
320
323 The conditions are similar to C conditions in syntax, though quoted
324 strings are supported, as with the Unix shell.
325 Simple conditions
327 (foo)
328 Evalutes to true if 'foo' is a non-empty string (single quotes,
330 double quotes, or back-quoted). Also evaluates to true if 'foo'
331 is a non-zero number. Note that the language is poorly typed,
332 so the string "0000" can be interpreted as a numerical zero.
333 This issue can be avoided by comparings strings to an empty
334 string, rather than by evaluating the string by itself.
335 If the word 'foo' is not a quoted string, then it can be taken
337 as a reference to a named attribute. See "Referencing attribute
338 lists", below, for examples of attribute references. The condi‐
339 tion evaluates to true if the named attribute exists.
340 Otherwise, if the word 'foo' is not a quoted string, and is not
342 an attribute reference, then it is interpreted as a reference to
343 a module return code. The condition evaluates to true if the
344 most recent module return code matches the name given here.
345 Valid module return codes are given in MODULE RETURN CODES,
346 below.
347 Negation
349 (!foo)
350 Evalutes to true if 'foo' evaluates to false, and vice-versa.
352 Short-circuit operators
354 (foo || bar)
355 (foo && bar)
356 "&&" and "||" are short-circuit operators. "&&" evaluates the
358 first condition, and evaluates the second condition if and only
359 if the result of the first condition is true. "||" is similar,
360 but executes the second command if and only if the result of the
361 first condition is false.
362 Comparisons
364 (foo == bar)
365 Compares 'foo' to 'bar', and evaluates to true if the comparison
367 holds true. Valid comparison operators are "==", "!=", "<",
368 "<=", ">", ">=", "=~", and "!~", all with their usual meanings.
369 Invalid comparison operators are ":=" and "=".
370 Attribute Comparisons
372 (&User-Name == "foo")
373 Compares the value of the User-Name attribute to the string
375 'foo', and evaluates to true if the comparison holds true. The
376 comparison is done by printing the attribute to a string, and
377 then doing a string comparison of the two sides of the condi‐
378 tion.
379 Inter-Attribute Comparisons
381 (&User-Name == &Filter-Id)
382 Compares the value of the User-Name attribute to the contents of
384 the Filter-Id attribute, and evaluates to true if the comparison
385 holds true. Unlike the previous example, this comparison is
386 done in a type-safe way. For example, comparing the IP
387 addresses 1.2.3.4 and 127.0.0.1 as strings will return different
388 results than comparing them as IP addresses.
389 The "&" character in the condition means that the comparison
391 "refers" to the Filter-Id attribute. If left off, it means that
392 the User-Name attribute is compared to the literal string "Fil‐
393 ter-Id".
394 Where the left-hand side is an attribute, the "&" can be omit‐
396 ted. However, it is allowed for backwards compatibility. e.g.
397 The comparison "(&User-Name == &Filter-Id)" is equivalent to the
398 example above.
399 We recommend using attribute references instead of printing
401 attributes to a string, e.g. (User-Name == "%{Filter-Id}").
402 Attribute references will be faster and more efficient.
403 The conditions will check only the first occurance of an
405 attribute. If there is more than one instance of an attribute,
406 the following syntax should be used:
407 (&Attribute-Name[*] == "foo")
409 Using the "[*]" syntax means that it checks all of the instances
411 of the named attribute. If one attribute matches, the condition
412 succeeds. If none match, the condition fails.
413 Casts (<type>foo == bar)
416 The left-hand-side of a condition can be "cast" to a specific
418 data type. The data type must be one which is valid for the
419 dictionaries. e.g. "integer", "ipaddr", etc.
420 The comparison is performed in a type-safe way, as with "Inter-
422 Attribute Comparisons", above. Both sides of the condition are
423 parsed into temporary attributes, and the attributes compared
424 via type-specific methods. The temporary attributes have no
425 other effect, and are not saved anywhere.
426 Casting allows conditions to perform type-specific comparisons.
428 In previous versions of the server, the data would have to be
429 manually placed into an intermediate attribute (or attributes),
430 and then the attribute (or attributes) compared. The use of a
431 cast allows for simpler policies.
432 Casts are allowed only on the left-hand side argument of a con‐
434 dition.
435 Conditions may be nested to any depth, subject only to line length lim‐
437 itations (8192 bytes).
438
440 There are only a few data types supported in the language. Reference
441 to attributes, numbers, and strings. Any data type can appear in
442 stand-alone condition, in which case they are evaluated as described in
443 "Simple conditions", above. They can also appear (with some exceptions
444 noted below) on the left-hand or on the right-hand side of a compari‐
445 son.
446 numbers
448 Numbers are composed of decimal digits. Floating point, hex,
449 and octal numbers are not supported. The maximum value for a
450 number is machine-dependent, but is usually 32-bits, including
451 one bit for a sign value.
452 word
454 Text that is not enclosed in quotes is interpreted differently
455 depending on where it occurs in a condition. On the left hand
456 side of a condition, it is interpreted as a reference to an
457 attribute. On the right hand side, it is interpreted as a sim‐
458 ple string, in the same manner as a single-quoted string.
459 Using attribute references permits limited type-specific compar‐
461 isons, as seen in the examples below.
462 if (&User-Name == "bob") {
464 ...
465 if (&Framed-IP-Address > 127.0.0.1) {
466 ...
467 if (&Service-Type == Login-User) {
468 "strings"
470 Double-quoted strings are expanded by inserting the value of any
471 attributes (see VARIABLES, below) before being evaluated. If
472 the result is a number it is evaluated in a numerical context.
473 String length is limited by line-length, usually about 8000
475 characters. A double quote character can be used in a string
476 via the normal back-slash escaping method. ("like \"this\" !")
477 'strings'
479 Single-quoted strings are evaluated as-is. Their values are not
480 expanded as with double-quoted strings above, and they are not
481 interpreted as attribute references.
482 `strings`
484 Back-quoted strings are evaluated by expanding the contents of
485 the string, as described above for double-quoted strings. The
486 resulting command given inside of the string in a sub-shell, and
487 taking the output as a string. This behavior is much the same
488 as that of Unix shells.
489 Note that for security reasons, the input string is split into
491 command and arguments before string expansion is done.
492 For performance reasons, we suggest that the use of back-quoted
494 strings be kept to a minimum. Executing external programs is
495 relatively expensive, and executing a large number of programs
496 for every request can quickly use all of the CPU time in a
497 server. If you believe that you need to execute many programs,
498 we suggest finding alternative ways to achieve the same result.
499 In some cases, using a real language may be sufficient.
500 /regex/im
503 These strings are valid only on the right-hand side of a compar‐
504 ison, and then only when the comparison operator is "=~" or
505 "!~". They are regular expressions, as implemented by the local
506 regular expression library on the system. This is usually Posix
507 regular expressions.
508 The trailing 'i' is optional, and indicates that the regular
510 expression match should be done in a case-insensitive fashion.
511 The trailing 'm' is also optional, and indicates that carrot '^'
513 and dollar '$' anchors should match on new lines as well as at
514 the start and end of the subject string.
515 If the comparison operator is "=~", then parantheses in the reg‐
517 ular expression will define variables containing the matching
518 text, as described below in the VARIABLES section.
519
521 Attributes are expanded using the ATTRIBUTE REFERENCE syntax described
522 above, and surrounding the reference with "%{...}"
523 %{Attribute-Reference}
525 The result will be a string which contains the value of the attribute
527 which was referenced, as a printable string. If the attribute does not
528 exist, the result will be an empty string.
529 Results of regular expression matches
531 If a regular expression match has previously been performed,
532 then the special variable %{0} will contain a copy of the
533 matched portion of the input string. The variables %{1} through
534 %{32} will contain the substring matches, starting from the
535 left-most capture group, onwards. If there are more than 32
536 capture groups, the additional results will not be accessible.
537 If the server is built with libpcre, the results of named cap‐
538 ture groups are available using the "%{regex:capture group}"
539 expansion. They will also be accessible using the variables
540 described above. Every time a regular expression is evaluated,
541 whether it matches or not, the capture group values will be
542 cleared.
543 Obtaining results from databases
545 It is useful to query a database for some information, and to
546 use the result in a condition. The following syntax will call a
547 module, pass it the given string, and replace the string expan‐
548 sion with the resulting string returned from the module.
549 %{module: string ...}
551 The syntax of the string is module-specific. Please read the
553 module documentation for additional details.
554 Conditional Syntax
556 Conditional syntax similar to that used in Unix shells may also
557 be used.
558 %{%{Foo}:-bar}
560 If %{Foo} has a value, returns that value.
561 Otherwise, returns literal string "bar".
562 %{%{Foo}:-%{Bar}}
564 If %{Foo} has a value, returns that value.
565 Otherwise, returns the expansion of %{Bar}.
566 These conditional expansions can be nested to almost any
568 depth, such as with %{%{One}:-%{%{Two}:-%{Three}}}
569 String lengths and arrays
571 Similar to a Unix shell, there are ways to reference string
572 lengths, and the second or more instance of an attribute in a
573 list. If you need more than this functionality, we suggest
574 using a real language.
575 %{strlen:string}
577 The number of characters in "string". If "string" does
578 not exist, then the length also does not exist, instead
579 of being zero.
580 The "string" is expanded before the length is taken.
582 %{integer:Attribute-Name}
585 The integer value of the Attribute-Name, instead of the
586 enumerated name.
587 e.g. If a request contains "Service-Type = Login-User",
589 the expansion of %{integer:Service-Type} will yeild "1".
590 %{hex:Attribute-Name}
593 The hex value of the Attribute-Name, as a series of hex
594 digits.
595 e.g. If a request contains "Framed-IP-Address =
597 127.0.0.1", the expansion of %{hex:Framed-IP-Address}
598 will yeild "0x7f000001".
599 %{Attribute-Name[#]}
602 The number of instances of Attribute-Name.
603 e.g. If a request contains "User-Name = bob", the expan‐
605 sion of %{User-Name[#]} will yeild "1".
606 %{Attribute-Name[*]}
609 All values of Attribute-Name, concatenated together with
610 ',' as the separator.
611 %{List-Name:[#]}
614 The number of attributes in the named list.
615 %{List-Name:[*]}
618 All values of attributes in the named-list, concatenated
619 together with ',' as the separator. Use the %{pairs:}
620 xlat to get a list of attributes and values.
621 e.g. If a response contains "Reply-Message = 'Hello',
623 Reply-Message = 'bob' the expansion of "%{reply:Reply-
624 Message[*]} will yield "Hello\nbob"
625
628 The attribute lists described above may be edited by listing one or
629 more attributes in an "update" section. Once the attributes have been
630 defined, they may be referenced as described above in the VARIABLES
631 section.
632 The following syntax defines attributes in an "update" section. Each
634 attribute and value has to be all on one line in the configuration
635 file. There is no need for commas or semi-colons after the value.
636 Attribute-Reference = value
638 Attribute Reference
640 The Attribute-Reference must be a reference (see above), using a
641 name previously defined in a dictionary. If an undefined name
642 is used, the server will return an error, and will not start.
643 Operators
646 The operator used to assign the value of the attribute may be
647 one of the following, with the given meaning.
648 = Add the attribute to the list, if and only if an
650 attribute of the same name is not already present in that
651 list.
652 := Add the attribute to the list. If any attribute of the
654 same name is already present in that list, its value is
655 replaced with the value of the current attribute.
656 += Add the attribute to the tail of the list, even if
658 attributes of the same name are already present in the
659 list. When the right hand side of the expression resolves
660 to multiple values, it means add all values to the tail
661 of the list.
662 Enforcement and Filtering Operators
664 The following operators may also be used in addition to the ones
665 listed above. Their function is to perform enforcement or fil‐
666 tering on attributes in a list.
667 -= Remove all matching attributes from the list. Both the
669 attribute name and value have to match in order for the
670 attribute to be removed from the list.
671 == Keep all matching attributes. Both the attribute name
673 and value have to match in order for the attribute to
674 remain in the list.
675 Note that this operator is very different than the '='
677 operator listed above!
678 != Keep all attributes with matching name, and value not
680 equal to the given one.
681 < Keep all attributes having values less than the value
683 given here. Any larger value is replaced by the value
684 given here. If no attribute exists, it is added with the
685 value given here, as with "+=".
686 <= Keep all attributes having values less than, or equal to,
688 the value given here. Any larger value is replaced by
689 the value given here. If no attribute exists, it is
690 added with the value given here, as with "+=".
691 > Keep all attributes having values greater than the value
693 given here. Any smaller value is replaced by the value
694 given here. If no attribute exists, it is added with the
695 value given here, as with "+=".
696 >= Keep all attributes having values greater than, or equal
698 to, the value given here. Any smaller value is replaced
699 by the value given here. If no attribute exists, it is
700 added with the value given here, as with "+=".
701 !* Delete all occurances of the named attribute, no matter
703 what the value.
704 =~ Keep all attributes having values which match the given
706 regular expression. If no attribute matches, nothing
707 else is done.
708 !~ Keep all attributes having values which fail to match the
710 given regular expression. If no attribute matches, noth‐
711 ing else is done.
712 Values
714 The value can be an attribute reference, or an attribute-spe‐
715 cific string.
716 When the value is an an attribute reference, it must take the
718 form of "&Attribute-Name". The leading "&" signifies that the
719 value is a reference. The "Attribute-Name" is an attribute
720 name, such as "User-Name" or "request:User-Name". When an
721 attribute reference is used, both attributes must have the same
722 data type. For example, "User-Name := &NAS-Port" is invalid,
723 because "User-Name" is a string, and "NAS-Port" is an integer.
724 We recommend using the form "Attribute-1 = &Attribute-2" for
726 updates, instead of "Attribute-1 = "%{Attribute-2}". The first
727 version will copy the attribute data, no matter what its form.
728 The second version will print the Attribute-2 to a string, and
729 then parse it to create the value for Attribute-1. This second
730 version is slower and more fragile than the first one.
731 When the value is an attribute-specific string, it can be a
733 string, integer, IP address, etc. The value may be expanded as
734 described above in the DATA TYPES section, above. For example,
735 specifying "Framed-IP-Address = 127.0.0.1" will cause the
736 "Framed-IP-Address" attribute to be set to the IP address
737 "127.0.0.1". However, using "Framed-IP-Address := module to be
738 run with a string "127.0.0.1". The output of the "echo" module
739 will then be parsed as an IP address, and placed into the
740 Framed-IP-Address attribute.
741 This flexibility means that you can assign an IP address by
743 specifying it directly, or by having the address returned from a
744 database query, or by having the address returned as the output
745 of a program that is executed.
746 When string values are finally assigned to an attribute, they
748 can have a maximum length of 253 characters. This limit is due
749 in part to both protocol and internal server requirements. That
750 is, the strings in the language can be nearly 8k in length, say
751 for a long SQL query. However, the output of that SQL query
752 should be no more than 253 characters in length.
753
755 Other keywords in the language are taken from the names of modules
756 loaded by the server. These keywords are dependent on both the mod‐
757 ules, and the local configuration.
758 Some use keywords that are defined in the default configuration file
760 are:
761 fail Cause the request to be treated as if a database failure had
763 occurred.
764 noop Do nothing. This also serves as an instruction to the config‐
766 urable failover tracking that nothing was done in the current
767 section.
768 ok Instructs the server that the request was processed properly.
770 This keyword can be used to over-ride earlier failures, if the
771 local administrator determines that the faiures are not cata‐
772 strophic.
773 reject Causes the request to be immediately rejected
775
777 When a module is called, it returns one of the following codes to
778 "unlang", with the following meaning.
779 notfound information was not found
781 noop the module did nothing
782 ok the module succeeded
783 updated the module updated the request
784 fail the module failed
785 reject the module rejected the request
786 userlock the user was locked out
787 invalid the configuration was invalid
788 handled the module has handled the request itself
789 These return codes can be tested for in a condition, as described above
791 in the CONDITIONS section.
792 See also the file doc/configurable_failover for additional methods of
794 trapping and modifying module return codes.
795
797 /etc/raddb/radiusd.conf
798
800 radiusd.conf(5), dictionary(5)
801
803 Alan DeKok <aland@deployingradius.com>
804 02 January 2016 unlang(5)