Chroot jailed X application testing in Debian
Setup a chroot jail to test some application
Sometimes you don't need a LXC container, and a chroot will do fine.
When you want to test an application, that requires additional packages to installed, you don't always want to install all those extra software on your desktop or laptop. Once installed, these packages come up with every update and are eating disc space.
When the idea is to get rid of all this stuff after the testing is done, a chroot jail is a good solution. Just install the base system in the chroot directory, install the extra needed packages and test your application. When you are done, you can obliterate the chroot directory, and everything is neat and clean again.
Debian is a great platform for this, because of the great debootstrap utility.
Create a chrooted base system with debootstrap
su - mkdir /srv/chroot cd chroot debootstrap stretch stretch http://ftp.nl.debian.org/debian
Here, we install the stretch version of Debian in a directory called stretch, and install from the mirror on ftp.nl.debian.org.
This is done as the root user, hence the "su -" at the start.
We choose to install the chroot in the directory /srv/chroot. This can of course be any other place.
In our example we can have several chroots adjacent to each other, f.e.:
Create a user in the chrooted base system
Enter the chroot, and add a user.
su - cd /srv/chroot/stretch chroot . adduser newuser
Leave the chroot environment with exit.
We can add additional packages from within the chroot directory.
Enter the chroot, and add packages:
su - cd /srv/chroot/stretch chroot . apt-get update apt-get install gman
Setup the necessary mount points
In order to use our new chroot, we have to create some additional mount points:
cd /srv/chroot/stretch mount -t proc /proc proc/ mount --rbind /sys sys/ mount --rbind /dev dev/ mount --bind /tmp tmp/ mount --rbind /var/run/dbus run/dbus/ mount --rbind /var/lib/dbus var/lib/dbus/ mount --rbind /run/user run/user/
After a reboot you have to recreate these mounts. If you run chroots more often, then it might be a good idea to put these lines in a small shellscript.
Prepare for X applications to connect to your local running X session
On the host, so outside the chroot, allow connections to be made to your running X session:
You do this as the user who is logged in on your desktop machine and has started X.
On the host, so outside the chroot, see how to connect to your running X session:
set | grep DISPLAY
This will show your display settings, like;
Setup the DISPLAY variable in your chroot
Inside the chroot, set the DISPLAY variable:
su - cd /srv/chroot/stretch chroot . su - newuser export DISPLAY=:0.0
First, we become the local user inside the chroot environment. There we set the DISPLAY variable.
Now, start your X application
(Here we use gman, as this is a small X application so you can quickly test your settings.)
You can add the line that sets the DISPLAY variable to your local .bashrc inside the chroot jail:
echo "export DISPLAY=:0.0" >> ~/.bashrc
After you are done with your test application, leave the chroot. First, type "exit" to leave the local user and return to the root user inside the chroot. After this, type "exit" to leave the chroot.
Debian comes with a very fine configuration of bash in your local .bashrc file. This checks to see if the file /etc/debian_chroot exists. When it does, it changes your prompt in bash. This is a great feature, so you can see at once if the terminal you are typing in, is in- or outside your chroot :)
So in the chroot directory, create the file /etc/debian_chroot and put something useful in it, like "stretch-chroot" or something like that. When you are inside the chroot, your prompt will look something like this:
Neat, isn't it?
Using D-BUS with klauncher in the chroot environment
I had a lot of trouble getting KDE applications running in the chroot environment, because of D-BUS connection errors.
This is what helped me starting a KDE application:
dbus-launch --autolaunch=`cat /var/lib/dbus/machine-id`
Run this in the chroot, with the same userid as on the real desktop session on the host. So f.e. on the host X is started with the user with userid 1001, then inside the chroot make sure you su to the user with the same userid 1001 in /etc/passwd.
Because of the bind mount of /var/lib/dbus, the machine-id of the host and the one inside the chroot jail are the same.
After your test is finished, you can simply obliterate the chroot directory.
A chroot is not as secure as a virtual machine. It is possible to escape from a chroot environment. However, for testing applications or building applications this is a great solution.
Opening up X for connections, which you do with the "xhost +" command, is considered unsafe. Make sure you do this only in a trusted environment.
Keep calm and have fun with your chroots with X apps.