[Nottingham] Someone doesn't like systemd

[Andy Smith]

Hi Jason,

On Thu, Aug 14, 2014 at 12:52:56PM +0100, Jason Irwin wrote:
> On 14/08/14 02:44, Andy Smith wrote:
> > Take the "oh no, binary logs!?" thing for example. Structured logs
> > are useful. But you can still have plain text logs with systemd if
> > you like—any syslogd you have running will get a plain text copy of
> > the journal messages too.
> That's news, you are the first person to mention it. From what I
> understood, systemd was binary only; end of discussion. Good to know. I
> was wondering how the various log-watchers (e.g. fail2ban) would
> continue to work if they had to start reading binary logs.

I'm still lacking much real-world experience with systemd but the
configuration of journald by default should have ForwardToSyslog
enabled, so if any classic syslogd is installed then it would get a
plain text copy of all log entries:

    http://www.freedesktop.org/software/systemd/man/journald.conf.html

I should think that many distributions at least in their desktop
flavours will eventually not install a syslogd by default, but the
current usual choice of rsyslog would probably still be packaged and
available.

Also on Lennart Poettering's "The Biggest Myths [about systemd]"
page (which is currently down, amusingly! Google cache of
http://0pointer.de/blog/projects/the-biggest-myths.html here:
http://webcache.googleusercontent.com/search?q=cache:AJ1jz3FYWUwJ:0pointer.de/blog/projects/the-biggest-myths.html)

    Myth: systemd makes it impossible to run syslog.

    Not true, we carefully made sure when we introduced the journal that
    all data is also passed on to any syslog daemon running. In fact, if
    something changed, then only that syslog gets more complete data now
    than it got before, since we now cover early boot stuff as well as
    STDOUT/STDERR of any system service.

> isn't the binary supposed to be more efficient?

I can't imagine there is much in it—I understand the binary format
is pretty much just KEY=VALUE as a set of null-terminated strings in
a big blob.

I expect the main advantages will be the ability to effectively
query the logs a bit like a database: select from/to dates,
particular services (units), match on any other of the fields. e.g.
"show me every cron task that exited with an unsuccessful exit code
in the last 5 days", which would be possible no matter what tree of
processes those jobs started and no matter whether any of those
processes actually put their name or PIDs in the message itself.

There are some other advantages like, absolutely all output of all
started services being captured, more metadata being captured, more
security that when a message enters the journal saying it is from a
specific program/pid that it actually is (there is no security on
current syslog, everyone can write free text to it).

I think there is also talk of eventual tamper-evident checkpointing
so that journal contents can be trusted even after a compromise,
although I don't think there is any real reason why that would not
be possible with syslog either. It's just that the traditional
syslog authors never had the chance to break everything and enforce
their own format. :)

I can fully appreciate that there's going to be loads of people who
feel that there's nothing really wrong with syslog and having to
have this additional thing for logging (even if it logs to nowhere)
is an abomination.

Cheers,
Andy

-- 
http://bitfolk.com/ -- No-nonsense VPS hosting

> The optimum programming team size is 1.
Has Jurassic Park taught us nothing?
 — pfilandr