Any objection to deleting support for "clients"?

classic Classic list List threaded Threaded
33 messages Options
12
| Threaded
Open this post in threaded view
|

Re: Deprecated features

Paul "TBBle" Hampson
On Thu, Jul 28, 2005 at 07:13:44PM +0200, Thor Spruyt wrote:
> Paul Hampson wrote:
> >> Would you include a fix for Exec-Program-Wait (see below)? If
> >> needed, I can submit it on bugs.freeradius.org

> > Can we instead nuke Exec-Program and Exec-Program-Wait? Are there any
> > more cases they handle that rlm_exec does not?

> > I didn't port the rlm_exec return values changes to Exec-Program-Wait,
> > because they're to do with the configurable failover, and the
> > Exec-Program calls are done after that's no longer relevant.

> > And because I'd like to see Exec-Program nuked. ^_^

> 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!
> I would suggest deprecating them, but not removing, so to give people time
> to move to rlm_exec or rlm_perl (when is that finaly going to be stable?).
> When I have time, I'll try rlm_exec again to see if things have changed in
> the right direction.

Exec-Program and Exec-Program-Wait _are_ deprecated.

What was rlm_exec insufficient to do? I'd much rather improve rlm_exec
to work than change any (deprecated and historical) Exec-Program
behavours. The less server-defined magic attributes the better. ^_^

--
Paul "TBBle" Hampson, on an alternate email client.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
| Threaded
Open this post in threaded view
|

Re: Deprecated features

Thor Spruyt
In reply to this post by Alan DeKok
Alan DeKok wrote:
> "Thor Spruyt" <[hidden email]> 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.

>> I would suggest deprecating them, but not removing, so to give
>> people time to move to rlm_exec or rlm_perl (when is that finaly
>> going to be stable?).
>
>   rlm_perl will be marked "stable" in 2.0.

Then I'll move to that I guess :)

--
Groeten, Regards, Salutations,

Thor Spruyt
M: +32 (0)475 67 22 65
E: [hidden email]
W: www.thor-spruyt.com

www.salesguide.be
www.telenethotspot.be

-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
| Threaded
Open this post in threaded view
|

Re: Deprecated features

Paul "TBBle" Hampson
On Fri, Jul 29, 2005 at 08:22:18AM +0200, Thor Spruyt wrote:
> Alan DeKok wrote:
> > "Thor Spruyt" <[hidden email]> 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?

--
Paul "TBBle" Hampson, on an alternate email client.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
| Threaded
Open this post in threaded view
|

Re: Deprecated features

Thor Spruyt
Paul Hampson wrote:

> On Fri, Jul 29, 2005 at 08:22:18AM +0200, Thor Spruyt wrote:
>> Alan DeKok wrote:
>>> "Thor Spruyt" <[hidden email]> 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)

--
Groeten, Regards, Salutations,

Thor Spruyt
M: +32 (0)475 67 22 65
E: [hidden email]
W: www.thor-spruyt.com

www.salesguide.be
www.telenethotspot.be

-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
| Threaded
Open this post in threaded view
|

Re: Deprecated features

Paul "TBBle" Hampson
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" <[hidden email]> 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.

--
Paul "TBBle" Hampson, on an alternate email client.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
| Threaded
Open this post in threaded view
|

Re: post-auth and post-proxy subsections (was: Deprecated features)

Nicolas Baradakis
In reply to this post by Alan DeKok
Alan DeKok wrote:

> Maybe we should just move to a completely separate way of handling things.

Another idea: allow the administrateur to set Post-Auth-Type during
post-auth, like we do for authorize. We first run the anonymous
modules outside any Post-Auth-Type stanzas. After that we check for
Post-Auth-Type and if it exists we run the corresponding subsection.

In this case, it could be possible to choose what will be run during
post-auth with the same syntax as the "users" file:

DEFAULT Realm == realm.net, Packet-Type == Access-Accept, Post-Auth-Type := ippool.realm.net

DEFAULT Realm == realm.net, Packet-Type == Access-Reject, Post-Auth-Type := sql_log.realm.net

DEFAULT Packet-Type == Access-Accept, Post-Auth-Type := other

--
Nicolas Baradakis

-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
| Threaded
Open this post in threaded view
|

Re: post-auth and post-proxy subsections (was: Deprecated features)

Alan DeKok
Nicolas Baradakis <[hidden email]> wrote:
> Another idea: allow the administrateur to set Post-Auth-Type during
> post-auth, like we do for authorize.

  I'd rather just steal pre-existing, more general solutions.  Things
like "pam_stack" may be useful, or the OpenRADIUS method.

  Alan DeKok.

-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
| Threaded
Open this post in threaded view
|

Re: Deprecated features

Thor Spruyt
In reply to this post by Paul "TBBle" Hampson
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" <[hidden email]> 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: [hidden email]
W: www.thor-spruyt.com

www.salesguide.be
www.telenethotspot.be

-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
| Threaded
Open this post in threaded view
|

Re: Deprecated features (was: Any objection to deleting support for "clients"?)

Alan DeKok
In reply to this post by Nicolas Baradakis
Nicolas Baradakis <[hidden email]> wrote:
> * usercollide
>
>   I never used this, but the doc says it doesn't work so well (with a
>   big warning), and there is another way of achieving the same goal.

  Gone.  The new "rlm_policy" can do this without hacks in the server
core.

  Alan DeKok.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
| Threaded
Open this post in threaded view
|

Re: Deprecated features

Nicolas Baradakis
In reply to this post by Nicolas Baradakis
If you read the recent CVS reports, Alan and I have done some cleaning
in the source. Here is little summary:

> * post_proxy_authorize

Option deleted.

> * authorize in rlm_attr_filter

Function removed.

> * usercollide

Option removed by Alan.

> * bind_address and port

Removed from documentation, and print a warning if people still use them.

* {lower,nospace}_{user,pass}

Options deleted by Alan.

* Exec-Program and Exec-Program-Wait

Attributes deleted.

* Callback-Id special case

Obscure code deleted.

--
Nicolas Baradakis

-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
| Threaded
Open this post in threaded view
|

Re: Deprecated features

Alan DeKok
Nicolas Baradakis <[hidden email]> wrote:
> * Exec-Program and Exec-Program-Wait
>
> Attributes deleted.

  I wouldn't oppose hacking rlm_exec to support these.  They're simple
& useful enough for many cases that they could stay.  But they *don't*
belong in the server core.

  I've also been trying to get the config file code updated so that as
little as possible gets re-initialized on a HUP signal.  I'm close,
but not quite done yet.

  Alan DeKok.

-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
| Threaded
Open this post in threaded view
|

Re: Deprecated features

Nicolas Baradakis
Alan DeKok wrote:

> > * Exec-Program and Exec-Program-Wait
> >
> > Attributes deleted.
>
>   I wouldn't oppose hacking rlm_exec to support these.  They're simple
> & useful enough for many cases that they could stay.  But they *don't*
> belong in the server core.

And what about the patch from Thor Spruyt under bugzilla #253 ? It's no
longer possible to add it CVS head, but it may go in branch 1.0. I've
no opinion about this, because it's deprecated anyway...

http://bugs.freeradius.org/show_bug.cgi?id=253

--
Nicolas Baradakis

-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
| Threaded
Open this post in threaded view
|

Re: Deprecated features

Alan DeKok
Nicolas Baradakis <[hidden email]> wrote:
> And what about the patch from Thor Spruyt under bugzilla #253 ? It's no
> longer possible to add it CVS head, but it may go in branch 1.0. I've
> no opinion about this, because it's deprecated anyway...

  Sure, it seems fine.

  Alan DeKok.


-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
12