[Bug 315896] [NEW] freeradius upgrade broken in hardy backports

[Launchpad Bug Tracker]

You have been subscribed to a public bug:

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.

** Affects: freeradius (Ubuntu)
     Importance: Undecided
         Status: New

-- 
freeradius upgrade broken in hardy backports
https://bugs.launchpad.net/bugs/315896
You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to freeradius in ubuntu.