Next release of the server?
It's been 4 months since the last release of the server. Any objections to a new release? Are people using the v2.1.x branch in "git"? My idea would be to release this version as 2.2.0. It's stable, and doing 2.2.0 would probably be better than 2.1.13. :) I'd also like to release 3.0 in the next few months. I know I've been saying that for a while. The delays have been due to some intended design changes which haven't yet been implemented. As background, the RADIUS protocol encoder/decoder has changed to its final form in 3.0. It does more with less code, and is easier to understand. I don't think it will change again. Similarly, the state machine for handling packets has been updated in 3.0. It's a lot better than 1.x or 2.x, but it's not quite done yet. The hope is that I can do some small changes for 3.0 which will finalize the internal state machine. That will make it easier to separate the RADIUS, DHCP, and VMPS functionality in the server. It will also mean that certain new features will be easier to add. :) Alan DeKok.
On 01/04/2012 09:49 AM, Alan DeKok wrote:
I'd also like to release 3.0 in the next few months. I know I've been saying that for a while. The delays have been due to some intended design changes which haven't yet been implemented.
Will 3.0 be configuration compatible with 2.0? -- John Dennis <jdennis@redhat.com> Looking to carve out IT costs? www.redhat.com/carveoutcosts/
Hi,
Will 3.0 be configuration compatible with 2.0?
no - it is currently not - mainly because of the new methods used int he SQL/LDAP etc servers. the current config is now different to the old config...and the old config will cause the new server to fail at startup. as the new features are fundamental to its operation, having some '-compat' flag to stop new features working would be pointless - as the new code is designed around the new features. alan
Add to this, IIRC there are some differences (regressions?) in regexp support in some ancillary files (e.g. users) and a minor dictionary entry glitch that need to be worked around to use 3.0 in a 2.x config tree. I managed to "future proof" most of my configs already by installing 3.0 in a separate directory and running/debugging with "-d /etc/raddb -n confname.conf -fxx -l stdout" and fixing anything that broke. It wasn't too hard in my case. YMMV. -----Original Message----- From: freeradius-users-bounces+bjulin=clarku.edu@lists.freeradius.org [mailto:freeradius-users-bounces+bjulin=clarku.edu@lists.freeradius.org] On Behalf Of Alan Buxey Sent: Wednesday, January 04, 2012 1:00 PM To: FreeRadius users mailing list Cc: Alan DeKok Subject: Re: Next release of the server? Hi,
Will 3.0 be configuration compatible with 2.0?
no - it is currently not - mainly because of the new methods used int he SQL/LDAP etc servers. the current config is now different to the old config...and the old config will cause the new server to fail at startup. as the new features are fundamental to its operation, having some '-compat' flag to stop new features working would be pointless - as the new code is designed around the new features. alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Brian Julin wrote:
Add to this, IIRC there are some differences (regressions?) in regexp support in some ancillary files (e.g. users)
I don't recall that... it *should* be compatible.
and a minor dictionary entry glitch that need to be worked around to use 3.0 in a 2.x config tree.
Which is... ? The dictionaries in 3.0 are simpler than the ones in 2.x. The whole "BEGIN-TLV" and "END-TLV" nonsense is gone. Alan DeKok.
________________________________________ Alan DeKok [aland@deployingradius.com] wrote:
Brian Julin wrote:
Add to this, IIRC there are some differences (regressions?) in regexp support in some ancillary files (e.g. users)
I don't recall that... it *should* be compatible.
For example, a line like this in a hints file: DEFAULT User-Name =~ "foo" ...which works for a 2.x server will cause this: hints_test[4]: Parse error (check) for entry DEFAULT: No regular expression found in User-Name rlm_preprocess: Error reading hints_test ...in 3.0 I tried to track it down at the time, but I got pretty lost. It seemed like an extra token was being dropped into the processing, but that's a wild-ass guess. At the time I didn't know whether the syntax had changed for regexp in check lines, so wasn't sure whether it was a bug or not, and I was leaning towards ditching hints in favor of unlang anyway.
and a minor dictionary entry glitch that need to be worked around to use 3.0 in a 2.x config tree.
Which is... ?
If you run 3.0 on 2.x dictionaries you need to exclude dictionary.dhcp because something in there does this: including dictionary file /etc/raddb/dictionary Errors reading dictionary: dict_init: /usr/share/freeradius/dictionary.dhcp[202]: Type "tlv" can only be for "format=1,1".
Brian Julin wrote:
For example, a line like this in a hints file:
DEFAULT User-Name =~ "foo"
...which works for a 2.x server will cause this:
hints_test[4]: Parse error (check) for entry DEFAULT: No regular expression found in User-Name rlm_preprocess: Error reading hints_test
Ah. That's a bug. I'll fix that before 3.0.
If you run 3.0 on 2.x dictionaries
Don't. Just... don't. Alan DeKok.
Alan DeKok wrote:
If you run 3.0 on 2.x dictionaries Don't. Just... don't.
In that case, it might help to document the "dictionary =" main configuration item. Patch attached. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Alan Buxey wrote:
no - it is currently not - mainly because of the new methods used int he SQL/LDAP etc servers. the current config is now different to the old config...and the old config will cause the new server to fail at startup. as the new features are fundamental to its operation, having some '-compat' flag to stop new features working would be pointless - as the new code is designed around the new features.
There is still some backwards compatibility code in 3.0 which I think should be removed. Features to support wrong functionality... that later got fixed. For 3.0, it should be just "use the new features" Alan DeKok.
On 01/05/2012 10:41 AM, Alan DeKok wrote:
Alan Buxey wrote:
no - it is currently not - mainly because of the new methods used int he SQL/LDAP etc servers. the current config is now different to the old config...and the old config will cause the new server to fail at startup. as the new features are fundamental to its operation, having some '-compat' flag to stop new features working would be pointless - as the new code is designed around the new features.
There is still some backwards compatibility code in 3.0 which I think should be removed. Features to support wrong functionality... that later got fixed. For 3.0, it should be just "use the new features"
As a package distributor where users install new package versions this is really critical to understand and get right so let me rephrase what I think I've heard to make sure we're all on the same page. Version 3.x is 100% configuration compatible with version 2.x. If someone installs 3.x over an existing 2.x install everything will run as it did in 2.x, however 3.x features will not be enabled (because they exist in the 3.x configuration files which did not replace the existing 2.x configuration files during the upgrade). This is guaranteed behavior. Is this true? -- John Dennis <jdennis@redhat.com> Looking to carve out IT costs? www.redhat.com/carveoutcosts/
John Dennis wrote:
Version 3.x is 100% configuration compatible with version 2.x.
No. Some things have changed. Even 2.2.0 will NOT be 100% compatible with 2.1.12. e.g. the "passwd" file has a configuration entry *forbidden*. It used to be marked "do not use". People used it. And then complained that things went wrong. So... marking it forbidden solves that problem. I don't recall the details now, but 3.0 is *not* a drop-in replacement for 2.x. As I tried to say, some old / broken behavior in 2.0 is not just deprecated, it's *gone*. The new way is better. The migration shouldn't be difficult, but it will be a migration. The alternative would be to keep config file compatibility with 0.x, which I can't afford to do. Alan DeKok.
On 01/05/2012 12:01 PM, Alan DeKok wrote:
John Dennis wrote:
Version 3.x is 100% configuration compatible with version 2.x.
No.
O.K. fair enough, I really wasn't expecting 3.x to be configuration compatible with 2.x. This then begs the question: What are the support plans for 2.x once 3.x is released? There is going to be a period of time where 2.x deployments will continue to exist and folks will not want to experience the pain and disruption of upgrading to the new 3.x version. What will happen when problems are discovered in the last 2.x release? Will they be fixed and a new 2.x released in parallel with 3.x or will folks be told their only option is to perform a 2.x to 3.x version upgrade? -- John Dennis <jdennis@redhat.com> Looking to carve out IT costs? www.redhat.com/carveoutcosts/
Hi,
This then begs the question: What are the support plans for 2.x once 3.x is released?
depends....on what you mean by support..and WHAT support. if you are thinking freeradius-users mailing list, then that depends on the mix of people on there.... i think that 2.x is close enough to 3.x that MOST things will be the same...eg unlang etc....but what i believe will happen will be similar to 1.x to 2.x - as more people move to 3.x then the support for 2.x will drop away.... given a year or two, anyone asking about 2.0.x or 2.1.x will probably be told to use 2.2.x or 3.x and 1.x queries will be just TOTALLY ignored :-) when 3.x is finally released, we will probably move wholesale to it so my 'on hand' 2.x systems will be gone...and I'll be telling people to upgrade to 3.x :-)
disruption of upgrading to the new 3.x version. What will happen when problems are discovered in the last 2.x release? Will they be fixed and a new 2.x released in parallel with 3.x or will folks be told their only option is to perform a 2.x to 3.x version upgrade?
there were SOME 1.x released (security/bug) - i'd expect, in short term that such will happen with 2.2.x - but anything that needs the new process engine etc will be 3.x - no backport alan
John Dennis wrote:
This then begs the question: What are the support plans for 2.x once 3.x is released?
2.2.x will be marked "stable" and "long term support", just like 1.1.x. The 1.1.x releases will no longer be supported for *anything*. 2.0 was released 4 years ago. There is no reason for anyone to be running 1.x.
There is going to be a period of time where 2.x deployments will continue to exist and folks will not want to experience the pain and disruption of upgrading to the new 3.x version. What will happen when problems are discovered in the last 2.x release?
People can submit patches to fix them. Or, perhaps they can purchase a support contract to help fund continuing development.
Will they be fixed and a new 2.x released in parallel with 3.x or will folks be told their only option is to perform a 2.x to 3.x version upgrade?
What happened with 1.x and 2.x? Alan DeKok.
On Fri, Jan 6, 2012 at 12:01 AM, Alan DeKok <aland@deployingradius.com> wrote:
John Dennis wrote:
Version 3.x is 100% configuration compatible with version 2.x.
No.
Some things have changed. Even 2.2.0 will NOT be 100% compatible with 2.1.12. e.g. the "passwd" file has a configuration entry *forbidden*. It used to be marked "do not use". People used it. And then complained that things went wrong. So... marking it forbidden solves that problem.
Is there a list for (planned) 2.2.0 vs 2.1.12 incompatible configuration directive? I'm using quite a number of 2.1.12 in my setup, and it was backward-compatible with previous versions (e.g. 2.1.7), so the "maintenance" process is usually something as simple as "upgrade all installations, but only change the config when you need to use some new features". If the difference is on things that I don't use, then I'd stick with that upgrade pattern. If not, then I'd probably freeze my implementation at 2.1.12 and create new FR-2.2 packages (or even skip directly to 3.0) -- Fajar
Fajar A. Nugraha wrote:
Is there a list for (planned) 2.2.0 vs 2.1.12 incompatible configuration directive?
The one change to rlm_passwd. That's it.
I'm using quite a number of 2.1.12 in my setup, and it was backward-compatible with previous versions (e.g. 2.1.7), so the "maintenance" process is usually something as simple as "upgrade all installations, but only change the config when you need to use some new features".
2.2.0 is explicitly compatible with 2.1.12. The only change is to fix something which was *broken* in 2.1.12. Alan DeKok.
On Fri, Jan 6, 2012 at 7:59 PM, Alan DeKok <aland@deployingradius.com> wrote:
Fajar A. Nugraha wrote:
Is there a list for (planned) 2.2.0 vs 2.1.12 incompatible configuration directive?
The one change to rlm_passwd. That's it.
Glad to hear it :D Looking forward to the release. -- Fajar
Hi,
2.2.0 is explicitly compatible with 2.1.12. The only change is to fix something which was *broken* in 2.1.12.
Is there really much point in calling it 2.2.0 then? If people don't like a "13" patch-level number, it could also be called 2.1.14 :-) Cranking up the minor version number just leads to many people asking the kind of "can I upgrade" questions we've just gone through. Greetings, Stefan Winter -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473
Stefan Winter wrote:
Is there really much point in calling it 2.2.0 then? If people don't like a "13" patch-level number, it could also be called 2.1.14 :-)
Perhaps.
Cranking up the minor version number just leads to many people asking the kind of "can I upgrade" questions we've just gone through.
Yeah... I'm not fixed on any one version number. Alan DeKok.
On 05/01/12 16:54, John Dennis wrote:
On 01/05/2012 10:41 AM, Alan DeKok wrote:
Alan Buxey wrote:
no - it is currently not - mainly because of the new methods used int he SQL/LDAP etc servers. the current config is now different to the old config...and the old config will cause the new server to fail at startup. as the new features are fundamental to its operation, having some '-compat' flag to stop new features working would be pointless - as the new code is designed around the new features.
There is still some backwards compatibility code in 3.0 which I think should be removed. Features to support wrong functionality... that later got fixed. For 3.0, it should be just "use the new features"
As a package distributor where users install new package versions this is really critical to understand and get right so let me rephrase what I think I've heard to make sure we're all on the same page.
Version 3.x is 100% configuration compatible with version 2.x. If someone installs 3.x over an existing 2.x install everything will run as it did in 2.x, however 3.x features will not be enabled (because they exist in the 3.x configuration files which did not replace the existing 2.x configuration files during the upgrade). This is guaranteed behavior.
Is this true?
I don't think so. 3.x contains a connection pool abstraction. At least one module (SQL) has been converted to use this abstraction, and the old config directives are not processed, and the server will not start without the new directives present. There might be an argument to process the old config items into an internally-created pool statement and print a BIG WARNING. Then again, maybe not.
If it isn't secret, where is the DHCP functionality on the priority list ? On 1/4/2012 3:49 PM, Alan DeKok wrote:
The hope is that I can do some small changes for 3.0 which will finalize the internal state machine. That will make it easier to separate the RADIUS, DHCP, and VMPS functionality in the server. It will also mean that certain new features will be easier to add. :)
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Marinko Tarlać wrote:
If it isn't secret, where is the DHCP functionality on the priority list ?
A number of DHCP fixes have gone into the 3.0 branch. The server is now a DHCP relay. The only DHCP related fix is to have the server allocate leases from SQL. That requires changes to rlm_sqlippool, or an SQL procedure, or a Perl script. As always, patches are welcome. Alan DeKok.
I'm not a developer but I will try to help as much as I can. Marinko On 1/6/2012 3:08 PM, Alan DeKok wrote:
Marinko Tarlać wrote:
If it isn't secret, where is the DHCP functionality on the priority list ? A number of DHCP fixes have gone into the 3.0 branch. The server is now a DHCP relay.
The only DHCP related fix is to have the server allocate leases from SQL. That requires changes to rlm_sqlippool, or an SQL procedure, or a Perl script.
As always, patches are welcome.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Sat, Jan 7, 2012 at 5:55 AM, Marinko Tarlac <mangia81@gmail.com> wrote:
I'm not a developer but I will try to help as much as I can.
@Marinko: If you use Ubuntu, I've just uploaded a new package to my unofficial ppa: https://launchpad.net/~freeradius/+archive/testing-2.x The master (3.0) branch is still missing some DHCP-related improvements present on v2.1.x, so if you want to do some DHCP-testing better stick with v2.1.x for now. The ppa is currently: - based on latest v2.1.x git commit (5fedd50), which already include some config file improvements needed to have a working DHCP server with dynamic and "static" IP assignment - has some additional patches to make testing easier (e.g. comments on how to use "static" IP assignement) - has dhcp functionality compiled-in, so only some configuration change is neeed to use the functionality (see comments /etc/freeradius/sites-available/dhcp) You can also compile yourself from v2.1.x git branch, but if you do that you (currently) still need to modify some config files manually. Let us know how your testing goes. -- Fajar
Marinko
On 1/6/2012 3:08 PM, Alan DeKok wrote:
Marinko Tarlać wrote:
If it isn't secret, where is the DHCP functionality on the priority list ?
A number of DHCP fixes have gone into the 3.0 branch. The server is now a DHCP relay.
The only DHCP related fix is to have the server allocate leases from SQL. That requires changes to rlm_sqlippool, or an SQL procedure, or a Perl script.
As always, patches are welcome.
Hi Fajar Thank you very much for your time. I'm using CentOS so I'll try with the latest 2.1.x from git The problem which bothers me is that I need more than classic ip-mac pairing. Beside the IP address I need to return a few other parameters to cable modems/MTA. For example ISC DHCP config for regular modems is: host blaBlaBla { filename "confingFile.cm"; fixed-address 192.168.12.167; hardware ethernet 00:cc:ab:11:cc:22; } As you can see, I'm returning the IP address and the name for config file. Is this possible with FreeRadius DHCP ? ISC DHCP can't cooperate with database (maybe omapi but I hate it) Best regards On 24.1.2012 10:05, Fajar A. Nugraha wrote:
On Sat, Jan 7, 2012 at 5:55 AM, Marinko Tarlac<mangia81@gmail.com> wrote:
I'm not a developer but I will try to help as much as I can.
@Marinko: If you use Ubuntu, I've just uploaded a new package to my unofficial ppa: https://launchpad.net/~freeradius/+archive/testing-2.x
The master (3.0) branch is still missing some DHCP-related improvements present on v2.1.x, so if you want to do some DHCP-testing better stick with v2.1.x for now.
The ppa is currently: - based on latest v2.1.x git commit (5fedd50), which already include some config file improvements needed to have a working DHCP server with dynamic and "static" IP assignment - has some additional patches to make testing easier (e.g. comments on how to use "static" IP assignement) - has dhcp functionality compiled-in, so only some configuration change is neeed to use the functionality (see comments /etc/freeradius/sites-available/dhcp)
You can also compile yourself from v2.1.x git branch, but if you do that you (currently) still need to modify some config files manually.
Let us know how your testing goes.
2012/1/24 Marinko Tarlać <mangia81@gmail.com>:
Hi Fajar
Thank you very much for your time.
I'm using CentOS so I'll try with the latest 2.1.x from git
Some of the config files in my ppa might be useful for you as well. These two files are a bit different to the one in Alan's tree, but it might help you create an implementation example that's suitable for your setup: - https://github.com/fajarnugraha/freeradius-server/blob/v2.1.x-dhcp/raddb/sit... - https://github.com/fajarnugraha/freeradius-server/blob/v2.1.x-dhcp/raddb/pol...
The problem which bothers me is that I need more than classic ip-mac pairing. Beside the IP address I need to return a few other parameters to cable modems/MTA.
For example ISC DHCP config for regular modems is:
host blaBlaBla { filename "confingFile.cm"; fixed-address 192.168.12.167; hardware ethernet 00:cc:ab:11:cc:22; }
As you can see, I'm returning the IP address and the name for config file.
Is this possible with FreeRadius DHCP ?
Should be. The IP address assignment (whether static or dynamic) is easy enough with a special instance of sqlipool like in the example. If you only want static IP then you can even use only files without db. As for the filename, dictionary.dhcp has DHCP-Boot-Filename attribute, though I haven't tried it. If you use the same filename for all clients, then just do it like DHCP-Router-Address in the example (i.e. put the attribute inside an "update reply" block). If each client has it's own file, creating a custom table to store ip <-> filename mapping and using sql expansion (%{sql: SELECT ....}) is the easy way to do it. Try it, and start a new thread to post your progress later. -- Fajar
participants (9)
-
Alan Buxey -
Alan DeKok -
Brian Julin -
Fajar A. Nugraha -
John Dennis -
Marinko Tarlac -
Marinko Tarlać
-
Phil Mayers -
Stefan Winter