FreeRADIUS 3 LDAP Questions

[Arran Cudbard-Bell]

>> Hm. That should be fixed, it shouldn't *require* list qualifiers. I'll take a look.
> 
> Ok, do you take care about this issue or do I have to create an issue on github?

Just testing the code now...

>>> checkItem        $GENERIC$                        radiusCheckItem
>>> replyItem        $GENERIC$                        radiusReplyItem
>>> This is very important. I don't want to define a ldap attribute for each VSA.
>> All check items should be modified to include the 'control:' list qualifier, all replyItems should be modified to include the 'reply:' list qualifier.
>> All generic RADIUS attributes should be stored in the same LDAP attribute.
>> Slight correction to what I said earlier, you can actually use any list qualifier that you'd use in an update section. I think it even takes request qualifiers (outer.) too.
> 
> Ahh, I think I have got it now. The list qualifier has to be part of the ldap attribute value. Well, this is quite good. For this it might be useful to get rid of the ldap attributes "radiusCheckItem" and "radiusReplyItem" in order to use a new one like e.g. "radiusGenericItem" in the freeradius ldap schema.

That was the idea behind it. I've just fixed the code. It now takes a very similar codepath to a normal update block, which means in addition to request qualifiers and list qualifiers it will also now support list to list copies (request: += &reply:), and the crazy multi VP exec logic where you can do stuff like:

request: += `<exec script which returns lots of VPs`

Not that I ever recommend using that... It's just nice to be consistent.

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