FreeRADIUS 2.X.X small functionality extensions

[Arran Cudbard-Bell]

> Yes indeed, he refused to add it.
> I our case I managed to overcome the problem by defining a slightly
> different regex. It is true that the info I 'd like to extract is only 5
> variables (fitting in the 8) but more groups can be needed in more
> compicated expressions. In our case the original regex was
> 
> /.*_((HUA)|(ALU))_([[:digit:]]+)(.*)? ((atm)|(eth)) ([[:digit:]]+)\/([[:digit:]]+)\/([[:digit:]]+)\/([[:digit:]]+)(:)?.*/
> 
> and I reduced the groups with
> 
> /.*__([[:digit:]]+)(.*)? [atmeth]{3} 0?([[:digit:]]+)\/0?([[:digit:]]+)\/0?([[:digit:]]+)\/0?([[:digit:]]+)(:)?.*/)
> 
> Not exactly the same but fits our purposes fine.


> [HUAALU]{3}

That'll work, but it's pretty bad.

> ((HUA)|(ALU))

Inputting (ALU|HUA) on debuggex, you get:



Meaning HUA and ALU count as atoms for the alternation. In fact (HUA|ALU) is exactly the same thing as ((HUA)|(ALU)) but uses two fewer capture groups.




I can't remember if it's the same in extended regular expressions but for PCRE at least 

(?:<expression>) makes expression an atom, but doesn't add the match to the capture groups.

'foo bar baz' =~ /([[:alnum:]]+) (?:[[:alnum:]]+) ([[:alnum:]]+)/

Would result in 

%{0} -> 'foo bar baz'
%{1} -> 'foo'
%{2} -> 'baz'

So you don't waste the capture groups if you're not actually going to use the data.

Try it with extended regular expressions and see if it works. If it doesn't the only way to fix it would be upgrade to v3.0.x and build with PCRE unfortunately.

>> It's the sort of thing that would be quite nice to define at build time 
>> TBH. Instead of increasing it for everyone, as there is a performance 
>> penalty.
>> 
> 
> I think generally this is the way to go, have it configurable since
> people can use it. Matching multiple times to reduce the number of
> groups is at least "not elegant". Maybe you can have it in the v3.x.x
> branch? 

Yes, i'll have a look.

>> 
>> Sure. I'm assuming that's because you don't have the facilities to properly
>> test your RADIUS service, and don't want to introduce changes where you 
>> can't fully determine what the impact will be.
>> 
> 
> We do have such facilities, however:
> 
> - we have a short timeframe for this project
> - the project is generally very big (company wide) and involves large
>  changes in various layers
> - we already operate FreeRADIUS v2.x.x for many years
> - (rather important) the environment I work is REALLY conservative in
>  changes

Yes, I know what ISPs can be like :)

> These are the reasons we will go with 2.x.x for now. We can revisit the
> subject and upgrade in the future (I also need to catchup with 3.x.x).
> 
>> 
>> Well the LDAP code doesn't suck, you'd probably get a marked performance 
>> improvement just from using the new rlm_ldap module.
>> 
>> In general the policy language is more efficient, and there's a greater 
>> number of validation checks on startup. It's generally a lot more 
>> consistent with v2.x.x.

*than v2.x.x

Arran Cudbard-Bell <a.cudbardb at freeradius.org>
FreeRADIUS Development Team

FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20140605/f12721d2/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: F6d_PXvs0Qut3cLn.png
Type: image/png
Size: 3736 bytes
Desc: not available
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20140605/f12721d2/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 881 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20140605/f12721d2/attachment-0001.pgp>