Open Source im professionellen Einsatz
Linux-Magazin 09/2013
© Alterfalter, Fotolia.com

© Alterfalter, Fotolia.com

Unattended Upgrades: Paketmanager im Vergleich

Automatisch sauber

,

Manuelle Software-Updates begleiten Admins durch den Tag. Dabei versprechen die Paketmanager diese Arbeit zu automatisieren. Der Artikel vergleicht die großen Distributionen und testet, wie viel Reinheit die mit den Systemen gelieferten Tools wirklich bringen – und welche Gefahren dabei entstehen.

464

In einem unterscheiden sich proprietäre oder offene Betriebssysteme kaum – egal ob der Anwender Windows, Mac OS oder das freie Linux einsetzt, stets ist er mit immer mehr Updates und Patches in immer kürzeren Abständen konfrontiert. Ob Bugfixes zu installieren, Sicherheitslöcher zu stopfen sind oder die mit einer neuen Programmversion lange erwartete Funktion endlich kommt: In schöner Regelmäßigkeit müssen Anwender und Admins Updates einspielen, in vielen Fällen sogar täglich.

Verführerische Versprechen

Einladend glänzen moderne Linux-Distributionen mit Schaltflächen, die wie Waschmaschinen eine Vollautomatik versprechen und den Anwender glauben lassen, der Rechner sei danach auf dem neuesten Stand, er kümmere sich ganz alleine darum, brauche keine Hilfe und sei durchaus in der Lage, mit heiklen Softwarepaketen umzugehen.

Doch ganz so einfach funktionieren Unattended Updates und Upgrades in der Praxis selten, vor allem wenn eigene oder exotische Software im Spiel ist. Aber nicht nur dann ist es immer noch keine gute Idee, ein Produktivsystem, einen Server oder gar eine ganze Rechnerfarm alleine, unbeaufsichtigt und vollautomatisch updaten oder upgraden zu lassen. An einem Desktop, mit dem der Benutzer Fehlermeldungen erhält und eingreifen oder den Admin anrufen kann, mag das anders aussehen.

Immer wieder tauchen Abhängigkeiten auf, die das Update scheitern lassen und so schlimmstenfalls für Produktionsausfälle sorgen – nicht nur bei selbst geschriebenen Applikationen. Um eine Testumgebung kommt der verantwortungsbewusste Admin nicht herum, doch kann die dank Virtualisierung heutzutage in Form von virtuellen Maschinen auch auf seinem Laptop laufen.

Noch besser ist es jedoch, angesichts von Kernelpatches und eventuellen proprietären Treibern, die Testsysteme aus identischer Hardware aufzubauen wie die produktiven Maschinen – sonst könnte es passieren, dass zwar alle Updates sauber durchlaufen, der Paketmanager keine Fehler meldet, aber das System einfach nicht mehr booten kann.

Hardware in Gefahr

Das kann allerdings auch andere Gründe haben, so wie 2004, als Suse schlicht beim Kernelupdate den XFS-Treiber fehlerhaft verbaut hatte [1], oder vor wenigen Wochen, als ein Bug in den Updates von Systemd und Journald Fedora-19- und -20-Systeme an den Rand eines Kollapses brachte [2].

Dabei geriet sogar Hardware in Gefahr: Im Systemprotokoll landeten Unmengen an alten Einträgen. So schnell es CPU und I/O des Systems eben hergaben, schrieben die Daemons Vierzeiler ins Log – und trieben Festplatten- und CPU-Last an die Grenzen. Auf unüberwachten, lüfterlosen Geräten war da schnell die Hardware an Grenzen. Abhilfe schaffte nur ein manuelles »yum downgrade rsyslog« , ein Eintrag in die Blacklist (damit nicht das nächste Update wieder den gleichen Fehler verursacht) – und dann warten, bis die Community den Bug behob.

Auf baugleicher Hardware und mit identischen Setups kann der Admin solche Fehler weitgehend ausschließen. Herstellerpatches lassen sich ausprobieren, ohne dass sie Schaden anrichten, bevor der Admin sie zum Ausrollen freigibt.

Diesen Artikel als PDF kaufen

Express-Kauf als PDF

Umfang: 7 Heftseiten

Preis € 0,99
(inkl. 19% MwSt.)

Linux-Magazin kaufen

Einzelne Ausgabe
 
Abonnements
 
TABLET & SMARTPHONE APPS
Bald erhältlich
Get it on Google Play

Deutschland

Ähnliche Artikel

  • Volatility 2.3

    Spurensuche im RAM, das ist die Domäne von Volatility. Das Forensiker-Werkzeug hilft Admins dabei, zu analysieren, was auf einem System schiefgelaufen ist. Für Rückschlüsse auf Malware, laufende oder gar kompromittierte Dienste reicht ihm meist ein Abbild des Arbeitsspeichers.

  • RPMs signieren

    Sichere Software entwickeln ist das eine. Genauso wichtig ist es, die Programme auf verlässlichen, nachvollziehbaren Wegen zum Anwender zu bringen. Dieser Artikel zeigt, wie Entwickler RPMs erstellen, signieren, in ein Repository stellen und sie vor Fehlern oder Manipulationen durch Dritte schützen.

  • Apt intern

    Wer auf Debian- und Ubuntu-Rechnern ein Upgrade anschiebt, setzt im Hintergrund eine Reihe unsichtbarer Mechanismen in Gang, die sich gegenseitig bedingen und die Apt-Spezialist und -Maintainer Michael Vogt in diesem Artikel im Detail erklärt.

  • Uranos

    Mit dem Durchbruch der Virtualisierung sind Menge und Artenvielfalt der Betriebssysteme, die ein Admin zu installieren hat, nicht eben geringer geworden. Ein Server mit dem schönen Namen Uranos will dem Verwalter größerer Betriebssystem-Zoos wieder Freiräume verschaffen.

  • Kern-Technik

    Das Rahmenwerk DKMS ordnet für Anwender und Entwickler Module so, dass sie auch nach einem Kernupdate noch laufen. Als Bonus schnürt das Tool sogar Installationspakete für Distributionen.

comments powered by Disqus

Stellenmarkt

Artikelserien und interessante Workshops aus dem Magazin können Sie hier als Bundle erwerben.