<div dir="ltr">Hi Daniel,<div><br></div><div style>I might be completely wrong and I'm only asking for educational purposes as I started to read netlink docs couple of hours ago but it looks like it's possible to crete new netlink protocol/group and use it for IPC between userspace applications, in fact it looks like that's what udev-monitor was doing. Am I missing something? And please feel to ignore me if the answer of this question is so obvious and can be found in the docs as I'm reading them :)</div>
<div style><br></div><div style>Best,</div><div style><br></div><div class="gmail_extra"><div class="gmail_quote">On Fri, Apr 12, 2013 at 5:31 PM, Daniel Lezcano <span dir="ltr"><<a href="mailto:daniel.lezcano@free.fr" target="_blank">daniel.lezcano@free.fr</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 04/12/2013 06:55 PM, S.Çağlar Onur wrote:<br>
> I'm not experienced with it so please forgive me if I'm talking<br>
> non-sense but what about switching back to using (or abusing depending<br>
> on your point of view) netlink via libnl?<br>
<br>
</div>Because it is much more than abusing :) It is hacking the rtnetlink<br>
service, which means you filter out the messages not coming from lxc<br>
(could be netlink messages about route changes, etc ...) and the<br>
different tools relying on this netlink family must ignore lxc messages.<br>
<br>
I will refresh my memory and implement a prototype based on af_inet<br>
messages, that may take awhile because I am very busy for the moment.<br>
<br>
Regards<br>
-- Daniel<br>
<div class="im"><br>
> On Fri, Apr 12, 2013 at 10:02 AM, Serge Hallyn<br>
</div><div class="im">> <<a href="mailto:serge.hallyn@ubuntu.com">serge.hallyn@ubuntu.com</a> <mailto:<a href="mailto:serge.hallyn@ubuntu.com">serge.hallyn@ubuntu.com</a>>> wrote:<br>
><br>
> Quoting Daniel Lezcano (<a href="mailto:daniel.lezcano@free.fr">daniel.lezcano@free.fr</a><br>
</div>> <mailto:<a href="mailto:daniel.lezcano@free.fr">daniel.lezcano@free.fr</a>>):<br>
<div><div class="h5">> > Sorry for jumping so late in the thread but I disagree to use<br>
> DBUS with<br>
> > LXC because of the dependency with more packages, LXC has been<br>
> designed<br>
> > to be stand alone, nothing prevent to add more complexity and<br>
> > dependencies but on top of LXC not inside.<br>
> ><br>
> > To answer the previous email Serge sent me, I thought a bit<br>
> about the<br>
> > mechanism in order to prevent a publish/subscribe approach. The<br>
> first<br>
> > version used the af_netlink socket to use some kind of message<br>
> multicast<br>
> > on processes. But it hacked a family of the netlink which was<br>
> > conflicting with the ip_route tool. In order to prevent this<br>
> conflict I<br>
> > switched "temporarly" to the AF_UNIX socket while looking for a<br>
> socket<br>
> > type matching our needs. The AF_IPN (Inter Process Network)<br>
> could have<br>
> > been perfect but the patchset has been rejected.<br>
> ><br>
> > I think the solution to solve this issue is to use the AF_INET<br>
> protocol<br>
> > on the loopback using the loopback's broadcast address and<br>
> filter the<br>
> > messages with the container name. The code should be 'trivial'.<br>
> ><br>
> > One question remains with this approach : which communication<br>
> port number ?<br>
><br>
> A consideration: right now the the monitors are per-lxcpath. So<br>
> if user joe is using lxcpath /home/joe/lxcbase, then his lxc-monitor<br>
> will only hear events for containers under /home/joe/lxcbase. If<br>
> we use loopback, then events for alllxcpaths on the host will be<br>
> combined.<br>
><br>
> That may be preferred, or may not be. But in the coming world of<br>
> per-unprivileged-user containers, where user joe has container c2<br>
> in /home/joe/lxcbase/c2, do we want user joe to hear all events<br>
> relating to system containers (under /var/lib/lxc) or jane's<br>
> /home/jane/lxcbase containers?<br>
><br>
> It's not so much a noise issue, as we can just make sure to add<br>
> the lxcpath to each message. It's more a security/privacy concern.<br>
><br>
> -serge<br>
><br>
> ------------------------------------------------------------------------------<br>
> Precog is a next-generation analytics platform capable of advanced<br>
> analytics on semi-structured data. The platform includes APIs for<br>
> building<br>
> apps and a phenomenal toolset for data science. Developers can use<br>
> our toolset for easy data analysis & visualization. Get a free<br>
> account!<br>
> <a href="http://www2.precog.com/precogplatform/slashdotnewsletter" target="_blank">http://www2.precog.com/precogplatform/slashdotnewsletter</a><br>
> _______________________________________________<br>
> Lxc-devel mailing list<br>
> <a href="mailto:Lxc-devel@lists.sourceforge.net">Lxc-devel@lists.sourceforge.net</a><br>
</div></div>> <mailto:<a href="mailto:Lxc-devel@lists.sourceforge.net">Lxc-devel@lists.sourceforge.net</a>><br>
> <a href="https://lists.sourceforge.net/lists/listinfo/lxc-devel" target="_blank">https://lists.sourceforge.net/lists/listinfo/lxc-devel</a><br>
><br>
><br>
><br>
<span class="HOEnZb"><font color="#888888">><br>
> --<br>
> S.Çağlar Onur <<a href="mailto:caglar@10ur.org">caglar@10ur.org</a> <mailto:<a href="mailto:caglar@10ur.org">caglar@10ur.org</a>>><br>
<br>
</font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br>S.Çağlar Onur <<a href="mailto:caglar@10ur.org">caglar@10ur.org</a>>
</div></div>