* Re: containerized syslog [not found] ` <1265915683.19130.166.camel-4BUXZ/Ty1v7iqR6jatDSCA@public.gmane.org> @ 2010-02-11 19:29 ` Serge E. Hallyn [not found] ` <20100211192952.GA20191-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org> 0 siblings, 1 reply; 5+ messages in thread From: Serge E. Hallyn @ 2010-02-11 19:29 UTC (permalink / raw) To: Jean-Marc Pigeon Quoting Jean-Marc Pigeon (jmp-4qkeo2rQ0gg@public.gmane.org): > Hello, > > > > > > Thanks Jean-Marc. But this really isn't doing most of what I'd > > recommended in my last emails (both public and private. In > > particular: > [....] > > > > syslog_ns should be moved into nsproxy and unshared with a > > separate clone(CLONE_SYSLOG); > This this not a problem. > My understanding a new clone flag was not an option > as we are short in CLONE flag. > No design nor arch problem if we set CLONE_SYSLOG > to be 0x100000000 ????? > > If moved in nsproxy what is the hook to > get the "current context". (used current_user_ns() > as it was in user_namespace). > > > [...] > > > That was why I suggested: > [...] > > >! 4. take a printk call like the iptables ones you want and turn > > >! int into nsprintk syscall. > > >! > > If my understanding is right you propose to use a > special nsprintk to be used by iptable such > we can send "packet log" in "container context" > Right? > > Logic is weak. No logic is irrefutable :) Because: > 1) > The way I changed printk, so far, make of it a "de facto" > nsprintk. So when called from netfilter, nsprintk > is still stay in HOST: context. My understanding, No, it could be called from the context of a task in any random container. -serge ^ permalink raw reply [flat|nested] 5+ messages in thread
[parent not found: <20100211192952.GA20191-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>]
* Re: containerized syslog [not found] ` <20100211192952.GA20191-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org> @ 2010-02-13 15:58 ` Matt Helsley [not found] ` <20100213155813.GU3714-52DBMbEzqgQ/wnmkkaCWp/UQ3DHhIser@public.gmane.org> 0 siblings, 1 reply; 5+ messages in thread From: Matt Helsley @ 2010-02-13 15:58 UTC (permalink / raw) To: Serge E. Hallyn; +Cc: Containers On Thu, Feb 11, 2010 at 01:29:52PM -0600, Serge E. Hallyn wrote: > Quoting Jean-Marc Pigeon (jmp-4qkeo2rQ0gg@public.gmane.org): > > Hello, > > > > > > > > > > Thanks Jean-Marc. But this really isn't doing most of what I'd > > > recommended in my last emails (both public and private. In > > > particular: > > [....] > > > > > > syslog_ns should be moved into nsproxy and unshared with a > > > separate clone(CLONE_SYSLOG); > > This this not a problem. > > My understanding a new clone flag was not an option > > as we are short in CLONE flag. > > No design nor arch problem if we set CLONE_SYSLOG > > to be 0x100000000 ????? > > > > If moved in nsproxy what is the hook to > > get the "current context". (used current_user_ns() > > as it was in user_namespace). > > > > > > [...] > > > > > That was why I suggested: > > [...] > > > >! 4. take a printk call like the iptables ones you want and turn > > > >! int into nsprintk syscall. > > > >! > > > > If my understanding is right you propose to use a > > special nsprintk to be used by iptable such > > we can send "packet log" in "container context" > > Right? > > > > Logic is weak. > > No logic is irrefutable :) Because: > > > 1) > > The way I changed printk, so far, make of it a "de facto" > > nsprintk. So when called from netfilter, nsprintk > > is still stay in HOST: context. My understanding, > > No, it could be called from the context of a task in any > random container. Your comments seem good. However, I do have an issue with the idea of finding a single syslog corresponding to the netns for a hypothetical printk in iptables. What happens with: /* in init_syslog_ns */ clone(CLONE_SYSLOG) /* syslog_ns 1 */ clone(CLONE_SYSLOG) /* syslog_ns 2 */ <do something with iptables in the netns which triggers a printk> Even though that same printk is relevant to three "syslogs", it'll only go to one, correct? If so, my feeling is that nsprintk shouldn't take a syslog_ns directly. It should take some other form of namespace and then write to the syslog of all the nsproxies which share that namespace (a netns in this case). Cheers, -Matt Helsley ^ permalink raw reply [flat|nested] 5+ messages in thread
[parent not found: <20100213155813.GU3714-52DBMbEzqgQ/wnmkkaCWp/UQ3DHhIser@public.gmane.org>]
* Re: containerized syslog [not found] ` <20100213155813.GU3714-52DBMbEzqgQ/wnmkkaCWp/UQ3DHhIser@public.gmane.org> @ 2010-02-13 16:03 ` Matt Helsley 2010-02-13 16:05 ` Serge E. Hallyn 1 sibling, 0 replies; 5+ messages in thread From: Matt Helsley @ 2010-02-13 16:03 UTC (permalink / raw) To: Matt Helsley; +Cc: Containers On Sat, Feb 13, 2010 at 07:58:13AM -0800, Matt Helsley wrote: <snip> > Your comments seem good. However, I do have an issue with the > idea of finding a single syslog corresponding to the netns for > a hypothetical printk in iptables. > > What happens with: > > /* in init_syslog_ns */ > clone(CLONE_SYSLOG) /* syslog_ns 1 */ > clone(CLONE_SYSLOG) /* syslog_ns 2 */ > <do something with iptables in the netns which triggers a printk> > > Even though that same printk is relevant to three "syslogs", it'll > only go to one, correct? If so, my feeling is that nsprintk > shouldn't take a syslog_ns directly. It should take some other > form of namespace and then write to the syslog of all the Sorry, I don't think I worded this clearly. "some other form" means a non-syslog_ns which is "relevant" to the printk e.g. a netns for iptables code. Cheers, -Matt Helsley ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: containerized syslog [not found] ` <20100213155813.GU3714-52DBMbEzqgQ/wnmkkaCWp/UQ3DHhIser@public.gmane.org> 2010-02-13 16:03 ` Matt Helsley @ 2010-02-13 16:05 ` Serge E. Hallyn 1 sibling, 0 replies; 5+ messages in thread From: Serge E. Hallyn @ 2010-02-13 16:05 UTC (permalink / raw) To: Matt Helsley; +Cc: Containers Quoting Matt Helsley (matthltc-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org): > On Thu, Feb 11, 2010 at 01:29:52PM -0600, Serge E. Hallyn wrote: > > Quoting Jean-Marc Pigeon (jmp-4qkeo2rQ0gg@public.gmane.org): > > > Hello, > > > > > > > > > > > > > > Thanks Jean-Marc. But this really isn't doing most of what I'd > > > > recommended in my last emails (both public and private. In > > > > particular: > > > [....] > > > > > > > > syslog_ns should be moved into nsproxy and unshared with a > > > > separate clone(CLONE_SYSLOG); > > > This this not a problem. > > > My understanding a new clone flag was not an option > > > as we are short in CLONE flag. > > > No design nor arch problem if we set CLONE_SYSLOG > > > to be 0x100000000 ????? > > > > > > If moved in nsproxy what is the hook to > > > get the "current context". (used current_user_ns() > > > as it was in user_namespace). > > > > > > > > > [...] > > > > > > > That was why I suggested: > > > [...] > > > > >! 4. take a printk call like the iptables ones you want and turn > > > > >! int into nsprintk syscall. > > > > >! > > > > > > If my understanding is right you propose to use a > > > special nsprintk to be used by iptable such > > > we can send "packet log" in "container context" > > > Right? > > > > > > Logic is weak. > > > > No logic is irrefutable :) Because: > > > > > 1) > > > The way I changed printk, so far, make of it a "de facto" > > > nsprintk. So when called from netfilter, nsprintk > > > is still stay in HOST: context. My understanding, > > > > No, it could be called from the context of a task in any > > random container. > > Your comments seem good. However, I do have an issue with the > idea of finding a single syslog corresponding to the netns for > a hypothetical printk in iptables. > > What happens with: > > /* in init_syslog_ns */ > clone(CLONE_SYSLOG) /* syslog_ns 1 */ > clone(CLONE_SYSLOG) /* syslog_ns 2 */ > <do something with iptables in the netns which triggers a printk> > > Even though that same printk is relevant to three "syslogs", it'll > only go to one, correct? If so, my feeling is that nsprintk > shouldn't take a syslog_ns directly. It should take some other > form of namespace and then write to the syslog of all the > nsproxies which share that namespace (a netns in this case). Could do that - but I think it'd be fair to just keep track of a single netns->syslog_ns, namely the one which corresponded to the netns when netns was created. Don't allow unshare of syslog_ns, only clone. That ensures that the init task in a container will always be tied to the same net, pid, and syslog namespaces, giving us a point of sanity. -serge ^ permalink raw reply [flat|nested] 5+ messages in thread
* Containerized syslog @ 2010-05-12 14:57 Jean-Philippe Menil 0 siblings, 0 replies; 5+ messages in thread From: Jean-Philippe Menil @ 2010-05-12 14:57 UTC (permalink / raw) To: containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA Cc: lxc-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f [-- Attachment #1: Type: text/plain, Size: 1098 bytes --] Hi, I'm playing with containers under debian (squeeze, 2.6.33.3) with the lxc tools. I'm really happy about all the features (attach veth on bridge, filter with iptables inside the containers, etc ...), and i was thinking to replace some of our vservers (and maybe some of our kvm) with this solution. But actually, i experiment a problem with the iptables logs: i've iptables on the host to filter some container, basically a squid proxy. I've another container who act as router, and he has his own iptables inside. All the log are deported to a dedicated syslog server. It appear that, the iptables log of the host are also deported by the syslog container (proxy). Some of our guest (container, vserver, etc ) are administer by other sys-admin, that should not have access to theses informations. This point is blocking me today, before going into production with containers. I've seen some patch made by Jean-Marc Pigeon about this problem, but they have not been commited. Is there any reason for that? Can someone advice me to circumvent this problem? Thanks a lot. Regards. [-- Attachment #2: jean-philippe_menil.vcf --] [-- Type: text/x-vcard, Size: 458 bytes --] begin:vcard fn:Jean-Philippe Menil n:Menil;Jean-Philippe org;quoted-printable:Universit=C3=A9 de Nantes;IRTS - DSI adr;quoted-printable:;;2, rue de la Houssini=C3=A8re;Nantes;Loire-Atlantique;44332;France email;internet:jean-philippe.menil-zanJymNeSEOeCSforKHNpg@public.gmane.org title;quoted-printable:Administrateur R=C3=A9seau tel;work:02.51.12.53.92 tel;fax:02.51.12.58.60 x-mozilla-html:FALSE url:http://www.criun.univ-nantes.fr/ version:2.1 end:vcard [-- Attachment #3: Type: text/plain, Size: 206 bytes --] _______________________________________________ Containers mailing list Containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org https://lists.linux-foundation.org/mailman/listinfo/containers ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2010-05-12 14:57 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <1265915683.19130.166.camel@Mercier.safe.ca>
[not found] ` <1265915683.19130.166.camel-4BUXZ/Ty1v7iqR6jatDSCA@public.gmane.org>
2010-02-11 19:29 ` containerized syslog Serge E. Hallyn
[not found] ` <20100211192952.GA20191-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2010-02-13 15:58 ` Matt Helsley
[not found] ` <20100213155813.GU3714-52DBMbEzqgQ/wnmkkaCWp/UQ3DHhIser@public.gmane.org>
2010-02-13 16:03 ` Matt Helsley
2010-02-13 16:05 ` Serge E. Hallyn
2010-05-12 14:57 Containerized syslog Jean-Philippe Menil
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.