Grundsätzlich lassen sich sowohl Desktop- als auch Server-Distributionen in einem Container betreiben. Üblich sind jedoch nur Server, da es nur unter Schwierigkeiten möglich ist, an die grafische Oberfläche zu kommen.

Als fertige Templates lassen sich beispielsweise alle OpenVZ-Templates benutzen. Man findet sie im OpenVZ-Wiki. Die meisten bekannten kostenlosen Distributionen werden in der aktuellen Version unterstützt. Eine Ausnahme bildet openSUSE. Die Templates für die Versionen 11.2 und 11.3 befinden sich noch im Beta-Stadium.

Zunächst muss cgroups nutzbar gemacht werden. Es dient dazu, Limits für die einzelnen Container festzulegen, etwa maximale Hauptspeichernutzung. Das geht mit den Befehlen

mkdir /cgroups
mount -t cgroups none /cgroups

Alle Befehle in dieser Anleitung benötigen Root-Rechte, die man sich praktischerweise einmalig mit sudo -s in einem Terminal verschafft. Damit das cgroup-Dateisystem nach jedem Reboot automatisch gestartet wird, fügt man am besten folgende Zeile in /etc/fstab hinzu:

none /cgroup cgroup defaults 0 0

Wer die Kommandozeilentools für lxc, etwa lxc-create, lxc-start, lxc-ps und lxc-ls, noch nicht installiert hat, sollte dies über die Paketverwaltung seiner Distribution erledigen. Unter Debian beziehungsweise Ubuntu geht das mit dem Befehl

apt-get install lxc

Als nächstes muss eine Konfigurationsdatei erstellt werden. Wichtigste Überlegung dabei ist, wie man das Betriebssystem im Container ans Netzwerk anbindet. In einem Rechner mit mehreren Ethernet-Ports lässt sich beispielsweise ein Interface komplett dem Container zuordnen.

Hat man nur eine Ethernetkarte, kann man ein virtuelles Interface mit einer eigenen MAC-Adresse verwenden. In diesem Fall sieht eine Konfigurationsdatei etwa wie folgt aus:

lxc.utsname = OpenSUSE11-1.ZDNetLabs.DarkTech.org
lxc.network.type = veth
lxc.network.flags = up
lxc.network.link = br0
lxc.network.name = eth0
lxc.network.hwaddr = 00:48:30:64:78:22
lxc.network.ipv4 = 192.168.1.29/24 # auf 0.0.0.0 wenn der Container DHCP benutzt
lxc.tty=4
lxc.pts=1024
lxc.rootfs=/var/lib/lxc/suse/rootfs

Anschließend legt man den Container mit dem Befehl lxc-create an. In folgendem Beispiel soll openSUSE 11.1 in einem Ubuntu-10.10-System virtualisiert werden:

lxc-create -n suse -f lxc-macvlan.conf

Dabei ist suse der frei wählbare Name des Containers und lxc-macvlan.conf der Name der Konfigurationsdatei. Anschließend installiert man das heruntergeladene OpenVZ-Template:

cd /var/lib/lxc/suse
mkdir rootfs
cd rootfs
tar xvf /home/christoh/Downloads/suse-11.1-x86.tar.gz

Vor dem Start des Containers muss die Netzwerkbrücke konfiguriert und aktiviert werden. Dabei ist zu beachten, dass das nicht mit einem WLAN-Interface funktioniert.

Angenommen, man befindet sich in einem Intranet mit privaten Adressen und hat die IP-Adresse 192.168.1.190. Der NAT-Router hat die Adresse 192.168.1.3 und der Name der Ethernetkarte ist eth0. Dann konfiguriert man die Bridge mit folgenden Befehlen:

brctl addbr br0
brctl setfd br0 0
ifconfig br0 192.168.1.190 netmask 255.255.255.0
brctl addif br0 eth0
ifconfig br0 up
route add -net default gw 192.168.1.3 dev br0

Die IP-Adresse der Brücke kann, muss aber nicht mit der IP-Adresse der Ethernetkarte identisch sein. Testen lässt sich die Brücke, indem man überprüft, ob etwa ping www.google.de funktioniert. Generell ist diese Brückenkonfiguration als Beispiel zu verstehen, die möglicherweise zum schnellen Erfolg führt. In jedem Netz können aber andere Voraussetzungen vorliegen, die andere Konfigurationen verlangen. Ohne fundierte Kenntnisse über Routing und Brücken unter Linux kommt man jedoch nicht weit.

Nun ist der Container bereit zum Start. Das lässt sich mit folgendem Befehl erreichen:

lxc-start -n suse

Wenn alles richtig läuft, sieht man folgendes Bild.


Der Container für openSUSE 11.1 startet, wie man es von einer nativen Installation gewohnt ist. Einloggen muss man sich mit SSH.

Da in der Beispielkonfiguration 192.168.1.29 als IP-Adresse eingetragen ist, könnte man sich per SSH theoretisch einloggen, etwa mit dem Befehl ssh root@192.168.1.29 oder von Windows aus mit PuTTY. Allerdings gibt es kein Root-Password und keine Keydatei in /root/.ssh.

Die einfachste Methode ist, in den Container eine Public-Keydatei authorized_keys zu schreiben. Das Verzeichnis /root/.ssh des Containers befindet sich auf dem Host in /var/lib/lxc/suse/rootfs/root/.ssh. Daher kann man folgende Befehle nutzen:

mkdir /var/lib/lxc/suse/rootfs/root/.ssh
cp /home/christoh/.ssh/authorized_keys /var/lib/lxc/suse/rootfs/root/.ssh

Danach ist ein Einloggen mit der entsprechenden Private-Key-Datei möglich. Eine Alternative wäre es, auf dem Host zu /var/lib/lxc/suse/rootfs zu "chrooten" und mit passwd ein Kennwort für root zu setzen. Anschließend muss die Datei /var/lib/lxc/suse/rootfs/etc/ssh/sshd_config so angepasst werden, dass sie Passwörter akzeptiert.


Das man nicht auf ursprünglichen Host unter Ubuntu 10.10 gelandet ist, sondern im Container unter openSUSE 11.1, erkennt man am typische „Have a lot of fun…“ und daran, dass nur die Prozesse des Containers sichtbar sind.

Page: 1 2 3 4

ZDNet.de Redaktion

Recent Posts

Bedrohungen in Europa: Schwachstellen in der Lieferkette dominieren

Hinter 84 Prozent der Zwischenfälle bei Herstellern stecken Schwachstellen in der Lieferkette. Auf dem Vormarsch…

6 Tagen ago

Bericht: Apple arbeitet an faltbarem iPad

Es kommt angeblich 2028 auf den Markt. Das aufgeklappte Gerät soll die Displayfläche von zwei…

6 Tagen ago

HPE baut Supercomputer am Leibniz-Rechenzentrum

Das System basiert auf Hardware von HPE-Cray und Nvidia. Die Inbetriebnahme erfolgt 2027.

7 Tagen ago

Bund meldet Fortschritte in der Netzversorgung

Die Bundesnetzagentur hat ihr Gigabit-Grundbuch aktualisiert. Drei von vier Haushalten sollen jetzt Zugang zu Breitbandanschlüssen…

7 Tagen ago

Vorinstallierte Schadsoftware auf IoT-Geräten

Mit dem Internet verbundene Digitale Bilderrahmen oder Mediaplayer können mit Schadsoftware infiziert werden und sind…

1 Woche ago

iOS und iPadOS 18.2 beseitigen 21 Sicherheitslücken

Schädliche Apps können unter Umständen einen Systemabsturz auslösen. Mindestens eine Anfälligkeit erlaubt eine Remotecodeausführung.

1 Woche ago