Es war ein Dienstagmorgen um vier Uhr, als das Telefon klingelte. Ein mittelständischer Automobilzulieferer hatte versucht, sein gesamtes Kernsystem über das Wochenende auf red hat enterprise linux 8 umzustellen. Sie dachten, ein einfaches In-Place-Upgrade würde reichen. Stattdessen saßen sie vor einem Scherbenhaufen: Die Datenbanken starteten nicht, weil die Bibliotheken nicht mehr zusammenpassten, und die spezialisierte Steuerungssoftware für die Fertigungsstraße quittierte den Dienst mit kryptischen Fehlermeldungen. In meiner Laufbahn habe ich das oft erlebt. Unternehmen unterschätzen die massiven architektonischen Verschiebungen, die mit dieser Version einhergehen. Sie behandeln ein Betriebssystem-Update wie ein Smartphone-Update. Das kostet am Ende nicht nur Nerven, sondern zehntausende Euro pro Stunde Stillstandszeit. Wer glaubt, dass man einfach nur ein paar Pakete aktualisiert, hat den Schuss nicht gehört.
Die Arroganz des In-Place-Upgrades unter red hat enterprise linux 8
Einer der teuersten Fehler, den Administratoren machen, ist der blinde Glaube an Werkzeuge wie Leapp. Verstehen Sie mich nicht falsch: Das Tool funktioniert technisch gesehen oft einwandfrei. Aber Technik ist nur die halbe Miete. Ich habe erlebt, wie ein Team stolz verkündete, der Migrationsprozess sei in zwanzig Minuten durchgelaufen, nur um festzustellen, dass die Security-Richtlinien der Firma nun komplett ausgehebelt waren.
Der Fehler liegt in der Annahme, dass Altlasten aus Version 7 einfach mitwandern können. In der Realität schleppen Sie Konfigurationsleichen mit, die unter der neuen Haube zu unvorhersehbarem Verhalten führen. Wenn Sie ein System haben, das seit fünf Jahren läuft, stecken dort hunderte manuelle Anpassungen drin, die niemand dokumentiert hat. Ein automatisches Upgrade schiebt diesen Müll einfach in die neue Umgebung.
Die Lösung ist schmerzhaft, aber effizient: Bauen Sie neu. Nutzen Sie die Gelegenheit, um Ihre Infrastruktur zu automatisieren. Wer heute noch Server von Hand installiert und dann ein Upgrade-Skript drüberlaufen lässt, verbrennt Geld. Ein sauberer Neuaufbau mit Ansible dauert beim ersten Mal länger, spart Ihnen aber in den folgenden drei Jahren hunderte Stunden bei der Fehlersuche. Wenn ein System reproduzierbar ist, spielt die Angst vor dem Upgrade keine Rolle mehr.
Warum Abhängigkeiten Ihr Genick brechen
Unter der Haube hat sich der Wechsel von Python 2 auf Python 3 vollzogen. Das klingt trivial. Ist es aber nicht, wenn Ihre kritischen Wartungsskripte oder Überwachungstools noch auf 2.7 basieren. Ich sah Administratoren, die verzweifelt versuchten, veraltete Bibliotheken per Hand nachzuinstallieren, was das System in einen instabilen Zustand versetzte. Es gibt keinen Grund, ein totes Pferd zu reiten. Wenn Ihre Software nicht mit Python 3 klarkommt, ist das Betriebssystem-Update Ihr geringstes Problem – Ihre Software ist dann schlicht veraltet und ein Sicherheitsrisiko.
Der fatale Irrtum über die Paketverwaltung und Module
Viele erfahrene Linux-Nutzer stolpern über AppStream. Sie sind es gewohnt, dass yum install genau eine Version liefert, die für die gesamte Lebensdauer des Systems stabil bleibt. In dieser speziellen Software-Umgebung ist das anders. Das Konzept der Modularität erlaubt es, verschiedene Versionen derselben Software vorzuhalten. Das ist ein Segen, wenn man weiß, was man tut, und ein Fluch, wenn man es ignoriert.
Ich habe ein Szenario erlebt, bei dem ein Entwicklerteam eigenmächtig eine neuere Node.js-Version über ein Modul aktiviert hat. Die Produktion lief zwei Wochen lang super, bis ein Sicherheitsupdate eingespielt wurde, das mit der spezifischen Modulversion kollidierte. Da niemand dokumentiert hatte, welches Modul aktiv war, dauerte die Wiederherstellung acht Stunden.
Statt blind Pakete zu installieren, müssen Sie Profile definieren. Sie müssen festlegen, welche Stream-Version für Ihr Unternehmen der Standard ist. Ohne eine zentrale Verwaltung über einen Satellite-Server oder zumindest eine sehr strikte Ansible-Konfiguration wird Ihre Serverlandschaft innerhalb weniger Monate zu einem unkontrollierbaren Flickenteppich. Modularität bedeutet Verantwortung, nicht Beliebigkeit.
Das Sicherheits-Fiasko durch missverstandenes Crypto-Policies
Sicherheit ist oft der Grund für den Wechsel, wird aber meistens falsch implementiert. Dieses System führt systemweite Krypto-Richtlinien ein. Früher mussten Sie jede Applikation einzeln konfigurieren, um unsichere Verschlüsselungen zu verbieten. Jetzt macht das System das zentral. Das Problem? Wenn Ihr alter Legacy-Loadbalancer nur veraltete TLS-Versionen spricht, wird die Kommunikation nach dem Update einfach gekappt.
Ich war bei einem Kunden, dessen gesamte interne Kommunikation zusammenbrach, weil sie die Richtlinie auf "FUTURE" gesetzt hatten, ohne zu prüfen, ob ihre Hardware-Tokens das überhaupt unterstützen. Das Ergebnis war ein kompletter Lockout. Man kann Sicherheit nicht erzwingen, indem man einen Schalter umlegt, ohne die Gegenseite zu kennen.
Der richtige Weg ist die schrittweise Anpassung. Fangen Sie mit der "DEFAULT"-Policy an und analysieren Sie die Logs. Schauen Sie nach abgelehnten Verbindungen. Erst wenn Sie sicher sind, dass Ihre Infrastruktur modern genug ist, ziehen Sie die Daumenschrauben an. Es bringt nichts, den sichersten Server der Welt zu haben, wenn er mit niemandem mehr reden kann.
Netzwerkmanagement ist kein optionales Wissen mehr
Wer immer noch versucht, die Netzwerkkonfiguration über manuelle Skripte in /etc/sysconfig/network-scripts/ zu regeln, wird früher oder später gegen eine Wand laufen. Der NetworkManager ist hier nicht mehr nur ein Vorschlag, er ist das Gesetz. Ich habe Admins gesehen, die den Dienst deaktiviert haben, weil sie ihn "nervig" fanden. Drei Tage später, nach einem Kernel-Update und einem Reboot, kam die Maschine nicht mehr hoch, weil die händischen Skripte nicht mehr gegriffen haben.
In meiner Praxis hat sich gezeigt, dass der Widerstand gegen neue Tools oft aus Bequemlichkeit resultiert. Aber Bequemlichkeit ist im Enterprise-Umfeld teuer. Der NetworkManager bietet über nmcli eine Mächtigkeit, die alte Skripte niemals hatten. Man muss sich nur die Zeit nehmen, es einmal richtig zu lernen. Wer das ignoriert, baut sich eine Zeitbombe.
Ein konkretes Beispiel für den falschen versus den richtigen Ansatz verdeutlicht das Problem:
Der falsche Ansatz (Vorher): Ein Admin möchte eine statische IP-Adresse vergeben. Er öffnet die Konfigurationsdatei mit vi, tippt die Werte ein, vertippt sich bei der Subnetzmaske und startet den Netzwerkdienst neu. Der Dienst bricht ab, der Server ist remote nicht mehr erreichbar. Er muss zum Rechenzentrum fahren oder über das IPMI-Interface mühsam den Fehler suchen. Er verbringt zwei Stunden mit der Fehlersuche, weil er die Syntax der alten Skripte falsch im Kopf hatte.
Der richtige Ansatz (Nachher):
Der Admin nutzt das Kommandozeilentool nmcli. Er gibt den Befehl ein, das Tool validiert die Eingabe sofort auf syntaktische Korrektheit. Er nutzt die interaktive Hilfe, um die Parameter zu setzen. Bevor er die Änderung dauerhaft macht, nutzt er eine Test-Konfiguration. Alles funktioniert beim ersten Mal, die Änderung wird sauber in den NetworkManager übernommen und ist über Reboots hinweg stabil. Der gesamte Prozess dauert fünf Minuten und hinterlässt eine saubere Konfiguration, die auch von Kollegen leicht verstanden wird.
Speicherplatz ist billig, aber falsche Partitionierung ist teuer
Ein Thema, das regelmäßig unterschätzt wird, ist die Größe der Partitionen im Kontext von Stratis und VDO. Diese Technologien zur Speicheroptimierung sind großartig, verlangen aber ein Umdenken. Ich habe Systeme gesehen, die nach sechs Monaten vollgelaufen sind, weil die Administratoren die Deduplizierungsraten zu optimistisch eingeschätzt hatten.
Wenn Sie VDO (Virtual Data Optimizer) einsetzen, gaukeln Sie dem System mehr Platz vor, als physisch vorhanden ist. Das ist wie beim Überbuchen von Flügen: Es geht gut, solange nicht alle gleichzeitig auftauchen. Wenn Ihre Daten aber nicht so gut komprimierbar sind wie gedacht, kracht es gewaltig. Ein Dateisystem, das auf einem VDO-Volume liegt und physisch keinen Platz mehr findet, korrumpiert im schlimmsten Fall Ihre Daten.
Verlassen Sie sich nicht auf die Marketing-Versprechen von 10:1 Kompression. In der realen Welt, besonders bei verschlüsselten Daten oder bereits komprimierten Formaten wie JPEG oder Video, ist die Rate fast Null. Testen Sie Ihre spezifischen Daten, bevor Sie die logische Größe Ihres Dateisystems festlegen. Und vor allem: Überwachen Sie den physischen Füllgrad, nicht den logischen. Wer nur auf df -h schaut, ist verlassen.
Zeitmanagement und die Illusion von Kompatibilität
Ein großer Fehler bei der Planung mit red hat enterprise linux 8 ist der Zeitplan. Manager denken oft, dass man eine ganze Serverfarm in einem Monat migrieren kann. In meiner Erfahrung braucht man pro Applikationsgruppe mindestens zwei Wochen für Tests, Fehlerbehebung und Validierung.
Dabei geht es nicht nur um das Betriebssystem. Es geht um das gesamte Ökosystem. PHP-Versionen, Datenbank-Treiber, Monitoring-Agenten – alles muss angefasst werden. Wer den Zeitplan zu eng steckt, wird am Ende Abstriche bei der Qualität machen. Und diese Abstriche holen Sie sechs Monate später ein, wenn die ersten unerklärlichen Abstürze in der Produktion auftreten.
Die Falle der Drittanbieter-Repositories
Ein klassischer Fehler ist das unkontrollierte Einbinden von Repositories wie EPEL oder noch schlimmer, irgendwelchen zufälligen RPM-Quellen aus dem Internet. Ich habe gesehen, wie Systeme durch inkompatible Pakete komplett unbrauchbar gemacht wurden, nur weil ein Admin schnell ein bestimmtes Tool brauchte. In einer Enterprise-Umgebung ist das ein absolutes No-Go. Wenn ein Paket nicht im Standardumfang ist, müssen Sie es selbst paketieren oder eine Lösung finden, die den Support-Status nicht gefährdet. Ein verbasteltes System bekommt keinen Support von Red Hat, wenn es brennt. Das ist das Geld, das Sie für die Subscription bezahlen, schlicht weggeschmissen.
Realitätscheck
Erfolgreich mit diesem System zu arbeiten bedeutet nicht, alle Befehle auswendig zu kennen. Es bedeutet, zu akzeptieren, dass sich die Art und Weise, wie wir Linux-Server verwalten, grundlegend geändert hat. Wer versucht, die Methoden von vor zehn Jahren anzuwenden, wird scheitern. Es braucht Disziplin bei der Automatisierung, Geduld beim Testen und die Bereitschaft, alte Zöpfe abzuschneiden.
Wenn Sie denken, Sie können die Komplexität wegignorieren, wird die Komplexität Sie irgendwann beißen. Es gibt keine Abkürzung. Ein stabiles System ist das Ergebnis von sauberer Architektur und gnadenloser Standardisierung. Alles andere ist nur Glückspiel auf Kosten der Firma. In meiner Praxis habe ich gesehen, dass die Teams am erfolgreichsten waren, die sich drei Monate Zeit für die Vorbereitung genommen haben, anstatt sofort mit dem Installieren anzufangen. Wer schnell sein will, muss langsam starten. Das ist die unbequeme Wahrheit, die kein Berater gerne ausspricht, weil sie nicht nach Fortschritt klingt. Aber sie ist der einzige Weg, um nachts ruhig schlafen zu können, während die Server draußen ihren Dienst tun.
