Linux Containers: Configuring Network Address (part 636)

 Computing, Linux, Working Notes  3 Responses »
Jun 052019
 

On previous occasions (yes that does mean more than once) I have messed around with the network configuration of containers to get :-

  1. A consistent behaviour.
  2. A fixed IPv4 address with no DHCP configuration (this one is easy).
  3. A fixed IPv6 address with no autoconfigured global addresses (this one has been tricky)

This turns out to be relatively easy providing that you configure the addresses within the container rather than within the container configuration. At least it looks good to go so far (I’ve been mistaken in the past).

The container configuration is quite simple :-

lxc.net.0.type = veth
lxc.net.0.flags = down
lxc.net.0.link = br0

Note that the bridge interface (br0) may be different. Also note that there is no lxc.net.0.ipv4.address, lxc.net.0.ipv4.gateway, lxc.net.0.ipv6.address, or lxc.net.0.ipv6.gateway.

The configuration within the container is dependent on what userland you are running, but for Debian (and Ubuntu if you’re not using Netplan) :-

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
    address 10.0.0.34/16
    gateway 10.0.0.1

iface eth0 inet6 static
    address 2001:0db8:cafe:dead:0000:0000:0000:3eb/64
    scope global
    gateway 2001:0db8:cafe:dead:0000:0000:0000:0001
    privext 0
    accept_ra 0
    autoconf 0

Not sure quite which options are required but having all of “privext 0”, “accept_ra 0” and “autoconf 0” does mean no additional autoconfigured IPv6 addresses.

(And no the part number of this post isn’t anything more than a joke)

Linux Containers: Don’t Configure The Container Network

 Computing, Linux, Working Notes  1 Response »
Oct 032015
 

More up to date information can be found here.

One thing that has always puzzled me about Linux Containers was why it is necessary to configure the network address in two places – the container configuration, and the operating system configuration. The short answer is that it isn’t.

If you configure network addresses statically within the container configuration :-

» grep net /var/lib/lxc/mango/config 
# networking
lxc.network.type = veth
lxc.network.flags = up
lxc.network.link = br0
lxc.network.ipv4 = 10.0.0.35/16
lxc.network.ipv4.gateway = 10.0.0.1
lxc.network.ipv6 =         2001:0db8:ca2c:dead:0000:0000:0000:000a/64
lxc.network.ipv6.gateway = 2001:0db8:ca2c:dead:0000:0000:0000:0001

Then the configuration within the container’s operating system can simply be :-

» cat /var/lib/lxc/mango/rootfs/etc/network/interfaces
auto lo
iface lo inet loopback

auto eth0
iface eth0 inet manual
iface eth0 inet6 manual

And that works fine.

Linux Containers: Disabling The Autoconfigured IPv6 Address

 Computing, Linux, Working Notes  No Responses »
Oct 032015
 

A newer post has more information (and more reliable information).

One of the things that has been mildly irritating me about my little collection of Linux containers has been that in addition to the statically defined IPv6 addresses, there is also an automatically defined IPv6 address :-

» lxc-ls --fancy
NAME      STATE    IPV4       IPV6                                                              AUTOSTART  
---------------------------------------------------------------------------------------------------------
apricot   RUNNING  10.0.0.34  2001:db8:ca2c:dead:21e:a0ff:feb6:6a, 2001:db8:ca2c:dead::3eb      YES        
chagers   RUNNING  10.0.0.32  2001:db8:ca2c:dead:804a:bfff:fe83:f98d, 2001:db8:ca2c:dead::5e11  YES        
glanders  RUNNING  10.0.0.31  2001:db8:ca2c:dead:21e:a0ff:feb6:66, 2001:db8:ca2c:dead::ba11     YES        
lyme      RUNNING  10.0.0.30  2001:db8:ca2c:dead:21e:a0ff:feb6:65, 2001:db8:ca2c:dead::cafe     YES        
mango     RUNNING  10.0.0.35  2001:db8:ca2c:dead:6c42:24ff:fe7d:4e9, 2001:db8:ca2c:dead::a      YES        
peach     RUNNING  10.0.0.33  2001:db8:ca2c:dead:21e:a0ff:feb6:68, 2001:db8:ca2c:dead::3a11     YES        
rhubarb   RUNNING  10.0.0.40  2001:db8:ca2c:dead:21e:a0ff:feb6:69, 2001:db8:ca2c:dead::dead     YES

Now this is hardly the end of the world, but it is not tidy and it is the sort of thing that may lead to problems down the road if servers are communicating on an address that is not reverse DNS registered. Or indeed when someone contacts a server on an address such as 2001:db8:ca2c:dead::3eb and the reply comes from 2001:db8:ca2c:dead:21e:a0ff:feb6:6a.

After any number of false starts, the answer is quite simple – use sysctl to turn off autoconfigured address from within the container; which doesn’t make much sense logically – containers don’t have a kernel of their own, so the global kernel should be the one that is tuned. However :-

for container in $(lxc-ls)
do
  echo net.ipv6.conf.eth0.autoconf = 0 >> /var/lib/lxc/$container/rootfs/etc/sysctl.conf
done

Does the trick (after a reboot)  :-

» lxc-ls --fancy
NAME      STATE    IPV4       IPV6                                                              AUTOSTART  
---------------------------------------------------------------------------------------------------------
apricot   RUNNING  10.0.0.34  2001:db8:ca2c:dead:21e:a0ff:feb6:6a, 2001:db8:ca2c:dead::3eb      YES        
chagers   RUNNING  10.0.0.32  2001:db8:ca2c:dead:18d9:99ff:fe28:3591, 2001:db8:ca2c:dead::5e11  YES        
glanders  RUNNING  10.0.0.31  2001:db8:ca2c:dead:21e:a0ff:feb6:66, 2001:db8:ca2c:dead::ba11     YES        
lyme      RUNNING  10.0.0.30  2001:db8:ca2c:dead::cafe                                          YES        
mango     RUNNING  10.0.0.35  2001:db8:ca2c:dead:2411:80ff:feb9:6600, 2001:db8:ca2c:dead::a     YES        
peach     RUNNING  10.0.0.33  2001:db8:ca2c:dead::3a11                                          YES        
rhubarb   RUNNING  10.0.0.40  2001:db8:ca2c:dead::dead                                          YES        

Except for the older containers 🙁

I’ve obviously missed something, but fixing nearly half of the containers is a good start.

After attending to pending upgrades (some of my old containers were still running wheezy), and setting the network configuration to manual, one of the recalictrant containers (glanders) lost it’s autoconfigured address.

Two more containers lost their unwanted extra addresses after “fixing” their configuration. I’m not sure what was wrong with the old configuration, but after copying and modifying a recently created container configuration, they rebooted with just one IPv6 address. The last one was mango, but after an extra reboot, it also was fixed :-

» lxc-ls --fancy
NAME      STATE    IPV4       IPV6                      AUTOSTART  
-----------------------------------------------------------------
apricot   RUNNING  10.0.0.34  2001:db8:ca2c:dead::3eb   YES        
chagers   RUNNING  10.0.0.32  2001:db8:ca2c:dead::5e11  YES        
glanders  RUNNING  10.0.0.31  2001:db8:ca2c:dead::ba11  YES        
lyme      RUNNING  10.0.0.30  2001:db8:ca2c:dead::cafe  YES        
mango     RUNNING  10.0.0.35  2001:db8:ca2c:dead::a     YES        
peach     RUNNING  10.0.0.33  2001:db8:ca2c:dead::3a11  YES        
rhubarb   RUNNING  10.0.0.40  2001:db8:ca2c:dead::dead  YES        

Solaris Zone Descriptions In Zone Configuration

 Computing  No Responses »
Jul 272009
 

I am a big fan of ‘self-documenting’ systems where the system has enough ‘comments’ to describe how it is configured and what things are doing. Unfortunately Solaris zones (or containers if you are so inclined to use the marketing name) lack one feature that would assist this :-

# zoneadm list -d
global
black                  Stealth Secondary DNS
grey                   Webserver for project X
white                  Mailbox server for project Y
blue                   Oracle DBMS for project X
puce                   MySQL DBMS for project X

It would seem that project Y hasn’t gotten beyond the talking stage 🙂

Yes, you’ve guessed it. Solaris zones could do with a “description” attribute to assist in documentation.