replacing rsyslogd in minimal with journald [was Re: systemd requires HTTP server and serves QR codes]

[Lennart Poettering]

On Tue, 09.10.12 16:53, Simo Sorce (simo at redhat.com) wrote:

> > > Also: what is the equivalent for logrotate in the systemd journal
> > > case?
> > 
> > Rotation happens in-line, i.e. each time before we are about to write an
> > entry we check if rotation is necessary and execute it. This should make
> > things a lot more robust, as this fixes a common issue with syslog where
> > a lot of data generated in bursts could flood the fs until a much later
> > time-based rotation took place. This time window goes away with the journal.
> 
> Lovely so now I have a perfect way to remove all traces of access all we
> need is to cause a lot of logging to go through until it is merrily
> deleted ?

We enforce per-cgroup ratelimiting. That means a service can run amok,
but this will cause its stream to be throttled while leaving other
services unaffacted.

> This *must* be configurable, there are places where rotation is not
> allowed at all and the system *must* crash and stop if logs can't be
> written and preserved.

Well, I am not sure what you are requesting. We cannot store more on a
disk than fits on a disk. So we need to do things based on disk
size/free space. Almost everybody would rather have log messages being
dropped than the machine come to a standstill because log messages can't
be written anymore.

If you want audit-like semantics with crashing if we cannot write, then
use something else, not the journal. The journal is supposed to be
robust and do the right thing so that you can leave it unnatteneded and
whatever happens it didn't spill the disk or become unavailable. It's
supposed to be "zero maintainance".

> > See SystemMaxUse= resp. SystemKeepFree= in journald.conf(5).
> 
> You need to allow boundless configurations, see above.

No, I don't. The journal is not a reimplementation of auditd. If people
want a "yes, please, crash my machine if a client enters a log spam
loop" policy, then we have other options than the journal, and which can
run side-by-side with the journal. I dont think this is in anyway
relevant for 99.9% of all installations. In those it is more interesting
to minimize the negative impact a misbehaving service can have, rather
than amplifying it. So no, I don't need, I don't must support all
thinkable setups.

I am not generally against adding time-based rotation, but really, this
is much less of a "necessity" than other things the journal provides,
which syslog does not: for example per-service rate limits, and
unfakable meta-data for log messages. I mean, really, how can we ship
a syslog where every random user can fake messages, say they are from a
privileged process and offer no way how to detect that?

> Also rotating based on use is generally annoying to admins, as it makes
> more difficult to predict where stuff will end up and what will
> deterministically be in backups.

For some sure, for most not.

> logrotate has time based policies for very good reasons.

Yeah, because Unix doesn't really allow much else...

> Your policy may make sense on space-constrained configuration but in any
> other system they make little sense, and log compression on rotation is
> all you really need (lots of repetitions in the logs allow big gains
> when compressing).

Well, I guess we have to agree to disagree on what is necessary to make
things robust, safe and secure.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.