After upgrading the VCT container to Wheezy, the turn came to the Debian sliver template. Besides the upgrade, I decided to make templates more useful by including enough configuration (to be discarded during sliver deployment in a node) as for being directly usable as containers for testing in one's PC. Since the template comes in a read-only Squashfs I included instructions on how to unpack the template into the local file system, but I also had a good time using LXC mount hooks to place a writable directory on top of the read-only template using AuFS or overlayfs. I also tried a more sophisticated approach which has the writable directory loop-mounted from a fixed-size image file, a simple and neat way to limit the disk space used by a container. Serge Hallyn liked the idea a lot, but unfortunately on container stop the image doesn't get properly unmounted and loop devices remain undetachable.
Also, while testing on Ubuntu hosts I found that the read-only proc causes the
error "lxc-start: Read-only file system - failed to change apparmor profile to
lxc-container-default", so I made it writable since it is now supposed to be
properly isolated from the host's proc. I also found that keeping the
sys_boot capability makes possible to halt and reboot the container properly
(regardless of Debian bug 706676). :)
I also added these latter fixes to the VCT container, but the really important change is how CONFINE software is now installed in it. Previously, the container only included a clone of the confine-dist repository (which includes VCT), a bare installation of the at-the-time-latest confine-controller, and their dependencies. The software wasn't configured at all. This saved some download time for some software, but VCT installation and configuration always had to be run, which resulted in software being downloaded and replaced and more data files (node images and sliver templates) being downloaded. It also implied that container preparation had to somehow replicate VCT and controller installation.
To avoid these problems and provide a container where VCT can be run out of
the box with no installation or downloads whatsoever, I changed the way the
container is prepared to simply include an invocation of vct_system_install.
This simplified its preparation, installation and usage enormously, of course
at the price of having a bigger container image that includes all downloaded
files. However users will be glad to know that they only need to run
vct_system_init to have a working VCT environment. :)
Pingback