Virtualizing without Virtualizing

By Kapil Hari Paranjape

Introduction

Nowadays one reads a lot about virtualization. The Gazette even ran an article on it. Most of these reports talk about Xen, Vserver, OpenVZ, Qemu, User Mode Linux or co-Linux. Each of those modern technologies has its place no doubt, but this article will concentrate on the humble chroot way of running programs in a virtual environment.

Here is the EULA¹ that you must agree to if you want to read further:

• The software you want to run “virtually” can run with your currently running kernel.
• Your super-user avatar trusts that the software you want to run is no less trustworthy than the software that is currently running on the system.
• You have enough disk-space to replicate a complete installation.
• You use Debian or a derived distribution. (These days that last line probably reads: “You run Ubuntu!”)

Here some possible scenarios where one might want to run programs in a virtual context in spite of these (admittedly rather stringent) conditions:

• You have installed the amd64 flavour of Debian but you need to compile and/or use 32-bit programs. (Read as: You want to see those flash thingies that everyone is talking about!).
• You have installed Debian stable but you want to “try out” some packages from testing or unstable; and you don’t really want to mess up your stable installation. (apt-get is great for resolving dependencies for upgrades; those who tried a downgrade have not lived to tell the tale).
• You really like Debian but the BDFL² has waltzed into town looking for new employees for Canonical and you want to impress him by running the Hardy Heron.
• “Girls³ just want to have fun!”. This is often the best reason of all — after all LG stands for Fun with Linux!

Ask the super

Your super-user avatar (SU) must carry out the following steps for you to enter the virtual context.

Allocate disk space

Either there is already enough disk space on some mounted partition or you have an unused partition. You will need this empty space to appear in some fixed location like /srv/schroot. SU can use mount (with the --bind option in the former case) to set this up.

Create a new Debian installation

Do not reach for that Debian boot CD! Here is a way that does not destroy your uptime record. SU should install debootstrap:

apt-get install debootstrap

and run it:

debootstrap --include=iceweasel,mozplugger lenny /srv/schroot

SU can of course replace iceweasel and mozplugger by any comma-separated list of programs which need to be installed. It is nice to add a local mirror at the tail end of the debootstrap invocation so as to get a faster download.

The main program

Since you run Debian, installing schroot is as easy as SU running:

apt-get install schroot

You also need to configure schroot; there are a number of rather interesting options. The following configuration stanza seemed to be just right:

[lenny]
description=Debian lenny (testing)
location=/srv/schroot
type=directory
users=luser
root-groups=root
root-users=root
aliases=testing,default
run-setup-scripts=true
run-exec-scripts=true

If you are planning to use a 32-bit chroot under a 64-bit system then you need to have personality=linux32 as part of this configuration. The above stanza is placed in the file schroot.conf in the configuration directory /etc/schroot/. It says that SU allows the user luser to use schroot to run under the directory /src/schroot after various standard setup and startup scripts have been executed.

You should also look through the setup script 10mount in the setup.d sub-directory of the above directory as you may need to create some additional mounts. For example, adding the line

do_mount "-o rw,bind" "/dev/snd"    "${CHROOT_PATH}/dev/snd"

to 10mount together with the creation of the dev/snd subdirectory of /srv/schroot ensures that the (ALSA) sound devices are accessible in the chroot. This is extremely important for flash!

That completes the setup that the super-user needs to do. After this, luser can go ahead and play in this newly created “sand-box”.

All play and no work

The authorized user luser can execute a shell by running

schroot -p -c lenny

The shell will normally run in an environment where the users home directories, /tmp and /dev will be mounted from the base system. Hence it should be possible to execute commands with need the X window environment as well. (The -p option given above is required to preserve the environment that includes the DISPLAY variable).

Another way to run a command like iceweasel directly is

schroot -p -c lenny iceweasel

Note that each such command creates a new schroot “session”. To re-use an already created session, you must save the session identifier and use it. For example, you can start a new session, without any command:

SCHROOT_SESSION=$(schroot -b -c lenny)

If you then issue the command

schroot -p --chroot $(SCHROOT_SESSION) iceweasel

the weasel will start up and run in that session. If you run this command another time, you will not create a new session.

Philosophy

The chroot command has existed for “eons”, but it was often felt that it is “for the super-user only”. By using schroot it becomes quite safely accessible to the regular user of the system. Using this kind of minimal virtualisation is certainly not in the same league security-wise as the “real” virtualisation techniques but has no overhead (except disk-usage); I hope the article demonstrates that schroot is at least as easy to set up.

Using schroot is a good solution to the frequently asked question:

How do I run the late-esht version of <name your favourite rapidly developing application> on Debian?

In my opinion, the above solution is to be preferred over running a mixed stable/testing version of Debian. Even backports are slightly worse, as a mixed stable/backports environment is not what the packages are being tested in by most developers.

The motivation to write this article came from a discussion I saw in the letters to Linux Weekly News where people said that Debian was hindering those who want to run 32-bit programs on a 64-bit system. If indeed mixed library setups are well packaged and maintained, then that is easier than the solution herein. All the same, Debian does have this solution!

The title of this article is inspired by John Archibald Wheeler, one of the most fascinating physicists of the 20th century, who passed away recently.

---

1

This is a dyslexic acronym for “Lookout — Advanced Experimental Usage”

2

Mark Shuttleworth: Benevolent Dictator For Life for Ubuntu

3

or boys as the case may be

Talkback: Discuss this article with The Answer Gang

---

Kapil Hari Paranjape has been a ``hack''-er since his punch-card days. Specifically, this means that he has never written a ``real'' program. He has merely tinkered with programs written by others. After playing with Minix in 1990-91 he thought of writing his first program---a ``genuine'' *nix kernel for the x86 class of machines. Luckily for him a certain L. Torvalds got there first---thereby saving him the trouble (once again) of actually writing code. In eternal gratitude he has spent a lot of time tinkering with and promoting Linux and GNU since those days---much to the dismay of many around him who think he should concentrate on mathematical research---which is his paying job. The interplay between actual running programs, what can be computed in principle and what can be shown to exist continues to fascinate him.