Thanks for you answer. I was thinking about removing CAP_NET_ADMIN capabilities but I think this will have a huge impact on applications running into the container that need like socket and stuff like this.. I have to do a lot of test. Not sure yet what I'm gonna do. The routing solution looks the most efficient .
Creating a network namespace could be another good solution, less impacts and no host dependencies like routing tables. Everything should be up and running after a reboot from the host or from the container. Maybe it will be interesting to provide a unique configuration of the container from the LXC configuration file that fully manage this kind of network configuration giving the opportunity to provide shared hosting containers (what I'm looking for). Cordialement, Benoit ----- Mail original ----- De: "Serge Hallyn" <serge.hal...@ubuntu.com> À: "lxc-users" <lxc-users@lists.linuxcontainers.org> Envoyé: Lundi 29 Juin 2015 10:54:22 Objet: Re: [lxc-users] LXC - Best way to avoid networking changes in a container Quoting Fajar A. Nugraha (l...@fajar.net): > On Fri, Jun 26, 2015 at 8:20 PM, Benoit GEORGELIN - Association > Web4all <benoit.george...@web4all.fr> wrote: > > Hi Fajar, > > > > If the container have this setting > > > > lxc.network.type = veth > > lxc.network.flags = up > > lxc.network.hwaddr = 00:16:3e:2e:51:17 > > lxc.network.veth.pair = veth-cont1-0 > > lxc.network.ipv4 = 209.126.100.172/32 > > lxc.network.ipv4.gateway = 10.0.0.1 > > > > > > And the root user in the container change the file /etc/network/interfaces > > to something else than > > > > iface eth0 inet manual > > > > Does the container configuration will be still the one used or the new ip > > address configured in the container will be talking to the network though > > the veth ? > > > The container config lines above makes lxc-start configure necessary > IP and routes. If the container has its own configuration, it will > override the current active ip/routes. > > If the container root user change its configuration (e.g > /etc/network/interfaces) to use the SAME IP/routes (like in my > previous link), it would obviously still work. > > If the container root user change it to use another container (e.g. > container B)'s IP address, then AFAIK the host will simply ignore it. > At least that what happens on my tests. If you really want to have the container not change its networking, I suppose you could either not grant it CAP_NET_ADMIN, or you could create a network namespace for the container, set it up, and then run the container inside that with 'lxc.network.type = none' in the container configuration. Otherwise, using ebtables/iptables to lock the container's veth to its mac and ip seem the best ways. It may be worth adding a new network_up hook which is sent the names of the host-side nics, and run from the host network namespace (obiously requiring root), to easily script setting these. _______________________________________________ lxc-users mailing list lxc-users@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-users _______________________________________________ lxc-users mailing list lxc-users@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-users
