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

[Simo Sorce]

On Wed, 2012-10-10 at 21:44 +0200, Kay Sievers wrote:
> On Wed, Oct 10, 2012 at 9:31 PM, Konstantin Ryabitsev
> <icon at fedoraproject.org> wrote:
> > On Tue, Oct 9, 2012 at 5:24 PM, Lennart Poettering <mzerqung at 0pointer.de> wrote:
> >> 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?
> >
> > I think you overestimate how much a sysadmin cares about fake
> > messages. The thing that's really important to a sysadmin is to make
> > sure that none of the REAL messages are lost. If someone fakes root
> > login entries by using something as trivial as "logger", I can easily
> > establish they are fake by looking at auditd logs. And then I would
> > *really* make that user regret their actions by using blunt
> > cryptanalysis tools.
> >
> > So, it's not accurate to say that we don't currently have ways to detect that.
> 
> That works only for very very few of the logged messages, and it is a
> good example how things should really not be designed or work today.
> 
> We need one source of system log and not a bunch of daemons with all
> overlap but still have only parts of the picture, store their own
> stuff all over the place.
> 
> Manual matching between the different data sources can sometimes be
> used to find out what was really going on, but that's really not good
> enough today.
> 
> The journal daemon uses similar close-to-the-kernel properties to
> establish trust in logged messages, and in the future it is planned
> that it will also rad all audit messages directly. The audit daemon
> will then mostly be a policy execution engine for (rather exotic)
> requirements like "crash the box if the message does not go to disk".

It seem your intention is to make the journal so much better that it
will be the preferred choice (and indeed the default).

So make it really better and support time-based rotation. You don't need
to make time-based rotation the default, but you'll make a lot of people
happy to have the option.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York