Running testing/unstable applications in Debian stable

[Head_on_a_Stick]

As we already know, adding testing/unstable repositories to a Debian stable system is unwise.
https://wiki.debian.org/DontBreakDebian ... nkenDebian

However, those who have elected to run systemd as their init system can take advantage of it's inbuilt namespace isolation scheme, systemd-nspawn, to run a Debian sid system in a lightweight, simple container within the stable system.

To set this up, first create the necessary directories for machinectl(1):

Code: Select all

# mkdir -p /var/lib/container/sid

`btrfs subvolume create` could be used instead for the sid system root directory.

Then install a basic sid system there:

Code: Select all

# debootstrap sid /var/lib/container/sid http://httpredir.debian.org/debian

https://packages.debian.org/jessie/debootstrap

Now start a root shell in the container:

Code: Select all

# systemd-nspawn --directory=/var/lib/container/sid

From there, add a new user:

Code: Select all

# adduser $user

Replace $user with the desired username, make sure that this (along with the UID & GID) matches the username for the "host" Debian stable system.

Now install sudo and add the user to that group:

Code: Select all

apt install sudo
gpasswd -a $user sudo

The shell can then be closed by holding down <Ctrl> and pressing the "]" key three times in quick succession (or by running `poweroff`).

Once this is done, log in to the system as the normal user with:

Code: Select all

# systemd-nspawn --boot --directory=/var/lib/container/sid

From there, the desired package(s) can be installed safely without disturbing the stable host.


To run a program from the container, simply set $DISPLAY explicitly; for example, to run `foobar`:

Code: Select all

DISPLAY=:0 foobar

The container can be started automatically at boot with:

Code: Select all

# systemctl enable systemd-nspawn@sid.service

Once the container is running, $application can be started with this general format:

Code: Select all

# systemd-nspawn --directory=/var/lib/container/sid --setenv=DISPLAY=:0 --user=$user $application

Here is a usage example for running Mandelbulber2:
https://forums.bunsenlabs.org/viewtopic ... 230#p34230

Further parameters may be needed depending on the application, consult systemd-nspawn(1)

For users who elect not to run systemd as their init system, see this guide by @fsmithred:
viewtopic.php?p=622055#p622055

[dasein]

Even though I'm not a huge fan of stickys, someone with a Green Hammer or above really ought to sticky this, IMO.

[JLloyd13]

Excellent! I second the call for a sticky

[dilberts_left_nut]

Another wish granted ... (only one left )

Been meaning to look into systemd-nspawn , cheers HOAS!

[stevepusser]

A nice trick for unbackportable applications!

But I took a look at mandelbulber2 from upstream, and it turns out that all the libgsl contortions can be avoided by building it against the stock libgls0-dev in Jessie, either by replacing libgsl-dev with that in the Build-Depends in debian/control, or adding it as an alternate B-D:

Code: Select all

libgsl-dev | libgsl0-dev,

The program builds and runs, even though the Qt 5 interface comes out as the fugly win95 Raleigh-type interface, when the rest of my Qt 5 apps are respecting my GTK theme in xfce.

Edit: weirdly, it looks OK when started from the menu; it has the funky old look only when I start it from the command line, as I did when first testing it to look for any messages or errors.

[Head_on_a_Stick]

The program builds and runs, even though the Qt 5 interface comes out as the fugly win95 Raleigh-type interface, when the rest of my Qt 5 apps are respecting my GTK theme in xfce.

Yes, that happened when I built it manually under Arch

Thanks for the information!


I feel I should note that this method is *inherently insecure* and should not be used with untrusted applications.

For such programs, an unprivileged container using LXC would be the way to go:
https://www.stgraber.org/2014/01/17/lxc ... ontainers/

[golinux]

However, those who have elected to run systemd as their init system can take advantage of it's inbuilt namespace isolation scheme, systemd-nspawn, to run a Debian sid system in a lightweight, simple container within the stable system.

FYI . . . an interesting discussion of systemd-nspawn in relation to the world of virtualization. The punch line:

But for a whole package, use lxc. It will configure all of the above for
you. systemd-nspawn is merely a NIH copy of it.

[Head_on_a_Stick]

FYI

Yes indeed, very interesting -- thanks

But for a whole package, use lxc.systemd-nspawn is merely a NIH copy of it.

I would agree with the general point that systemd-nspawn is not a complete container solution and lacks a lot of the features of LXC (as intimated in my post immediately above yours) but for me the main advantage of systemd-nspawn is it's simplicity and the automatic integration of the host network (although this can be disabled) with no need for bridges or any of that nonsense.

In respect of the "NIH" comment, I would note that systemd-nspawn is primarily intended for debugging and testing and also that I would prefer to use the systemd-supplied components (systemd-boot, systemd-networkd, systemd-resolved, etc) wherever available as I believe this offers a more cohesive, UNIX-like working environment.

[golinux]

Yes, I did see your post above mine. As to your last para conclusion . . . that would depend on your definition of a "UNIX-like working environment" which many argue that systemd is NOT and in fact files in the face of!

[JLloyd13]

Yes, I did see your post above mine. As to your last para conclusion . . . that would depend on your definition of a "UNIX-like working environment" which many argue that systemd is NOT and in fact files in the face of!

The OP made it very clear this is simply a guide for an option for those who chose to use systemd as their init system. Everyone is well aware of the systemd vs Unix arguments and we don't need to rehash them in a howto.

[golinux]

Everyone is well aware of the systemd vs Unix arguments and we don't need to rehash them in a howto.

Really? Everyone? Unlikely. So I think it's always a good idea to present a differing opinion. Otherwise 'opinion' can easily turn into fact and the rewriting of history becomes a fait accompli.

[JLloyd13]

Everyone is well aware of the systemd vs Unix arguments and we don't need to rehash them in a howto.

Really? Everyone? Unlikely. So I think it's always a good idea to present a differing opinion. Otherwise 'opinion' can easily turn into fact and the rewriting of history becomes a fait accompli.

everyone is a poor word choice, which is my bad, but on this forum I think at least most users are well aware of the controversy. My point is this isn't the place to continue to debate systemd. Maybe a moderator would disagree, but I think your comments are both nonconstructive and off topic. If you wanted to do something that is actually constructive, you could perhaps create a systemd-less guide yourself as an alternative.

[fsmithred]

Here's an alternate way to do the same thing without systemd-nspawn:

Do the debootstrap install and create a user as described above. (Note: in this case, the user does not need to be the same as the user on the host system. Edit: Looks like the uid and gid do need to be the same, but the name can be different.)
Set a root password. (You could probably set up sudo as described above, but I've never done that.)

Instead of a debootstrap install, you could use an existing installation on another partition. If so, mount that partition somewhere. For the purpose of this guide, $chrootdir is either the mount point of that other system, or it's the directory where you debootstrapped sid. (i.e. /var/lib/container/sid in the OP.)

Mount some stuff:

Code: Select all

mount --bind /sys $chrootdir/sys
mount --bind /proc $chrootdir/proc
mount --bind /dev $chrootdir/dev
mount --bind /dev/pts $chrootdir/dev/pts

Then go into the chroot:

Code: Select all

chroot $chrootdir

You now have a root shell in the chrooted system (sid). You can run commands as root or 'su $user' to run commands or graphical applications as user.

To run a window manager, you can install the xserver-xephyr package in the chroot. I'll use icewm here for example.*

Code: Select all

apt-get install xserver-xephyr icewm

Switch to unprivileged user and start Xephyr and icewm:

Code: Select all

su $user
Xephyr :1 -screen 1024x768 -resizeable & sleep 2 ; icewm --display=:1

Have fun!

* I know icewm and jwm work. I couldn't get xfce4 to run, and I didn't see how to set the display number with openbox in the five seconds I looked at the man page.

[Head_on_a_Stick]

^ That's brilliant, thanks fsmithred!


I have added a link to your post in the OP.

[Head_on_a_Stick]

Once the container is running, $application can be started with this general format:

Code: Select all

# systemd-nspawn --directory=/var/lib/container/sid --setenv=DISPLAY=:0 --user=$user $application

For use with untrusted programs, try this command instead:

Code: Select all

# systemd-nspawn --directory=/var/lib/container/sid --setenv=DISPLAY=:0 --user=$user --drop-capabilities=CAP_SYS_ADMIN $application

This drops CAP_SYS_ADMIN within the container and should increase security significantly.

Thanks to Mr. Poettering for that tip:
https://lists.freedesktop.org/archives/ ... 28140.html