Any objection to deleting support for "clients"?
Alan DeKok wrote:
It's been deprecated forever...
I agree. And I think we could perhaps take a moment to look at other deprecated features. * post_proxy_authorize This option provides backward compatibility with FreeRADIUS 0.7. It is obsoleted with the post-proxy section. We might make the default to "post_proxy_authorize = no" or perhaps completely remove the option from the documentation. * authorize in rlm_attr_filter This module should be used in {pre,post}-proxy sections only. There is a warning at module startup since a long time, nobody should be using it in authorize section anymore. * 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. * bind_address and port The "listen" directive can do the same, and it's much more flexible. We might remove the old directives from the documentation. What do you think? This list has to be completed, of course. -- Nicolas Baradakis
Nicolas Baradakis <nbk@sitadelle.com> wrote:
I agree. And I think we could perhaps take a moment to look at other deprecated features.
* post_proxy_authorize
We can delete it.
* authorize in rlm_attr_filter
Delete it. We should also note that the "rlm_protocol_filter" module does related things.
* 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.
It's a hack. Nuke it. Also, the "lower_user" and "nospace_user" directives are atrocious. They should be deleted, and replaced with something else.
* bind_address and port
The "listen" directive can do the same, and it's much more flexible. We might remove the old directives from the documentation.
Sounds reasonable.
What do you think? This list has to be completed, of course.
I think that the CVS head has changed enough from the 1.0.x branch that we should call it 2.0, and not 1.1.x. Since it's a 2.0, we should fix everything we can find. e.g. I've hacked up rlm_unix, so "Auth-Type := System" doesn't exist. Also, the modules should have a header ala Apache, which allows us to do better sanity checking on them. Alan DeKok.
Alan DeKok wrote:
* post_proxy_authorize
We can delete it.
Better change the default to "no" first. Since the default is still "yes" even in 1.0.4, I guess a lot of people still use "yes"!
I think that the CVS head has changed enough from the 1.0.x branch that we should call it 2.0, and not 1.1.x. Since it's a 2.0, we should fix everything we can find.
Would you include a fix for Exec-Program-Wait (see below)? If needed, I can submit it on bugs.freeradius.org --- src/main/auth.c.orig 2005-07-18 14:17:40.000000000 +0000 +++ src/main/auth.c 2005-07-18 14:31:31.000000000 +0000 @@ -895,24 +895,35 @@ pairmove(&request->reply->vps, &tmp); pairfree(&tmp); - if (r != 0) { + if (r < 0) { /* * Error. radius_exec_program() returns -1 on - * fork/exec errors, or >0 if the exec'ed program - * had a non-zero exit status. + * fork/exec errors. */ - if (umsg[0] == '\0') { - user_msg = "\r\nAccess denied (external check failed)."; - } else { - user_msg = &umsg[0]; - } - request->reply->code = PW_AUTHENTICATION_REJECT; + user_msg = "Access denied (external check failed)"; tmp = pairmake("Reply-Message", user_msg, T_OP_SET); - pairadd(&request->reply->vps, tmp); + + request->reply->code = PW_AUTHENTICATION_REJECT; + rad_authlog("Login incorrect (external check failed)", - request, 0); + request, 1); + + rad_postauth_reject(request); + + return RLM_MODULE_REJECT; + } + if (r > 0) { + /* + * Reject. radius_exec_program() returns or >0 + * if the exec'ed program had a non-zero exit status. + */ + + request->reply->code = PW_AUTHENTICATION_REJECT; + + rad_authlog("Login incorrect (external check said so)", + request, 1); rad_postauth_reject(request); -- Groeten, Regards, Salutations, Thor Spruyt M: +32 (0)475 67 22 65 E: thor.spruyt@telenet.be W: www.thor-spruyt.com www.salesguide.be www.telenethotspot.be
Thor Spruyt wrote:
Would you include a fix for Exec-Program-Wait (see below)? If needed, I can submit it on bugs.freeradius.org
Comments below..
--- src/main/auth.c.orig 2005-07-18 14:17:40.000000000 +0000 +++ src/main/auth.c 2005-07-18 14:31:31.000000000 +0000 @@ -895,24 +895,35 @@ pairmove(&request->reply->vps, &tmp); pairfree(&tmp);
- if (r != 0) { + if (r < 0) { /* * Error. radius_exec_program() returns -1 on - * fork/exec errors, or >0 if the exec'ed program - * had a non-zero exit status. + * fork/exec errors. */ - if (umsg[0] == '\0') { - user_msg = "\r\nAccess denied (external check failed)."; - } else { - user_msg = &umsg[0]; - }
Is it correct to forget the message in umsg ? I don't know this part of the code, what sort of message is in the string umsg ? If it isn't usefull, we could pass NULL to the function radius_exec_program().
- request->reply->code = PW_AUTHENTICATION_REJECT; + user_msg = "Access denied (external check failed)"; tmp = pairmake("Reply-Message", user_msg, T_OP_SET); - pairadd(&request->reply->vps, tmp); + + request->reply->code = PW_AUTHENTICATION_REJECT; + rad_authlog("Login incorrect (external check failed)", - request, 0); + request, 1); + + rad_postauth_reject(request); + + return RLM_MODULE_REJECT; + } + if (r > 0) { + /* + * Reject. radius_exec_program() returns or >0 + * if the exec'ed program had a non-zero exit status. + */
In CVS head a return code >0 has a different meaning for the rlm_exec module. Perhaps we may want something similar with Exec-Program-Wait, what do you think? See the rlm_exec examples in http://www.freeradius.org/cgi-bin/cvsweb.cgi/~checkout~/radiusd/raddb/radius...
+ request->reply->code = PW_AUTHENTICATION_REJECT; + + rad_authlog("Login incorrect (external check said so)", + request, 1);
rad_postauth_reject(request);
In the case (r > 0) you didn't add a "Reply-Message" in request->reply->vps. -- Nicolas Baradakis
Nicolas Baradakis wrote:
Is it correct to forget the message in umsg ? I don't know this part of the code, what sort of message is in the string umsg ?
If the external program fails, it won't be sending a message :-) So we can just add our own message indicating that the external program failed. I even wouldn't add that message, since the user shouldn't know something failed, but it should be logged!
In CVS head a return code >0 has a different meaning for the rlm_exec module. Perhaps we may want something similar with Exec-Program-Wait, what do you think?
Sure, but I'm not that good in coding :)
In the case (r > 0) you didn't add a "Reply-Message" in request->reply->vps.
No, since the external program didn't fail, I think it's up to the external program to supply a message if it whishes to do so. The Reply-Message is an attribute that should contain a message readable by the user, so it shouldn't be something like "(external check failed)", but it should be like "Your account had expired" or whatever the external program whishes. -- Groeten, Regards, Salutations, Thor Spruyt M: +32 (0)475 67 22 65 E: thor.spruyt@telenet.be W: www.thor-spruyt.com www.salesguide.be www.telenethotspot.be
On Wed, Jul 27, 2005 at 07:25:54PM +0200, Thor Spruyt wrote:
Alan DeKok wrote:
I think that the CVS head has changed enough from the 1.0.x branch that we should call it 2.0, and not 1.1.x. Since it's a 2.0, we should fix everything we can find.
Definately. ^_^
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. ^_^ -- Paul "TBBle" Hampson, on an alternate email client.
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. -- Groeten, Regards, Salutations, Thor Spruyt M: +32 (0)475 67 22 65 E: thor.spruyt@telenet.be W: www.thor-spruyt.com www.salesguide.be www.telenethotspot.be
"Thor Spruyt" <thor.spruyt@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?
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. Alan DeKok.
Alan DeKok wrote:
"Thor Spruyt" <thor.spruyt@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.
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: thor.spruyt@telenet.be W: www.thor-spruyt.com www.salesguide.be www.telenethotspot.be
On Fri, Jul 29, 2005 at 08:22:18AM +0200, Thor Spruyt wrote:
Alan DeKok wrote:
"Thor Spruyt" <thor.spruyt@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? -- Paul "TBBle" Hampson, on an alternate email client.
Paul Hampson wrote:
On Fri, Jul 29, 2005 at 08:22:18AM +0200, Thor Spruyt wrote:
Alan DeKok wrote:
"Thor Spruyt" <thor.spruyt@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) -- Groeten, Regards, Salutations, Thor Spruyt M: +32 (0)475 67 22 65 E: thor.spruyt@telenet.be W: www.thor-spruyt.com www.salesguide.be www.telenethotspot.be
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@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. -- Paul "TBBle" Hampson, on an alternate email client.
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@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@telenet.be W: www.thor-spruyt.com www.salesguide.be www.telenethotspot.be
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.
Nicolas Baradakis wrote:
I agree. And I think we could perhaps take a moment to look at other deprecated features.
* post_proxy_authorize
This option provides backward compatibility with FreeRADIUS 0.7. It is obsoleted with the post-proxy section. We might make the default to "post_proxy_authorize = no" or perhaps completely remove the option from the documentation.
Huh... my current v1.0.1 production servers have this set to "yes" and probably a lot of other people still have this set to "yes", since that's the default. Regularly the advice of "only change the defaults if needed" is given. Therfore, I wouldn't just delete this configuration parameter or funtionality, but just change the default, so that users don't use it anymore over time! -- Groeten, Regards, Salutations, Thor Spruyt M: +32 (0)475 67 22 65 E: thor.spruyt@telenet.be W: www.thor-spruyt.com www.salesguide.be www.telenethotspot.be
"Thor Spruyt" <thor.spruyt@telenet.be> wrote:
* post_proxy_authorize ... Huh... my current v1.0.1 production servers have this set to "yes" and probably a lot of other people still have this set to "yes", since that's the default.
That's OK.
Regularly the advice of "only change the defaults if needed" is given. Therfore, I wouldn't just delete this configuration parameter or funtionality, but just change the default, so that users don't use it anymore over time!
I'd say change both. I'd like to update the server core to allow more configurable calling of sections. So the "post-proxy-authorize" can morph into "when receiving a reply from a home server, use section foo, and call the modules authorize function for each module listed in that section" That kind of flexibility also allows you to automagically do different things based on packet reply code, in a more flexible way that the current "post-auth-type REJECT". Alan DeKok.
Alan DeKok wrote:
"Thor Spruyt" <thor.spruyt@telenet.be> wrote:
Regularly the advice of "only change the defaults if needed" is given. Therfore, I wouldn't just delete this configuration parameter or funtionality, but just change the default, so that users don't use it anymore over time!
I'd say change both. I'd like to update the server core to allow more configurable calling of sections. So the "post-proxy-authorize" can morph into "when receiving a reply from a home server, use section foo, and call the modules authorize function for each module listed in that section"
In CVS head we have the stanza 'Post-Proxy-Type' which allows to run different modules groups when receiving a reply from a home server. Perhaps I didn't understand what you'd like to do, but I'd prefer not running modules from authorize section a second time. (and moving all the modules to the section post-proxy)
That kind of flexibility also allows you to automagically do different things based on packet reply code, in a more flexible way that the current "post-auth-type REJECT".
It could be easy to have a "Post-Proxy-Type REJECT", too. -- Nicolas Baradakis
Nicolas Baradakis wrote:
Alan DeKok wrote:
"Thor Spruyt" <thor.spruyt@telenet.be> wrote:
Regularly the advice of "only change the defaults if needed" is given. Therfore, I wouldn't just delete this configuration parameter or funtionality, but just change the default, so that users don't use it anymore over time!
I'd say change both. I'd like to update the server core to allow more configurable calling of sections. So the "post-proxy-authorize" can morph into "when receiving a reply from a home server, use section foo, and call the modules authorize function for each module listed in that section"
In CVS head we have the stanza 'Post-Proxy-Type' which allows to run different modules groups when receiving a reply from a home server. Perhaps I didn't understand what you'd like to do, but I'd prefer not running modules from authorize section a second time. (and moving all the modules to the section post-proxy)
That kind of flexibility also allows you to automagically do different things based on packet reply code, in a more flexible way that the current "post-auth-type REJECT".
It could be easy to have a "Post-Proxy-Type REJECT", too.
I want to log replies sent to my NAS, whether it's an Accept or Reject or whether the request was proxied or not. I haven't been able to do this with 1.0.1, but I'll be upgrading to 1.0.4 with which I managed to do so. As long as that's possible, everything is fine for me :) -- Groeten, Regards, Salutations, Thor Spruyt M: +32 (0)475 67 22 65 E: thor.spruyt@telenet.be W: www.thor-spruyt.com www.salesguide.be www.telenethotspot.be
Thor Spruyt wrote:
I want to log replies sent to my NAS, whether it's an Accept or Reject or whether the request was proxied or not. I haven't been able to do this with 1.0.1, but I'll be upgrading to 1.0.4 with which I managed to do so. As long as that's possible, everything is fine for me :)
Logging replies sent to the NAS should be done in post-auth and has nothing to do with the authorize section. Changing the default for post_proxy_authorize will never break that. -- Nicolas Baradakis
Nicolas Baradakis <nbk@sitadelle.com> wrote:
In CVS head we have the stanza 'Post-Proxy-Type' which allows to run different modules groups when receiving a reply from a home server. Perhaps I didn't understand what you'd like to do, but I'd prefer not running modules from authorize section a second time. (and moving all the modules to the section post-proxy)
I agree with the last bit. As for what I'm trying to do, I'm not exactly sure. Maybe in "post-auth", we need to have sub-sections, to make it clear what's run, and where: post-auth { Access-Accept { ... } Access-Challenge { ... } Access-Reject { ... } } That would be obvious, at least. Alan DeKok.
Alan DeKok wrote:
I agree with the last bit.
As for what I'm trying to do, I'm not exactly sure. Maybe in "post-auth", we need to have sub-sections, to make it clear what's run, and where:
post-auth { Access-Accept { ... } Access-Challenge { ... } Access-Reject { ... } }
That would be obvious, at least.
But what should we do when the administrator wants different Post-Auth-Type stanzas for each realm on a multi-realm server? I'm not sure about about it either. Perhaps this approach could be possible: if a check item 'Post-Auth-Type' already exists, we can look for a stanza named %{check:Post-Auth-Type}.%{reply:Packet-Type}. If we found such a stanza, we run the modules we found inside. Otherwise we run the modules in the stanza named %{check:Post-Auth-Type}. (fallback to the current behaviour) -- Nicolas Baradakis
Hi, On Thu, Jul 28, 2005 at 11:53:56AM +0200, Nicolas Baradakis wrote:
Alan DeKok wrote:
I agree with the last bit.
As for what I'm trying to do, I'm not exactly sure. Maybe in "post-auth", we need to have sub-sections, to make it clear what's run, and where:
post-auth { Access-Accept { ... } Access-Challenge { ... } Access-Reject { ... } }
That would be obvious, at least.
But what should we do when the administrator wants different Post-Auth-Type stanzas for each realm on a multi-realm server?
I'm not sure about about it either. Perhaps this approach could be possible: if a check item 'Post-Auth-Type' already exists, we can look for a stanza named %{check:Post-Auth-Type}.%{reply:Packet-Type}. If we found such a stanza, we run the modules we found inside. Otherwise we run the modules in the stanza named %{check:Post-Auth-Type}. (fallback to the current behaviour)
<tongue loosely in cheeck> I see I definitely did choose the right approach in OpenRADIUS to leave that sort of decision wholly to the administrator, and to put that sort of logic on a layer well above the server code. Cheers, Emile -- E-Advies - Emile van Bergen emile@e-advies.nl tel. +31 (0)70 3906153 http://www.e-advies.nl
Emile van Bergen <emile-fr@evbergen.xs4all.nl> wrote:
I see I definitely did choose the right approach in OpenRADIUS to leave that sort of decision wholly to the administrator, and to put that sort of logic on a layer well above the server code.
FreeRADIUS is structured that way, too, it's just not obvious. The "track radius request" code is independent of the modules, which are independent of how the modules are put together in lists. There's really nothing preventing FreeRADIUS from doing something similar to OpenRADIUS, other than time. Alan DeKok.
Nicolas Baradakis <nbk@sitadelle.com> wrote:
But what should we do when the administrator wants different Post-Auth-Type stanzas for each realm on a multi-realm server?
Hmm...
I'm not sure about about it either. Perhaps this approach could be possible: ....
Maybe we should just move to a completely separate way of handling things. 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
Nicolas Baradakis <nbk@sitadelle.com> 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.
Nicolas Baradakis <nbk@sitadelle.com> 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.
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
Nicolas Baradakis <nbk@sitadelle.com> 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.
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
Nicolas Baradakis <nbk@sitadelle.com> 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.
participants (5)
-
Alan DeKok -
Emile van Bergen -
Nicolas Baradakis -
Paul.Hampson＠PObox.com -
Thor Spruyt