Zur Übersicht
Hat dir diese Seite weitergeholfen?
Durchschnittliche Bewertung (Rootserver):
2.93/3 (450 Stimmen)

Alturo-Server mit Debian GNU/Linux anpassen

...wer will schon was fertiges?

Für einige Zeit lief diese Seite auf einem Rootserver von Alturo. Die vorkonfigurierten Systeme mögen zwar funktionieren, aber wer doch spezielle Wünsche hat, kann einiges erreichen, sofern er weiß wie. Diese Seite stellt einige Aspekte vor, und soll auch mir als Gedächtnisstütze dienen :-)

Inzwischen ist Alturo inzwischen Geschichte ist, liegen meine Seiten nun bei Hetzner: Die Einrichtung des neuen Servers und den Umzug des Systems habe ich ebenfalls dokumentiert. Da sich die UI-Server nicht groß voneinander unterscheiden, und die ANleitun für debootstrap auch für andere nützlich sein kann, lasse ich diese Seite einfach online, auch wenn es wohl keine Alturo-Kunden mehr geben wird, die ihre Server auf ein eigenes Debian umstellen werden.

Die Wahl des Systems

Alturo bietet verschiedene Betriebssysteme für seine Rootserver an: Standardmäßig bootet der Rechner mit einer SuSE-Installation, die man natürlich schnell gegen ein Debian eintauschen möchte. Zur Auswahl stehen im Konfigurationsbereich unter anderem:

Das vorbereitete Sarge-Basissystem mag eine gute Grundlage sein, allerdings hatte ich einige zusätzliche Wünsche, aufgrund derer ich das System dann doch komplett neu aufgebaut habe. Anstelle statischer Partitionen soll der Server seine Daten auf einem LVM-Speicher ablegen, um so später Dateisysteme problemlos und ohne Neupartitionierung vergrößern oder verkleinern zu können. LVM bietet zudem viele Vorteile beim erstellen eines Backups: Mit einem Kommando kann das Dateisystem "eingefroren" werden, und so eine Kopie des statischen Zustands erstellt werden. Da LVM eine eigene Partition erfordert, ist es sehr schwierig, ein bereits installiertes System darauf umzustellen.

Debian vom Reißbrett

Mit diesem Ziel vor Augen sollte das System also komplett von Grund auf neu aufgebaut werden, ohne auf die vorbereiteten Server-Abbilder zurückzugreifen. Debian verfügt hierzu über das Programm "debootstrap", dass aus einem laufenden System heraus eine (fast) lauffähige Debian-Installation zu kreieren.

Dieses laufende Debian-System erhält man über das Rettungssystem, das Altuo in mehreren Varianten bereitstellt: Der Menüpunkt "Recovery-Tool" bietet die Möglichkeit, den Server neuzustarten und das zu ladende betriebssystem zu wählen. Neben dem eigentlichen Betriebssystem auf der Festplatte offeriert Alturo zwei Rettungssysteme, die sich via Netzwerk in einer Ramdisk installieren. Auch wenn die Alturo-Seite von "woody" spricht: Bei den beiden Varianten mit 2.6er und 2.4er Kernel handelt es sich um ein abgespecktes Debian Sarge.

Partitionen und LVM

Nachdem der Neustart im Web-Dialog beantragt wurde, erstellt dieser ein neues Passwort, und rebootet den Server nach einigen Minuten. Der Server ist danach unter der gleichen IP-Adresse per SSH erreichbar, zur Anmeldung dienen "root" und das generierte Passwort. Nach dem Login geht es nun daran, die Festplatte aufzuteilen; Um den Startvorgang zu vereinfachen - Dem Nervenkitzel, ein entferntes System manuell zu installieren, wollte ich nicht noch durch "Booten von LVM" intensivieren -, habe ich folgende herkömmliche Partitionen angelegt:

Die Partitionen lassen sich recht einfach mit "cfdisk" erstellen, allerdings tut es auch das gute alte "fdisk". Freundlicherweise unterstützen die Kernel der Rettungssysteme auch LVM, und bringen auch direkt die notwendigen Programme zur Einrichtung derartiger Volumes mit. Der erste Schritt besteht nun darin, die für LVM vorgesehene Partition (hier "hda4") als "physical volume" einzurichten:

rescue:~# pvcreate /dev/hda4
pvcreate -- physical volume "/dev/hda4" successfully created

Der Befehl schreibt die LVM-Signaturen in die Partition, und bereitet die Partition auf die Mitgliedschaft in einer Volume-Group vor; diese Gruppen können mehrere physische Datenträger zu einem logischen Speicherblock zusammenfassen. Da wir hier nur eine Festplatte (und auch nur eine Partition), fristet die Partition innhalb der "Gruppe" ein recht einsames Dasein:

rescue:~# vgcreate mainvol /dev/hda4
vgcreate -- INFO: using default physical extent size 4 MB
vgcreate -- INFO: maximum logical volume size is 255.99 Gigabyte
vgcreate -- doing automatic backup of volume group "mainvol"
vgcreate -- volume group "mainvol" successfully created and activated

Nun hat "vgcreate" eine Gruppe mit der Bezeichnung "mainvol" erstellt. Der Name ist beliebig, und sollte die Gruppe treffend bezeichnen; allerdings ist die Gefahr, auf einem System mit einer einzigen Platte die Übersicht über seine Laufwerke zu verlieren, relativ gering.

Innerhalb der Volume-Group können wir nun die eigentlichen "Partitionen" erstellen, auf denen wir dann die Dateisysteme anlegen. Die "Logical Volumes" werden mit dem Befehl "vgcreate angelegt:

rescue:~# lvcreate -n var -L 10G mainvol
lvcreate -- doing automatic backup of "mainvol"
lvcreate -- logical volume "/dev/mainvol/var" successfully created

Auch der hinter "-n" angegebene Name ist frei wählbar, er hat nicht mit dem später zugeordneten Mountpoint zu tun - allerdings tut man gut daran, eine treffende Bezeichnung zu wählen. Um flexibel zu bleiben, bietet es sich an, Verzeichnisse mit wachsenden und veränderlichen Daten auf Logical-Volumes abzulegen. Zudem ist es ratsam, etwas Platz in der Gruppe unbelegt zu lassen - Das macht es einfach, Dateisysteme mit wachsendem Platzbedarf zu vergrößern oder Backups mit dem Snapshot-Modus zu erstellen (hierzu später mehr). Eigene Volumes bietet sich unter anderem an für:

Sind alle Partitionen, Gruppen und Volumes erstellt, so kann man damit beginnen, die Dateisysteme anzulegen. Ich habe mich (konservativ) für das ext3-FS entschieden, analog kann man natürlich auch seine Daten XFS oder ReiserFS anvertrauen - tatsächlich verfügt das vorbereitete Alturo-Image über XFS-Partitionen.

Nachdem alle Partitionen der Behandlung von "mkfs.ext3" und "mkswap" unterworfen wurden, kann man das System "zusammensetzen": Dazu legt man sich innerhalb des Rettungssystems ein Verzeichnis "/deb" an, in dem das neue System geboren werden soll. Nun geht es daran, die erstellten Dateisysteme in ihre spätere Struktur zu montieren: Das Root-Dateisystem wird auf "/deb/" gemountet, und darin Mountpoints angelegt, die danach direkt mit den dazugehörigen Partitionen verknüpft werden.

rescue:~# mkdir /deb
rescue:~# mount /dev/hda2 /deb
rescue:~# mkdir /deb/boot /deb/usr /deb/home /deb/proc /deb/sys /deb/var
rescue:~# mount /dev/hda1 /deb/boot
rescue:~# mount /dev/mainvol/var /deb/var
[...]

Da sich unter "/deb" nun bereits die spätere Datenträgerstruktur gebildet hat, kann nun die eigentliche Installation beginnen.

Starthilfe

Das Programm "debootstrap" dient dazu, die notwendigsten Pakete in ein beliebiges Verzeichnis zu installieren, um so ein minimales Debian-System zu erstellen. Leider ist das Programm nicht in der Rettungsinstallation enthalten, so dass es nachinstalliert werden muss. Dem entgegen steht leider der knappe Platz in der RAMDisk, so dass wir tricksen müssen: Eine herkömmliche Installation in das laufende (temporäre) System kommt nicht in Frage, so dass wir das Paket manuell zerpflücken müssen. Um ein geräumiges Arbeitsfeld zu schaffen, legen wir zunächst das Verzeichnis "/deb/tmp" an; Anschließend laden wir das debootstrap-Paket mit "wget" in dieses Verzeichnis herunter.

Um nicht die Übersicht zu verlieren, legen wir noch ein Verzeichnis "/deb/tmp/bootstrap" an, in das wir nun das Debian-Paket manuell entpacken. Debian-Pakete bestehen aus zwei Teilen: Einmal den Paketinformationen und Installationsskripten, sowie den eigentlichen Paketdateien. Beide Teile werden in Form eines "ar"-Archivs zusammengefasst, so dass die beiden Bestandteile auch ohne Paketverwaltung extrahiert werden können:

rescue:/deb/tmp# ar x debootstrap_0.2.45-0.2_i386.deb
rescue:/deb/tmp# mkdir bootstrap
rescue:/deb/tmp# cd bootstrap
rescue:/deb/tmp/bootstrap# tar xfvz ../data.tar.gz
[...]

Die Datei "data.tar.gz" enthält die Dateien des Pakets, das wir nun unterhalb von "/deb/tmp/bootstrap" extrahiert haben. Leider erwartet das Programm "/deb/tmp/bootstrap/usr/sbin/debootstrap" seine Beschreibungsdateien im Verzeichnis "/usr/lib/debootstrap/", so dass wir einen symbolischen Link erstellen müssen:

ln -s /deb/tmp/bootstrap/usr/lib/debootstrap/ /usr/lib/

"debootstrap" konstruiert das neue System anhand der in diesem Verzeichnis abgelegten Beschreibungsdateien und Skripte; um den Prozess zu starten, genügt der folgende Befehl:

/deb/tmp/bootstrap/usr/sbin/debootstrap --arch i386 sarge /deb/ http://ftp.de.debian.org/debian

Danach beginnt das Programm, im Verzeichnis "/deb/" eine Sarge-Basisinstallation für die x86-Architektur zu erzeugen. Die dazu nötigen Pakete bezieht es vom angegebenen Debian-Server.

Seitenwechsel

Ist der letzte Schritt abgeschlossen, kann man getrost mit "chroot /deb/" in das neue System umziehen. Der Befehl macht das Verzeichnis zum neuen Dateibaumwurzel, so dass man nun wie gewohnt an der Systeminstallation feilen kann, ohne sich um verbogene Pfade Gedanken zu machen. Wir wollen nun erstmal die wichtigsten Konfigurationsfragen lösen: Dies erledigt der Befehl "base-config new". Allerdings ist hier Vorsicht geboten: Unter Umständen erstellt der Assistent eine fehlerhafte "/etc/apt/sources.list", die anstelle der gewünschten Sarge-Quellen "testing" einträgt, was den Server auf direktem Wege auf "Etch" aktualisiert; Hier sollte man aufpassen und gegebenenfalls manuell eingreifen:

# Debian Sarge (stable) package sources:
deb http://ftp.de.debian.org/debian/ sarge main non-free contrib
deb http://security.debian.org/ sarge/updates main contrib non-free

Die zwei größten Herausforderungen folgen auf dem Fuße: Es muss sichergestellt sein, dass das System problemlos startet, und es muss ebenso sicher seine Netzanbindung finden. Durch das Rettungssystem besteht glücklicherweise keine Gefahr, sich komplett aus dem System auszusperren.

Der Kernel und GRUB

Die Installation von Kernel und Bootloader ist mit einigen Fallstricken verbunden: So schlägt die Installation des Kernel-Pakets "kernel-image-2.6.8-2-686" fehl, da das Installationsscript Probleme hat, das Root-Device zu ermitteln. Auch ein nochmaliges Mounten des "/proc"-Dateisystems innerhalb der neuen Systemumgebung ("mount -t proc none /proc/") brachte hier keine Lösung. Es reichte jedoch, die Root-Partition in der Datei "/etc/mkinitrd/mkinitrd.conf" manuell festzulegen:

# If this is set to probe mkinitrd will try to figure out what's needed to
# mount the root file system.  This is equivalent to the old PROBE=on setting.
#ROOT=probe
ROOT=/dev/hda3

Danach ließ sich der Kernel problemlos installieren.

Netzwerkonfiguration

Alturo verteilt die Netzdaten per DHCP - Das sollte es eigentlich einfach machen. Allerdings funktioniert eine einfache DHCP-Konfiguration nicht: Alturo verteilt mit den DHCP-Daten auch eine statische Route, die dem Server erst den Kontakt zur Außenwelt erlaubt. Um diese Information auch im System zu verwenden, hat Alturo in den vorgefertigten Images das folgende Skript unter "/etc/dhcp3/dhclient-exit-hooks.d/local" abgelegt; Es sorgt dafür, dass die vom DHCP-Server mitgeteilte Route auch in die Routing-Tabelle eingetragen wird:

#! /bin/sh 

if [ "x$reason" != xEXPIRE ] && [ "x$reason" != xFAIL ] && \
   [ "x$reason" != xRELEASE ] && [ "x$reason" != xSTOP ] && \
   [ -n "$new_static_routes" ] && [ -n "$new_routers" ] ; then

  for dest in $new_static_routes; do
    route add -host $dest dev $interface
  done
  for router in $new_routers; do
    route del default gw $router 2>/dev/null || /bin/true
    route add default gw $router
  done
fi

FTP-Backup mit LVM

Siehe folgende Seite.