Hi, Not a show stopper, but it seems doing a comparision on 'check:...' in unlang does not work (however using 'control:...' does): ---- ldap-lanwarden if (ok) { if (check:LanWarden-Host-State != "enable") { update reply { Reply-Message := "LW: disabled" } reject } .... } ---- The above results in: ---- [ldap_lanwarden2] No default NMAS login sequence [ldap_lanwarden2] looking for check items in directory... [ldap_lanwarden2] owner -> LanWarden-Host-Owner == "cn=ac56,ou=Staff,ou=Active,ou=Accounts,o=soas" [ldap_lanwarden2] lanwardenHostAuthenticateMethod -> LanWarden-Host-Auth-Method == "none" [ldap_lanwarden2] lanwardenHostState -> LanWarden-Host-State == "enable" [ldap_lanwarden2] looking for reply items in directory... WARNING: No "known good" password was found in LDAP. Are you sure that the user is configured correctly? [ldap_lanwarden2] user authorized to use remote access [ldap_lanwarden2] ldap_release_conn: Release Id: 0 ++++[ldap_lanwarden2] returns ok +++- redundant-load-balance group redundant-load-balance returns ok ++- policy ldap-lanwarden returns ok ++? if (ok) ? Evaluating (ok) -> TRUE ++? if (ok) -> TRUE ++- entering if (ok) {...} +++? if (check:LanWarden-Host-State != "enable") ? Evaluating (check:LanWarden-Host-State != "enable") -> TRUE <--- WTF? +++? if (check:LanWarden-Host-State != "enable") -> TRUE +++- entering if (check:LanWarden-Host-State != "enable") {...} ++++[reply] returns ok ++++[reject] returns reject +++- if (check:LanWarden-Host-State != "enable") returns reject ++- if (ok) returns reject } # server lanwarden ---- Turns out that it is actually doing is saying the *string* "check:LanWarden-Host-State" does not compare, rather than the *variable* 'check:LanWarden-Host-State'. Replacing it with "%{check:LanWarden-Host-State}" (or 'control:LanWarden-Host-State') works around the problem however I was say that either that phrase 'looking for check items...' needs amending, or the code to be tweaked to align the behaviour of unlang to treat control/check equally. I vaguely recall that 'check' is depreated in favour 'control' however in it's current state the logic leads to madness...as I found out this morning :-/ Cheers -- Alexander Clouter .sigmonster says: Satire does not look pretty upon a tombstone.
Alexander Clouter wrote:
Hi,
Not a show stopper, but it seems doing a comparision on 'check:...' in unlang does not work (however using 'control:...' does):
$ man unlang "check" doesn't work, and isn't intended to work.
Turns out that it is actually doing is saying the *string* "check:LanWarden-Host-State" does not compare, rather than the *variable* 'check:LanWarden-Host-State'.
Replacing it with "%{check:LanWarden-Host-State}" (or 'control:LanWarden-Host-State') works around the problem however I was say that either that phrase 'looking for check items...' needs amending, or the code to be tweaked to align the behaviour of unlang to treat control/check equally. I vaguely recall that 'check' is depreated in favour 'control' however in it's current state the logic leads to madness...as I found out this morning :-/
Yup. Alan DeKok.
Alan DeKok <aland@deployingradius.com> wrote:
Not a show stopper, but it seems doing a comparision on 'check:...' in unlang does not work (however using 'control:...' does):
$ man unlang
"check" doesn't work, and isn't intended to work.
...probably neither should %{check:...} then? Cheers -- Alexander Clouter .sigmonster says: This PORCUPINE knows his ZIPCODE ... And he has "VISA"!!
Alexander Clouter wrote:
Alan DeKok <aland@deployingradius.com> wrote:
Not a show stopper, but it seems doing a comparision on 'check:...' in unlang does not work (however using 'control:...' does): $ man unlang
"check" doesn't work, and isn't intended to work.
...probably neither should %{check:...} then?
Different code base. Something about duplicate code && backwards compatibility. <sigh> src/main/evaluate.c versus src/main/xlat.c Alan DeKok.
participants (2)
-
Alan DeKok -
Alexander Clouter