Der perfekte TYPO3 Linux Server im Jahr 2015

Nach den vielen Sicherheitslücken und daraus resultierenden Updates des Jahres 2014 und der damit verbundenen Arbeitszeit, war der Leidensdruck mit meiner bis dato liebsten Distribution schon recht groß. Der Druck war sogar so groß, dass ich nach über 10 Jahren (Open)SuSE am Server etwas langfristigeres haben wollte.
Dabei stellt sich dann die Frage, will man ein Rolling-Release, oder lieber eine LTS Version. Da ich am Desktop schon vor einigen Jahren mit einer Rolling-Release experimentierte, und von der Stabilität wenig begeistert war, fiel die Wahl sehr schnell auf den klassischen LTS Ansatz. Dann begann die Suche nach einer Distribution die für den Webservereinsatz gut geeignet ist, und sich dort auch einer gewissen Beliebtheit erfreut, was ja meist in entsprechenden Foreneinträgen, Hilfeseiten, FAQ etc... resultiert. Schliesslich sollen meine Produktivsysteme kein Testlabor werden.
Auch hier wurde ich recht schnell fündig, und meine Wahl fiel auf CentOS. CentOS ist binärkompatibel zu REHL, und bietet einen unglaublich langen Zeitraum für Sicherheitsupdates.
Derzeit sind zwei CentOS Versionen im LTS-Modus verfügbar, und zwar Version 6, welche Updates bis 2020 liefert, und die neue Version 7, erschienen Mitte 2014, welche sogar Updates bis 2024 verspricht!

Leider scheint es so, dass mein Rechenzentrumsbetreiber 1und1 am Minimal-Image von centOS 7 einiges 'gedreht' hat. Dies führt dazu, dass eine vollkommen frische Installation nach dem ersten 'yum update' schlicht nicht mehr bootet. So wie es aussieht wurden die Images von 1und1 mit einem Vanilla-Kernel ausgestattet, und obendrein wurde noch an der Grub-Konfiguration rumgebastelt.
Das alles war offensichtlich für ganz bestimmte Treiber-Module für einige Netzwerk- bzw. RAID-Controller notwendig, die aber mittlerweile vom aktuellen Kernel von Haus aus unterstützt werden sollten.

Aber keine Angst, in den meisten Fällen lässt sich dies auch nachträglich noch beheben.
Der erste Schritt ist, einen Reboot über das Recovery-Tool im 1und1 Kontrollzentrum zu erzwingen. Gleichzeitig sollte man bereits über die serielle Konsole mit dem Server verbunden sein.
Sobald die Boot-Auswahl kommt, sollte man den ältesten verfügbaren Standardkernel wählen. Bei mir war dies folgender Eintrag:
"CentOS Linux, with Linux 3.10.0-123.9.3.el7.x86_64".

Mit der Wahl dieses Kernels sollte das Starten des Servers dann auch gut klappen. Falls das Booten immer noch nicht klappt, probieren Sie einfach einen der anderen Einträge aus.
Im schlimmsten Fall müssten Sie evtl. den Weg über ein Rescue-System gehen.

Wenn das Booten erfolgreich war, sollten Sie sich am Server einloggen, und können im Anschluss Ihre Installation reparieren.
In der Hauptsache ist das Boot-Problem durch falsche (für den offiziellen Kernel unverträgliche) Grub-Einstellungen verursacht.

Editieren Sie also die Datei /etc/default/grub wie folgt (dass man vorher eine Sicherungskopie der Datei anlegt ist selbstverständlich!):

Ändern Sie Zeile:

GRUB_CMDLINE_LINUX="rd.driver=raid1,ahci,dm_mod,part_gpt domdadm dolvm rd.lvm.vg=vg00 rd.lvm.lv=vg00/usr console=ttyS0,57600 console=tty0"

auf

GRUB_CMDLINE_LINUX="rd.auto rd.auto=1 domdadm dolvm rd.lvm.vg=vg00 rd.lvm.lv=vg00/usr console=ttyS0,57600 console=tty0 crashkernel=auto"

und kommentieren Sie die Zeile

GRUB_DISABLE_LINUX_UUID=true

mit der Raute:

#GRUB_DISABLE_LINUX_UUID=true

Im Anschluss können Sie die Grub-Konfiguration neu schreiben lassen. Auch hier gilt, machen Sie ein Backup, bevor Sie die .cfg-Dateien neu schreiben lassen.
Bei meinen Systemen sind zwei Grub-Konfigurationen vorhanden. Weil ich zu faul war zu kontrollieren, welche nun tatsächlich zum Einsatz kommt ;), hab ich einfach beide neu geschrieben:

grub2-mkconfig --output=/boot/grub2/grub.cfg

grub2-mkconfig --output=/etc/grub2.cfg

Im Anschluss sollten Sie noch in der Datei /etc/dracut.conf die Zeile

add_drivers+="raid1 ahci dm_mod arcmsr aacraid 3w-9xxx 3w-xxxx 3w-sas mptspi sd_mod"

mit der Raute auskommentieren:

#add_drivers+="raid1 ahci dm_mod arcmsr aacraid 3w-9xxx 3w-xxxx 3w-sas mptspi sd_mod"

Nun noch ein beherztes 'reboot' in die Konsole getippt, und schnell auf die serielle Konsole des Servers gewechselt um den Boot-Vorgang zu beobachten.

Bei mir war nun alles wieder in Ordnung, und ich konnte mit dem Einrichten des Servers fortfahren.

Selbstverständlich sollten Sie auf Ihrem System im Anschluss noch z.B. die volle Funktionstüchtigkeit Ihres RAID-Verbundes prüfen.

EDIT am 07.01.2018

Im Zuge von Meltdown und Spectre musste einer unserer Server aus 2015 mit CentOS 7 minimal bei der 1und1 nach beinahe 3 Jahren durchgängiger Lauffähigkeit neu gestartet werden, um den neuen Kernel auch tatsächlich zu laden. Was bleibt zu sagen? -> Das Szenario oben musste wiederholt werden ... Sprich: Grub2 musste neu konfiguriert werden.
Bei aller Liebe, aber das fühlt sich für einen Produktionsserver doch reichlich 'hacky' an. Da kann ich ja gleich auf einen Microsoft Server wechseln ...

Inhalt noch in Bearbeitung ...