debian mit debootstrap in chroot-Umgebung installieren

Einleitung

Im Folgenden wird eine Möglichkeit beschrieben, mit dem Installer des Grundsystems debootstap eine debian-Installation im laufenden System, das nicht zwangsweise auch ein debian sein muss, durchzuführen. Danach kann man mittels chroot in diese neue Umgebung wechseln und Pakete nachinstallieren.

Warum könnte man so etwas wollen?

  • Man kann so z. B. den "unstable"-Zweig von debian in einem "stable"-System testen, ohne ein Mischsystem zu haben, da beide Systeme ein eigenes root-Verzeichnis haben.
  • Man möchte auf einem Produktivserver mit einer veralteten Distribution, für die keine Updates mehr verfügbar sind, aktuelle Softwarepakete nutzen, ohne das System neu aufsetzen zu müssen (Downtime!).

Der erste Punkt ist ganz nett, da man endlich aktuelle debian-Pakete installieren kann, ohne seine stabile Installation zu versauen. ;-)

Hier soll es sich aber primär um den zweiten Punkt drehen, also das Verwenden neuerer Pakete in einer chroot-Umgebung, gestartet durch ein selbst geschriebenes init-Skript.

Der Weg zu Punkt zwei führt aber über Punkt eins und alle, die sich nur dafür interessieren, können getrost weiterlesen.

« zurück (Gesammelte Anleitungen)

Inhalt

« nach oben

« zurück (Gesammelte Anleitungen)

Installation des Basissystems mit debootstrap

debootstrap herunterladen und installieren

Als ersten Schritt benötigt man das Paket debootstrap, das man im Falle eines laufenden debian-Systems einfach installiert: 

# apt-get install debootstrap

Innerhalb eines "fremden" Systems, hier soll ein altes, RPM-basierte SuSE als Beispiel dienen, muss man die Installation von Hand durchführen.

Zuerst lädt man sich debootstrap als DEB-Paket via debian (Packages) herunter. Die für das Auspacken des Archiv benötigten Programme (ar, tar und gzip) sollten auf den meisten UNIX-Systemen bereits installiert sein. Zusätzlich wird noch wget benötigt, das debootstrap benutzt, um die Pakete aus dem Internet nachzuladen.

Hinweis: Auch wenn die Dateiendung DEB ein eigenes Format vermuten lässt, so ist ein DEB-Paket doch nur ein ar-Archiv, dass zwei weitere tar-Archive (data.tar.gz und control.tar.gz) und eine Textdatei debian-binary mit der DEB-Version enthält.

Zuerst erstellen wir ein neues Verzeichnis und entpacken darin das heruntergeladene debootstrap-Paket: 

$ mkdir work
$ cd work
$ ar -xf ../debootstrap_0.X.X_all.deb
$ ls
control.tar.gz  data.tar.gz  debian-binary
$

Die Programmdateien befinden sich im Archiv data.tar.gz, dass wir nun als Benutzer root in das Wurzelverzeichnis entpacken: 

# cd /
# zcat /full/path/to/work/data.tar.gz | tar xv

Hinweis: Die letzte Kommandozeile entpackt Dateien in das laufende System, die nicht vom Paketmanager (z. B. RPM) erfasst sind. Die Liste dieser Dateien kann man sich mit dem Kommando
$ tar tzf data.tar.gz
(Achtung: benötigt GNU-tar) auflisten lassen, falls man diese nach der Installation wieder (von Hand) entfernen will.

Jetzt sollte das Programm unter /usr/sbin/debootstrap verfügbar sein.

« nach oben

Basissystem installieren

Nun kommen wir zur eigentlichen Installation, die uns freundlicherweise debootstrap abnimmt. Wir müssen lediglich ein Basisverzeichnis für das neue debian-System anlegen: 

# mkdir /srv/debian-chroot

Hinweis: Da in diesem Verzeichnis eine vollständige debian-Installation inkl. welt-schreibbaren tmp-Verzeichnissen befindet, sollte es nicht auf der gleichen Partition wie das root-Verzeichniss des Hostsystems liegen. Für das Basissystem werden ca. 170 MB freier Speicherplatz benötigt.

Jetzt starten wir die Installation des Basissystems von einem debian Spiegelserver in Deutschland aus: 

# /usr/sbin/debootstrap --arch i386 etch /srv/debian-chroot http://ftp.de.debian.org/debian

Die hier angegebene Architektur muss man je nach verwendeten Prozessor anpassen, ebenso den zu installierenden debian-Zweig. Für unstable wählt man hier "sid". Wenn alles funktioniert, sieht die Installation dann folgendermaßen aus (Ausgaben gekürzt): 

I: Retrieving Packages
I: Validating Packages
I: Resolving dependencies of required packages...
I: Resolving dependencies of base packages...
I: Checking component main on http://ftp.de.debian.org/debian...
I: Retrieving adduser
I: Validating adduser
I: Retrieving apt
I: Validating apt
I: Retrieving apt-utils
I: Validating apt-utils
[...]
I: Installing core packages...
I: Unpacking required packages...
I: Unpacking base-files...
I: Unpacking base-passwd...
I: Unpacking bash...
[...]
I: Configuring required packages...
I: Configuring sysv-rc...
I: Configuring tzdata...
[...]
I: Configuring sysklogd...
I: Configuring tasksel...
I: Base system installed successfully.

Ist alles gutgegangen? Dann ist jetzt ein debian-Basissystem unter /srv/debian-chroot installiert worden, in das man via chroot-Kommando wechseln kann. Vorher muss man aber noch das proc-Verzeichnis dort einhängen: 

# mount -o bind /proc /srv/debian-chroot/proc
# LANG=C chroot /srv/debian-chroot /bin/bash

Jetzt befindet man sich im chroot-Käfig und kann mit apt-get oder aptitude benötigte Pakete nachinstallieren bzw. das System weiter konfigurieren (fstab anpassen, Zeitzone setzen, etc.).

Hier befinden wir uns am Ende von dem obigen Punkt eins, wer also nur das unstable-System zum Experimentieren wollte, kann jetzt und hier aufhören weiterzulesen. ;-)

« nach oben

Dienste innerhalb debian-chroot starten

Als nächstes möchten wir nun beispielhaft eine aktuellere Version von spamassassin installieren, da für unsere alte SuSE leider keine Updates mehr zur Verfügung stehen und wir das Ganze nicht mit CPAN in ein Mischsystem (CPAN/RPM) verwandeln wollen. Wir installieren alle dafür benötigten Debianpakete via aptitude in der chroot-Umgebung.

Anschließend benötigen wir noch ein init-Skript, dass spamassassin inkl. benötigter weiterer Dienste (hier: syslogd) beim Systemstart mit starten und beim Herunterfahren oder einem Reboot beenden kann.

Hier gibt es beispielhaft so ein Skript: 

#!/bin/bash
#
# Copyright (c) 2008 Kai Hildebrandt
#
# Authors: Kai Hildebrandt <kai.hildebrandt@web.de>
#
# /etc/init.d/debian-chroot
#
### BEGIN INIT INFO
# Provides:                     debian-chroot
# Required-Start:               $local_fs $remote_fs $network
# Required-Stop:                $local_fs $remote_fs $network
# Default-Start:                3 5
# Default-Stop:                 0 1 2 6
# Short-Description:            chrooted debian etch
# Description:                  Start a chrooted debian etch (spamassassin)
### END INIT INFO

ROOT="/srv/debian-chroot"

case "$1" in
    start)
        echo "starting chrooted debian system (spamassassin) in $ROOT";

        mount -o bind /proc $ROOT/proc

        chroot $ROOT /bin/bash << EOF
        /etc/init.d/sysklogd start
        /etc/init.d/spamassassin start
EOF
        ;;

    stop)
        echo "stopping chrooted debian system (spamassassin) in $ROOT";
        chroot $ROOT /bin/bash << EOF
        /etc/init.d/spamassassin stop
        /etc/init.d/sysklogd stop
EOF
        umount $ROOT/proc
        ;;

    restart)
        $0 stop
        $0 start
esac

Download debian-chroot init-Skript

Das Skript kopiert man in das Verzeichnis /etc/init.d und erstellt symbolische Links unterhalb dem Verzeichnis /etc/rcN.d, wobei N für den default-Runlevel (2, 3, 4 oder 5) steht.

Hinweis: Die oben genannten Verzeichnisse für die init-Skripte können variieren. SuSE verwendet z. B. eine Hierarchie unterhalb von /etc/rc.d.

Den default-Runlevel bekommt man mit dem folgenden Befehl heraus: 

$ grep initdefault /etc/inittab
id:2:initdefault:

Will man andere oder weitere Dienste laufen lassen muss man darauf achten, dass evtl. davon abhängige Dienste mitgestartet werden.

Im Falle von Netzwerkdiensten dürfen diese außerdem nicht mit Diensten im Basissystem in Konflikt stehen, so kann man keinen konkurrierenden IMAP-Server installieren, da die Sockets bereits vom Hostsystem verwendet werden, es sei denn, man konfiguriert ihn so, dass er auf einem anderen TCP-Port als 143 (default) lauscht.

« nach oben

Limitierungen

Diese Technik hat mehrere Beschränkungen, von denen einige bereits genannt worden sind.

Hier das Ganze nochmal als Liste:

  • Kernel: Sowohl das Hostsystem, als auch das chrooted-System benutzen denselben Kernel. Alle Geräte, die in das chroot-System reingereicht werden, könnten die Stabilität des Hostsystems gefährden. Auch kann man keine Netzwerkdienste betreiben, die auf bereits verwendete Ports binden, hierfür muss man die Dienste entsprechend konfigurieren, dass sie auf anderen Ports lauschen.
  • Sicherheit: Die hier verwendete Art von chroot ist mitnichten als sicherer Käfig für gefährdete Dienste zu betrachten, da sich darin ein vollständiges System befindet. Normalerweise beschränken sich diese Käfige auf das Programm mit seinen Bibliotheken, seine Konfiguration und die Datendateien, damit im Falle eines Angriffs auf diesen Dienst nicht gleich die Kontrolle über das System erlangt werden kann.
  • Speicherbedarf: Im Gegensatz zu einem debian-Mischsystem via Pinning werden hier Pakete in unterschiedlichen Versionen installiert, d. h. es wird entprechend auch etwa der doppelte Speicherplatz für diese Pakete verbraucht. Außerdem muss man darauf achten, dass das chroot-System nicht die root-Partiton des Hostsystems vollschreiben kann.

Trotz den genannten Limitierungen ist es doch eine recht schnelle und (betriebs-)sichere Art, aktuelle Dienste in eine veraltete Distribution zu integrieren. Durch die Kapselung des chroot-Systems gibt es keine Versionkonflikte mit den Bibliotheken des Hostsystems und es gibt keine Downtime, da die Installation ohne größere Beeinträchtigung durchgeführt werden kann.

« nach oben

Weiterführende Links