Changelog
freeradius (2.1.10+dfsg-2) unstable; urgency=medium
* The zombie period start time variable mistakenly got set to a random
value because of an upstream typo. Cherry-picked upstream commit
7b7dff7724721f8af5fd163f2292d427a869992d into a Debian patch,
requested for squeeze in #600465.
* Since 2.1.9, the daemon stopped reopening the default radius.log file
constantly, which means the default logrotate setup breaks the default
logging. D'oh. We now have to send SIGHUP to the daemon as a postrotate
action, which makes it reopen log files and continue normally.
* Added delaycompress to the logrotate options, just to be on the safe
side.
* Added a reload action into the init script accordingly, so that the
right pidfile is picked up (one that can be overridden by the admin
in /etc/default/freeradius, available since the last release).
* Called reload from the postrotate section, closes: #602815.
* However, the latter signal also makes the server re-read configuration
files, but unlike the initial server start, this all happens under
the unprivileged user. That in turn means that if by any chance there
is any part of FR configuration that happens not to be readable by
group freerad (or whatever non-default is configured), the reload
will fail, effectively silently, as the log has been moved away. Gah.
So we have to make an effort to ensure that the configuration files
are still readable by that user, otherwise the reload fails and the
aforementioned bug is not fixed. The files seem to revert to
root:root upon conffile actions, at least that's what happened to me
and I think that was the cause. So, on upgrade, try to re-apply the
dpkg-statoverrides on our /etc/freeradius/* stuff, whatever they are,
under the assumption they will let the freerad group read config files
as is the initial setup. (I wish dpkg-statoverride --update $file
just did the right thing, but it doesn't, so there's a new local
function that does that.)
* While doing the latter, noticed that we were checking for directories
in dpkg-statoverride --list output with trailing slashes, but they
get output without it, so it was a no-op. Fixed the check by removing
the trailing slashes. Also then noticed that we were grepping --list
output, but it takes an optional glob pattern, so saved us that
pointless grep fork by using that facility, just as described in the
policy manual.
* force-reload switches from restart to reload, per policy 9.3.2.
* lenny backport needed also libltdl-dev (2.2.x) to build properly, rather
than libltdl3-dev, which is obsolete and doesn't make sense anyway.
-- Josip Rodin <email address hidden> Sat, 13 Nov 2010 15:21:30 +0100
