Difference between revisions of "Linux Containers"

From Funtoo Linux
Jump to: navigation, search
(Setting up a Funtoo Linux LXC Container)
(/etc/lxc/funtoo/fstab)
Line 103: Line 103:
 
none /lxc/funtoo/proc proc defaults 0 0
 
none /lxc/funtoo/proc proc defaults 0 0
 
none /lxc/funtoo/sys sysfs defaults 0 0
 
none /lxc/funtoo/sys sysfs defaults 0 0
none /lxc/funtoo/dev/shm tmpfs defaults 0 0
+
none /lxc/funtoo/dev/shm tmpfs nodev,nosuid,noexec,mode=1777,rw 0 0
none /lxc/funtoo/libexec/rc/init.d tmpfs defaults 0 0
+
none /lxc/funtoo/libexec/rc/init.d tmpfs rw,mode=755 0 0
 
</pre>
 
</pre>
  

Revision as of 17:19, 27 December 2011

Linux Containers, or LXC, is a Linux feature that allows Linux to run one or more isolated virtual systems (with their own network interfaces, process namespace, user namespace, and power state) using a single Linux kernel on a single server.

Contents

Configuring the Funtoo Host System

Install LXC kernel

I am using vanilla-sources-3.1.0 with no initrd.

Emerge lxc

Configure Networking For Container

Typically, one uses a bridge to allow containers to connect to the network. This is how to do it under Funtoo Linux:

  1. create a bridge using the Funtoo network configuration scripts. Name the bridge something like brwan (using /etc/init.d/netif.brwan). Configure your bridge to have an IP address.
  2. Make your physical interface, such as eth0, an interface with no IP address (use the Funtoo interface-noip template.)
  3. Make netif.eth0 a slave of netif.brwan in /etc/conf.d/netif.brwan.
  4. Enable your new bridged network and make sure it is functioning properly on the host.

You will now be able to configure LXC to automatically add your container's virtual ethernet interface to the bridge when it starts, which will connect it to your network.

Setting up a Funtoo Linux LXC Container

Here are the steps required to get Funtoo Linux running inside a container. The steps below show you how to set up a container using an existing Funtoo Linux OpenVZ template. It is now also possible to use Metro to build an lxc container tarball directly, which will save you manual configuration steps and will provide an /etc/fstab.lxc file that you can use for your host container config. See Metro Recipes for info on how to use Metro to generate an lxc container.

Create and Configure Container Filesystem

  1. Start with a Funtoo OpenVZ template, and unpack it to a directory such as /lxc/funtoo.
  2. Edit /lxc/funtoo/etc/rc.conf and change rc_sys=openvz to rc_sys=lxc.
  3. Create an empty /lxc/funtoo/etc/fstab file.
  4. Ensure c1 line is uncommented (enabled) and c2 through c6 lines are disabled in /lxc/funtoo/etc/inittab.
  5. Edit udev-mount, udev-postmount and udev-save and change the keyword line to have the arguments -openvz -vserver -lxc. (will be fixed in about a week)

That's all you need to get the container filesystem ready to start.

Create Container Configuration Files

Create the following files:

/etc/lxc/funtoo/config

Daniel Robbins needs to update this config to be more in line with http://wiki.progress-linux.org/software/lxc/ -- this config appears to have nice, refined device node permissions and other goodies.


Read "man 5 lxc.conf" , to get more information about linux container configuration file.

lxc.utsname = funtoo
lxc.network.type = veth
lxc.network.flags = up
lxc.network.link = brwan
lxc.network.ipv4 = <your IPv4 address here, like 1.2.3.4/29>
lxc.network.hwaddr = <your randomly-generated MAC address here, like a2:97:b6:df:df:28>
lxc.network.name = eth0
lxc.mount = /etc/lxc/funtoo/fstab
lxc.rootfs = /lxc/funtoo
lxc.tty = 12
lxc.pts = 128
# allow access to minimal set of device nodes only:
lxc.cgroup.devices.deny = a # deny by default
# Allow only the following devices to be opened:
lxc.cgroup.devices.allow = c 1:3 rwm # dev/null
lxc.cgroup.devices.allow = c 1:5 rwm # dev/zero
lxc.cgroup.devices.allow = c 1:9 rwm # dev/urandom
lxc.cgroup.devices.allow = c 1:8 rwm # dev/random
lxc.cgroup.devices.allow = c 5:0 rwm # /dev/tty - allows ssh-add/password input
lxc.cgroup.devices.allow = c 5:1 rwm # /dev/console - allows lxc-start output
lxc.cgroup.devices.allow = c 4:0 rwm # /dev/tty0
lxc.cgroup.devices.allow = c 4:1 rwm # /dev/tty1
lxc.cgroup.devices.allow = c 4:2 rwm # /dev/tty2
lxc.cgroup.devices.allow = c 136:* rwm # dev/pts/*
lxc.cgroup.devices.allow = c 5:2 rwm # dev/pts/ptmx
lxc.cgroup.devices.allow = c 254:0 rwm # rtc
# restrict capabilities:
lxc.cap.drop = audit_control
lxc.cap.drop = audit_write
lxc.cap.drop = mac_admin
lxc.cap.drop = mac_override
lxc.cap.drop = setpcap
lxc.cap.drop = sys_admin
lxc.cap.drop = sys_boot
lxc.cap.drop = sys_module
lxc.cap.drop = sys_rawio
# By default, don't use lxc.cap.drop = mknod. This will allow mknod to create
# device nodes so build scripts and other things don't fail. Then, we'll
# rely on the devices.deny settings (default deny) to prevent any created 
# device nodes inside the container from being used to access the host's 
# hardware:
# lxc.cap.drop = mknod

Read "man 7 capabilities" to get more information aboout Linux capabilities.

Above, use the following command to generate a random MAC for lxc.network.hwaddr:

# openssl rand -hex 6 | sed 's/\(..\)/\1:/g; s/.$//'

It is a very good idea to assign a static MAC address to your container using lxc.network.hwaddr. If you don't, LXC will auto-generate a new random MAC every time your container starts, which may confuse network equipment that expects MAC addresses to remain constant.

/etc/lxc/funtoo/fstab

none /lxc/funtoo/dev/pts devpts defaults 0 0
none /lxc/funtoo/proc proc defaults 0 0
none /lxc/funtoo/sys sysfs defaults 0 0
none /lxc/funtoo/dev/shm tmpfs nodev,nosuid,noexec,mode=1777,rw 0 0
none /lxc/funtoo/libexec/rc/init.d tmpfs rw,mode=755 0 0

Initializing and Starting the Container

You will probably need to set the root password for the container before you can log in. You can use chroot to do this quickly:

# chroot /lxc/funtoo
(chroot) # passwd
New password: XXXXXXXX
Retype new password: XXXXXXXX
passwd: password updated successfully
# exit

Now that the root password is set, run:

# lxc-start -n funtoo -d

The -d option will cause it to run in the background.

To attach to the console:

# lxc-console -n funtoo

You should now be able to log in and use the container. In addition, the container should now be accessible on the network.

To stop the container:

# lxc-stop -n funtoo

Ensure that networking is working from within the container while it is running, and you're good to go!

LXC Bugs/Missing Features

This section is devoted to documenting issues with the current implementation of LXC and its associated tools. We will be gradually expanding this section with detailed descriptions of problems, their status, and proposed solutions.

reboot

By default, lxc does not support rebooting a container from within. It will simply stop and the host will not know to start it.

PID namespaces

Process ID namespaces are functional, but the container can still see the CPU utilization of the host via the system load (ie. in top).

/dev/pts newinstance

  • Some changes may be required to the host to properly implement "newinstance" /dev/pts. See This Red Hat bug.

lxc-create and lxc-destroy

  • LXC's shell scripts are badly designed and are sure way to destruction, avoid using lxc-create and lxc-destroy.

network initialization and cleanup

  • Re-starting a container can result in a failure as network resource are tied up from the already-defunct instance: [1]

lxc-halt

  • Missing tool to graceful shutdown container. 'lxc-halt' should be written and be posix sh-compatible, using lxc-execute to run halt in container.

funtoo

  • Our udev should be updated to contain -lxc in scripts. (This has been done as of 02-Nov-2011, so should be resolved. But not fixed in our openvz templates, so need to regen them in a few days.)
  • Our openrc should be patched to handle the case where it cannot mount tmpfs, and gracefully handle this situation somehow. (Work-around in our docs above, which is to mount tmpfs to /libexec/rc/init.d using the container-specific fstab file (on the host.)
  • Emerging udev within a container can/will fail when realdev is run, if a device node cannot be created (such as /dev/console) if there are no mknod capabilities within the container. This should be fixed.

References

  • man 7 capabilities
  • man 5 lxc.conf

Links

Personal tools
Namespaces

Variants
Actions
Categories
Toolbox
Stuff