Virtualizing without virtualizingKapil Hari Paranjape |
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 EULA1 that you must agree to if you want to read further:
Here some possible scenarios where one might want to run programs in a virtual context in spite of these (admittedly rather stringent) conditions:
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!).
apt-get
is great for resolving dependencies for
upgrades; those who tried a downgrade have not lived
to tell the tale).
Your super-user avatar (SU) must carry out the following steps for you to enter the virtual context.
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.
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.
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; which 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”.
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
to get the weasel up and running in that session. If you run this command another time, you will not create a new session.
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 overheads (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.
This document was translated from LATEX by HEVEA.