Quick poll. For 3.0 the ldap module will be moving away from using the ldap.attrmap file and instead use a config based mapping. There are a few ways we are considering for organising the mapping. We can use something like the existing unlang: update control { Cleartext-Password := userpassword } update reply { User-Name = radiusUserName } update outer.reply { Reply-Message = radiusReplyMessage } Or something like rlm_rest and rlm_cache: update { control:Cleartext-Password := userpassword reply:User-Name = radiusUserName reply.outer:User-Name = radiusUserName } It really depends on whether people are actually using the full ldap.attrmap, or whether they're just pulling out one or two attributes. Each approach is as efficient as the other performance wise, so it comes down to which one people prefer. Any thoughts? -Arran
On 10/30/2012 06:38 AM, Arran Cudbard-Bell wrote:
Quick poll.
For 3.0 the ldap module will be moving away from using the ldap.attrmap file and instead use a config based mapping.
There are a few ways we are considering for organising the mapping.
We can use something like the existing unlang:
Or something like rlm_rest and rlm_cache:
It really depends on whether people are actually using the full ldap.attrmap, or whether they're just pulling out one or two attributes. Each approach is as efficient as the other performance wise, so it comes down to which one people prefer.
Any thoughts?
What I'd like to see is the individual modules converging on common behavior so there is a consistent model. I suspect a number of the modules were written independently and contributed, their diverse heritage makes for some awkwardness when viewing the totality of FreeRADIUS. If rlm_rest and rlm_cache have attribute models that are elegant and well thought out then let's move everything to that model. On the other hand if ulang is conceptually cleaner then lets move rlm_rest and rlm_cache to a ulang solution. Pick one idea and make everything follow those rules. Consistency is a virtue and should be a goal of 3.0 IMHO, it will make using FreeRADIUS easier. A major version upgrade is one of the very few opportunities available to clean up. -- John Dennis <jdennis@redhat.com> Looking to carve out IT costs? www.redhat.com/carveoutcosts/
On 30 Oct 2012, at 13:00, John Dennis <jdennis@redhat.com> wrote:
On 10/30/2012 06:38 AM, Arran Cudbard-Bell wrote:
Quick poll.
For 3.0 the ldap module will be moving away from using the ldap.attrmap file and instead use a config based mapping.
There are a few ways we are considering for organising the mapping.
We can use something like the existing unlang:
Or something like rlm_rest and rlm_cache:
It really depends on whether people are actually using the full ldap.attrmap, or whether they're just pulling out one or two attributes. Each approach is as efficient as the other performance wise, so it comes down to which one people prefer.
Any thoughts?
What I'd like to see is the individual modules converging on common behavior so there is a consistent model.
This is what's happening. We now have a common API for connections which means that managing connection pools is done in a consistant and easy to understand way. TLS configuration is also being standardised as much as possible, though there will probably be some minor differences where libraries only expose a subset of OpenSSL configuration parameters.
I suspect a number of the modules were written independently and contributed, their diverse heritage makes for some awkwardness when viewing the totality of FreeRADIUS.
Yes.
If rlm_rest and rlm_cache have attribute models that are elegant and well thought out then let's move everything to that model. On the other hand if ulang is conceptually cleaner then lets move rlm_rest and rlm_cache to a ulang solution. Pick one idea and make everything follow those rules.
With 2.0 there was an effort to maintain configuration compatibility, which limited standardisation efforts. Maintaining config compatiblity with 3.0 we don't have that constraint. That said, discuss whether using exactly the same syntax is useful. People may get more confused and try to use other unlang statements within module configs.
Consistency is a virtue and should be a goal of 3.0 IMHO, it will make using FreeRADIUS easier. A major version upgrade is one of the very few opportunities available to clean up.
Yes. -Arran
If rlm_rest and rlm_cache have attribute models that are elegant and well thought out then let's move everything to that model. On the other hand if ulang is conceptually cleaner then lets move rlm_rest and rlm_cache to a ulang solution. Pick one idea and make everything follow those rules.
With 2.0 there was an effort to maintain configuration compatibility, which limited standardisation efforts. Maintaining config compatiblity with 3.0 we don't have that constraint.
* Were not maintaining config compatibility with 3.0 so we don't have that constraint. Just talking with Alan, apparently whole subsections can be referenced. This is especially useful for things like TLS, where you're using the same certs in multiple places, and you can define a global TLS section and then reference it from the various module configuration. -Arran
+1 Personally I'd rather the latter format everywhere, even unlang: update { request:foo = 1 } John Dennis <jdennis@redhat.com> wrote:
What I'd like to see is the individual modules converging on common behavior so there is a consistent model.
I suspect a number of the modules were written independently and contributed, their diverse heritage makes for some awkwardness when viewing the totality of FreeRADIUS.
If rlm_rest and rlm_cache have attribute models that are elegant and well thought out then let's move everything to that model. On the other
hand if ulang is conceptually cleaner then lets move rlm_rest and rlm_cache to a ulang solution. Pick one idea and make everything follow
those rules. Consistency is a virtue and should be a goal of 3.0 IMHO, it will make using FreeRADIUS easier. A major version upgrade is one of
the very few opportunities available to clean up.
-- Sent from my mobile device, please excuse brevity and typos.
On Tue, Oct 30, 2012 at 07:02:02PM +0000, Phil Mayers wrote:
+1
Personally I'd rather the latter format everywhere, even unlang:
update { request:foo = 1 }
Agreed - having that option would make things much tidier when several things in different lists are being updated at once. update { config:Auth-Type = Reject reply:Reply-Message = "Go away" } On the other hand, the current form is nicer when updating a few attributes all in one list, so maybe both...? :) or... update [<default list>] { ... } update reply { config:Auth-Type = Reject Reply-Message = "Go away" } Matthew -- Matthew Newton, Ph.D. <mcn4@le.ac.uk> Systems Architect (UNIX and Networks), Network Services, I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom For IT help contact helpdesk extn. 2253, <ithelp@le.ac.uk>
participants (5)
-
Alan DeKok -
Arran Cudbard-Bell -
John Dennis -
Matthew Newton -
Phil Mayers