Issue with VSA Attributes with Tags and 3.0x

[Arran Cudbard-Bell]

> On 16 Aug 2015, at 17:39, Peter Lambrechtsen <peter at crypt.co.nz> wrote:
> 
> On Sun, Aug 16, 2015 at 11:01 AM, Arran Cudbard-Bell <
> a.cudbardb at freeradius.org> wrote:
> 
>> 
>>> On 15 Aug 2015, at 18:17, Peter Lambrechtsen <peter at crypt.co.nz> wrote:
>>> 
>>> Hi
>>> 
>>> I'm trying to pass a number of Tunnel-Type VSAs from RFC2868 back that
>> have
>>> multiple tags to a NAS using LDAP generic mapping attributes.
>>> 
>>> This used to work in 2.x, but no longer works in 3.0.x
>>> 
>>> In LDAP I have a multi-valued attribute that contains all the VSAs I want
>>> to return:
>>> 
>>> Tunnel-Type:1 = L2TP
>>> Tunnel-Type:2 = L2TP
>>> Tunnel-Medium-Type:1 = IP
>>> Tunnel-Medium-Type:2 = IP
>>> Tunnel-Server-Endpoint:1 = 1.2.3.4
>>> Tunnel-Server-Endpoint:2 = 2.3.4.5
>>> 
>>> Previously in 2.x I had the ldap.attrmap to set the $GENERIC$ point to
>> the
>>> ldap attribute I have defined
>> 
>> *sigh* that was a a hack for backwards compatibility.  You should really
>> use the generic attribute, and qualify your attributes in LDAP with list
>> prefixes.
>> I guess it should still be fixed though.
>> 
> 
> Yep... The $GENERIC$ was used in 2.x in the ldap.attrmap and $GENERIC$ was
> a beautiful thing. Now in 3.0.x I am now using:
> 
> ldap {
>        update {
> ...
>                control:                        += 'proxyControl'
>                request:                        += 'proxyRequest'
>                reply:                          += 'proxyReply'
>        }
> 
> And that works a treat for me now that I have fixed the tag issue :)

You know generic got even more beautiful and generic and can now represent any
list in the server, right?

That's what the valuepair_attribute configuration item sets, the one true generic
LDAP attribute who's values can represent any request/list and value in the
server.

You can even do things like:

	radiusAttribute: outer.request: += `/my/script/that/makes/multuple/attributes`

	radiusAttribute: request:User-Name := 'foo'

	radiusAttribute: disconnect:Acct-Session-Id := &outer.request:Acct-Session-Id

Code path is similar to update blocks in config files.

> 
> It's feeling a lot like map_to_request and callbacks should be altered in
>> v3.1.x so that they produce a list of maps with the rhs resolved to
>> TMPL_TYPE_DATA, instead of producing VPs. We then get rid of the 'op' field
>> from VALUE_PAIRs and remove all the pairmove functions and switch
>> everything to operate on map lists.
>> 
> 
> That too would make more sense, since there would be less steps in the
> translation and places things like tag and other esoteric VSAs types that
> get missed in code from when the data is sucked out of the database
> whatever flavour that database maybe until it's on the wire.

It also allows atomic updates again :)

-Arran

Arran Cudbard-Bell <a.cudbardb at freeradius.org>
FreeRADIUS development team

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 872 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.freeradius.org/pipermail/freeradius-devel/attachments/20150816/40d89dfe/attachment.sig>