On Mon, 27 May 2024 at 03:29:53 +0100, Luca Boccassi wrote:
> The list of affected packages according to apt-cache showpkg is not
> that long either:
>
> anacron
> approx
> fail2ban
> fwlogwatch
> heartbeat
> hippotat-server
> inetutils-ftpd
> inetutils-inetd
> inetutils-talkd
> inetutils-telnetd
> ldirectord
> logcheck
> lyskom-server
> prelude-lml
> psad
> request-tracker4
> request-tracker5
> rlinetd
> snort
> socklog-run
> socklog-run:i386
> spamd
> sympa
> xinetd
> xwatch
> zoneminder
I think we can divide these into: packages that want to write to a logging
service via the syslog protocol, and packages that want to read a
traditional plain-text syslog file.
For packages that want to write out messages via syslog(3) or equivalent
and have them get written out somewhere that the sysadmin can see them,
I agree that the systemd Journal (whether persistent or volatile) is
sufficient to provide a suitable log sink. Obviously many sysadmins will
want these messages to persist across a reboot, but that's a configuration
choice, for which I think defaulting to persistent but allowing volatile
at the sysadmin's own risk is a good arrangement.
However, for packages that want to read a traditional /var/log/syslog
or similar, notably logcheck, I think it might still make sense to declare
a dependency on system-log-daemon - this is not functionality that the
systemd Journal provides. Obviously the same information exists and can
be retrieved by journalctl(1) or via libsystemd, or received and written
out to the traditional flat file over time by rsyslog or equivalent,
but it's no longer provided as a flat file on disk by default.
If these log consumers have not been updated to be able to read messages
out via journald's C API (or the journalctl CLI if they must), then they
do still have a functional dependency on rsyslog or one of its competitors,
so I think they do still genuinly need a dependency.
It would make sense to file a wishlist bug asking for them to be taught
to bypass the flat file and read directly from the Journal, but I don't
think that's really quite the same category of bug report as something
like approx or spamd that just wants a working logging destination, and
until that feature has been written, they genuinely do need a traditional
syslog implementation.
See also recent bug traffic in src:fail2ban about teaching fail2ban
to read from the systemd Journal, instead of relying on having the
traditional syslog flat-files from which it can read log records for
failed sshd logins. (The required configuration change seems to have
been to change `backend = auto` to `backend = systemd` by default,
and bump up the Recommends on python3-systemd to a Depends.)
smcv
