Was sind systemd-nspawn-Container? Kurz gesagt ist ein solcher Container eine auf dem lokalen PC laufende virtuelle Maschine mit einem eigenen Betriebssystem, welches völlig isoliert vom Rest des PCs läuft. Das bedeutet, alle in der VM vorgenommenen Änderungen oder Installationen haben keinerlei Einfluss auf das primäre Betriebssystem, das primäre Betriebssystem bleibt unverändert.

Vielleicht ist es nicht ganz wie eine richtige VM, sondern eher wie eine Chroot-Umgebung, aber es ist eine richtig gut getunte Chroot-Umgebung - systemd selber sagt ein wenig ironisch "wie chroot auf steroide". Ursprünglich waren diese Container wohl mal als Werkzeug für System-Tester oder -Entwickler gedacht. Mittlerweile hat sich diese etwas einfachere Form der Virtualisierung aber wohl auch schon als echte eigenständige Container-Lösung etabliert. Ein systemd-Container ist tatsächlich eine für viele Belange ausreichende virtuelle Maschine auf dem physischen Host, in der sowohl einzelne Prozesse isoliert vom eigentlichen Betriebssystem laufen können und in der tatsächlich sogar auch ein vollständiges Linux-Betriebssystem enthalten kann. Ob ein solches Betriebssystem auch über ein grafisches Desktop-Environment verfügen kann, weiß ich nicht. Ich habe zwar mal was darüber gelesen, mich aber mangels Interesse nicht weiter damit befasst. Ich halte einen solchen Lösungsansatz auch nicht wirklich für eine gute Idee und entscheide dabei eher nach der Devise, für jedes Problem das richtige Programm zu verwenden. Wenn ich also tatsächlich eine VM mit GUI und einem Desktop-Environment benötige, dann verwende ich besser libvirt-VMs, oder Qemu oder VirtualBox, aber sicher nicht einen systemd-nspawn-Container.

Allerdings ist ein solcher Container eine geradezu geniale Lösung, wenn man z.B. mal auf die Schnelle einen neuen Service testen will, oder veränderte Einstellungen, z.B. bei einem Mail-Server, oder einen FTP-Server, oder einen OpenVPN-Server und wenn man das produktiv laufende eigentliche System aus Gründen der gefährdeten System-Integrität nicht leichtsinnig anpacken will. Genau dafür nutze ich das beispielsweise häufig, alle Änderungen werden erst auf einem Testsystem auf Herz und Nieren geprüft und erst dann, wenn die Unbedenklichkeit erwiesen ist, werden die Änderungen auf das produktive System transportiert. Aber ich brauch das auch für die einmalige Erzeugung eines Programms anhand des Quellcodes, wenn dafür die einmalige Installation einer bestimmten Entwicklungsumgebung notwendig ist und ich gleichermaßen auf meinem PC für diese Entwicklungsumgebung in anderer Zeit überhaupt keine Verwendung habe. All das kann der systemd-nspawn-Container geradezu perfekt lösen. Wenn man den Container hinterher löscht, kann man anschließend sicher sein, dass alle dort durchgeführten Aktionen den eigentlichen Arbeits-PC nicht verändert haben, denn alle im Container laufenden Prozesse laufen in einer vom eigentlichen Linux gekapselten Umgebung.

Ich habe in meinem Rechner 8 GB RAM installiert, da bietet es sich geradezu an, den Container allein im RAM zu erstellen. Das erspart es mir, hinterher auch noch wieder den Müll entsorgen zu müssen. Nach einem Poweroff oder Reboot kann ich sicher sein, dass alles zuvor erstellte, generierte oder sonstwie veränderte einfach wieder gelöscht ist.

Auch an dieser Stelle erfolgt der obligatorische Hinweis von mir: Ich verwende kein m.M.n. sicherheitskritisches "sudo" und werde dem bei allen Schritten keine Beachtung schenken. Ich unterstelle, dass ein root-Password vergeben ist und dass alle Arbeiten als root in einer eigenen Login-Shell durchgeführt werden.

Je nach Dauer, wie lange der letzte Upgrade zurückliegt, wird das System zunächst einmal auf einen aktuellen Stand gebracht.

$ su -

# apt update

        Statusinformationen werden eingelesen.... Fertig

        Alle Pakete sind aktuell.

# apt full-upgrade

# systemctl reboot

$ su -

# dpkg -l systemd-container debootstrap

# apt install systemd-container debootstrap

Zuerst wird ein Zielverzeichnis für den Container eingerichtet, in dem der Container erstellt wird. Achtung: Bitte hier unbedingt beachten, dass ich im debootstrap-Command "buster" eingetragen und als Name für den Container D10 (Debian Buster) gewählt habe. Das ist deshalb so, weil auf meinem PC bereits Debian 10 installiert ist. Wenn auf dem eigenen PC und schließlich auch auf dem Ziel-PC (der Server) jedoch eine andere Debian-Distribution installiert ist, so muss natürlich hier auch der passende Name eingetragen sein. Der Container-Name selber kann natürlich frei wählbar geändert werden.

# cd /

# mkdir -p /tmp/D10

# debootstrap buster /tmp/D10

# systemd-nspawn -D /tmp/D10

Spawning container D10 on /tmp/D10.

Press ^] three times within 1s to kill container.

root@D10:~#

# passwd       

# dpkg -l locales dbus

# apt install locales dbus

# dpkg-reconfigure locales

# exit

logout

Container D10 exited successfully. 

# systemd-nspawn -D /tmp/D10 -b

# df

# ip a

# apt purge --remove sudo rsyslog

# apt update; apt full-upgrade

# apt autoremove; apt autoclean       

# hostnamectl set-hostname d10snvm

# timedatectl set-timezone Europe/Berlin

# dpkg -l mc ne htop

# apt install mc ne htop

# apt install cifs-utils --no-install-recommends

# adduser thomas

# systemctl poweroff 

# mkdir -p /home/install

# cd /tmp

# tar -cvf /home/install/d10snvm.tar D10/

# ls /home/install

insgesamt 504M

-rw-r--r-- 1 root root 504M 2019-04-26 16:42 d10snvm.tar

# rm -f -r -d /tmp/D10

Die Sicherung mit tar macht allerdings wirklich nur jetzt in diesem Moment Sinn und auch wirklich nur dann, wenn man dieses fast unberührte Setup in naher Zukunft erneut verwenden will. Wenn man diesen Container für eine spezielle Aufgabe eingerichtet hat und dafür einmal zusätzliche Software installiert hat, ist er eben ab dem Moment kein Basic-Setup mehr. Diese Entscheidung muss man nun treffen... und das vor dem Hintergrund, dass man eigentlich auch nichts verkehrt machen kann. Selbst wenn man diesen Container nach Erreichen seines Ziel einer anderen Aufgabe wieder löschen würde, ist das kein Problem... man sieht ja hier in der Beschreibung, wie schnell man sich wieder einen neuen Container einrichten kann.

Ich behalte diesen frischen Container eigentlich nur deshalb und verwende ihn aus dem tar-File heraus immer wieder für neue Vorhaben, weil zu meinen von mir einmalig installierten Basics eben auch noch das Customizing von Midnight Commander, Nice Editor, Tmux und ein paar eigene Komfort-Scripte gehören. Das erspart es mir, die immer gleichen Einstellungen jedes Mal bei einem komplett neuen Container wiederholen zu müssen. Und jeweils nach dem Ende des neuen Vorhabens wird diese nun geänderte Container-Version beim Ausschalten einfach wieder vergessen, weil er in einer RAM-Disk lief. Aber wie gesagt, viel verkehrt machen kann man dabei nicht.

# cd /tmp

# tar -xf /home/install/d10snvm.tar

# systemd-nspawn -D /tmp/D10 -b

# systemctl poweroff

# machinectl list

# machinectl login D10

# machinectl poweroff D10

# machinectl status D10