Schalten Distributionen neue Releases frei, sorgt das gewöhnlich für ein großes Hallo in der Linux-Welt. Wenig Beachtung findet die stete Arbeit der Paketmaintainer an vor Monaten oder Jahren erschienen Versionen. Dabei sorgt die Maintenance genannte Softwarepflege erst für Sicherheit und Stabilität.

Keine Frage: Neue Versionen von Linux-Distribution herauszubringen, macht viel Arbeit. Fedora, Open Suse, Debian oder Slackware sind Linuxe, die unzählige Entwickler from Scratch zusammenbauen. Die haben zumindest Aussicht auf Dank für ihre Mühe, sobald die neue Version der Distribution herauskommt und Hunderttausende die Softwarezusammenstellung auf ihren Rechnern installieren.

Dass die tausenden Pakete einer Linux-Version nach deren Erscheinen gepflegt werden müssen, würdigen dagegen die wenigsten Anwender – zumindest unter den privaten. Die Maintenance, also das stetige Einpflegen von Securitypatches und Bugfixes, bringt keinen Ruhm, ist für den produktiven Einsatz jedes Betriebssystem aber zwingend.

Professionelle Anwender, insbesondere solche, die Server mit aus dem Internet direkt erreichbaren IP-Adressen betreiben, wissen fast alle um die Bedeutung der Softwarepflege und honorieren – ideell und vielfach auch materiell – die kontinuierliche, umfassende und zugleich schnelle Arbeit der organisierten Community und der Distributionshersteller.

Lebensgrundlage mancher

Nüchtern betrachtet, fußt das Geschäftsmodell der Linux-Subskriptionen, das Red Hat und Suse im großen Maßstab betreiben, hauptsächlich auf der Maintenance: Der Anwender einer kommerziell orientierten Distribution wie Red Hat Enterpise Linux (RHEL) oder Suse Linux Enterprise Server (SLES) zahlt einen jährlichen Obulus in nennenswerter Höhe für das kontinuierliche Bereitstellen von Updates für die hauseigenen Pakete – die Software selbst ist zum Freigabezeitpunkt einer Release kostenlos.

Dieser Artikel macht es sich zur Aufgabe, die Qualität der mühevollen Kärrnerarbeit der großen Distributionen anhand einiger Beispiele zu betrachten. Dazu haben die Tester analysiert, ob und wann die Maintainer der Anbieter auf Patches reagieren, welche die Programmierer der Projekte bereitstellen, von denen sich die einzelnen Pakete ableiten.

Überraschend komplex

Was sich in der Theorie einfach anhört, erweist sich in der Praxis als einigermaßen komplex: Egal, welchen Beobachtungszeitraum man auswählt, die in den bedeutsamen Distributionen jeweils verbauten Komponenten weisten unterschiedliche Versionsstände auf. Die Ursache dafür liegt weniger in den unterschiedlichen Releasedaten der betrachteten Distributionen, sondern in deren Philosophie bei der Auswahl: Sehr auf Stabilität bedachte Linux-Sammlungen wie Debian, SLES oder RHEL neigen deutlich dazu, ältere und damit besser getestete Softwarestände zu integrieren, während Ubuntu sowie Suses und Red Hats Community-Ausgaben tendenziell nach der jüngsten verfügbaren Software schauen.

Welche der beiden Philosopien die richtige ist, vermag nur der Linux-Benutzer selbst in Kenntnis seiner Anforderungen an sein Betriebssystem beantworten. Sicher dagegen ist, dass mit den unterschiedlichen Versionsständen auch die Notwenigkeit variieren kann, zu einem Zeitpunkt X ein Paket zu patchen oder auch nicht.

Hinzu kommt, dass sich die konservative oder progressive Haltung zu Versionswechseln auch während der Maintenance fortsetzt: Während manche Distributionen fast jeden Versionswechsel von zum Beispiel Firefox oder dem Linux-Kernel mitmachen, halten andere über den ganzen Lebenszyklus einer Distribution an den einmal ausgewählten Versionsnummer eisern fest, um langzeitstabile Schnittstellen zu garantieren und beim Anwender keinen extra Schulungsaufwand zu provozieren.

Mehr über das Thema Enterprise-Support lässt sich aus dem Artikel ab Seite 30 entnehmen, der zugleich der Frage nachgeht, was Benutzer tun können, die eine Distribution länger als fünf oder sieben Jahre stabil zu betreiben haben.

Testfeld und betrachtete Software

Tabelle 1 zählt die im Rahmen dieses Beitrags beobachteten Distributionen auf. Als Informationsquellen diente neben umfangreichen Internetrecherchen auch ein Analysetool, das die Redaktion beim langjährigen Perl-Snashot-Kolumnisten Michael Schilli in Auftrag gegeben hatte. Das mit Plugins erweiterte Tool rattert die Repositories der Community-Distributionen nach einem Suchstring ab und gibt die gefundenen Paket-Dateinamen zusammen mit dem Erscheinungsdatum auf dem Repositoryserver aus. Im Perl-Snapshot ab Seite 94 beschreibt Schilli, wie er dabei vorgeht.

Für die kommerziell orientierten Distributionen funktioniert eine solche Toolunterstützung nicht, da die Anbieter die Paketupdates vor der Allgemeinheit verbergen. Der Grund leuchtet schnell ein: Ihr Geschäftsmodell beruht darauf, Updates nur zahlenden Kunden bereitzustellen (Subskriptionen). Für Untersuchungen an SLES eignet sich der Novell Patch Finder ([1], Abbildung 1) ganz gut als zuverlässiger Einstiegspunkt. Red Hat betreibt etwas Ähnliches, die Oberfläche erreichen aber nur Kunden, die sich bei Red Hat Network angemeldet haben.

Abbildung 1: Eine der Recherchequellen zu diesem Test – der Novell Patch Finder zeigt zu einzelnen SLES-Versionen die erschienen Patches an.

Kernel, Äpfel und Birnen

Beim Linux-Kernel sind die Kandidaten schwer zu vergleichen, denn sie gingen mit unterschiedlichen Kernelversionen an den Start: Ubuntu 12.04 mit Version 3.2.0, der ursprüngliche Kernel 2.6.37 in SLES 11 erlebte zum SP2 ein Upgrade auf 3.0, und lediglich Debian 6.0 (Squeeze) hat Kernel 2.6.32 mit RHEL 6.3 (und damit auch Centos) gemein.

Hier zeigen sich deutliche Unterschiede: Während die Debianer ihren Stable-Kernel im Beobachtungszeitraum nur einmal aktualisierten ([2], Abbildung 2), veröffentlichte Red Hat zwischen Juli und Dezember fünf Security- und Bugfix-Updates in unterschiedlichen Dringlichkeitsstufen.

Abbildung 2: Auf der Changelog-Seite für Debians Kernel 2.6 findet sich ein einziger Eintrag für den Beobachtungszeitraum, aber ein umfangreicher.

Bei Fedora hagelt es Kerne

Am meisten bringt Fedora auf die Waage: Die Community-Distribution zieht mit ein paar Tagen oder wenigen Wochen Abstand mit der neuesten Kernelgeneration mit – allein Mitte bis Ende 2012 von 3.4.0 bis 3.6.11. In Abbildung 3, die die wichtigen Ereignisse bei den beobachteten Distributionen auf einem Zeitstrahl visualisiert, fehlen die meisten Fedora-Kernel-Ereignisse; andernfalls wäre die Grafik von blauen F-Logos übersät.

Ben Hutchings von Debians Kernel-Team wies die Redaktion auf Nachfrage darauf hin, dass manche Kernelbugs und CVEs nicht auf Squeeze zutreffen, da diese Debian-Release manche Features gar nicht unterstützt, etwa das Dateisystem Btr-FS. Das September-Update enthält zahlreiche Fixes für Sicherheitsprobleme und Bugs sowie einige Verbesserungen.

Ubuntu bringt es in diesem Zeitraum auf sechs Security-relevante Updates, allerdings für seinen Kernel 3.2. Daneben verfolgen die Ubuntu-Entwickler die offizielle Kernelentwicklung und binden deren Bugfixes sowie die Unterstützung für neue Hardware ein.

Abbildung 3: Security- und Bugfixes sowie funktionserweiternde Updates bei den betrachteten Distributionen im zweiten Halbjahr 2012.

Mittendrin ein Major-Update

Suses Umstieg auf eine neue Kernelversion innerhalb einer SLES-Release ist für Enterprise-Distributionen ungewöhnlich. Laut Olaf Kirch, Abteilungsleiter SLES-Engineering, ist das Upgrade dem “Spannungsfeld zwischen Konstanz und Aktualität” geschuldet. Die Kunden erwarten zum einen ein gleichbleibendes Userland-ABI als Basis ihrer Anwendungen. Zum anderen wünschen sie Unterstützung für neue Hardware und Performancesteigerungen. Zudem tauchen immer wieder Sicherheitslücken auf, die der Distributor beheben muss. In der Regel erledigen die Entwickler das durch Backports, das heißt die Integration reparierten oder verbesserten Codes in die bestehende Softwarebasis.

Im Lauf der Zeit entfernt sich der verwendete Kernel immer weiter von der offiziellen Entwicklung. Das macht Backports wohl immer schwieriger, umfangreicher – und riskanter. “Man fängt sich in Backports grundsätzlich Performance-Regressionen ein”, sagt Kirch. Mit der Vorbereitung auf SLES 11 SP2 begannen die Nachteile der Backports zu überwiegen, und sie machte die Vorteile eines Kernel-Upgrades deutlich: Der neue Kernel würde eine saubere Codebasis für die weitere Wartungsperiode bereiten.

Der im Februar 2009 ausgerollte Kernel 3.0 brachte als Dreingabe noch die Lightweight-Virtualisierung Linux Containers (LXC) mit. Zudem konnte Suse als erste Distribution kommerziellen Support für das neue Dateisystem Btr-FS anbieten. Für den Beobachtungszeitraum dieses Artikels gibt es zwei weitere Security- und Bugfix-Updates zu vermelden.

Die Firefox-Politik, Debian mit Iceweasel

Noch mehr los als beim Kernel war im zweiten Halbjahr 2012 bei Firefox. Das Projekt hat mehrere Majorupdates veröffentlicht und auch Securityfixes. Die Abbildung 4 zeigt nur das letzte Vierteljahr – mehr gibt der Platz nicht her. Wie beim Kernel machen die Community-Distributionen mit leichter Verspätung jede Aktion von Mozilla mit. RHEL, SLES (beide Firefox 10.0) und Debian (Iceweasel 3.5.16) verhalten sich gegensätzlich und spielen nur Securityfixes ein.

Abbildung 4: Bei Firefox war in den Repositories so viel los, dass hier nur das letzte Vierteljahr 2012 darstellbar ist.

Ermessensspielraum bei Infrastruktur-Software

Die Entscheidungen – möglicherweise auch die Auslastung – der Paketmaintainer sind ganz unterschiedlich. Das ist am Beispiel des IMAP-Servers Dovecot zu sehen. Im Beobachtungszeitraum für diesen Artikel traten keine Sicherheitsprobleme mit der Software auf. Die Betreuer standen also nicht unter Zugzwang. Bei Debian und Open Suse tat sich folgerichtig gar nichts beim Dovecot-Paket, in SLES ist es nicht enthalten. Ubuntu und Fedora aktualisierten das Paket nach ein paar Monaten, und Red Hat besserte eine ältere Version nach (Abbildung 5).

Doch selbst wenn Sicherheitslücken vorliegen, kann die Reaktion der Distributionen unterschiedlich ausfallen. Eine Anfälligkeit von HTTPS-Verbindungen mit Apache 2 (CVE-2012-4929) war Anfang November 2012 nur Ubuntu einen Security-Fix für das Paket wert. Debian folgte am Ende des Monats. Red Hat vermeldete das Risiko zwar und schätzte es als “mäßig” ein, lieferte aber kein ausgebessertes Paket. Bei SLES, Open Suse und Fedora geschah gar nichts (Abbildung 6).

Wie bei den eben besprochenen Infrastruktur-Komponenten verhält es sich beim Datenbankserver MySQL. Nicht nur, dass wenig passierte, die Distributionshersteller hatten auch beim Nachziehen die Ruhe weg (Abbildung 7).

Abbildung 5: Ohne entdeckte Sicherheitslücken verlaufen Updates in gemächlichem Tempo.

Abbildung 6: Ein Apache-2-Loch stopften nur die Distributionen Ubuntu und Debian.

Abbildung 7: Beim Datenbankserver MySQL behoben die Distributionen vordringlich Security-Probleme.

Ein Schlaglicht

Dieser Test kann unmöglich ein vollständiges und damit gerechtes Bild zum Thema Maintenance zeichnen – moderne Distributionen bestehen aus viel zu viel Software, die in Breite und Tiefe selbst mit Unterstützung von Tools nicht untersuchbar ist, um wissenschaftlichen Kriterien zu genügen. Wohl aber vermag die untersuchte Stichprobe Tendenzen aufzuzeigen: Der Umfang der zu bewältigenden Aufgaben der Paketmaintainer scheinen sehr unterschiedlich verteilt zu sein – von alle paar Monate ein paar Handgriffe bis zum Kampfeinsatz im Wochenrhythmus.

Bei den Community-Linuxen, die den Upstream von Firefox nachvollziehen, scheint Fedora zeitlich die Nase vorne zu haben, der Nächste ist Open Suse und dann Ubuntu. Debian kocht hier mit Iceweasel ein eigenes Süppchen.

Beim Kernel schlägt sich Ubuntu auf die Seite der Versionsstabilen, während Fedora am progressivsten vorgeht. Es mag an der Auswahl der untersuchten Pakete liegen, aber den vielleicht erwarteten Sachzusammenhang zwischen Debian-Updates und denen des Debian-Derivats Ubuntu vermag dieser Test nicht zu belegen. Jenseits der Pakete, bei denen es hoch hergeht, läuft die Arbeit der Paketpfleger in ruhigen Bahnen, in so ruhigen, dass mancher Securityfix schleppend oder nie den Weg in manche Distribution findet.

download.use_deltarpm = true