freeradius upgrade broken in hardy backports

[Dameon Wagner]

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/radiusd.conf means that `freeradius -XC` has a return code of 0, indicating the config is clean, and freeradius will then start.

The initscript gives the impression that the daemon should use "/var/run/freeradius/freeradius.pid" as it's $PIDFILE, and that if the containing directory doesn't exist, it will be created. This only partially happens -- the directory is created, and correctly chown'd, but no PIDFILE is created within it. However, a logentry in "/var/log/freeradius/radius.log" states: "Error: Failed creating PID file /var/run/radiusd/radiusd.pid: No such file or directory".

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/freeradius, doesn't find it, and therefore can't kill the process, leaving freeradius running, and un-restartable (it can't bind to it's socket, because it's already in use, by the previous, unstopped, freeradius process), leaveing the system in an inconsistent state -- the PIDFILE, which isn't used, says one thing, but `ps aux | grep rad` says another. Editing the initscript seems to clear up this ambiguity, but it's not a clean fix as it means that it's no longer in sync with the repository package, and while that's usually OK and expected with config files, it's not normally a good idea for initscripts.

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.

[Alan DeKok (aland-freeradius)]

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.

[Dameon Wagner (d-wagner-ru)]

I understand that it might not be recommended to do cross major version upgrades, but it is one of the (usually) strong points of the APT system, and indeed, I've rarely had any issues doing such things in the past. However, normally there's a ncurses dialog that mentions a few things, possibly warns about issues that might be faced, and often offers to show the admin a diff of old vs. new configuration files (not that that is always easy between major revisions, due to changes in config syntax and options). What I take issue with is that there weren't any of these warnings to enlighten me.

What I see as the main issue here is the inconsistency of the package itself, not that it's a cross major version upgrade. Indeed, the major issue, other than the post-upgrade missing binaries (that was easily fixed by installing the errant package) is that the NEW radiusd.conf and the NEW initscript don't match, and from what I can gather, this would also have been the had I installed freeradius 2.1.0 fresh, rather than as an upgrade. The simple matter is that the installed radiusd.conf configures the daemon to use "/var/run/radiusd/radiusd.pid" as it's PIDFILE, where as the initscript chooses to use "/var/run/freeradius/freeradius.pid".

Other than the SQL $INDCLUDE files issue (which probably don't need to be there by default, and are likely useless without further configuration by the system admin), the matter of the pidfiles should be a simple and inconsequential fix -- I don't really care which way round it goes, but radiusd.conf and the daemon's initscript need to agree on where the PIDFILE is going to go, and what it's called.

I've attached a small patch that fixes both non-existant $INCLUDE and PIDFILE issues. It works for me.

[Alan DeKok (aland-freeradius)]

OK. I've put similar patches into git head (stable && master branches). They should be in the next major release of the server (2.1.4)

[Dameon Wagner (d-wagner-ru)]

Brilliant, thanks Alan.

[Chuck Short (zulcss)]

Nearly all of these issues have been resolved in karmic. Maybe the backporters would like to fix it.

Regards
chuck

[Chuck Short (zulcss)]

Nearly all of these issues have been resolved in karmic. Maybe the backporters would like to fix their backport.

Regards
chuck

[Robert C Jennings (rcj)]

Marking as "won't fix" due to hardy EOL.