There have been a lot of changes to the v4.0.x branch in the last few weeks. I thought I'd take some time to give people updates as to what's happening, and what our plans are. As background, we've been working on re-designing the internals to remove RADIUS from the server core, and put it into a plug-in module. This change makes many things simpler. It lets DHCP change from a hack on top of RADIUS to a full-fledged protocol on par with RADIUS. It lets us add many more protocols, with much less effort than before. The changes mean that in the short term, the old-style "listen" sections go away, and are replaced with new-style "listen" sections. An unfortunate side-effect is that proxying is temporarily disabled, along with the "originate coa" functionality. The good news is that basic proxying is only a day or two effort away. And once that's done, the "originate coa" functionality become about 20 lines of "unlang" configuration. Where in v3, it was hundreds of lines of C code in the server core. Our tentative plan is to have an alpha release of v4 this year. We can then have official releases once we've made a bit more progress. Alan DeKok.
On 3 Jul 2017, at 12:16, Alan DeKok <aland@deployingradius.com> wrote:
There have been a lot of changes to the v4.0.x branch in the last few weeks. I thought I'd take some time to give people updates as to what's happening, and what our plans are.
As background, we've been working on re-designing the internals to remove RADIUS from the server core, and put it into a plug-in module. This change makes many things simpler. It lets DHCP change from a hack on top of RADIUS to a full-fledged protocol on par with RADIUS. It lets us add many more protocols, with much less effort than before.
The changes mean that in the short term, the old-style "listen" sections go away, and are replaced with new-style "listen" sections. An unfortunate side-effect is that proxying is temporarily disabled, along with the "originate coa" functionality.
The good news is that basic proxying is only a day or two effort away. And once that's done, the "originate coa" functionality become about 20 lines of "unlang" configuration. Where in v3, it was hundreds of lines of C code in the server core.
One of the major, fundamental, changes in v4.0.x was to remove the old proxying framework. home servers, pools, realms and even proxy.conf have all been removed in favour of unhang. The hope is that this will make for a much shallower learning curve, as proxying is now just the same as querying an SQL database, or calling a REST API. -Arran
On Jul 3, 2017, at 9:40 PM, Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:
One of the major, fundamental, changes in v4.0.x was to remove the old proxying framework. home servers, pools, realms and even proxy.conf have all been removed in favour of unhang.
The hope is that this will make for a much shallower learning curve, as proxying is now just the same as querying an SQL database, or calling a REST API.
It will unfortunately confuse the heck out of everyone who's use proxy.conf since version 0. :( Much apologies to everyone, but it's the only way to get other features in. We can always glue in proxy.conf via other methods... What's now possible in unlang: load-balance { home_server1 home_server2 home_server3 } Which is different than the old way, but means it's all just Unlang. Or fail-over: redundant { home_server1 home_server2 home_server3 } What's now trivial is this: authenticate pap { pap if (!ok) { home_server1 } } i.e. auth locally, and if that fails, proxy it. Or this: recv Accounting-Request { ... home_server1 # proxy here home_server2 # and then here home_server3 # and finally here. } Those two examples were *impossible* before. They're now trivial. Alan DeKok.
It will unfortunately confuse the heck out of everyone who's use proxy.conf since version 0.
yes but at least now it means people have to set things up a little better - the number of sites working in federated 802.1X environments that have DEFAULT for their proxy destination and thus send all irrelevant junk upstream....at least proxying can/should now be based on simply rules alan On 4 July 2017 at 02:47, Alan DeKok <aland@deployingradius.com> wrote:
On Jul 3, 2017, at 9:40 PM, Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:
One of the major, fundamental, changes in v4.0.x was to remove the old proxying framework. home servers, pools, realms and even proxy.conf have all been removed in favour of unhang.
The hope is that this will make for a much shallower learning curve, as proxying is now just the same as querying an SQL database, or calling a REST API.
It will unfortunately confuse the heck out of everyone who's use proxy.conf since version 0. :(
Much apologies to everyone, but it's the only way to get other features in. We can always glue in proxy.conf via other methods...
What's now possible in unlang:
load-balance { home_server1 home_server2 home_server3 }
Which is different than the old way, but means it's all just Unlang.
Or fail-over:
redundant { home_server1 home_server2 home_server3 }
What's now trivial is this:
authenticate pap { pap if (!ok) { home_server1 } }
i.e. auth locally, and if that fails, proxy it.
Or this:
recv Accounting-Request { ... home_server1 # proxy here home_server2 # and then here home_server3 # and finally here. }
Those two examples were *impossible* before. They're now trivial.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On 4 Jul 2017, at 04:15, Alan Buxey <alan.buxey@gmail.com> wrote:
It will unfortunately confuse the heck out of everyone who's use proxy.conf since version 0.
yes but at least now it means people have to set things up a little better - the number of sites working in federated 802.1X environments that have DEFAULT for their proxy destination and thus send all irrelevant junk upstream....at least proxying can/should now be based on simply rules
Yes now they’ll just have: switch &Realm { case ‘local.ac.uk’ { ldap eap } case { redundant { nrps0 nrps1 } } } :) We’ll see how confused people actually get. If there’s significant backlash, it’s fairly easy to create a mods-enabled/home_servers, and a policy.d/realm from a proxy.conf file. It’d almost be a drop in replacement for v3.0.x configs. -Arran
participants (3)
-
Alan Buxey -
Alan DeKok -
Arran Cudbard-Bell