>
> or...
>
> update [] {
> ...
> }
>
> update reply {
> config:Auth-Type = Reject
> Reply-Message = "Go away"
> }
That one gets my vote.
update {
}
defaults to request.
-Arran
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Phil Mayers wrote:
> +1
>
> Personally I'd rather the latter format everywhere, even unlang:
>
> update {
> request:foo = 1
> }
Yeah. That shouldn't be hard. Maybe I can look at it in 2 weeks,
after IETF.
Alan DeKok.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/
On Tue, Oct 30, 2012 at 07:02:02PM +, 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.
+1
Personally I'd rather the latter format everywhere, even unlang:
update {
request:foo = 1
}
John Dennis 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
>
>> 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 th
On 30 Oct 2012, at 13:00, John Dennis 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 organi
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:
I pull out only the attributes I need and change ldap.attrmap to match my
schema. Personally, I can live with either config method.
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.
>
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 := use
9 matches
Mail list logo
