The changes in today add "compile-time" validation, and evaluation of static values. For example: if (Session-Timeout < blue) { In v2, the server will start, and give run-time errors. In v3, the server will refuse to start, as "blue" is not a valid number. Even better, parts of the virtual servers can now be removed at start time: if (0) { sql ldap } When the contents of a condition are statically equivalent to false (e.g. 0), then the contents of the "if" block are completely ignored. It lets you have conditional parts of the configuration, which have zero run-time CPU or memory cost. Alan DeKok.
On 16 May 2013, at 17:51, Alan DeKok <aland@deployingradius.com> wrote:
The changes in today add "compile-time" validation, and evaluation of static values. For example:
if (Session-Timeout < blue) {
In v2, the server will start, and give run-time errors.
In v3, the server will refuse to start, as "blue" is not a valid number.
Even better, parts of the virtual servers can now be removed at start time:
if (0) { sql ldap }
When the contents of a condition are statically equivalent to false (e.g. 0), then the contents of the "if" block are completely ignored. It lets you have conditional parts of the configuration, which have zero run-time CPU or memory cost.
The idea being that you can reference other things in your conditions like environmental variables, or other configuration items and enable or disable blocks of policy code. Regular expressions should work too, as should all of the casting previously discussed. The idea is to allow something like: if (<cidr>$ENV{HOSTNAME} == 192.168/24) { // slight variation in policy } else if (<cidr>$ENV{hostname} == 172.0/24) { // other slight variation in policy } or if ($ENV{HOSTNAME} =~ /*.[.]cluster_x.example.org$/) { // slight variation in policy } else if ($ENV{hostname} =~ /*.[.]cluster_y.example.org$/) { // other slight variation in policy } So if you're deploying the same OS image to multiple virtual machines or multiple clusters, and require slight variations in policy, you can now do that extremely efficiently. HUP will cause the config to be re-read, re-parsed and so re-evaluate all the pre-evaluated conditions. Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team
Alan DeKok, 16.05.2013 23:51:
The changes in today add "compile-time" validation, and evaluation of static values. For example:
if (Session-Timeout < blue) {
Is there any difference (functional or performance-wise) between this and the previously posted form with the ampersand, i.e. "if (&Session-Timeout < ..."?
Even better, parts of the virtual servers can now be removed at start time:
So it seem there's quite a lot of good stuff coming :) Btw, if you are still looking for more ideas, what about this: - ternary logic, like C's "condition ? yes : no" This would save a bunch of lines, because instead of if (some condition) { update reply { Some-Attribute := "foo" Session-Timeout := 600 } } else { update reply { Some-Attribute := "bar" Session-Timeout := 600 } } we could do a simple and short update reply { Some-Attribute := (some condition) ? "foo" : "bar" } Not sure how easy this is to parse, though. Maybe something like "%{cond ? true : false}" would be better. - regex-like comparison operators E.g. =^ and =$ would be true if the LHS starts/ends with the RHS string. I.e., ( "foobar" =^ "foo") -> true ( "foobar" =^ "bar") -> false ( "foobar" =$ "foo") -> false ( "foobar" =$ "bar") -> true This would elimate the need for a lot of regex matches. I never looked into the unlang code, but if I find the time, I could try to implement it myself, but probably not for 2.x, now that 3.x is upcoming. Regards Jakob
Jakob Hirsch wrote:
So it seem there's quite a lot of good stuff coming :)
Yeah.
Btw, if you are still looking for more ideas, what about this:
- ternary logic, like C's "condition ? yes : no"
That's hard. Mostly because the configuration file parser is bad.
Not sure how easy this is to parse, though. Maybe something like "%{cond ? true : false}" would be better.
Hmm... that may be easier to do.
- regex-like comparison operators E.g. =^ and =$ would be true if the LHS starts/ends with the RHS string. I.e.,
( "foobar" =^ "foo") -> true ( "foobar" =^ "bar") -> false ( "foobar" =$ "foo") -> false ( "foobar" =$ "bar") -> true
This would elimate the need for a lot of regex matches.
Sure... but regex matches work for now. Alan DeKok.
On 17 May 2013, at 08:33, Alan DeKok <aland@deployingradius.com> wrote:
Jakob Hirsch wrote:
So it seem there's quite a lot of good stuff coming :)
Yeah.
Btw, if you are still looking for more ideas, what about this:
- ternary logic, like C's "condition ? yes : no"
That's hard. Mostly because the configuration file parser is bad.
Not sure how easy this is to parse, though. Maybe something like "%{cond ? true : false}" would be better.
Hmm... that may be easier to do.
*sigh*, please no, no pointless variations, this isn't Perl.
- regex-like comparison operators E.g. =^ and =$ would be true if the LHS starts/ends with the RHS string. I.e.,
( "foobar" =^ "foo") -> true ( "foobar" =^ "bar") -> false ( "foobar" =$ "foo") -> false ( "foobar" =$ "bar") -> true
This would elimate the need for a lot of regex matches.
Sure... but regex matches work for now.
and the new xlat parser may eventually allow pre-compilation of static expressions so the performance hit should go down significantly. Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team
participants (3)
-
Alan DeKok -
Arran Cudbard-Bell -
Jakob Hirsch