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
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
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.