Debian Sarge auf Hetzner DS3000 mit RAID1 auf VIA Chipsatz installieren

Dienstag, 25. Dezember 2007

Diese Anleitung behandelt den Hetzner Root-Server DS 3000 mit VIA Chipset. Klar, einer der größeren Server wäre mir zum Testen lieber gewesen, die Anleitung wird bei abweichender Hardware natürlich nicht mehr funktionieren.

# lspci
0000:00:0f.0 RAID bus controller: VIA Technologies, Inc. VIA VT6420 SATA RAID Controller (rev 80)

Das verwendete Mainboard MSI Neo2-F mit VIA Chipsatz hat zwar die Möglichkeit, ein Array zu erstellen:

...

Hetzner Lara BIOS Config RAID Array VIA

Das Array wird hinterher auch angezeigt:

...nutzbar ist es aber nicht, da unter Debian weiterhin beiden Platten erscheinen, und kein Array zu sehen ist, auch zwischen den Platten nicht synchronisiert wird. Der Sinn dieser Funktion erschliesst sich mir nicht.

Ob Debian diesen Controller standardmäßig unterstützen würde, habe ich gar nicht probiert, sicherheitshalber sagen wir Debian bei der Installation, dass es die benötigten Module in die initrd packen soll, damit gehen wir auf Nummer sicher. Debian wird diese Einstellung auch bei Kernel Updates (z.B. bei Sicherheitslücken) berücksichtigen, dadurch sollten wir immer einen Kernel erhalten, der auf dieser Hardware sauber bootet.

Wir installieren wieder ein reines 32 Bit System, da 64 Bit-Systeme bei dieser Hardware (1 Gbyte RAM) unsinng sind und der 64-Bit Overhead den Rechner nur ausbremst.

Das vorinstallierte Hetzner-Image war bei mir nicht mit RAID eingerichtet. Prinzipiell installiere ich meine Systeme sowieso lieber selbst, dann weiss ich wenigstens genau, was am Ende auf dem Server installiert ist.

Praktisch bieten preiswerte RAID-Controller (wie sie auf Mainboards oft verbaut werden) aber sowieso nur einen geringen Nutzen, da sie keine eigene CPU haben und hauptsächlich das Initalisieren der Arrays verwalten. Der Rechenaufwand wird bei diesen Controllern durch die CPU geleistet, insofern sollte ein reines Software-RAID vergleichbar performant sein.

Hetzner bietet durch seine seriellen Konsolen Zugriff auf das BIOS des Rechners.

Meinem Wunsch nach RAID-Arrays liegt aber nicht die Performance, sondern die Datensicherheit, zu Grunde. Mein Ziel ist es, alle Datenpartitionen als gespiegeltes RAID-1 zu betreiben. Die Masterbootrecords der beiden Festplatten bleiben eigenständig, d.h. den Bootloader installiere ich nur auf der ersten Festplatte, eine Installation kann aber optional auch auf der 2ten Festplatte vorgenommen werden, damit auch die 2te Festplatte allein bootfähig ist.

Ob dies dann im Havariefall auch wirklich funktioniert, ist meiner Ansicht nach nicht so relevant, denn eine hoch verfügbare Webanwendung wird man sicher nicht auf einem solchen System laufen lassen. Außerdem gibt es dann verschiedene Dinge zu bedenken:

1. Der Bootloader muss an die 2te Festplatte angepasst werden
2. Im / nach einem Havariefall muss die Festplatte auch weiterhin an der bekannten Hardwareadresse ansprechbar sein

Letztendlich ist dies bei einem Root-Server ohne physikalische Zugriffsmöglichkeit nicht vorher testbar, exakt gleiche Hardware hat man regulär auch nicht daheim herumstehen. Erst im Havariefall wird man schlauer sein.

• Nun wird sich manch einer fragen: Warum dann das RAID 1?

Die Plattengrößen von 2mal 160 Gbyte bietet einem klassischen Webserver mehr als genügend Platz. Durch das RAID1 bleiben wenigstens 160 Gbyte nutzbar und die Daten werden auf beiden Platten redundant abgelegt. Beim Ausfall der ersten Festplatte würde das System zwar nicht mehr rebooten, dies muss es regulär aber gar nicht, da die SATA-Platten und Chipsatz hoffentlich HotPlug fähig sind, ich also davon ausgehe, dass im Havariefall der Server weiter läuft und die Platte im laufenden Betrieb getauscht werden kann. Selbst wenn diese Voraussetzung nicht gegeben sein sollte, kann man sicher mit dem Techniker eine Übereinkunft bezüglich der Uhrzeit des Plattenwechsels treffen. Für das Recovery der Arrays muss man in jedem Fall eine Downtime einplanen -> es könnte ja etwas schief gehen.

Recovery-Überlegungen:

• Ausfall sdb:

1. sdb tauschen lassen
2. sdb einrichten
3. Array Recovery

• Ausfall sda:

1. sda tauschen lassen
2. sda einrichten
3. Array Recovery
4. Bootmanager in den MBR schreiben

• Ausfall sda und notweniger Reboot

1. Rescue System booten
2. sdb nach / mounten
3. Bootmanager in den MBR installieren

Dieser Schritt kann durch eine Vorinstallation des Bootmanagers in den MBR der sdb vorbereitet werden.

In jedem Fall sollte die Downtime drastisch geringer ausfallen, als bei einer Neuinstallation mit anschliessendem Restore der Daten aus dem Backup.

Beim Bootvorgang muss nun der Bootloader den Kernel usw. anfangs direkt von einer Partition (nicht vom Array) laden, was aber read-only erfolgt und somit kein Problem ist.

Folgendes Partitionierungsschema habe ich mir überlegt:

Die Aufteilung kann natürlich jedermann selbst an seine Bedürfnisse anpassen. Die /backuppartition könnte man natürlich auch als RAID0 gestalten, man sollte jedoch bedenken, dass im Havariefall eine beachtliche Zeit vergehen kann, bis man große Datenmengen vom Backup-FTP (falls man einen hat) zurückgeholt hat, denn bei einem RAID0 ist ja beim Ausfall einer Platte das gesamte Array verloren. Die Backuppartition ist wegen der geplanten Nutzung von differentiellen Backups größer als der Rest. Nicht alle Webs sind in der Sicherung inbegriffen, es gibt Daten in den web Verzeichnissen, die auf Datenträgern vorliegen und notfalls auch von dort wieder eingespielt werden können. Für meine Zwecke werden ca 60 Gbyte auf der /var Partition, auf der ich die webs anlege, mehr als ausreichend sein.

Dass die Backuppartition nicht /backup heisst liegt in der Handhabung meiner Backup-Excludelisten begründet.

Auf den nächsten Seiten schilde ich nun detailiert die Installation des Servers mit Debian GNU/Linux Sarge aus dem Rescue-System heraus.

• Die nun folgenden Schritte führen wir auf dem Rescue System aus. Dazu muss im Verwaltungs-Webinterface die Bootreihenfolge entsprechend eingestellt werden. Nach einer kurzen Wartezeit führt ein Reboot dann ins Rettungssystem, welches unter dem gewohnten Hostnamen per ssh erreichbar ist.

• Zuerst versetzen wir die Platten logisch in den Neuzustand. Dazu schreiben wir Nullen in den Startbereich der Festplatte. Anschliessend sind die Festplatten logisch im Auslieferungszustand, da keine lesbare Partitionstabelle mehr existiert:

1. root:~# dd if=/dev/zero of=/dev/sda count=1
   1. 1+0 records in 1+0 records out
      ...
2. root:~# dd if=/dev/zero of=/dev/sdb count=1
   1. 1+0 records in 1+0 records out

• Die Partitionstabellen sollten nun leer sein, dies prüfen wir, indem wir uns die Partitionstabelle anzeigen lassen:

1. root:~# fdisk -l /dev/sda /dev/sdb
   1. ...
      Disk /dev/sda doesn't contain a valid partition table
      ...
      Disk /dev/sdb doesn't contain a valid partition table

• Wenn nun zuvor schon Arrays existierten (z.B. von vorheringen Tests), müssten wir diese nun stoppen, der Einfachheit halber führen wir stattdessen einfach einen Reboot durch.

1. root:~# reboot -n
   1. Broadcast message from root (pts/0) (Thu Nov 17 23:29:26 2005):
      The system is going down for reboot NOW!

• Nach der erneuten Anmeldung am Rescue System, beginnen wir nun mit der Partitionierung der Festplatte. Hierzu setzen wir die geplante Partitionstabelle in die Praxis um. Die Wahl des Partitionierers bleibt dem persönlichen Geschmack überlassen. Ich habe sda mit cfdisk partitioniert und anschliessend dieses Layout mit sfdisk nach sdb kopiert. Detailwissen zur Partitionierung setze ich bei den Lesern dieses Artikels voraus. Der Partitionstyp "fd" = "Linux RAID Autodetect" sorgt für eine automatische Aktivierung der Arrays durch den Kernel. Wir können uns also Konfigurationsdateien (/etc/raidtab) für die Arrays sparen.

• Hinterher soll die Partitionierung in etwa so aussehen (Bild stammt von einem Strato AMD Server, daher hda statt sda):

• Nun kopieren wir die eben erzeugte Partitionstabelle von sda nach sdb:

1. root:~# sfdisk -d /dev/sda > /tmp/sda.table
2. root:~# sfdisk /dev/sdb < /tmp/sda.table
   1. ...
      
      Checking that no-one is using this disk right now ...
      Successfully wrote the new partition table
      Re-reading the partition table ... ...

• sdb sollte nun auch in cfdisk ein Abbild von sda darstellen
• Ich persönlich ziehe eine Kontrolle mit fdisk vor (Die Ausgabe kann abhängig von den verwendeten Platten abweichen!):

1. root:~# fdisk -l /dev/sda /dev/sdb
   1. Disk /dev/sda: 164.6 GB, 164696555520 bytes
      255 heads, 63 sectors/track, 20023 cylinders
      Units = cylinders of 16065 * 512 = 8225280 bytes
      
      Device Boot Start End Blocks Id System
      /dev/sda1 * 1 124 995998+ fd Linux raid autodetect
      /dev/sda2 125 373 2000092+ 82 Linux swap / Solaris
      /dev/sda3 374 20023 157838625 5 Extended
      /dev/sda5 374 995 4996183+ fd Linux raid autodetect
      /dev/sda6 996 1617 4996183+ fd Linux raid autodetect
      /dev/sda7 1618 2737 8996368+ fd Linux raid autodetect
      /dev/sda8 2738 10207 60002743+ fd Linux raid autodetect
      /dev/sda9 10208 20023 78846988+ fd Linux raid autodetect
   2. Disk /dev/sdb: 164.6 GB, 164696555520 bytes
      255 heads, 63 sectors/track, 20023 cylinders
      Units = cylinders of 16065 * 512 = 8225280 bytes
      
      Device Boot Start End Blocks Id System
      /dev/sdb1 * 1 124 995998+ fd Linux raid autodetect
      /dev/sdb2 125 373 2000092+ 82 Linux swap / Solaris
      /dev/sdb3 374 20023 157838625 5 Extended
      /dev/sdb5 374 995 4996183+ fd Linux raid autodetect
      /dev/sdb6 996 1617 4996183+ fd Linux raid autodetect
      /dev/sdb7 1618 2737 8996368+ fd Linux raid autodetect
      /dev/sdb8 2738 10207 60002743+ fd Linux raid autodetect
      /dev/sdb9 10208 20023 78846988+ fd Linux raid autodetect

• Damit ist die Partitionierung der Festplatte abgeschlossen. Dateisysteme werden an dieser Stelle noch nicht erzeugt.

• Nun können wir mit der Einrichtung der RAID Arrays weitermachen. Zuerst werfen wir wieder einen Blick auf die geplante Partitionierung:

• Bevor es losgeht sollten wir aber den aktuellen RAID-Status prüfen, hier sollten keine Arrays mehr erscheinen. Dies haben wir durch Löschen der Partitionstabellen mit anschliessendem Reboot sichergestellt.

1. root:~# cat /proc/mdstat
   1. cat: /proc/mdstat: No such file or directory

• Wie erwartet sind keine Arrays vorhanden, beginnen wir also mit der Erzeugung der Arrays:

1. root:~# mdadm --create /dev/md0 --level=mirror --raid-devices=2 /dev/sda1 /dev/sdb1
   1. mdadm: /dev/sda1 appears to be part of a raid array:
      level=raid1 devices=2 ctime=Thu Nov 17 23:36:10 2005
      mdadm: /dev/sdb1 appears to contain an ext2fs file system
      size=995904K mtime=Fri Nov 18 19:12:18 2005
      mdadm: /dev/sdb1 appears to be part of a raid array:
      level=raid1 devices=2 ctime=Thu Nov 17 23:36:10 2005
      Continue creating array? yes
      mdadm: array /dev/md0 started.
      ...
2. root:~# mdadm --create /dev/md1 --level=mirror --raid-devices=2 /dev/sda5 /dev/sdb5
   
   1. ...
3. root:~# mdadm --create /dev/md2 --level=mirror --raid-devices=2 /dev/sda6 /dev/sdb6
   
   1. ...
4. root:~# mdadm --create /dev/md3 --level=mirror --raid-devices=2 /dev/sda7 /dev/sdb7
   
   1. ...
5. root:~# mdadm --create /dev/md4 --level=mirror --raid-devices=2 /dev/sda8 /dev/sdb8
   
   1. ...
6. root:~# mdadm --create /dev/md5 --level=mirror --raid-devices=2 /dev/sda9 /dev/sdb9
   
   1. ...
      mdadm: array /dev/md5 started.

• Wir haben nun alle Arrays erzeugt und prüfen den RAID Status:

1. root:~# cat /proc/mdstat
   1. Personalities : [raid0] [raid1] [raid10]
      md5 : active raid1 sdb9[1] sda9[0] 78846912 blocks [2/2] [UU]
      resync=DELAYED
      
      md4 : active raid1 sdb8[1] sda8[0] 60002624 blocks [2/2] [UU]
      resync=DELAYED
      
      md3 : active raid1 sdb7[1] sda7[0] 8996288 blocks [2/2] [UU]
      [==========>..........] resync = 50.1%
      (4509888/8996288)
      finish=1.2min speed=60780K/sec
      md2 : active raid1 sdb6[1] sda6[0] 4996096 blocks [2/2] [UU]
      
      md1 : active raid1 sdb5[1] sda5[0] 4996096 blocks [2/2] [UU]
      
      md0 : active raid1 sdb1[1] sda1[0] 995904 blocks [2/2] [UU]
      
      unused devices: <none>

• Wir könnten nun schon die Dateisysteme erzeugen, dies bremst aber die Synchronisierung der Arrays aus, da diese nur mit freien Systemresourcen durchgeführt wird.

• Die RAID Arrays sollten nun fertig sein, davon überzeugen wir uns:

1. root:~# cat /proc/mdstat
   1. Personalities : [raid0] [raid1] [raid10]
      md5 : active raid1 sdb9[1] sda9[0] 78846912 blocks [2/2] [UU]
      
      md4 : active raid1 sdb8[1] sda8[0] 60002624 blocks [2/2] [UU
      
      md3 : active raid1 sdb7[1] sda7[0] 8996288 blocks [2/2] [UU]
      
      md2 : active raid1 sdb6[1] sda6[0] 4996096 blocks [2/2] [UU]
      
      md1 : active raid1 sdb5[1] sda5[0] 4996096 blocks [2/2] [UU]
      
      md0 : active raid1 sdb1[1] sda1[0] 995904 blocks [2/2] [UU]
      
      unused devices: <none>

• Beginnen wir beim Erzeugen der Dateisysteme mit den beiden (nicht gespiegelten) SWAP-Partitionen:

1. root:~# mkswap /dev/sda2
   1. Setting up swapspace version 1, size = 2048090 kB
      no label, UUID=6018e38e-ab16-4ce7-ae11-154a0f804c6e
2. root:~# mkswap /dev/sdb2
   1. setting up swapspace version 1, size = 2048090 kB
      no label, UUID=b59510a1-f5b9-442e-a5c7-5188583ea841

• Nun erzeugen wir ext3 Journaling Dateisysteme auf den Arrays. Wer ein anderes Dateisystem verwenden will, muss dies bei der Erstellung der /etc/fstab Datei bedenken.

1. root:~# mke2fs -j /dev/md0
   1. mke2fs 1.37 (21-Mar-2005)
      Filesystem label=
      OS type: Linux
      Block size=4096 (log=2)
      Fragment size=4096 (log=2)
      124672 inodes, 248976 blocks
      12448 blocks (5.00%) reserved for the super user
      First data block=0
      8 block groups
      32768 blocks per group, 32768 fragments per group
      15584 inodes per group
      Superblock backups stored on blocks:
      32768, 98304, 163840, 229376
      
      Writing inode tables: done
      Creating journal (4096 blocks): done
      Writing superblocks and filesystem accounting information: done
      
      This filesystem will be automatically checked every 36 mounts or
      180 days, whichever comes first. Use tune2fs -c or -i to override.

1. root:~# mke2fs -j /dev/md1
2. root:~# mke2fs -j /dev/md2
3. root:~# mke2fs -j /dev/md3
4. root:~# mke2fs -j /dev/md4
5. root:~# mke2fs -j /dev/md5

• Die Arrays und Dateisysteme haben wir nun erzeugt, nun sollten wir diese Konfiguration gleich in der /etc/fstab-Datei der künftigten Root / Partition hinterlegen. Zu diesem Zweck müssen wir die Partition mounten:

1. root:~# mount /dev/md1 /mnt/

• Wenn wir einmal beim mounten sind, binden wir die anderen Dateisystem auch gleich mit ein, denn die später zu installierenden Daten sollten gleich auf den entsprechenden Dateisystemen landen, damit sparen wir uns Arbeit, da wir die Dateien nicht später auf die Dateisysteme migrieren müssen.
  Vor dem Mounten der Dateisysteme müssen die MountPoints erzeugt werden, logischerweise unterhalb der künftigen Root / :

1. root:/# cd /mnt
2. root:/mnt# mkdir home usr var boot backuppartition
3. root:/mnt# ls
   1. backuppartition boot home lost+found usr var

• Die Mountpoints stehen bereit, also mounten wir die Dateisysteme:

1. root:/mnt# mount /dev/md0 boot
2. root:/mnt# mount /dev/md2 home
3. root:/mnt# mount /dev/md3 usr
4. root:/mnt# mount /dev/md4 var
5. root:/mnt# mount /dev/md5 backuppartition/

• Die Dateisystem-Konfiguration verewigen wir nun in der Datei /etc/fstab, welche unterhalb des zukünftigen / angelegt werden muss. Der Inhalt der Datei soll so aussehen:

1. root:/# mkdir /mnt/etc
2. root:/# vi /mnt/etc/fstab

   1. proc /proc proc defaults 0 0 /dev/md0 /boot ext3 defaults 0 2 /dev/md1 / ext3 defaults,errors=remount-ro 0 1 /dev/md2 /home ext3 defaults 0 2 /dev/md3 /usr ext3 defaults 0 2 /dev/md4 /var ext3 defaults 0 2 /dev/md5 /backuppartition ext3 defaults 0 2 /dev/sda2 none swap defaults,pri=1 0 0 /dev/sdb2 none swap defaults,pri=1 0 0

(Bild stammt von Strato Installation, Inhalt passt aber)

• Auf der nächsten Seite widmen wir uns der Installation des Debian Basissystems.

• Bei Hetzner ist das Package debootstrap im Rescue System schon installiert, wir können es direkt benutzen.
• Debootstrap kann mit verschiedenen Parametern aufgerufen werden, unter anderem kann man die Architektur angeben, zum Beispiel durch den Paramter "--arch amd64" und der Angabe der passenden URL für die AMD64-Pakete.
  
  Hetzner bietet wohl auch 64 Bit Rescue Systeme, der Boot eines solchen Systems ist dann Voraussetzung für eine --arch amd64 Installation.
• Starten wir nun Debootstrap unter Angabe der Distribution und des Mountpoints, der künftigten Root /. Da der Default Mirror während der Installation nicht erreichbar war, übergebe ich außerdem die URL eines anderen Mirrors:

1. root:/# debootstrap sarge /mnt ftp://ftp2.de.debian.org/debian/

• Nun werden diverse Pakete vom Debian Archiv heruntergeladen, validiert und anschliessend entpackt und eingerichtet:

1. 1. ...
      Setting up console-common (0.7.49) ...
      Looking for keymap to install: NONE
      
      setting up base-config (2.53.10) ...

• Am Ende sollte eine Meldung in dieser Art ausgegeben werden:

1. 1. I: Base system installed successfully.
      umount: /mnt/dev/pts: not mounted
      umount: /mnt/dev/shm: not mounted
      umount: /mnt/proc/bus/usb: not mounted

• Wir können nun in das neue System wechseln um mit der Konfiguration fortzufahren.

• Um mit dem neuen System arbeiten zu können, müssen wir unsere Root / nach /mnt verlegen, /mnt gilt dann als Root /. Dazu dient der Befehl chroot:

1. root:/# chroot /mnt
   1. root:/#

• Als erste Amtshandlung im neuen System führen wir base-config aus und richten Zeitzone, hostname und Passwörter ein. Die weiteren möglichen Konfigurationen überspringe ich an dieser Stelle.

1. root:/# base-config

• Nächster Schritt ist die Einrichtung von apt, hier könnten wir apt-config verwenden, jedoch richtet dieser bei Verwendung unserer Sarge Distributionen die sources nach "testing" ein. Ich möchte aber Pakete aus "stable" verwenden und daher erzeugen wir die sources.list selbst, hinterher soll sie so aussehen:

1. vi /etc/apt/sources.list
   

   1. #stable deb http://ftp.de.debian.org/debian sarge main non-free contrib deb-src http://ftp.de.debian.org/debian sarge main non-free contrib #security deb http://security.debian.org/ stable/updates main contrib non-free #nonus deb http://non-us.debian.org/debian-non-US stable/non-US main contrib non-free

• Nun lassen wir apt die Paketlisten herunterladen:

1. root:/# apt-get update
   
   1. Hit http://ftp.de.debian.org sarge/main Packages
      ...
      Reading Package Lists... Done

• Der nächster Schritt ist die Installation des Kernels und des Bootloaders, mehr dazu auf der nächsten Seite.

• Nun wollen wir den Kernel und den Bootloader installieren. Obwohl ich ein Fan des Bootloaders GRUB bin, habe ich mich hier der Einfachheit halber für den LinuxLoader lilo entschieden. Aber suchen wir zuerst nach einem passenden Kernelimage:

1. root:/# apt-cache search kernel image 2.6 AMD
   1. kernel-image-2.6-amd64-generic - Linux kernel image for version 2.6 on generic x86_64 systems
      kernel-image-2.6-amd64-k8 - Linux kernel image for version 2.6 on AMD64 systems
      kernel-image-2.6-amd64-k8-smp - Linux kernel image for version 2.6 on AMD64 SMP systems
      kernel-image-2.6-k7 - Linux kernel image for version 2.6 on AMD K7.
      kernel-image-2.6-k7-smp - Linux kernel image for version 2.6 on AMD K7 SMP.
      kernel-image-2.6.8-11-amd64-generic - Linux kernel image for version 2.6.8 on generic x86_64 systems
      kernel-image-2.6.8-11-amd64-k8 - Linux kernel image for version 2.6.8 on AMD64 systems
      kernel-image-2.6.8-11-amd64-k8-smp - Linux kernel image for version 2.6.8 on AMD64 SMP systems
      kernel-image-2.6.8-2-k7 - Linux kernel image for version 2.6.8 on AMD K7.
      kernel-image-2.6.8-2-k7-smp - Linux kernel image for version 2.6.8 on AMD K7 SMP.

• Da wir nur eine CPU, ohne HyperThreading oder DualCore, haben, ist das Kernelimage kernel-image-2.6-k7 das richtige Image für uns. Dieses Image verweist auf die aktuelle Version dieses Kernels im entsprechenden Debian Tree, so dass wir auch Updates für dieses Paket mit apt-get upgrade installieren können und von apticron über neuere Versionen informiert werden. Das AMD64 Paket nehmen wir nicht, da es Probleme mit iptables macht und laut den Aussagen diverser Forenthreads Nachteile hat, einen solchen Server mit einem 64 Bit Kernel zu fahren.
• Der Installer wird beim Installieren des Kernels und der entsprechenden abhängigen Pakete mit folgender Fehlermeldung herum"meckern":

1. 1. /usr/sbin/mkinitrd: neither /dev/fd or /proc/self/fd exists!
      Try mounting the proc filesystem: mount -tproc none /proc
      Failed to create initrd image.

• Um dieses Porblem zu vermeiden, befolgen wir den Hinweis aus der Fehlermeldung und führen den genannten Befehl schon jetzt aus:

1. root:/# mount -tproc none /proc

• Bei der Installation wird immer auch der passende initrd erzeugt, man könnte dies auch händisch mit mkinitrd machen. Installieren wir zuerst das Package initrd-tools, bei der Gelegenheit auch gleich den vim.

1. root:/# apt-get install -y initrd-tools vim

• Nun stehen uns die nötigen Konfigurationsfiles zur Verfügung, wir müssen nun angeben, welche Module in den initrd kommen sollen:

1. root:/# vim /etc/mkinitrd/modules

   1. # /etc/mkinitrd/modules: Kernel modules to load for initrd. # # This file should contain the names of kernel modules and their arguments # (if any) that are needed to mount the root file system, one per line. # Comments begin with a `#', and everything on the line after them are ignored. # # You must run mkinitrd(8) to effect this change. # # Examples: # # ext2 # wd io=0x300 ext3 jbd via82cxxx libata scsi_mod sd_mod sata_via raid1 md

• Beauftragen wir nun apt mit der Installation des Kernel-Images und des Linuxloaders. mdadm und die raidtools2 installieren wir bei dieser Gelegenheit gleich mit:

1. root:/# apt-get install kernel-image-2.6-k7 lilo mdadm raidtools2 -y

• Wir bestätigen die nun folgenden Fragen

1. 1. ...
      The following NEW packages will be installed:
      cramfsprogs dash kernel-image-2.6-k7 .......... libdevmapper1.01 lilo mdadm
      module-init-tools raidtools2
      ...
   2. in /etc/kernel-img.conf.
      Note that this is optional, but if you do not,
      you will continue to see this message whenever you install a kernel
      image using initrd.
      Do you want to stop now? [Y/n]
2. Wir bestätigen durch Eingabe von N, dass wir fortfahren wollen.

1. 1. ...
      Do you want me to create a link from /boot/initrd.img-2.6.8-..... to initrd.img?[Yn]
2. Wir bestätigen durch Eingabe von Y, dass der Link erzeugt werden soll.
   1. ...
      Do you wish to set up Linux to boot from the hard disk? [Yes] No
3. Hier geben wir "No" ein, da wir erst noch die lilo.conf erzeugen müssen. Bei Eingabe von "Yes" würde der Installer eine für uns unpassende lilo.conf erzeugen.
   1. ...
      Errors were encountered while processing:
      lilo
      E: Sub-process /usr/bin/dpkg returned an error code (1)

• Den Fehler ignorieren wir vorerst, er wird sich später im frisch gebooteten System von selbst erledigen.

• Nun müssen wir noch den LinuxLoader lilo einrichten. Die automatische Konfiguration würde an unseren RAID-Arrays scheitern, außer möchten wir lilo gleich so einrichten, dass wir den Bootvorgang an der seriellen Konsole beobachten können. Die Datei /etc/lilo.conf soll so aussehen:

1. root:/# vi /etc/lilo.conf

   1. boot=/dev/sda root=/dev/md1 compact install=/boot/boot.b map=/boot/map vga=normal delay=20 image=/vmlinuz append="console=tty0 console=ttyS0,57600" label = Linux read-only initrd=/initrd.img

• Die anfangs besprochene optionale Installation auf sdb übergehen wir hier.

• Nachdem wir nun die Konfiguration des lilo fertiggestellt haben, installieren wir lilo:

1. root:/# lilo
   1. Warning: COMPACT may conflict with LBA32 on some systems
      Warning: '/proc/partitions' does not match '/dev' directory structure.
      Name change: '/dev/md/0' -> '/dev/md0'
      Added Linux *

• Wir nähern uns unaufhaltsam dem ersten Boot in das neue System, wollen aber auf der nächsten Seite noch ein paar Konfigurationen vornehmen.

• Damit das neue System später auch an der seriellen Konsole ansprechbar ist, fügen wir die entsprechende Zeile der Datei /etc/inittab hinzu:

1. root:/# echo "S0:12345:respawn:/sbin/getty -L 57600 ttyS0 vt102" >> /etc/inittab

• Damit der Kernel die Netzwerkhardware ansprechen kann, müssen wir ihm mitteilen, welches Modul er laden soll. Sehen wir uns zuerst an, welche Hardware im Server verbaut wurde, dies muss je nach Server individuell geschehen, da sich der Typ der verbauten Hardware ja ändern kann.:

1. root:/# lspci | grep Ethernet
   1. 0000:00:0d.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8169 Gigabit Ethernet (rev 10)

• Laut Google benötigen wir für diesen Adapter das Modul "tg3", dies schreiben wir so in die /etc/modules.conf:

1. root:/# vi /etc/modules

   1. r8169

• Widmen wir uns nun den weiteren Netzwerkkonfigurationsdateien /etc/hosts und /etc/hostname, diese könnten dann so aussehen:

1. root:/# echo "127.0.0.1 localhost" > /etc/hosts

• Die Netzwerkkonfiguration nehmen wir per DHCP vor, die Datei /etc/network/interfaces sieht so aus:

1. root:/# vi /etc/network/interfaces

   1. auto lo iface lo inet loopback auto eth0 iface eth0 inet dhcp

• (Nicht nur) Strato hat nun bekanntermaßen Besonderheiten bei der Netzwerkkonfiguration. Der von mir verwendete DHCP-Client weigert sich bei Strato nun, entsprechende Routen zu setzen.
  Daher verwende ich nun überall den dhcp Client: dhcpcd - DHCP client for automatically configuring IPv4 networking.

1. root:/# apt-get install -y dhcpcd

• An dieser Stelle bietet sich auch die Installtion des ssh daemons an:

1. root:/# apt-get install ssh -y

Ein paar Fragen müssen beantwortet werden.

1. 1. ... Setting up ssh (3.8.1p1-8.sarge.4) ...
      Creating SSH2 RSA key; this may take some time ...
      Creating SSH2 DSA key; this may take some time ...
      Restarting OpenBSD Secure Shell server: sshd.

• Nun sind wir soweit, dass wir das neue System starten können.

• Im Strato Konfigurations-Webinterface muss die Bootreihenfolge des Servers nun wieder auf Booten von Festplatte eingestellt werden. Wir verlassen nun die chrooted-Umgebung und rebooten das System:

1. root:/# exit
   1. exit
2. root:/# reboot -n
   1. Broadcast message from root (pts/0) (Fri Apr 7 19:04:40 2006):
      The system is going down for reboot NOW!

• Unser frisch installierter Debian Server bootet nun sauber von der Festplatte:

• Nun könnt Ihr Euch per ssh einloggen und das System wie gewohnt einrichten.

• Credits:

1. Besonderen Dank widme ich dem Rootforum, von dort stammt ein guter Teil meines Wissens, vor allem möchte ich mich bei den Personen bedanken, die die Vorarbeit durch ihre Anleitungen und Skripte geleistet haben. Letztendlich habe ich dieses Wissen nur zusammengefasst und mit der RAID-Configuration ergänzt
2. Weiterhin vielen Dank an Hetzner, die:
   1. Emails schnell und kompetent beantworteten
   2. telefonisch gut erreichbar und hilfsbereit waren
   3. mir den Server zum Testen bereitgestellt haben.