Re: Setting different IDLE-TIMEOUTS based on IP Address
Hi, (moving to -devel) On Wed, Apr 17, 2013 at 08:29:51PM +0000, Alan Buxey wrote:
Use any one of the clients.conf methods that were mentioned yesterday with some unlang and this would be working already. I seem to recall that huntgroups might be going the way if the dodo(?) It doesn't do regex methods because its older... pre 1.0 code
It's down to the userparse() function in valuepair.c, which is used by many things including rlm_preprocess for huntgroups, but also rlm_files. So the bug also affects this in the users file (which I'm guessing won't be going away any time soon!): DEFAULT NAS-IP-Address =~ /^10\.0\./ does not work, but DEFAULT NAS-IP-Address =~ ^10\.0\. does. userparse() doesn't strip the /'s off the regex and saves it in the the AVP value. This gets passed directly into regcomp() in radius_compare_vps (valuepair.c), which tries to match the /'s... and fails. In contrast, for an "if" statement in unlang the expression is passed to radius_evaluate_condition() in evaluate.c, which parses it and passes what it thinks are regexes to getregex(). This has the entirely opposite behaviour - it refuses to recognise it as a regex *unless* it is bracketed with /'s. Then it returns just the bit inside the /'s for the regex comparison. I have a bit of a love hate relationship with unlang. It's fantastic for conditionals and wierd logic, but it looks hideous if doing big lookups in the config. So with a couple of these I'd recommend unlang as quickest, but he may have hundreds to compare and huntgroups might be easier than listing them all in the clients.conf file if they have odd logic (and is certain to be much tidier than a massive 'if'-list in unlang). Personally, I'd probably move from huntgroups towards an instantiation of the files module (keyed on NAS-IP-Address, for instance), but that suffers from the same regex bug/feature... :-) If nothing else, moving huntgroups from rlm_preprocess into a new module rlm_huntgroups would probably make a lot more sense. It does tend to confuse people now as it's not too obvious where it's being looked up. Cheers, Matthew -- Matthew Newton, Ph.D. <mcn4@le.ac.uk> Systems Specialist, Infrastructure Services, I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom For IT help contact helpdesk extn. 2253, <ithelp@le.ac.uk>
Matthew Newton wrote:
It's down to the userparse() function in valuepair.c, which is used by many things including rlm_preprocess for huntgroups, but also rlm_files. So the bug also affects this in the users file (which I'm guessing won't be going away any time soon!):
No. But it could use some fixing.
In contrast, for an "if" statement in unlang the expression is passed to radius_evaluate_condition() in evaluate.c, which parses it and passes what it thinks are regexes to getregex(). This has the entirely opposite behaviour - it refuses to recognise it as a regex *unless* it is bracketed with /'s. Then it returns just the bit inside the /'s for the regex comparison.
Yes. And that's getting fixed for 3.0, too. The conditions will be parsed when the config files are loaded. They'll then be interpreted at run time. i.e. no string checking at run time. Much simpler.
I have a bit of a love hate relationship with unlang. It's fantastic for conditionals and wierd logic, but it looks hideous if doing big lookups in the config.
It's intended to *not* do that. There should really be a "map" function, something like the "passwd" module. i.e. "map X to Y". Unlang is for policies. Managing groups should be done elsewhere.
If nothing else, moving huntgroups from rlm_preprocess into a new module rlm_huntgroups would probably make a lot more sense. It does tend to confuse people now as it's not too obvious where it's being looked up.
Well... they don't need to edit the preprocess configuration. Just poke raddb/huntgroups. That should be enough for most people. Alan DeKok.
participants (2)
-
Alan DeKok -
Matthew Newton