Package: etckeeper
Version: 1.18.22-2
Severity: normal
Dear Maintainer,
The Debian package enables etckeeper.timer on install. The timer runs
/etc/etckeeper/daily, which never sources /etc/etckeeper/etckeeper.conf and is
therefore unaffected by any setting in that file. On a default Debian
installation this has two consequences.
1. AVOID_DAILY_AUTOCOMMITS=1 has no effect.
Only /etc/cron.daily/etckeeper honours it. On this host the setting has been
present since 2019 and /etc nevertheless contains 34 "daily autocommit"
commits.
2. It silently defeats AVOID_COMMIT_BEFORE_INSTALL=1.
That guard (pre-install.d/50uncommitted-changes) aborts an apt run when /etc
has uncommitted changes, so the admin can commit them deliberately with a
meaningful message. Because the timer commits those same changes first, as an
unattributed "daily autocommit", the guard never fires and the provenance of
the change is lost. This is how I noticed: three files I had added to /etc by
hand were committed as "daily autocommit" three days later, although both
AVOID_DAILY_AUTOCOMMITS=1 and AVOID_COMMIT_BEFORE_INSTALL=1 were set.
The shipped /etc/etckeeper/etckeeper.conf tells the admin the timer is opt-in:
# Etckeeper includes both a cron job and a systemd timer, which each
# can commit exiting changes to /etc automatically once per day.
# To enable the systemd timer, run: systemctl enable etckeeper.timer
# The cron job is enabled by default (unless the systemd timer is also
# enabled); to disable it, uncomment this next line.
#AVOID_DAILY_AUTOCOMMITS=1
On Debian that instruction is incorrect: the timer is already enabled, as the
postinst itself notes ("was-enabled defaults to true, so new installations run
enable"). The command that does control it, "systemctl disable
etckeeper.timer", is documented nowhere in the package, so the only
documented knob for daily autocommits is the one that does not work.
Not fixed in 1.18.23-2. I unpacked that version to check:
/etc/etckeeper/daily and /usr/lib/systemd/system/etckeeper.service are
byte-identical to 1.18.22-2, and debian/postinst still enables the timer.
The only related change is cron.daily standing down when the timer is enabled,
which addresses #883263. #884824 is closed as fixed in 1.18.23-1, but the
scenario above still reproduces on 1.18.23-2.
Reproducer:
echo AVOID_DAILY_AUTOCOMMITS=1 >> /etc/etckeeper/etckeeper.conf
touch /etc/zzz-test
systemctl start etckeeper.service
cd /etc && git log -1 # -> "daily autocommit"
Any one of the following would resolve it:
- ship etckeeper.timer disabled by default, matching the wording already in
etckeeper.conf (upstream clearly expects it to be opt-in);
- make /etc/etckeeper/daily source etckeeper.conf and honour
AVOID_DAILY_AUTOCOMMITS, so both mechanisms obey the same switch;
- or, if enabling the timer by default is intentional Debian policy, amend
the Debian etckeeper.conf comment and README.Debian to say so, and to point
at systemctl as the way to control daily autocommits.
I have no preference between these; the current state is just surprising,
because the documentation and the behaviour disagree.
-- System Information:
Debian Release: 13.7 (trixie)
etckeeper: 1.18.22-2
Architecture: amd64
Init: systemd
etckeeper.timer: was enabled (now disabled manually as a workaround)
--
Gerd Aschemann (er/he) --- Veröffentlichen heißt Verändern (Carmen Thomas)
+49/173/3264070 -- [email protected] -- https://aschemann.net
