© maridav, 123RF.com

Wer vorhat, über lange Zeit ein LAMP-System “nur” zu betreiben, wünscht sich, dass der Distributionshersteller seine Upgrades sowohl unkompliziert gestaltet als auch die Basis stabil hält, auf der eigene Anwendungen laufen. Zwei freie Distributionen in einer Fünf-Jahres-Retrospektive.

Wer im Rechenzentrum komplexe, geschäftskritische und verzahnt arbeitende Anwendungen betreibt, hantiert natürlich mit Enterprise-Distributionen und einem mit kostenpflichtigen Subscriptions unterlegten Softwaremanagement auf der richtigen Spielfeldhälfte. Wenn etwas nach einem Update oder Upgrade crasht, darf er den Herstellersupport einfordern (siehe Artikel “Klasse Luxusklasse?”).

Es existieren aber auch die simplen Fälle, wo der Server einfach nur über lange Zeit Dienst schieben soll. Dabei ist es egal, ob es sich um einen dedizierten Server im eigenen Haus oder beim Provider handelt oder um eine virtuelle Maschine. Dem Admin drängt sich natürlich die Frage auf, ob es nicht ein “normales” Linux auch tut. Das Linux-Magazin geht ihr nach und greift die im deutschsprachigen Raum wohl verbreitetsten Distributionen heraus: Ubuntu und Open Suse.

Um deren Langzeitstabilität zu beurteilen, sind die Magazin-Tester fünf Jahre in der Zeit zurückgereist. Dann simulierten sie die Arbeitsgänge, die ein (an der Distribution eher desinteressierter) Admin bis heute hätte leisten müssen, um ein Security-gepatchtes 64-Bit-System zu behalten. Als Indikator für die Nachhaltigkeit des Ganzen diente die deutsche Version des freien Content Management System Joomla 2.5. [1]. Um das machen Distributionshersteller offenbar gern einen Bogen – vielleicht, weil sie Versionskonflikte zwischen dessen Komponenten und dem erforderlichen LAMP befürchten. Das macht es zum idealen Funktionsbenchmark-Kandidaten.

Ubuntu LTS Server Edition

Wer mit Ubuntu Linux Desktop arbeitet und Anwenderwissen aufgebaut hat, für den erscheint es nur natürlich, seine Distribution auch auf Servern zu verwenden – zumal es eine Server Edition gibt. Die fällt zudem im Vergleich zur Desktop Edition und zu den Mitbewerbern als sehr schlank auf, passt auf eine CD und enthält weder grafische Oberfläche noch GUI-Programme. Wenig Software bedeutet hier, dass im laufenden Betrieb auch wenig Pakete zu warten sind.

Es heißt im Fall von Ubuntu Server auch, dass Admins kaum Verwaltungswerkzeug bekommen und Konfigurationsdateien manuell ändern müssen. Mit der Komforteinbuße nähert sich Canonical andererseits wieder der ursprünglichen Philosophie von Unix und Linux, die Klarheit und Kleinteiligkeit kombiniert. Salopp gesagt: Alte Unix-Hasen kommen mit Ubuntu Server sicher auf Anhieb klar.

Die dem Artikel zugrunde liegende Aufgabe unterstützt Ubuntu zudem mit seinen langzeitstabilen LTS-Versionen. Für die Server Editions bedeutet “Long Term Support”, dass auch Anwender ohne Supportvertrag nach dem Erscheinen fünf Jahre lang mit laufend bereitgestellten Securityfixes in Paketform rechnen dürfen. Dieser Test beginnt denn auch mit Ubuntu 8.04 LTS, Codename “Hardy Heron” [2]. Die Version erschien im April 2008, der Support lief im Mai 2013 aus.

Bei der Installation von CD folgten die Tester so gut es ging den Empfehlungen der Wizard-Macher, um ein System von der Stange zu bekommen. Bei der Paketvorauswahl nahmen sie »LAMP« . Nach dem Kopieren der Pakete klappte der Ubuntu-Start von Festplatte erwartungsgemäß gut. Um Joomla aufs System zu bekommen, mussten sie nur den Tarball im Document-Root »/var/www/joomla« entpacken und Owner und Group aller CMS-Dateien manuell setzen. Das per Browser von außen gestartete Joomla-Setup verlief ohne Fehler. Gleich im Anschluss war das CMS einsatzbereit.

Weil »apt-get check« nichts bemängelte, griffen die Tester mit »apt-get update« ins mittlerweile abgelaufene Online-Repository. Auch nach dieser Aktion liefen alle Joomla-Komponenten klaglos weiter.

Upgrade auf 10.04 LTS

Im Netz existieren lange Anleitungen, welche Vor- und Nachbereitungen im Zuge von Ubuntu-Upgrades zu treffen sind. Die Tester gingen, wie vermutlich die meisten Anwender in der Praxis auch, weit weniger zart zu Werke und tippten lediglich im laufenden System »sudo do-release-upgrade« . Das funktionsmächtige Kommandozeilentool, das kaum Parameter kennt, kümmert sich um die für ein Upgrade nötigen Arbeiten. Ubuntus Konzept sieht eleganterweise Online-Upgrades innerhalb der laufenden Distribution vor – der Admin muss also nicht mit Datenträgern hantieren wie bei den meisten anderen Linuxen.

Wer »do-release-upgrade« auf eine LTS-Distribution anwendet, landet intelligenterweise bei der nächsten LTS. Sprünge zur übernächsten Version sind nicht vorgesehen. Die Systematik der Upgrade-Zielsuche ist übrigens in der Datei »/etc/update-manager/release-upgrades« hinter dem Eintrag »Prompt=« änderbar.

Das »do-release-upgrade« , das im Test von der 8.04 zur 10.04 führte, ging schmerzarm vonstatten: Zum einen kam eine Nachfrage zur Konfigurationsdatei für Dhclient, die Tester folgten dem Vorschlag, die alte Datei beizubehalten. Außerdem tauchten Warnungen zu Apparmor-Modulen auf. Die Frage der Routine, 20 alte Pakete entfernen zu wollen – GCC 4.2, Python 2.5 und diverse Bibliotheken –, bejahten die Tester. Geschafft: Nach einem Neustart meldete sich der Laborrechner als Ubuntu 10.04. Angenehm überraschte der Umstand, dass das manuell installierte Joomla-CMS auch sofort loslief und erreichbar war.

Schlusspunkt Ubuntu 12.04

Bei der Software-Ausstattung im April 2010 gut angekommen und mit den aktuellen Sicherheitsupdates versorgt, rüsteteten sich die Tester für den zweiten großen Sprung. Ohne irgendwelche Paketquellen zu prüfen oder gar zu einzustellen, stießen sie auf der Maschine abermals ein »do-release-upgrade« an.

Der Vorgang ähnelte dem vorigen sehr, dauerte aber merklich länger. Auch stellte das Setup den Testern mehr (allerdings einfache) Fragen. Am Ende entfernte das Tool 18 Pakete, hauptsächlich Libraries und Python 2.6. Nach einem Neustart zeigte sich die Joomla-Erlebniskulisse: Alles bestens (Abbildung 1 und 2).

Abbildung 1 und 2: Die Systeminfo-Seite im Joomla-Backend spiegelt hier die Ubuntu-Versionsgeschichte wider – oben 8.04, unten 12.04.” width=”300″ height=”59″ /> Abbildung 1 und 2: Die Systeminfo-Seite im Joomla-Backend spiegelt hier die Ubuntu-Versionsgeschichte wider – oben 8.04, unten 12.04.

Open Suse 11.0

Im Juni 2008 veröffentlichte die Open-Suse-Community ihre Version 11.0 [3], alle acht Monate folgt eine neue Version. Gerade mal 18 Monate versorgen die Macher die Repositories mit Sicherheits- und Bugfix-Updates – eigentlich nicht gerade eine Einladung für den Langzeiteinsatz. Als Evergreen [4] firmiert ein Unterprojekt, das ausgewählte Versionen künftig länger pflegen will.

Der Installer von Open Suse 11.0 ist gleich nach dem Booten von DVD grafisch viel opulenter als der von Ubuntu Server. Die Tester wählten mit Hinblick auf den Einsatzzweck unter »Desktop auswählen« die Option »Weitere | Minimale Serverauswahl (Textmodus)« . Beim ersten Booten von Festplatte irritierte eine Fehlermeldung von »/usr/sbin/smartd« .

Dass die »Serverauswahl« tatsächlich minimal ausfällt, merkten die Tester daran, dass weder Apache noch MySQL installiert waren. Mit der Konsolenversion von Yast 2 installierten sie also das Softwareschema »Web- und LAMP-Server« nach.

Die Setup-Routine des wie bei Ubuntu manuell eingespielten Joomla scheiterte trotzdem. Wie sich herausstellte, beinhaltet das »Web- und LAMP-Server« -Schema entgegen der Yast-Beschreibung statt MySQL ein PostgreSQL. Die Tester installierten nun MySQL nach und schalteten sie im Runlevel-Editor ein. Um Joomla zu erwecken, fehlten außerdem das Paket »php5-zlib« und ein Apache-Restart per Inetd. Die gute Nachricht: Nach einem Online-Update (mit Delta-RPMs), das in zwei Stufen und mit einem Reboot ablief, funktionierte das CMS weiter.

Upgrade auf Version 11.1

Suses Standard-Update-Konzept erwartet den Datenträger der nächsten Linux-Version und dass der Rechner heruntergefahren ist. Die Tester booteten darum die 11.0-Maschine von einer Open-Suse-11.1-DVD, wählten dann den Punkt zum Installieren, dann Aktualisieren (Abbildung 3). Beides ging ohne Probleme ab, ein Test des CMS verlief positiv. Das blieb auch nach dem anschließend per Yast angestoßenen Online-Update so.

Nach gleichem Schema lief der Übergang zu Open Suse 11.2, mit dem Unterschied, dass Yast meldete: »Es konnten nicht alle Konflikte gelöst werden. Ein manueller Eingriff ist erforderlich.« Es stellte sich heraus, dass zwei alte »kernel-default« –Pakete im Clinch lagen. Beim unbeaufsichtigten Booten fiel den Testern eine ungünstige Grub-Konfiguration auf die Füße, die versuchte, den 11.0er-Kernel zu booten, was unter kryptischen Fehlermeldungen im Single Mode endete. Der nun gewählte, neue Kernel war trotz der beim 11.0-Setup angekündigten Servernutzung ein »2.6.31.5-0.1-desktop« .

Die nächste Ungereimtheit: Yast meldet beim Versuch online zu aktualisieren: »Es ist noch kein Aktualisierungs-Repository konfiguriert« . Da kein einfacher Weg, den Verlust der Repositories automatisch zu beheben, ersichtlich war, beließen es die Tester dabei. Joomla war davon zum Glück nicht zu beeindrucken.

Abbildung 3: Nach dem Booten von der Suse-DVD ist zum Upgraden der Modus »Aktualisierung« die richtige Wahl – hier beim Weg von 11.0 zu 11.1.

Open Suse 11.3 und 11.4

Das Upgrade von der Chaosversion 11.2 auf Suse 11.3 versetzte das System in einen besseren Zustand. Yast konnte auch wieder Online-Updates ausführen. Nach dem dann erforderlichen Reboot verschwand übrigens auch die Fehlermeldung von »/usr/sbin/smartd« , die den Test seit Version 11.0 begleitet hatte.

Der positive Eindruck konnte sich mit dem Übergang zu Suse 11.4 leider nicht festigen: Die Upgrade-Routine kündigte einen Paketkonflikt »preload-kmp-default-Version benötigt ksym Version« nebst »Nicht installierbare Anbieter: kernel-default-2.6.37.Version« an. Die nicht leichte Entscheidung zwischen Deinstallation, Behalten der alten Version und dem Ignorieren der Abhängigkeiten fiel auf die erste Option.

Das Aktualisieren von 572 Paketen, das Einspielen von 43 neuen und das Löschen von 35 weiteren bereitete dann keine Probleme. Beim Neustart irritierte, dass »Starting mcelog« nicht geklappt hätte. Joomla dagegen funktionierte prächtig. Als hätten die 1,3 GByte des DVD-Upgrades nicht gereicht, dauerte die Online-Aktualisierung auffällig lange. Mit einem weiteren Neustart verschwand dafür die Mcelog-Fehlermeldung.

Übergang zu 12.1 und 12.2

Trotz neuer Major-Version, die wegen des Wechsels auf den Dreier-Kernel gerechtfertigt erscheint, läuft Suses Upgradeprozedur für den Admin genau wie zwischen zwei Elfern ab. Nach Einspielen von 1,5 GByte Update-Paketen ging der Systemstart von Platte ohne Fehlermeldungen vonstatten. Doch oh Schreck: Joomla war erstmals nicht mehr erreichbar! Tests ergaben, dass Apache HTML ausliefern konnte, auch PHP und MySQL waren zugegen. Die Tester fanden zwei Workarounds: Entweder in Yast eine Apache-Neukonfiguration erzwingen oder Apache per Initd neustarten. Seltsam.

Nach dem nächsten Online-Update meldete MySQL beim Hochfahren wahrheitswidrig, dass »/dev/stderr« fehle. Konsequenterweise blieb die Anzeige hängen – vermutlich, weil eine Fehlerausschrift des Daemons keinen Ausgabekanal fand. Nach [Enter] ging die Anzeige weiter. Das Verhalten blieb über das Upgrade auf Open Suse 12.2. hinaus bestehen. Gleiches galt für das hängende Joomla.

Wertung und Fazit

Vermutlich wird niemand behaupten wollen, Suse sei schon immer eine Upgrade-Spezialistin gewesen. In Anwenderforen überwiegt historisch wie auch aktuell die Meinung, die Neuinstallation sei der Königsweg, um von einer zur nächsten Version zu gelangen. Andererseits bieten die Nürnberger Installationsmedien die Upgrade-Funktion explizit an. Und: Suses traditionelle Herangehensweise, die alte Distribution im heruntergefahrenen Zustand zu erneuern, lässt eigentlich bessere Ergebnisse erwarten als von Linux-Bundles, die Gleiches aus dem laufenden Betrieb heraus versuchen.

Hinzu kommt, dass die gestellte Aufgabe die Latte nicht sonderlich hoch legt: Bis auf Joomla – was hakelig genug zu installieren war – begann die Reise durch die Geschichte bei einem knitterfreien Open Suse 11.0 von der Stange. Dass diese so erlebnisreich verlief, sorgte im Testlabor für einiges Erstaunen. Es machte sogar das Zitat eines früheren Redakteurskollegen die Runde: “Das hat wohl nie einer ausprobiert.”

Aber um das eigentliche Ziel des Tests nicht aus dem Auge zu verlieren: Auf beiden Distributionen blieb das an den Paketverwaltungen vorbei installierte Joomla 2.5 über simulierte fünf Jahre lang unmodifiziert lauffähig. Das ist so selbstverständlich nicht, da sich Apache und seine Module in der Zeit merklich veränderten. Auch MySQL musste sein Datenbankformat in den fünf Jahren kompatibel, und die Sprache PHP ihre Sprachsyntax und die Bibliotheksschnittstellen trotz hochtickender Versionsnummer stabil halten.

Beide Kandidatinnen, die eine Deb-, die andere RPM-basiert, haben die ihnen gestellte Marathonaufgabe mit Bravour gemeistert. Ihre Langzeitstabilität, die man eher als exklusives Merkmal in der mit teuren Subscriptions unterlegten Enterprise-Linux-Klasse erwartet, bildet eine prima Basis für eigene, oft ebenso simple wie wichtige Anwendungen, die ohne viel Wartungsaufwand über Jahre einfach nur laufen sollen. Bravo!