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.