Re: RFC: Network namespaces in NM

[Stjepan Groš <stjepan gros fer hr>]

On 04.02.2016 17:12, Thomas Haller wrote:

On Thu, 2016-02-04 at 12:21 +0100, Stjepan Groš wrote:

Hi!

Is anyone working on network namespaces support in NetworkManager? Or
was thinking what is a "proper way" of implementing them?

Nobody is currently working on that. Great that you pick it up. You did
already an impressive amount of work!

I'm experimenting with adding support to NM and what I implemented so
far is:

1. Added objects NMNetnsController which would control all network
namespaces managed by NM.

2. Each network namespace is represented with an object NMNetns and
exposed on DBus. There are no methods so far but only a property name
which contains network namespace's name on the filesystem.

3. NMNetnsController exposes object NetworkNamespacesController with
methods AddNetworkNamepace and ListNetworkNamespaces. The first one
take a name as an argument and creates a new (iproute2 compatible)
network namespace, while the second one provides a list of existing
namespaces.

4. When new network namespace is created (using  AddNetworkNamepace
method) a new, private, platform layer is instantiated and loopback
interface within namespace activated. Note that new platform layer
has to be created because once a socket is opened in one network
namespace it is bound to the given namespace no matter which
namespace is active so current singleton object wouldn't work without
heavy refactoring!

What I intend to do next is:

1. NM has to monitor devices/IP addresses in new network namespaces
properly.

2. Methods that would allow an IPv4 or IPv6 address to be assigned in
some network namespace.

All the code is here:

https://github.com/sgros/MIF_NetworkManager

and since this is PoC, there are A LOT OF BUGS AND MISSING FEATURES.

So, what do you think? Any comments, suggestions, critiques, etc?

This was on the future todo list, but at this point it's not yet fully
clear what is the purpose of netns support in NM should be.

I could imagine:

  - exposing runtime configuration about existing netns on the D-Bus 
    API
  - possibly including the devices and IP address configuration on
    each of these namespaces
  - possibly creating new namespaces
  - possibly an "ip netns exec" counterpart?

The above is relatively easy.

The use case scenario I'm trying to implement is the possiblity of isolating certain network configurations. The main example of this would be VPN connection, i.e. the ability to put VPN connection into separate network namespace and then to start applications in this namespace and so restrict them to use a specific network connection.

Also, in IET MIF group is discussing scenarios in which clients are provisioned with "special" network configuration that allow them, e.g. to access IPTV or VoIP services.

Possibly there are other possibilities of using such configurations.

One thing to consider is that potentially a huge number of netns exists
(e.g. spawning many containers). So, we must be careful not to do too
much.
For example, NM uses D-Bus ObjectManager, meaning that (even if there
are no users interested in those namespaces), the D-Bus API will
already construct the whole object tree.
Preferably objects are created on demand so you don't pay for it if you
don't use it.

I'm not certain that I understood this? I don't think that NM should manage every network namespace there is, just the opposite. My intention is to allow NM to use network namespaces for its own purposes (isolation of certain connection it manages) but to not touch anything else. D-Bus exposes what ever it is told to expose, so if I don't tell him to expose certain network namespaces it won't.

What beyond that? Yes I see https://datatracker.ietf.org/wg/mif/charter
 , but that seems like a big thing which needs lots of thoughts.
NetworkManager mostly managed devices and IP configuration (in it's
netns). 

(I'm sorry if the above link explains it all. I will read up on it!)

Yes, it really needs a lots of thoughts and that's the reason MIF WG decided to retract with majority of current proposals and wait for some implementations to appear. On of the implementations is the one I'm working on currently. They then want to continue based on the experiences gained. There is also one "interesting" IPR claim regarding DHCP configuration of multiple provisioning domains (networking configuration). You can read more about IPR claim in the draft I wrote with my colleagues:

https://tools.ietf.org/html/draft-sgros-dhcp-and-ipr-claim-analysis-00

Sadly, IETF doesn't want nor has resources to dig this deeper. That is the reason I'm working only on IPv6 part for the time being

SG

P.S. To be able to run patched NM you also need patched libndp
library available here:

https://github.com/sgros/MIF_libndp

Some comments:

it would be great if you could adhere strictly to our coding style.


+typedef struct _pvdid {
+    enum ndp_pvdid_type type;
+    guint8 len;
+    union {
+         char uuid[37];
+    };
+} PVDID;

all stuff in headers *must* have a nm/NM prefix.

Typedefs are camel cased

no // comments

we are picky about whitespace.


+    pvds = nm_device_get_pvds(device);
                             ^^^ space

#define BUFFER_SIZE»»···2048
no non-leading tabs




+// TODO: Remove this, only for debugging using printfs
+#include <stdio.h>

there is g_print(), g_message(), _LOGx(). Just use those.



libnm/nm-ip-config.h:

#include <ndp.h>

I think we don't ever want to include ndp.h for our client headers.





+    g_dbus_method_invocation_return_value (context,
+                        g_variant_new ("(^ao)", (char **) paths));

First indention with tabs, then with spaces to align the second line.




+ * (C) Copyright 2007 - 2011 Red Hat, Inc.
+ * (C) Copyright 2008 Novell, Inc.

headers.





+     * Create a node in /var/run/netns 

no trailing whitespaces

Ok, I'll adhere to this suggestions and in time I'll fix existing stuff.

Come see us on #nm on freenode and possibly merge individual features
early -- maybe it's beneficial to merge small parts towards the full
solution.

Great! I'll come by next week.

SG

Great stuff!!
(looking more later)

Thanks
Thomas

Attachment: signature.asc
Description: OpenPGP digital signature