On Sun, Mar 05, 2023 at 06:45:59PM +0100, Guillem Jover wrote:
> After upgrade, something that used to work stopped working, which
> seemed appropriate to me, but if you disagree I don't feel like
> arguing over this.
Debian decided that support for non-systemd init systems is optional and
that we're allowed to use systemd features. I am not a systemd fanboi,
but I see its advantages and have committed to using its features and I
feel that it's fair to leave the work of supporting non-systemd init
systems to the users of those init systems. Thanks for helping here, and
I will try to be as accomodating as possible while not spending too much
time myself. My focus therefore is not to break systemd systemd and not
to add ballast.
> -if command -v systemd-sysusers >/dev/null; then
> +if command -v adduser >/dev/null; then
> + # XXX: Use deprecated options to handle a smooth partial upgrade,
> + # switch the the new options after bookworm's release.
> + adduser --system --group --force-badname --quiet \
> + --no-create-home --home /var/lib/aide --shell /usr/sbin/nologin \
> + ---gecos 'Advanced Intrusion Detection Environment' _aide
> +elif command -v systemd-sysusers >/dev/null; then
> systemd-sysusers
> fi
I am not sure whether calling systemd-sysusers from postinst is still
necessary if dh_installsysusers is used, so I'll adapt this after
testing the new dh_installsysusers stuff.
> # added updating to 0.18-1
> rm -rf /var/tmp/aide.cron.daily /var/tmp/aide.cron.daily.old.*
>
> -if dpkg --compare-versions "$2" lt 0.17.5-1; then
> +if dpkg --compare-versions "$2" lt "0.18-2"; then
I am wondering why your postinst didn't trigger there. And I think if
there is one person in Debian who knows how dpkg --compare-versions
works then I am right now talking to him.
Current stable has 0.17.3-4+deb11u1, and we had number of 0.17.4
versions in testing during the bullseye cycle, so even the first version
comparing with 0.17.5-1 should have always triggered the chown
mechanisms, right?
> # we're updating from a version earlier than 0.17.5, chown logs and
> databases
> chown --quiet _aide:adm /var/log/aide /var/log/aide/aide.log
> /var/log/aide/aide.log.* || true
> + chown --quiet _aide:adm /var/log/aide/aideinit.log
> /var/log/aide/aideinit.errors || true
> chmod --quiet 2755 /var/log/aide || true
> chown --quiet _aide:root /var/lib/aide/aide.db /var/lib/aide/aide.db.new
> || true
This would re-chown the other logfiles and the database for a user who
had updated to 0.18-1 or 0.18-2 before and then decided to run aide with
a different user. Wouldn't it be clearer to have a dedicated dpkg
--compare-versions route for the forgotten aideinit.log, like:
if dpkg --compare-versions "$2" lt 0.18-3; then
# we're updating from a version earlier than 0.18-3, chown aideinit logs
chown --quiet _aide:adm /var/log/aide/aideinit.log
/var/log/aide/aideinit.errors|| true
fi
> Depends: aide (>= 0.17),
> liblockfile1,
> ucf (>= 2.0020),
> + adduser | systemd-sysusers,
> ${misc:Depends}
This is hopefully handled by dh_installsysusers
> Recommends: cron,
> + libcap2-bin,
> bsd-mailx | mailx | s-nail
I'd rather not have this but document it in README.Debian to not pull in
libcap2-bin on systemd systems which don't need that dependency. I have
added a half-sentence mentioning libcap2-bin to README.Debian. The
scripts should run fine without libcap2-bin installed and fall back to
running as root instead.
Greetings
Marc
