Update sections in 3.0 are considerably more powerful than 2.x.x
In addition to being able to override lists on an attribute by attribute basis,
e.g:
update {
request:foo = 'bar'
}
You can also perform full list copies:
update {
request: += &reply:
}
Filtered list copies (all instance of attribute in a list)
update {
request: += &reply:foo
}
Reference attributes:
update {
request:foo += &reply:foo
}
and perform both types of program execution:
update {
request:foo := `<my program>` # foo is assigned the output of my program
}
update {
request: := `<my program>` # any VALUE_PAIRs returned by my program are
added to the request list
}
Update sections may now also return fail.
(0) update {
(0) Executing: "/tmp/foo %{User-Name}"
(0) expand: "%{User-Name}" -> 'foo'
(0) Program returned code (2): Failed to execute "/tmp/foo": No such file or
directory
(0) ERROR: Failed to execute "/tmp/foo": No such file or directory
(0) } # update = fail
In which case subsequent statements are not executed. As with modules failure
this can be checked with if (fail).
Update sections are no longer atomic as a whole. But individual statements are.
That is if a statement fails, all VALUE_PAIRs created up to the point of the
failure are discarded.
We may be able to restore atomicity of update sections once sets and lists are
implemented in 3.1. If you absolutely require it in 3.0 you can wrap each
statement in it's own update section and check for failure.
-Arran
Arran Cudbard-Bell <a.cudba...@freeradius.org>
FreeRADIUS Development Team
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
