People interested in the "latest and greatest" may want to hold off for the next month or so. I will be dropping much of the server on the floor, and re-arranging it. Specifically, the current listeners and state machine will be deleted. All "authorize", "authenticate", etc. sections will disappear. All "originate CoA" functionality will disappear. All detail file reading will disappear. All non-UDP functionality will disappear. Sorry about that. But it's just too hard working on the "new" code, while trying to not break functionality in the "old" code. The old code had sockets and protocol state machines welded together. The new code won't have that. I'm at the point where the new state machine works, but I can't fix the socket code without breaking compatibility with the old code. And worse, leaving the old socket code in there makes it harder to see what's going on, and harder to fix things. So... it's all going away. Once I've done my re-arrangements, I will be re-introducing TCP / TLS functionality, via a better (abstracted) system. The "originate CoA" function is already 90% there in the "rlm_radius_client" module, The detail file reading will become a socket-style input, just like UDP / TCP / TLS / whatever. And it won't be tied to RADIUS. This means that the server will get *much* better, and much more configurable. The hope is that there will even be less code, as it will be better re-arranged. The end result will be that the server core will know *nothing* about RADIUS. Which has been a goal of mine for 10+ years now. :( The RADIUS knowledge will be limited to a RADIUS transport library, a RADIUS server library, and a RADIUS client library. All told, probably 4K LoC. The rest of the server (100K+ LoC) will be RADIUS agnostic. Once that's done, adding new protocols (DHCP, DHCPv6) is really only writing a server library for the protocol, to handle the server side of the protocol state machine. Again, probably 2K to 4K LoC. The hope is to allow people to write server plugins with the same ease that you can now write module plugins. Wish me luck. :) Alan DeKok.
On Fri, Sep 02, 2016 at 09:30:36AM -0400, Alan DeKok wrote:
People interested in the "latest and greatest" may want to hold off for the next month or so. I will be dropping much of the server on the floor, and re-arranging it.
Sounds messy (and nice)! Slightly related to this, not entirely shelving v3.1.x for the time being would be good, just to give something that's got more features than v3.0.x but still works and is pretty stable. (This may be as easy as not rejecting the odd pull request against it every now and then for the time being.) Also means module development for 4.0 has somewhere stable to be tested in by more than a couple of people.
So... it's all going away. Once I've done my re-arrangements, I will be re-introducing TCP / TLS functionality, via a better (abstracted) system. The "originate CoA" function is already 90% there in the "rlm_radius_client" module, The detail file
I never managed to look at originate CoA yet - but having a module to do this that can be called as-and-when rather than being fixed in the server core sounds much more sensible.
The end result will be that the server core will know *nothing* about RADIUS. Which has been a goal of mine for 10+ years now. :( The RADIUS knowledge will be limited to a RADIUS transport library, a RADIUS server library, and a RADIUS client library. All told, probably 4K LoC. The rest of the server (100K+ LoC) will be RADIUS agnostic.
Nice! Project should rename to " Free* ", of course.
Wish me luck. :)
Sounds like you're going to need it!! Have fun. Matthew -- Matthew Newton, Ph.D. <mcn4@leicester.ac.uk> Systems Specialist, Infrastructure Services, I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom For IT help contact helpdesk extn. 2253, <ithelp@le.ac.uk>
On Sep 2, 2016, at 11:32 AM, Matthew Newton <mcn4@leicester.ac.uk> wrote:
Slightly related to this, not entirely shelving v3.1.x for the time being would be good, just to give something that's got more features than v3.0.x but still works and is pretty stable. (This may be as easy as not rejecting the odd pull request against it every now and then for the time being.)
Yes. I'm happy with bug fixes being pulled into v3.1.x, so long as I don't have to do it.
Also means module development for 4.0 has somewhere stable to be tested in by more than a couple of people.
True. The current module API won't change much for 4.0.
I never managed to look at originate CoA yet - but having a module to do this that can be called as-and-when rather than being fixed in the server core sounds much more sensible.
Yes. Want to send accounting packets to 2 destinations? recv Accounting-Request { ... radius_client_1 radius_client_2 ... } Complex configurations become much, much, easier. The downside is that as with v1 -> v2, simple configurations become more complex.
Nice! Project should rename to " Free* ", of course.
We already have a name, a web site (empty for now), and a logo.
Wish me luck. :)
Sounds like you're going to need it!!
Have fun.
Thanks. Alan DeKok.
Good luck for this important enhancement! What's it so the new name? Bye G. On Sep 2, 2016 7:11 PM, "Alan DeKok" <aland@deployingradius.com> wrote:
On Sep 2, 2016, at 11:32 AM, Matthew Newton <mcn4@leicester.ac.uk> wrote:
Slightly related to this, not entirely shelving v3.1.x for the time being would be good, just to give something that's got more features than v3.0.x but still works and is pretty stable. (This may be as easy as not rejecting the odd pull request against it every now and then for the time being.)
Yes. I'm happy with bug fixes being pulled into v3.1.x, so long as I don't have to do it.
Also means module development for 4.0 has somewhere stable to be tested in by more than a couple of people.
True. The current module API won't change much for 4.0.
I never managed to look at originate CoA yet - but having a module to do this that can be called as-and-when rather than being fixed in the server core sounds much more sensible.
Yes.
Want to send accounting packets to 2 destinations?
recv Accounting-Request { ... radius_client_1 radius_client_2 ... }
Complex configurations become much, much, easier. The downside is that as with v1 -> v2, simple configurations become more complex.
Nice! Project should rename to " Free* ", of course.
We already have a name, a web site (empty for now), and a logo.
Wish me luck. :)
Sounds like you're going to need it!!
Have fun.
Thanks.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/ list/devel.html
The end result will be that the server core will know *nothing* about RADIUS. Which has been a goal of mine for 10+ years now. :( The RADIUS knowledge will be limited to a RADIUS transport library, a RADIUS server library, and a RADIUS client library. All told, probably 4K LoC. The rest of the server (100K+ LoC) will be RADIUS agnostic.
Nice! Project should rename to " Free* ", of course.
That would thankfully mean that RedHat + CentOS won't be constrained with version backward-compatibility then! Hallelujah! :-) Stefan Paetow Moonshot Industry & Research Liaison Coordinator t: +44 (0)1235 822 125 gpg: 0x3FCE5142 xmpp: stefanp@jabber.dev.ja.net skype: stefan.paetow.janet jisc.ac.uk Jisc is a registered charity (number 1149740) and a company limited by guarantee which is registered in England under Company No. 5747339, VAT No. GB 197 0632 86. Jisc’s registered office is: One Castlepark, Tower Hill, Bristol, BS2 0JA. T 0203 697 5800.
On 09/02/2016 04:30 PM, Alan DeKok wrote:
People interested in the "latest and greatest" may want to hold off for the next month or so. I will be dropping much of the server on the floor, and re-arranging it.
Specifically, the current listeners and state machine will be deleted. All "authorize", "authenticate", etc. sections will disappear. All "originate CoA" functionality will disappear. All detail file reading will disappear. All non-UDP functionality will disappear.
Sorry about that. But it's just too hard working on the "new" code, while trying to not break functionality in the "old" code. The old code had sockets and protocol state machines welded together. The new code won't have that. I'm at the point where the new state machine works, but I can't fix the socket code without breaking compatibility with the old code.
And worse, leaving the old socket code in there makes it harder to see what's going on, and harder to fix things.
So... it's all going away. Once I've done my re-arrangements, I will be re-introducing TCP / TLS functionality, via a better (abstracted) system. The "originate CoA" function is already 90% there in the "rlm_radius_client" module, The detail file reading will become a socket-style input, just like UDP / TCP / TLS / whatever. And it won't be tied to RADIUS.
This means that the server will get *much* better, and much more configurable. The hope is that there will even be less code, as it will be better re-arranged.
The end result will be that the server core will know *nothing* about RADIUS. Which has been a goal of mine for 10+ years now. :( The RADIUS knowledge will be limited to a RADIUS transport library, a RADIUS server library, and a RADIUS client library. All told, probably 4K LoC. The rest of the server (100K+ LoC) will be RADIUS agnostic.
Once that's done, adding new protocols (DHCP, DHCPv6) is really only writing a server library for the protocol, to handle the server side of the protocol state machine. Again, probably 2K to 4K LoC. The hope is to allow people to write server plugins with the same ease that you can now write module plugins.
Wish me luck. :)
Sounds really exciting! Good luck, Alan! Nick
participants (6)
-
Alan DeKok -
Geaaru -
Matthew Newton -
Nikolai Kondrashov -
Phil Mayers -
Stefan Paetow