Die teuren Managementwerkzeuge der Enterprise-Systeme versprechen Admins zentral gesteuerte, reibungslose Updates und sorgenfreien Rundumservice. Hält die Technik unter der Haube von SLES, RHEL und Ubuntu dieses Versprechen oder leistet sie kaum mehr als die Holzklasse normaler Distributionen?
Damit er ruhig schlafen kann, wünscht sich der typische Admin meist nur zwei Dinge: Die von ihm überwachten Systeme mögen funktionieren und keine zusätzliche Arbeit verursachen. Zum anderen sollen die Systeme sicher sein und entsprechend korrigierte Pakete eventuelle Sicherheitslöcher möglichst automatisch korrigieren.
Herzinfarktgefahr
Wer aber jetzt glaubt, die regelmäßige, automatische Installation von Security-Fixes sei dafür ausreichend, der sieht sich getäuscht. Erfahrene Admins können ein Lied davon singen, dass Updates auch bei Enterprise-Systemen viel mehr Faktoren umfassen als “einfach mal ein neues Paket einspielen”.
Im Unternehmensbereich spielen die Enterprise-Distributionen mit kostenpflichtigen Subskriptionen eine wichtige Rolle. Der Deal dabei lautet: Suse, Red Hat oder Canonical kümmern sich recht zügig um zeitnahe Fixes und versprechen eine ausreichend lange Lebenszeit ihrer Systeme, damit der Kunde nicht zu oft ein komplettes Distributions-Upgrade bewältigen muss ([1], [2]).
Upgrades und Updates
In ausgewachsenen IT-Setups erreicht das flächendeckende Upgrade von einer Version einer Distribution auf die nächste nicht selten biblische Ausmaße. Mit Enterprise-Distributionen erkaufen sich Unternehmen die Sicherheit, dass ein derart großes Update nur alle paar Jahre ansteht. Dann aber geht’s zur Sache: Meist kommt gleich die gesamte Applikation auf den Prüfstand und die Migration zieht sich über Monate.
Ähnliche Faktoren wie bei Distributions-Upgrades betreffen aber auch die vielen regulären Updates im Alltag. Technisch ist das zwar kein Problem, bieten doch alle Paketmanager und deren GUIs entsprechende Funktionen. Doch dass bei einem unbewachten Upgrade einiges passieren kann, zeigt ein eigener Artikel in dieser Titelstrecke.
In Enterprise-Setups kommen aber weitere Gefahren hinzu: Längst nicht jede Applikation übersteht den Reboot ohne Probleme, noch schwieriger wird es, wenn sich Setups über mehrere Server erstrecken. Wer Clustersoftware einsetzt, möchte zudem verhindern, dass der Clustermanager aus dem Tritt gerät und beim Reboot von einem Knoten ein Fail-over-Festival startet, obwohl die Admins eigentlich doch “nur ein paar Updates” eingespielt haben.
Die Liste der Dinge, die bei einem automatischen Upgrade schiefgehen können, ist lang und führt unmittelbar zu der Frage, welche Möglichkeiten denn Enterprise-Distributionen bieten, um aus dieser Zwickmühle auszubrechen, ohne den Administrator mit Arbeit zu überhäufen.
Dieser Artikel beschäftigt sich im weiteren Verlauf mit den drei großen Enterprise-Distributionen (RHEL, SLES und Ubuntu), für die der Hersteller ein zentrales Managementwerkzeug für Upgrades nebst entsprechendem Support zur Verfügung stellt.
Red Hat Customer Portal
Red Hat gilt bei Spöttern als jene Firma, die die Namen ihrer Produkte grundlos, aber in regelmäßigen Abständen ändert. Was bis vor nicht allzu langer Zeit noch das Red Hat Network war, firmiert mittlerweile unter dem Begriff Red Hat Customer Portal (RHCP, Abbildung 1, [3]). Die Funktionalität blieb allerdings weitgehend identisch.

Abbildung 1: Das frühere Red Hat Network mit seinen Satellite-Servern bringt jetzt als Red Hat Customer Portal die Updates zu den Kunden.
Nur wer ein “echtes” Red Hat mit Supportvertrag betreibt (Subscription), wird das Customer Portal überhaupt zu Gesicht bekommen. Centos, Scientifix Linux oder ein anderer RHEL-Klon bleiben außen vor. Wer aber ein RHEL inklusive Lizenz besitzt, muss allerdings – und das ist im Vergleich zu Suse und Ubuntu durchaus erwähnenswert – nicht zusätzlich Geld abliefern, damit er die Managementfunktionen vom Red Hat Customer Portal nutzen kann. Ist ein Rechner im Portal registriert, lässt er sich per Mausklick aus der Weboberfläche heraus entsprechend verwalten. In diese Verwaltung fallen auch die Patches, die Red Hat “Errata” getauft hat.
Der Hersteller erwähnt in seiner Dokumentation übrigens ausdrücklich die innere Zerrissenheit, der Admins beim Thema Security-Updates ausgesetzt sind, und empfiehlt letztlich, im produktiven Umfeld Updates zu testen, bevor sie den Weg auf das System finden. Hält der Administrator ein Sicherheitsupdate für hinreichend stabil, um es zu installieren, kann er das mit dem Red Hat Customer Portal per Klick auf vielen verschiedenen Rechnern gleichzeitig tun.
Das Portal nutzt die typische Staffelung, die alle Systeme in diesem Vergleich aufweisen, und teilt dem Admin mit, ob relevante Updates vorliegen oder welche der insgesamt vorhandenen Updates für das jeweilige System sinnvoll sind. Stimmt der Admin dem Vorschlag zu, rattert das verwaltete System sofort los und aktualisiert seinen Softwarebestand.
Insgesamt erweist sich das RHCP als unspektakulär. Die von Red Hat beworbene Update-Funktionalität ist vorhanden und steht dem Admin bei Bedarf zur Verfügung. Automatische Updates kann er anhand verschiedener Kriterien konfigurieren.
Suse Manager
Anders als bei Red Hat und Ubuntu ist bei dem Linux aus Nürnberg kein Dienst zu finden, der das Servermanagement über ein von Suse gehostetes Werkzeug erlaubt. Während man sich als Admin bei Ubuntus Landscape oder dem Red Hat Network auf der jeweiligen Website einloggt und die gewünschten Änderungen vornimmt, kommt der Suse Manager [4] als fertige Appliance daher, die lokal laufen muss.
Wer sich von dem Schock erholt hat, den die Rechnung für den Manager erst mal auslöst (die Einzellizenz schlägt laut Liste mit satten 11 000 Euro zu Buche), schnappt sich ein lokales System und installiert darauf den Manager. Will der Admin dafür kein Blech opfern, dann betreibt er ihn in einer virtuellen Maschine. Bei der Kalkulation darf er eines nicht außer Acht lassen: Zusätzlich zu den Lizenzen, die für den Manager notwendig sind, kommen noch die Lizenzen für die SLES-Systeme selbst – ohne die gibt es erst gar keine Update-Repositories, aus denen die Aktualisierungen sinnvoll zu beziehen wären.
Wer jedoch lizenzierte SLES-Systeme an dieser Instanz des Suse Manager anmeldet (Abbildung 2), kann sich die umfassenden Managementfunktionen zunutze machen. Vollständiges Monitoring ist ebenso enthalten wie die Möglichkeit, plattformweit über den Scheduler Events zu planen, die dann auf den dafür ausgewählten Servern stattfinden.

Abbildung 2: Automatische Updates mit Suse Manager sind möglich und bieten dann eine zentrale Verwaltung – sobald man den Schock nach Erhalt der Rechnung überwunden hat.
Das Thema Update-Management nimmt bei Suse einen eigenen Platz ein, wobei Suse lieber den Begriff “Compliancy Management” nutzt. De facto geht es aber um das Gleiche wie bei der Konkurrenz: Das automatische Einspielen der wichtigsten Updates, die bei Suse traditionell “Patches” heißen.
Ein solcher Flicken ist im Grunde eine Liste aktualisierter Pakete. Die verfügbaren Patches für ein System listet der Manager übersichtlich auf und lässt den Admin zwischen verschiedenen Optionen entscheiden.
Suse Manager unterteilt bereitstehende Patches in drei Stufen mit ansteigender Relevanz:
- Mit einem Ausrufezeichen versehene kritische Security-Patches.
- Bugs, die Fehler korrigieren, zum Beispiel Crashes in Desktopsoftware.
- Verbesserungen und Optimierungen an Paketen, etwa Versions-Upgrades.
Für einzelne Rechner legen Administratoren fest, ob Pakete dort per automatischem Update einzuspielen sind, und wenn ja, welches Level ein Patch haben muss, damit es sich für das Upgrade auf dieser Maschine qualifiziert.
Suse Manager selbst ist ebenfalls fleißig und erstellt eine Vorauswahl der “Relevant Patches”, die auf jedes einzelne System zugeschnitten ist. Per Klick lässt sich dann bestimmen, ob die festgelegten Kriterien Updates automatisch auf das System bringen oder ob die Installation vom Admin händisch anzustoßen ist. Suse Manager beherrscht übrigens auch das genaue Gegenteil: Wenn der Admin mal viel Zeit hat oder sich Ärger ersparen möchte, legt er per Klick im Manager-Fenster Patch für Patch fest, welches seinen Weg auf den Server finden soll und welches nicht.
Insgesamt macht der Suse Manager einen sehr flexiblen Eindruck, der hohe Preis scheint einigermaßen gerechtfertigt.
Ubuntu Landscape
Den jüngsten Dienst für Enterprise-Systemverwaltung bietet Ubuntu an: Landscape [5]. Wer bei Canonical einen Supportvertrag kauft, kriegt auf das Verwaltungswerkzeug Zugriff. Im Grunde ist dessen Funktionalität ganz ähnlich der von Red Hat und Suse, auch wenn Landscape unter der Haube natürlich andere Tags nutzt und einen anderen Arbeitsablauf praktiziert (Abbildung 3).
Unter dem Menüpunkt »Packages« lassen sich aus der Ferne Pakete installieren und löschen. Sind Sicherheitsupdates verfügbar, so weist Landscape über eine entsprechende Nachricht darauf hin und ermöglicht es dem Admin, später eine entsprechende Auswahl zu treffen. Der gesamte Vorgang ist auch für viele verschiedene Rechner gleichzeitig nutzbar, sodass selbst ein Update von Hunderten Rechnern in der Serverfarm keine Klick-Orgien verursacht.
Fazit: Kein Kinderspiel
Egal was das Marketing verspricht: Automatische Security-Updates sind und bleiben eine wackelige Angelegenheit, die der Admin mit Bedacht handhaben sollte. Weil die Gründe dafür nicht nur rein technischer Natur sind, tun sich auch die Hersteller schwer.
Immerhin schaffen es RHCP, Landscape und Suse Manager, die Updates von Systemen zentral und hinter einem hübschen GUI versteckt zu steuern. Wer gern klickt, kommt hier voll und ganz auf seine Kosten. Einen echten technischen Mehrwert bietet aber von den vorgestellten Systemen eigentlich keines.
Sinnfrei, teuer, aber schick
Dass automatische Updates in vielen Setups gar nicht sinnvoll sind, daran können die Werkzeuge ohnehin nur wenig ändern. Die von den großen Enterprise-Distributionen gebotenen Update-Funktionen schaffen es nur selten, das beträchtliche Preisschild vergessen zu machen. Wer Red Hat nutzt, hat in der Regel für den Support ohnehin schon gezahlt und somit Zugriff auf das Red Hat Customer Portal. Bei Suse oder Ubuntu zahlt er für die gebotenen Managementfeatures extra, und das nicht zu knapp. Etwas behutsamer geht Canonical zu Werke, wo Landscape ebenfalls Bestandteil der Support-Subscriptions ist. Die kosten bei allen Kandidaten wenige Hundert Euro pro Maschine.
Im Hinblick auf die Qualität der gebotenen Features war bei den drei Probanden kein nennenswerter Unterschied zu erkennen; Suse Manager, das Red Hat Customer Portal und Ubuntu Landscape sind nahezu identisch in Funktionsumfang und Flexibilität, zumindest was die Konfiguration angeht. Wer nicht bereits einen der Dienste für das Management der eigenen Systeme nutzt, braucht sich derzeit auch keine Gedanken darüber zu machen. Vielmehr darf er einen Blick auf Linux-Standard-Tools wie Puppet oder Chef werfen, die ihm viel Arbeit abnehmen können (siehe Kasten “Puppet und Chef”) und Systeme unterschiedlicher Hersteller verwalten.
Puppet und Chef
Wer keinem der großen Distributoren Geld für ein zentrales Managementwerkzeug zahlen möchte, muss auf ein solches Tool nicht zwangsläufig verzichten. Die freien Alternativen Puppet und Chef bieten sich insbesondere dort auch für Upgrades an, wo ohnehin schon eines der beiden Werkzeuge zum zentralen Konfigurationsmanagement im Einsatz ist.
Unterschiedliche Systeme verwalten
Ein weiterer Vorteil: Nur so lassen sich unterschiedliche Distributionen zentral betreuen. Anders als die kommerziellen Tools suggerieren, ist es durchaus möglich, Systeme von Red Hat, Suse und Ubuntu gemeinsam unter einem Dach zu verwalten. Theoretisch lässt sich so über die Grenzen der Systeme hinweg beispielsweise ein Security-Update anstoßen, wobei Puppet und Chef auf den jeweiligen Systemen das für die Distribution spezifisch Nötige erledigen. In der Praxis bieten »dpkg« -gestützte Distributionen mehr Freiheiten in der Update-Verwaltung als ihre RPM-Kollegen.
Puppet-Apt – der Apt-Dater und das Kochbuch für die Chef-unattended-Upgrades
Eine besonders hübsche Kombination ist die aus Puppet und Apt auf Ubuntu oder Debian: Mittels »puppet-apt« [6] lässt sich die Paketverwaltung via Apt unmittelbar aus Puppet heraus steuern, und über »apt-Dater« [7] erhält »puppet-apt« direkte Angaben darüber, ob Pakete automatisch zu aktualisieren sind. Zur Not stoßen Admins über diese Kombination auch manuelle Updates an, etwa wenn ein dringendes Sicherheitsproblem auftaucht.
Wer auf Chef statt auf Puppet setzt, kommt bei Debian-Systemen über das »chef-unattended-upgrades« -Cookbook [8] weiter. Es nutzt auf Debian-Systemen zwar auch nur die »unattended-upgrades« -Funktion, erlaubt es aber, wenigstens die Einstellungen zentral zu steuern, also zum Beispiel, welche Pakete von den Unattended Upgrades denn ausgenommen sein sollen und welche nicht.
Puppet-yum: Yum automatisieren auf Enterprise-Linux
Puppet-yum [9] unterstützt auf Enterprise-Systemen die Automatik von Yum. Über eine zentrale Konfigurationsdatei stellt der Admin ein, ob Yum Updates per Crontab durchführen soll oder nicht. So erlaubt es das Chef-Modul, zum Beispiel nach entsprechenden Staging-Tests die automatischen Updates zu aktivieren und so zeitlich gesteuert die Hosts auf den neuesten Stand zu bringen. Puppet-yum unterstützt aktuelle Red-Hat-Enterprise-Linux-Systeme, wobei die hiermit kompatiblen Distributionen freilich eingeschlossen sind.
Infos
- Titelthema zur Update-Qualität von Distributionen, “Paketservice im Test”: Linux-Magazin 03/13 S. 22 bis 38
- Markus Feilner, “Und läuft und läuft”: Linux-Magazin 03/13, S. 30
- Red Hat Customer Portal: https://access.redhat.com/home
- Suse Manager: https://www.suse.com/products/suse-manager/
- Ubuntu Landscape: http://www.canonical.com/enterprise-services/ubuntu-advantage/landscape
- Puppet-apt von Example42 mit Apt-Dater-Support: https://github.com/example42/puppet-apt
- Apt-Dater: https://github.com/DE-IBH/apt-dater
- Chef Unattended Upgrades Cookbook: https://github.com/jeremyolliver/cookbook-unattended-upgrades
- Puppet-yum von Example42: https://github.com/example42/puppet-yum






