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.cudbardb@freeradius.org> FreeRADIUS Development Team
On 10/07/13 15:43, Arran Cudbard-Bell wrote:
Update sections may now also return fail.
Can you clarify - AIUI, sql xlat can now also distinguish between empty and fail, so if I do this: update { request:Tmp-String-0 := "%{sql:...}" } ...and the SQL server is down, the xlat will fail and the update section as a whole will fail? If so - very very cool.
On 10 Jul 2013, at 16:29, Phil Mayers <p.mayers@IMPERIAL.AC.UK> wrote:
On 10/07/13 15:43, Arran Cudbard-Bell wrote:
Update sections may now also return fail.
Can you clarify - AIUI, sql xlat can now also distinguish between empty and fail, so if I do this:
update { request:Tmp-String-0 := "%{sql:...}" }
...and the SQL server is down, the xlat will fail and the update section as a whole will fail? If so - very very cool. -
Yes. Errors bubble from sql_xlat up to the update section. If the value returned from the SQL statement is empty, a zero length attribute will be created, as with 2.x.x, provided that the statement completed successfully. To support the above, all xlat functions now return an ssize_t, where >= 0 is success (length of data written to buffer), and < 0 is failure. As of a couple of minutes ago, an update section will now return two RLM_* codes, RLM_MODULE_FAIL if something has actually failed and RLM_MODULE_INVALID if an attribute or list was referenced that doesn't exist in the current request. -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team
On 10 Jul 2013, at 23:59, Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:
On 10 Jul 2013, at 16:29, Phil Mayers <p.mayers@IMPERIAL.AC.UK> wrote:
On 10/07/13 15:43, Arran Cudbard-Bell wrote:
Update sections may now also return fail.
Can you clarify - AIUI, sql xlat can now also distinguish between empty and fail, so if I do this:
update { request:Tmp-String-0 := "%{sql:...}" }
...and the SQL server is down, the xlat will fail and the update section as a whole will fail? If so - very very cool. -
Yes. Errors bubble from sql_xlat up to the update section. If the value returned from the SQL statement is empty, a zero length attribute will be created, as with 2.x.x, provided that the statement completed successfully.
Ah, yes, and the reason for the failure will be available in Module-Failure-Msg, which is now pretty much always populated correctly as it's updated by the RERROR REDEBUG REDEBUG2 macros. Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team
participants (2)
-
Arran Cudbard-Bell -
Phil Mayers