[lxc-devel] [PATCH] Add lxc-net tool

[Christian Seiler]

Hi again,

>> Extending lxc-attach would also be fine by me - is anybody already
>> working on this? If not, I'd be willing to do that.
>
> It's on the todo list at the moment, I don't believe anyone is
> actively working on it at the moment.
>
> So if you want to do it, it'd be much appreciated.

Ok, I'll get back to you on that.

> I believe the idea was to keep the same syntax as lxc-unshare for
> lxc-attach. Essentially introduce a -s flag accepting an ORed list of
> namespaces.

Yes, sounds reasonable to me. Just one question: I've actually taken a
peek at iproute2's implementation now that you mentioned it and they
actually do two things in ip netns exec:

 - they setns() to the new namespace
 - they unshare the mount namespace and remount /sys - apparently, in
   contrast to /proc, which depends on the current process's context,
   /sys depends on the context of the process mounting it

So for lxc-attach without mount namespaces but with network namespaces,
should we do the same? (i.e. catch that case) Or should we just ignore
/sys? Do any non-shell-script utilities actually use it? I am under the
impression that any network interface information is also available via
netlink or similar, and that all "real" tools use that, which does take
into account process context. (One could even argue that /sys should -
just as /proc does - reflect the current namespace for relevant things
and that this is a bug/missing feature in the kernel.) Thoughts?

> Currently only ipc, net and uts are usable on a standard kernel,
> patches for the remaining ones and the user namespace are currently
> on lkml with some of them in linux-next.

About only ipc, net and uts being usable, I know about that, I'm
currently using the patches under
<http://lxc.sourceforge.net/patches/linux/3.0.0/3.0.0-lxc1/patches/>
(slightly modified to apply against 3.2) to be able to properly use
lxc-attach. I'm glad to hear that they are on their way into the kernel.

Regards,
Christian