Hi all, I've been looking at the freeradius 2.0pre versions, and first, I want to say nice work. The new features look wonderful. I'm a little concerned about the upgrade path for distributions, though, and I wanted to raise it as an issue for consideration. I am fully aware that it may be unfixable. It appears now that a 1.x config file will not be parsed by a 2.x server, and you'll be left with a non-functioning radius service after an upgrade. This makes me feel like the right upgrade path for distributions is to ship the new version as freeradius2 (complete with /etc/freeradius2, /usr/sbin/freeradius2, and so on). This would allow admins to coinstall the two versions, and plan an orderly migration, rather than just break the existing setup. As you can imagine, this introduces quite a bit of divergence that I really do not want to add. It also means that we will have to ship the last version of freeradius 1.x code to provide an upgrade path, which means maintaining 2 code bases instead of one for the next several years, which I also really don't want to do. (Not that freeradius is in general a difficult package to maintain - thanks to everyone for a stable and secure server). I'm just hoping to put the issue on people's radar if it is able to be worked around. If it's not, then I'll just bite the bullet and make the divergence, but I was really hoping not to. Thanks all, -- -------------------------------------------------------------------------- | Stephen Gran | All science is either physics or stamp | | steve@lobefin.net | collecting. -- Ernest Rutherford | | http://www.lobefin.net/~steve | | --------------------------------------------------------------------------
Stephen Gran wrote:
I've been looking at the freeradius 2.0pre versions, and first, I want to say nice work. The new features look wonderful.
Much, much, better.
I'm a little concerned about the upgrade path for distributions, though, and I wanted to raise it as an issue for consideration. I am fully aware that it may be unfixable. It appears now that a 1.x config file will not be parsed by a 2.x server, and you'll be left with a non-functioning radius service after an upgrade.
There is that distinct possibility. While every effort has been made to ensure backwards compatibility, some things just aren't worth fixing.
This makes me feel like the right upgrade path for distributions is to ship the new version as freeradius2 (complete with /etc/freeradius2, /usr/sbin/freeradius2, and so on). This would allow admins to coinstall the two versions, and plan an orderly migration, rather than just break the existing setup.
I understand... but it's pretty awkward. How is this handled for other packages?
I'm just hoping to put the issue on people's radar if it is able to be worked around. If it's not, then I'll just bite the bullet and make the divergence, but I was really hoping not to.
I *really* don't want to see a "freeradius2" anywhere. It's already confusing enough to have Debian install the binary as "freeradius", rather than "radiusd". Since the existing Debian "radiusd" binaries are from RADIUS servers that haven't been maintained for years, people get confused. Anyways... I'm not sure what to do here. Breaking peoples existing systems is bad, but upgrading is useful, too. I *don't* want Debian to take the RedHat route of shipping versions of software that are 5 years out of date... Alan DeKok.
Alan DeKok wrote:
Stephen Gran wrote:
This makes me feel like the right upgrade path for distributions is to ship the new version as freeradius2 (complete with /etc/freeradius2, /usr/sbin/freeradius2, and so on). This would allow admins to coinstall the two versions, and plan an orderly migration, rather than just break the existing setup.
I understand... but it's pretty awkward. How is this handled for other packages?
Debian has two packages "apache" and "apache2". (among other examples) -- Nicolas Baradakis
On Sun 02 Sep 2007, Nicolas Baradakis wrote:
Alan DeKok wrote:
Stephen Gran wrote:
This makes me feel like the right upgrade path for distributions is to ship the new version as freeradius2 (complete with /etc/freeradius2, /usr/sbin/freeradius2, and so on). This would allow admins to coinstall the two versions, and plan an orderly migration, rather than just break the existing setup.
I understand... but it's pretty awkward. How is this handled for other packages?
Debian has two packages "apache" and "apache2". (among other examples)
Yes. SUSE handles things in a similar manner. I suggest however that this time around we solve the problem by renaming to "freeradius-server" given that we now have a "freeradius-client". This doesn't solve the issue of having version 1.x and 2.x installed side by side, but at least it means that there is not a package name conflict. Regards -- Peter Nixon http://peternixon.net/
Peter Nixon wrote:
I suggest however that this time around we solve the problem by renaming to "freeradius-server" given that we now have a "freeradius-client".
Er, yes. We've discussed that before. I'm losing... something. I'll remember in a bit.
This doesn't solve the issue of having version 1.x and 2.x installed side by side, but at least it means that there is not a package name conflict.
Maybe debian can put things into /etc/freeradius, instead of /etc/raddb. I do dislike version numbers in filenames. And why not call the binary "radiusd"? I know it conflicts with Debian's xtradius, etc. But geez, does anyone *really* use that stuff any more? Alan DeKok.
On Sun, Sep 02, 2007 at 03:59:51PM +0200, Alan DeKok said:
Peter Nixon wrote:
This doesn't solve the issue of having version 1.x and 2.x installed side by side, but at least it means that there is not a package name conflict.
Maybe debian can put things into /etc/freeradius, instead of /etc/raddb. I do dislike version numbers in filenames.
We already do, and that's part of the problem here, unfortunately. Trust me, I'm not loving the new package name idea and all that goes with it.
And why not call the binary "radiusd"? I know it conflicts with Debian's xtradius, etc. But geez, does anyone *really* use that stuff any more?
Heh, probably not, but since we ship a bunch of radiusd's, I think it would be impolite to take the name unilaterally. That's why apache is shipped as apache/apache2 rather than httpd, for instance. -- -------------------------------------------------------------------------- | Stephen Gran | A prohibitionist is the sort of man one | | steve@lobefin.net | wouldn't care to drink with -- even if | | http://www.lobefin.net/~steve | he drank. -- H. L. Mencken | --------------------------------------------------------------------------
Stephen Gran wrote:
We already do, and that's part of the problem here, unfortunately. Trust me, I'm not loving the new package name idea and all that goes with it.
Well, we're moving to calling the tarballs 'freeradius-server", because the project is becoming bigger than just a RADIUS server.
And why not call the binary "radiusd"? I know it conflicts with Debian's xtradius, etc. But geez, does anyone *really* use that stuff any more?
Heh, probably not, but since we ship a bunch of radiusd's, I think it would be impolite to take the name unilaterally.
Yeah, but speaking as a (cough) completely unbiased observer, those other RADIUS servers *suck*. And I'm not talking about features. Who in their right mind would deploy a critical server which hasn't had a release or a post to it's mailing list in 3 years?
That's why apache is shipped as apache/apache2 rather than httpd, for instance.
Yeah, it doesn't mean I like it. And realistically speaking, 1.1.x isn't strictly backwards compatible, either. People have *had* to upgrade at some point. Once 2.0 is released, I *very* much doubt we'll continue with development on the 1.1.x branch. The new features are so powerful that it's just too painful to use 1.1.x any more. Alan DeKok.
On Sun 02 Sep 2007, Alan DeKok wrote:
Stephen Gran wrote:
We already do, and that's part of the problem here, unfortunately. Trust me, I'm not loving the new package name idea and all that goes with it.
Well, we're moving to calling the tarballs 'freeradius-server", because the project is becoming bigger than just a RADIUS server.
And why not call the binary "radiusd"? I know it conflicts with Debian's xtradius, etc. But geez, does anyone *really* use that stuff any more?
Heh, probably not, but since we ship a bunch of radiusd's, I think it would be impolite to take the name unilaterally.
Yeah, but speaking as a (cough) completely unbiased observer, those other RADIUS servers *suck*. And I'm not talking about features. Who in their right mind would deploy a critical server which hasn't had a release or a post to it's mailing list in 3 years?
Yeah, for the record though, I am all for using /etc/freeradius and using /usr/sbin/freeradiusd as the binary.
That's why apache is shipped as apache/apache2 rather than httpd, for instance.
Yeah, it doesn't mean I like it.
And realistically speaking, 1.1.x isn't strictly backwards compatible, either. People have *had* to upgrade at some point.
Once 2.0 is released, I *very* much doubt we'll continue with development on the 1.1.x branch. The new features are so powerful that it's just too painful to use 1.1.x any more.
We should keep in mind however that there are distros that maintain backwards compatibility and support for up to 7 years. I am not saying we should go out of our way, but if its not difficult we should address any major security issues found in the 1.1.x branch for a while to come at least.. New features for 1.1.x would of course be a complete waste of energy. Regards -- Peter Nixon http://peternixon.net/
Peter Nixon wrote:
Yeah, for the record though, I am all for using /etc/freeradius and using /usr/sbin/freeradiusd as the binary.
Yeah. That change should be made before 2.0 is released...
We should keep in mind however that there are distros that maintain backwards compatibility and support for up to 7 years. I am not saying we should go out of our way, but if its not difficult we should address any major security issues found in the 1.1.x branch for a while to come at least..
Yes.
New features for 1.1.x would of course be a complete waste of energy.
I just converted the entire CVS tree (including history) to Mercurial. It's smaller than the CVS tree, but still about 35M. It took an hour or so on my laptop. I'll put it up on hg.freeradius.org. After that, I may just start using it full-time, while syncing CVS & mercurial. What does this have to do with 1.1.x? If we're using a cheap & sane version control system, it's easier to back-port fixes, and it's easier to pull in features. e.g. I'd prefer to put third-party patches into an "untrusted" tree, where they won't be lost... if they stay on web sites or on mailing lists, they will get lost. And git? All I can say is "git commit" versus "git commit -a". Ouch. If git ends up being superior to mercurial, they two systems are compatible enough that the trees can be converted. Alan DeKok.
Hi,
And realistically speaking, 1.1.x isn't strictly backwards compatible, either. People have *had* to upgrade at some point.
Once 2.0 is released, I *very* much doubt we'll continue with development on the 1.1.x branch. The new features are so powerful that it's just too painful to use 1.1.x any more.
hmm, on the other hand, is there any way in which we could migrate 1.1.x installations to 2.0 - eg upgrade SQL schema, convert their tables so User-Password -> Cleartext-Password (and change operator)... the issue are those folk that have edited their conf files so badly/much that there is no way of parsing them easily.... though perhaps using a 1.1.x radiusd engine to parse the options and to spew them out as a radiusd 2.x config file? alan
A.L.M.Buxey@lboro.ac.uk wrote:
hmm, on the other hand, is there any way in which we could migrate 1.1.x installations to 2.0 - eg upgrade SQL schema, convert their tables so User-Password -> Cleartext-Password (and change operator)... the issue are those folk that have edited their conf files so badly/much that there is no way of parsing them easily.... though perhaps using a 1.1.x radiusd engine to parse the options and to spew them out as a radiusd 2.x config file?
"Yuck". It's easier to just document how to fix it, I think. Alan DeKok.
Ala DeKok said:
How is this handled for other packages?
[I'm kinda playing Devils Advocate here, with my BOFH hat on] Well, if you do it the 'sendmail' way, you just put out the new version, let it silently screw up everyone's installs, then shrug and say "Oooops". And there is something to be said for that approach. As a sendmail guru said to me when I bitched about it, "that's why package managers have exceptions lists." So you can put your mission critical services on them, and handle updates yourself, rather than expecting 'yum' or 'up2date' to do your job for you. If individual package maintainers wish to be a little more helpful, or have contractual obligations to provide backward compatibility, they have the option to provide a separate v2 package. But other than maybe moving v2 into /etc/freeradius and changing the binary name, that's not really your problem. So my $0.02 is to look at this as an opportunity to drag everyone kicking and screaming into the Brave New World of FR2/unlang, and not lose any sleep over it. Cut people too much slack, and we'll still be dealing with 1.0.3 in another 5 years. Just remind me to be on vacation the week it hits the streets. ;)
Alan DeKok.
-- hugh
participants (6)
-
A.L.M.Buxey＠lboro.ac.uk -
Alan DeKok -
Hugh Messenger -
Nicolas Baradakis -
Peter Nixon -
Stephen Gran