On 16 Aug 2015, at 17:39, Peter Lambrechtsen <peter@crypt.co.nz> wrote:
On Sun, Aug 16, 2015 at 11:01 AM, Arran Cudbard-Bell < a.cudbardb@freeradius.org> wrote:
On 15 Aug 2015, at 18:17, Peter Lambrechtsen <peter@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@freeradius.org> FreeRADIUS development team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2