From: ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org (Eric W. Biederman)
To: Glauber Costa <glommer-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
Cc: Rui Xiang <leo.ruixiang-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
Andrew Morton
<akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>,
containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH RFC 0/5] Containerize syslog
Date: Wed, 12 Dec 2012 12:08:50 -0800 [thread overview]
Message-ID: <87obhzkp7x.fsf@xmission.com> (raw)
In-Reply-To: <50C846C7.5050904-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org> (Glauber Costa's message of "Wed, 12 Dec 2012 12:56:39 +0400")
This conversation is really debating the wrong question.
The fundamental question is can we modify the kernel such that
containers don't care about anything that goes into the kernel log.
The fundamental question leads to the question what functionality
that is logged to the kernel log must we see in containers.
Serge has a collected a lot of cases and it seems reasonable to assume
that we will find those cases that must show up in a container or
require huge userspace reworking.
These messages that must show up in a container (or break userspace) are
messages that already exist today. These messages quite likely are
specific to the container itself and I don't think we will need to
double log them.
But the first step of the process is to find the kernel messages that if
we don't log to user space via the kernel log will break user space.
Once we have found those messages and the cases in which there are no
work-arounds we can refine the design with nice to haves.
But this conversation really needs to be about which messages must we
deliver to userspace via the kernel log.
There are a lot of nice to haves messages out there. Mount failures,
selinux failures etc. Some of those have a pretty compelling case to be
double logged.
I think for the compelling cases we won't want to doulbe log them, and
those compelling cases need to drive the design.
The most compelling case I know of are firewall log messages that are
logge by explicit user request when selected packets hit the local
firewall. Those messages I definitely don't want to double log and
those messages are most definitely not interesting to the operator of
the machine. Those messages are only interesting to the admin who
configured his firewall to log them.
We should look to see if there are alternatives to user configured
firewall log messages that a system administratrator can use. If not we
have our first compelling case for this functionality.
Eric
next prev parent reply other threads:[~2012-12-12 20:08 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-19 8:16 [PATCH RFC 0/5] Containerize syslog Rui Xiang
[not found] ` <50A9EAD8.9090501-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2012-11-19 9:51 ` Eric W. Biederman
[not found] ` <874nklkjjm.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2012-12-07 9:03 ` Andrew Morton
2012-12-07 9:03 ` Andrew Morton
[not found] ` <20121207010355.c809b3f7.akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>
2012-12-07 14:23 ` Serge Hallyn
2012-12-07 14:30 ` Glauber Costa
[not found] ` <50C1FD9D.5020703-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
2012-12-07 18:05 ` Eric W. Biederman
[not found] ` <87r4n1buuw.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2012-12-11 8:25 ` Glauber Costa
2012-12-11 8:25 ` Glauber Costa
[not found] ` <50C6EDF0.5060108-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
2012-12-11 18:22 ` Eric W. Biederman
[not found] ` <87txrs30ur.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2012-12-12 8:56 ` Glauber Costa
2012-12-12 8:56 ` Glauber Costa
[not found] ` <50C846C7.5050904-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
2012-12-12 20:08 ` Eric W. Biederman [this message]
2012-12-07 18:21 ` Eric W. Biederman
2012-12-07 18:21 ` Eric W. Biederman
2012-11-19 14:37 ` Serge E. Hallyn
[not found] ` <20121119143702.GB4620-7LNsyQBKDXoIagZqoN9o3w@public.gmane.org>
2012-11-21 9:35 ` Rui Xiang
[not found] ` <50ACA05F.7080005-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2012-11-26 15:16 ` Eric W. Biederman
2012-11-26 15:16 ` Eric W. Biederman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87obhzkp7x.fsf@xmission.com \
--to=ebiederm-as9lmozglivwk0htik3j/w@public.gmane.org \
--cc=akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org \
--cc=containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
--cc=glommer-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org \
--cc=leo.ruixiang-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.