Deprecated features

Thor Spruyt thor.spruyt at telenet.be
Fri Jul 29 20:27:56 CEST 2005


Paul Hampson wrote:
> On Fri, Jul 29, 2005 at 12:43:54PM +0200, Thor Spruyt wrote:
>> Paul Hampson wrote:
>>> On Fri, Jul 29, 2005 at 08:22:18AM +0200, Thor Spruyt wrote:
>>>> Alan DeKok wrote:
>>>>> "Thor Spruyt" <thor.spruyt at telenet.be> wrote:
>>>>>> Well, I experimented with rlm_exec half a year ago, and I didn't
>>>>>> found it suitable for my needs, where Exec-Program and
>>>>>> Exec-Program-Wait did!
> 
>>>>>   What were the differences?
> 
>>>> The rejecting was also not implemented the way I wanted it.
> 
>>> OK, so how do you want the rejecting implemented?
> 
>> If external program fails (or exit <1): don't add a fixed
>> reply-message (optionally, a configurable reply-message could be
>> sent) 
>> If external program runs ok (exit 0) and wants to allow the user:
>> let the external program add, modify or remove reply attributes
>> If external program runs ok and wants to reject the user: let the
>> external program add attributes (like reply-message)
> 
> Hmm...
> exec testproggy {
> wait = yes
> program = "/usr/bin/testproggy ${User-Name}"
> input_pairs = request
> output_pairs = reply
> }
> 
> Where /usr/bin/testproggy is something like
> 
> #! /bin/sh
> if test $USER_REQUIREMENTS; then
> echo "Reply-Attribute = bob"
> echo "Reply-Attribute2 = down"
> return 0
> else
> echo "Reply-Message = under"
> return 1
> fi
> 
> I really don't think your program should be failing, and if it is, I
> don't expect the RADIUS server to take any notice of what is _does_
> do. And a quick glance at the code suggests that a catastrophic
> failure (eg -1) return RLM_MODULE_FAIL, and doesn't do anything to
> the replies. 

Ok.
I will most likely use rlm_perl anyway if it's going to be stable in 2.x

-- 
Groeten, Regards, Salutations,

Thor Spruyt
M: +32 (0)475 67 22 65
E: thor.spruyt at telenet.be
W: www.thor-spruyt.com

www.salesguide.be
www.telenethotspot.be




More information about the Freeradius-Devel mailing list