[Pkg-puppet-devel] Bug#941080: package ships two log rotation mechanisms

[Antoine Beaupre]

Source: puppetdb
Version: 6.2.0-3
Severity: normal

This package ships two log rotation mechanisms for
/var/log/puppetdb/puppetdb.log:

root at pauli:~# dpkg -L puppetdb | grep log
/etc/puppetdb/logback.xml
/etc/puppetdb/request-logging.xml
/usr/share/doc/puppetdb/changelog.Debian.gz
/var/log
/var/log/puppetdb
/etc/logrotate.d/puppetdb

This creates noise when logrotate comes at night to try rotating the
logs:

/etc/cron.daily/logrotate:
error: destination /var/log/puppetdb/puppetdb-access.log.1 already exists, renaming to /var/log/puppetdb/puppetdb-access.log.1-2019030706.backup
error: error setting owner of /var/log/puppetdb/puppetdb-access.log.1 to uid 119 and gid 125: Operation not permitted
error: destination /var/log/puppetdb/puppetdb.log.1 already exists, renaming to /var/log/puppetdb/puppetdb.log.1-2019030706.backup
error: error setting owner of /var/log/puppetdb/puppetdb.log.1 to uid 119 and gid 125: Operation not permitted
run-parts: /etc/cron.daily/logrotate exited with return code 1

It also marks the service as "degraded" in systemd, just for good
measure.

A workaround is to not ship a logrotate.d file at all, and it's the
approach DSA has taken to solve the issue so far:

https://salsa.debian.org/dsa-team/mirror/dsa-puppet/commit/e31d91af7a8a5d9b90bc309e38067605c00d7f13

... but I wonder if we would rather not ship `logback.xml`, to follow
POLA (Principle Of Least Astonishment). That config file is:

 1. XML, and therefore not quite human readable
 2. non-standard, as far as basic Linux sysadmin work is concerned (it
    might be "standard" in the Java world, but looks like gibberish to
    me)

So I would suggest to not let PuppetDB rotate its own logs unless
there's a good reason to do so in the first place.

But in either case, we shouldn't do *both*.

PS: after investigation, I noticed this bug (#881584) was declared
fixed in 4.4.1-3, but that's not really accurate: the bug won't be
present on new installs, but on upgrade, the old config file sticks
around. So you need to somehow remove that config file on upgarde, but
I would still argue against using the logback.xml mechanism and
instead revert to using the logrotate one.

-- System Information:
Debian Release: 10.1
  APT prefers stable
  APT policy: (500, 'stable'), (1, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-6-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.UTF-8 (charmap=UTF-8), LANGUAGE=fr_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled