freeradius upgrade broken in hardy backports
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
freeradius (Ubuntu) |
Won't Fix
|
Undecided
|
Unassigned |
Bug Description
When upgrading from freeradius 1.1.7 to freeradius 2.1.0 from the hardy backports repository, the upgrade isn't clean, and left freeradius on my system unusable without remediation.
It seems that the freeradius package from 1.1.7 has been split into several smaller packages in 2.1.0, and while the upgrade correctly pulls in the new freeradius-common package, it doesn't also pull in the also new freeradius-utils package as a dependency. This means that many binaries, such as "radtest", that were previously installed, are no longer available, until the new "-utils" package is installed.
Additionally, there seem to be issues with the supplied configuration and initscripts.
With the configuration as delivered by the package, freeradius won't start due to configuration errors, where files that don't exist are pulled in using "$INDLUDE". The main issue here is with some of the SQL config files. Commenting out the relevant $INCLUDE lines in /etc/freeradius
The initscript gives the impression that the daemon should use "/var/run/
If I create that directory, then a PIDFILE is created correctly, but when shutting down freeradius, the initscript looks for the configured PIDFILE in /var/run/
Has anyone else had this issue? I can't see any other bugs relating to it here on launchpad, but maybe I just got here first...
Cheers.
Dameon.
Performing automated upgrades across major revision numbers of a program isn't recommended.
There are a large number of changes in the configuration files and in their processing from version 1.1.x to version 2.1.x. Writing scripts to do automated upgrades is extremely difficult. The upgrade process MUST be done by hand.
My suggestion is that the 2.1.x installer check the major version number of the previously installed package. If they don't match, it should refuse to do the upgrade.