Re: [Sks-devel] SKS logging to syslog using 1.1.6-2~bpo8+1 from debian-packports

[Daniel Kahn Gillmor]

On Mon 2016-12-05 09:37:13 -0500, Pete Stephenson wrote:
> I don't mind having certain behavior be the default -- and, as you
> say, there are good reasons for having that be the default -- but
> user-added entries in the config file should take precedence.

hm, i think i agree with you there, but the default should *actually* be
to log to stdout or stderr.

there are a lot more subtleties, corner cases which can break, and
potential permissions problems if the daemon has to open and write to
and close the file, and respond to logrotation events, even if it
doesn't manage the rotation itself (e.g. what happens to a file if it's
copy+truncated while i'm holding it open to write to it?)

writing to a known file descriptor and then forgetting about it is the
simplest possible thing :)

> However, using it as a logging system is strange to me. Years of
> habitually using tools like tail to follow log files and having
> logrotate rotate them day-by-day and gzip old logs is a bit of an
> obstacle to overcome for something that, IMHO, doesn't seem to do
> anything particularly better...but I'm willing to learn.

the idea is that it's a system service manager -- it knows how to start
and stop services, what to do with their output, how to keep track of
any children they might spawn, how to clean them up, what resources to
give them, etc.  This is what an init system *should* do, since it's
well-placed to see all the pieces of the puzzle and to help keep them
isolated where possible and connected where necessary.

> I'm using a bog-standard Debian Jessie installation and it appears to
> be using rsyslog. I'm not familiar with how rsyslog and systemd
> interact in regards to logging, but if you have any advice to point me
> in the right direction I'd be very much obliged.

rsyslog receives its input from journald at /run/systemd/journal/syslog,
as standard syslog messages, annotated with identity, facility, and
priority (see syslog(3) for a common library interface used by clients
to write this information)

It then writes them to various files, as determined by the properties
mentioned above, matched as described in rsyslog.conf(5).  On debian
jessie, you should be able to drop a file in /etc/rsyslog.d/sks.conf
that contains directives to produce the old /var/log/sks/*.log files,
using the expected permissions, etc.  Only now, you don't actually need
to have those files writable (or readable) by the sks-debian user
account at all; the logging is independent of the daemon, and if the
daemon is ever compromised, it can't overwrite its logs.

if you come up with a reasonable /etc/rsyslog.d/sks.conf that you think
would work for other people who happen to run rsyslog in addition to
systemd, i'd be happy to ship it in the debian package to support that
use case.  If you decide to do that, you can mail it to the list here,
or you can report it via the debian BTS using "reportbug sks".

Happy hacking,

      --dkg

signature.asc
Description: PGP signature