FreeRADIUS 2.X.X small functionality extensions

[Kostas Zorbadelos]

Arran Cudbard-Bell <a.cudbardb at freeradius.org> writes:

Hi,

>> 
>> The parsed form is the string we want to extract and use it later
>> against an LDAP repository containing ports to verify the port status
>> and make decisions based on that. We have reached in a regex containing
>> more than 8 groups. Also, as you can see, some DSLAMs send initial zeroes
>> in front of numbers describing DSLAM port/slot.
>
> You can strip those out trivially in a regex...
>
> Say you had /1/01/01/12
>
> Your regex would be
>
> /0?([0-9]+)/0?([0-9]+)/0?([0-9]+)/0?([0-9]+)
>

Of course you are right and it was really silly I didn't think of that. 

>
> For v2.x.x the 0 stripping stuff can be done in a bunch of ways without 
> requiring extra code, so that's definitely not going to be added.
>

Yes, I am convinced about that.
 
> Alan has final on the number of capture groups and whether they'll be 
> increased for v2.x.x. I suspect they won't be as it's in feature freeze.
>

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

/.*_[HUAALU]{3}_([[:digit:]]+)(.*)? [atmeth]{3} 0?([[:digit:]]+)\/0?([[:digit:]]+)\/0?([[:digit:]]+)\/0?([[:digit:]]+)(:)?.*/)

Not exactly the same but fits our purposes fine.

> 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? 

>
> 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

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.
>
> But i'm not here to sell it to you. Upgrade when you want... or don't.
>

Thanks,

Kostas