Linux Container Development
 help / color / mirror / Atom feed
From: Daniel Lezcano <daniel.lezcano-GANU6spQydw@public.gmane.org>
To: "Eric W. Biederman" <ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
Cc: containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org
Subject: Re: VRF-like use of Network Namespaces
Date: Sun, 13 Jun 2010 22:30:15 +0200	[thread overview]
Message-ID: <4C153FD7.7000400@free.fr> (raw)
In-Reply-To: <m11vcbl0d5.fsf-+imSwln9KH6u2/kzUuoCbdi2O/JbrIOy@public.gmane.org>

On 06/13/2010 11:59 AM, Eric W. Biederman wrote:
> Daniel Lezcano<daniel.lezcano-GANU6spQydw@public.gmane.org>  writes:
>
>    
>> On 06/11/2010 04:47 PM, Mathieu Peresse wrote:
>>      
>>> Hi,
>>>
>>> [this is related to the use of Eric Biederman's new set of patches for named
>>> netns / netns switching]
>>>
>>> ok so I successfully modified /sbin/ip. I can now:
>>> - add/del a new netns by name: "ip netns {addns,delns} ns_name"
>>> ->   The namespace files are mounted on /var/run/netns/ns_name (so you have to
>>> mkdir /var/run/netns/ for this to work).
>>>
>>>        
>> IMHO, the ip command is not suitable for this, it does not write
>> anything to the fs.
>>      
> It does configuration by all kinds of means.  As far as it goes I
> think the ip command is perfectly suitable in this particular
> situation.  Having a vrf functionality in linux is very desirable.
>    

I agree it would be preferable to centralize all in the ip command.

But the approach proposed by Mathieu relies on the filesystem. I don't 
think there is another solution but having the ip command mounting, 
writing and reading from this directory is a bit weird IMHO, may be 
because it does not do that (or I missed something).

And for this reason, only, I find the ip command not suitable for this.
But I am perfectly fine with the idea in general.

That makes me feel, maybe a 'netnsfs' is missing. IMHO, it is like we 
fork and we store the pid in /var/run/pid/1234.
In the other hand, the 'ip' command is run as root, so we can assume he 
knows what it does, like the 'mount' command writing to /etc/mtab.

> Getting this into ip has the major advantage that we will have a defacto
> standard, and using IFLA_NET_NS_FD makes a lot more sense if everything
> is in ip.
>    

Sure, if the netdev guys are ok with writing into /var/run/netns, I 
won't argue against.

>> You should write you own command, which can be a perl script using the
>> 'unshare' command (util-linux package on my distro).
>>
>> vrf create<name>
>> vrf delete<name>
>> vrf attach<name>
>> vrf list
>>
>> vrf create will bind mount the ns at the place you decided in the script
>> (eg. a tmpfs in order to keep the directory consistent across (unclean)
>> reboots).
>>
>>      
>>> - list netns: "ip netns show"
>>> - use /sbin/ip in any named netns: "ip -netns ns_name link show"
>>>
>>> (rough patch against current git tree attached)
>>>
>>> I want now to move devices across namespaces using their filesystem names
>>> (instead of using PIDs...). I'm not sure I can do it in userspace with the
>>> current code yet, can I ?
>>>
>>>        
>> No, you can do that only with pids, but why don't you move the devices
>> at the create time ?
>> You have all the latitude to do that, no ?
>>      
> Does my published tree not have IFLA_NET_NS_FD in it?

Hmm, AFAICS no.
>>> I saw there was a rtnetlink attribute to set the netns of a device but it
>>> uses the PID of a namespace owner to do so... within 'ip' i can refer to
>>> only one namespace (i.e. the one that 'ip' task_struct->ns_proxy currently
>>> points to), so I won't be able to move an interface from outside my
>>> namespace to my namespace...
>>> I hope my explanation is clear and that this will get some interest... :)
>>>
>>>        
>> Your 'create' command can open a fd to its current  netns, unshare a new
>> namespace, bind mount it, and then return to the previously saved netns.
>>
>>      
>>> BTW is this the right ML to post this on ?
>>>
>>>        
>> Well, this is something related to a subsystem of the containers, so it
>> has some interest but I would suggest to send to the netdev@ mailing
>> list (netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org), maybe cc'ing this mailing list.
>>      
> Anyway it looks like time to post the core of my patchset for review,
> and get things moving on this.
>    
Reviewing in progress ... ;)

Thanks
   -- Daniel

  parent reply	other threads:[~2010-06-13 20:30 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-06-08 15:23 VRF-like use of Network Namespaces Mathieu Peresse
     [not found] ` <AANLkTimA_0aZwZM1uZ-GH3OxfEZvegoitaaKTYPLvW5F-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2010-06-08 15:40   ` Daniel Lezcano
     [not found]     ` <4C0E6466.3030100-GANU6spQydw@public.gmane.org>
2010-06-08 17:12       ` Mathieu Peresse
     [not found]         ` <AANLkTik77W7F7BV7qp9ZQlM3yJCKNydHAMN47FaLTr7Z-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2010-06-08 21:06           ` Daniel Lezcano
     [not found]             ` <4C0EB0C5.8070904-GANU6spQydw@public.gmane.org>
2010-06-08 21:48               ` Mathieu Peresse
     [not found]                 ` <AANLkTinmsRRKdWaf8QONeRRJSQRXPhaUtY1cFv_JGcy8-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2010-06-11 14:47                   ` Mathieu Peresse
     [not found]                     ` <AANLkTilUNrMAeeUjHsXkTwd7Ysx0o9mdl8UaSUvG6wvf-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2010-06-11 14:59                       ` Dan Smith
2010-06-11 15:52                       ` Daniel Lezcano
     [not found]                         ` <4C125BA4.4020300-GANU6spQydw@public.gmane.org>
2010-06-13  9:59                           ` Eric W. Biederman
     [not found]                             ` <m11vcbl0d5.fsf-+imSwln9KH6u2/kzUuoCbdi2O/JbrIOy@public.gmane.org>
2010-06-13 13:35                               ` Mathieu Peresse
2010-06-13 20:30                               ` Daniel Lezcano [this message]
2010-06-13  9:43                       ` 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=4C153FD7.7000400@free.fr \
    --to=daniel.lezcano-ganu6spqydw@public.gmane.org \
    --cc=containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
    --cc=ebiederm-aS9lmoZGLiVWk0Htik3J/w@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox