Nach Sicherheitsimplikation und Wichtigkeit sortierte Patches, die Möglichkeit zum Zurückrollen von Updates – OpenSuse bietet beim Thema Softwareaktualisierungen einige Besonderheiten.

“Never change a running system”, hieß es in früheren Zeiten. Doch damals bezweifelten Privatanwender beim Thema IT-Angriffe noch mit einigem Recht, dass es jemand gäbe, der sie angreifen wolle. Die Welt hat sich weitergedreht, Trojaner mit Erpressersoftware sind an der Tagesordnung.

Ebenso liefern aber täglich auch die Update-Repositories von OpenSuse Bug- und Security-Fixes aus, die man am besten zeitnah einspielt. Dass die Welt nicht perfekt ist, gilt aber auch beim Update-Vorgang selbst: Wer lange genug mit Linux arbeitet, dürfte es schon erlebt haben, dass Updates neue Probleme heraufbeschworen und im Extremfall vielleicht sogar das ganze System lahmlegten.

Diese OpenSuse-Tipps geben Ratschläge, wie Sie Probleme bei einem Update vermeiden oder wieder loswerden, sei es eine einzelne streikende Anwendung oder ein beschädigtes Gesamtsystem.

More risk, more fun

OpenSuse liegt bekanntlich in zwei Spielarten vor: dem traditionellen Leap [1], dessen Updates lediglich Fehlerkorrekturen liefern, und der Rolling-Release-Ausgabe Tumbleweed [2], die neue Softwareversionen zügig nach Erscheinen ins laufende System einspeist. Leap-Anwender müssen auf diese Neuerungen bis zum etwa jährlich erfolgenden Release einer neuen Leap-Fassung warten.

Tumbleweed-Anwender arbeiten also mit einem aktuelleren System. Dafür sind sie häufiger von sogenannten Regressionen betroffen (Abbildung 1). So nennt man es, wenn nach einem Versions-Update Programmfunktionen Probleme bereiten, die vorher tadellos ihren Dienst taten. Dass sich so etwas nicht immer ganz vermeiden lässt, liegt daran, dass Entwickler sich erfahrungsgemäß schwertun zu überblicken, welche Auswirkungen Neuerungen auf bestehende Teile der Software haben.

Abbildung 1: Unter OpenSuse Leap funktioniert die Notizfunktion von Kmail (rechts). Unter Tumbleweed stürzt dabei im Moment das Mail-Programm ab, wie der Bug-Report links berichtet.

Bevor aufgefrischte Programmpakete in den Tumbleweed-Repositories aufschlagen, haben sie keinen ausgedehnten Praxistest hinter sich. Ein automatisierter Test [3] – immerhin etwas, was OpenSuse anderen Rolling-Release-Distributionen voraus hat – verhindert Totalausfälle, wie etwa, dass ein Programm gar nicht erst startet. Leap-Anwender betreffen Regressionen seltener: Bis neue Softwareversionen ihr System erreichen, sind Fehler oft schon entdeckt und ausgebügelt.

Kleinigkeiten wie fehlende Notizmöglichkeiten in Kmail dürften die meisten Tumbleweed-Anwender verschmerzen. Wenn jedoch Bugs auftreten, die die Arbeit mit dem System empfindlich stören, hält Tumbleweed zwei Mechanismen bereit, um zu einem früheren Systemzustand zurückzukehren: Dateisystem-Snapshots und Schnappschüsse des Tumbleweed-Software-Repositorys.

Eingeschnappt

OpenSuse richtet bei der Installation ein fertig konfiguriertes System ein, das den alten Systemzustand vor allen per YaST ausgeführten Konfigurationsänderungen und Software-Updates festhält (Abbildung 2). Die Teile des Dateisystems, die sich nicht verändert haben, belegen dabei nur einmal Speicherplatz.

Abbildung 2: Im Verzeichnis .snapshots/ lassen sich die Zustände der Root-Partition vor und nach jeder Softwareinstallation wie ein vollständiges Dateisystem auslesen. Dank einer Differenzfunktion im Dateisystem Btrfs läuft bei der Speicherbelegung dennoch nur die Summe aller Veränderungen auf.

Es gibt ein YaST-Modul Dateisystemschnappschuss (Abbildung 2), das allerdings nur dafür gedacht ist, den Inhalt von Schnappschüssen mit dem des aktuellen Systems zu vergleichen sowie einzelne Dateien zurückzudrehen, zum Beispiel nach Konfigurationsänderungen. Möchten Sie dagegen ein komplettes Software-Update rückgängig machen, dann verwenden Sie dazu das Kommandozeilenwerkzeug Snapper (Abbildung 3), und zwar stets als Root.

Abbildung 3: Das Kommandozeilen-Tool Snapper zeigt genauere Daten zu Dateisystem-Snapshots an und kann außerdem das Root-System vollständig auf einen früheren Zustand zurücksetzen.

Das Kommando snapper list zeigt eine Liste aller Snapshots. Vorher-nachher-Schnappschusspaare (Typ: pre/post) mit der Beschreibung zypp(zypper) entstehen beim Ausführen von Zypper, dem Kommandozeilenwerkzeug zur Softwareverwaltung. Das grafische YaST-Modul Software installieren oder löschen signiert stattdessen mit yast sw_single. Der Befehl snapper rollback Snapshot-Nr. setzt beim nächsten Neustart das System auf den Zustand des Schnappschusses mit der angegebenen Nummer (Spalte # in der Ausgabe von snapper list) zurück.

Vor dem Rollback hält Snapper noch einmal den aktuellen Systemzustand fest. Das ist schon deswegen sinnvoll, weil das Tool keine Rücksicht auf Hintergrunddienste wie PostgreSQL- oder MySQL-Datenbanken nimmt. Sie können sich also nach dem Zurückdrehen in einem inkonsistenten Zustand befinden. Macht also das zurückgedrehte System mehr Probleme als vor dem Rollback, können Sie die Wiederherstellung des alten Zustands noch einmal rückgängig machen.

Geschichtswissenschaft

Eine große Einschränkung bei einem Tumbleweed-System in einem historischen Zustand ist, dass sich hier keine neue Software mehr installieren lässt: Die Repositories mit allen ihren Bibliotheken sind weitergerollt (siehe Kasten “Paketabhängigkeiten”). Ähnlich wie bei einem Update nach einer langen Aktualisierungspause führt dann schon die Installation eines einzelnen Pakets zu einer kleinen Update-Orgie, um die Abhängigkeiten des neuen Pakets zu erfüllen (Abbildung 4). Doch gerade das wollen Sie ja vermeiden.

Abbildung 4: Die Aktualisierung des einzelnen Pakets plasma5-session zieht als Automatische Änderungen (sprich: Paketabhängigkeiten) einen Gutteil der KDE-Desktop-Umgebung mit. Partielle Updates sind unter Tumbleweed daher praktisch nicht möglich.

Aus diesem Grund entstand das Kommandozeilen-Tool Tumbleweed (Pakettumbleweed-cli), das einen anderen Ansatz verfolgt: Die Tumbleweed-Maintainer archivieren die Repositories, bevor sie deren Inhalt auffrischen. Das Tool Tumbleweed bindet diese Repository-Snapshots ein, ohne Sie mit Details wie der URL zum Snapshot zu belasten. Sie rufen es stets mit Root-Rechten auf.

Der Befehl tumbleweed list zeigt die verfügbaren Snapshots und ihr Erstellungsdatum im Format Jahr Monat Tag. Vor der ersten Verwendung rufen Sie tumbleweed init auf. Anschließend setzen Sie bei Bedarf mit tumbleweed switch --install Snapshot das ganze System auf den Versionsstand des Snapshots zurück (Abbildung 5). Neue Pakete installiert der Paketmanager ab sofort ebenfalls in einer zu diesem Snapshot passenden Version. Damit befindet sich nicht nur das System auf einem historischen Stand, sondern auch die eingebundenen Tumbleweed-Repositories.

Abbildung 5: Das Kommando tumbleweed switch stellt die eingebundenen Softwarerepositories vom Haupt-Repository auf Snapshots mit dem Versionsstand von vor einigen Tagen oder Wochen um.

Prinzipiell wäre es möglich, den Befehl tumbleweed switch ohne den Parameter --install aufzurufen und dann mit Zypper oder der grafischen Softwareverwaltung nur einzelne Pakete aus dem herabgestuften Repository zu installieren. Der Paketmanager wird aber je nach Anzahl der Abhängigkeiten weitere Pakete downgraden. Bei KDE-Paketen betrifft das meist einen guten Teil der Desktop-Umgebung, bei unabhängigen Programmen mit etwas Glück nur wenige Pakete. Sie verlassen mit diesem Vorgehen jedoch definitiv das getestete Terrain.

Beim Rückstufen der Repositories verlieren Sie zudem die Möglichkeit, aktuelle Sicherheitsaktualisierungen einzuspielen. Obendrein reichen die Snapshots nur einen Monat zurück, dann entfernen die OpenSuse-Maintainer sie. Sie können das System dann zwar weiter unangetastet im bestehenden Zustand belassen, das Installieren weiterer Pakete funktioniert aber erst nach einem Switch auf einen noch online vorgehaltenen Schnappschuss.

Die Repository-Snapshots sind dafür gedacht, dass Sie nach der Rückkehr zu einem funktionierenden Tumbleweed-Snapshot eine beschränkte Zeit lang darauf warten können, dass die OpenSuse-Maintainer zusammen mit den Entwicklern der von Bugs betroffenen Software eine Lösung finden. Allerdings synchronisiert das von wohl den meisten OpenSuse-Anwendern für Anwendungen und Codecs aus dem Multimediabereich genutzte Packman-Repository (Abbildung 6) nur auf den neuesten Tumbleweed-Snapshot, sodass sich hier fast zwangsläufig ebenfalls Abhängigkeitsprobleme ergeben.

Abbildung 6: Das Packman-Repository mit nicht aus lizenzrechtlichen Gründen beschnittenen Multimediapaketen synchronisiert sich mit dem aktuellen Stand von Tumbleweed, jedoch nicht mit den per tumbleweed verfügbaren historischen Snapshots.

Zum aktuellen Zustand der Distribution gelangen Sie jederzeit mit tumbleweed update zurück, tumbleweed uninit stellt die vor dem Aufruf von tumbleweed init vorhandenen Repositories wieder her. Anschließend nutzen Sie wieder Zypper, um Upgrades einzuspielen.

Stolperfalle

Das bei Tumbleweed wie unter Leap in der Taskleiste zu findende Icon für Softwareaktualisierungen funktioniert auf den ersten Blick auch bei der Rolling-Release-Variante wie gewohnt. Längerfristig führt sein Einsatz allerdings zwangsläufig zu Problemen, da es einfach nicht mit allen Szenarien umgehen kann, die bei Tumbleweed-Updates auftreten.

Ärgerlicherweise gibt es für Neulinge keinen erkennbaren Grund, mit Ungemach zu rechnen, wenn sie das vorinstallierte Update-Applet benutzen. Das Kommandozeilenwerkzeug Zypper gibt immerhin inzwischen eine Warnung aus, wenn man es unter Tumbleweed mit zypper up aufruft, dem Befehl zum Einspielen der Updates unter Leap. Daneben gibt es einen Eintrag im OpenSuse-Wiki, der das richtige Vorgehen beschreibt.

Zum Update von Tumbleweed-Systemen dient nach einem einleitenden zypper ref zum Abholen der aktuellen Daten das Kommando zypper dup (Langform: zypper dist-upgrade). Es handelt sich bei Tumbleweed-Updates ja immer auch um eine teilweise Distributionsaktualisierung. Unter Leap kommt zum Einspielen dagegen zypper up zum Einsatz, zypper dup stellt hier nur bei einem Upgrade auf eine neue Leap-Ausgabe die richtige Wahl dar.

Das Kommando zypper dup frischt nicht nur die Versionen der installierten Pakete auf, sondern entfernt auch aus den Repositories verschwundene Pakete, die ansonsten das Weiterrollen der Systemumgebung verhindern würden. Dabei handelt es sich zum Glück meist nicht um Desktop-Programme, die Anwender vermissen würden.

Für das Update sollen Sie sich unter Tumbleweed außerdem aus der Desktop-Umgebung abmelden und am Login-Screen [Strg]+[Alt]+[F1] drücken. Dann erscheint eine blanke Textkonsole, auf der Sie sich als Benutzer root mit dem zugehörigen Passwort einloggen. Die grafische Umgebung könnte während eines Upgrades abstürzen. Der Befehl reboot startet das System zum Abschluss neu. Mit [Alt]+[F7] können Sie jederzeit in die grafische Umgebung zurückkehren.

Wahlfreiheit

Die vorherigen Abschnitte haben gezeigt, dass Tumbleweed-Anwender für die größere Aktualität der Distribution einen Preis zahlen: Sie sind häufiger von Softwareregressionen betroffen. Updates laufen nach dem Friss-oder-stirb-Prinzip ab, also entweder mit allen von den Maintainern eingepflegten Änderungen oder gar nicht.

Leap-Anwendern steht dagegen beim Einspielen von Updates ein selektives Vorgehen frei, weil hier die aufgefrischten Pakete die ursprüngliche Softwareversion beibehalten, also keine neuen Abhängigkeiten mitbringen. Die Möglichkeit, nur ausgewählte Aktualisierungen einzuspielen, haben die OpenSuse-Entwickler komfortabel ausgebaut: Während Anwender anderer Distributionen bloß die Namen der aufzufrischenden Pakete sehen (Abbildung 7), kennt OpenSuse sogenannte Patches (deutsch: Flicken).

Abbildung 7: Kubuntu-Anwender sehen lediglich, für welche Programme Updates bereitstehen …

Ein Patch enthält eine konkrete Beschreibung des von ihm angesprochenen Fehlers (Abbildung 8). Patches frischen nicht nur ein Paket auf, sondern bei Bedarf beliebig viele. Es gibt sie in den Kategorien optional, recommended und security. Dieses Konzept stammt von der für den Enterprise-Bereich gedachten Spielart von Suse. Auf diese Weise können Unternehmenskunden nur sicherheitsrelevante Patches einspielen und ansonsten möglichst wenig verändern. Privatanwender, die ihr System minimalinvasiv aktualisieren möchten, liegen daher mit OpenSuse Leap goldrichtig.

Abbildung 8: … während unter OpenSuse im Update-Applet nach einem Klick auf einen Patch eine ausführliche Beschreibung des ausgebügelten Fehlers erscheint.

Das Update-Applet in der Statusleiste bringt den Schalter Install Updates mit, Kontrollkästchen vor den Patches gestatten ein selektives Einspielen. Klicken Sie auf einen Patch, dann klappt eine Beschreibung auf. Sie enthält auch einen Link zu Suses Online-Bug-Management-System Bugtracker [4], der noch mehr Details liefert.

Sammeln sich allerdings viele Patches an, ist eine Auswahl im in seiner Größe nicht veränderbaren Aufklappfenster nicht mehr praktikabel. Zudem dauert das Einspielen von Updates über das Desktop-Applet oft viel länger als über das Kommandozeilenprogramm Zypper.

Konsolentricks

Das Kommando zypper lp zeigt alle vorliegenden Patches in einer achtspaltigen Tabelle an, die jedoch kaum in ein Terminalfenster passt (Abbildung 9). Mit Cut picken Sie die Spalten Patch-Name und Kurzbeschreibung heraus (Listing 1, erste Zeile). Zusätzlich können Sie die Ausgabe mit Grep filtern, um beispielsweise nur Name und Beschreibung der Sicherheitsfixes zu sehen (zweite Zeile).

Abbildung 9: Der Cut-Befehl unten filtert die etwas zu ausführlich geratene Patch-Liste von Zypper und zeigt nur die wichtigsten Bestandteile.

$ zypper lp | cut -d '|' -f 2,8
$ zypper lp | grep security | cut -d '|' -f 2,8
$ zypper lp | grep security | cut -d '|' -f2 | xargs zypper in -t patch

Auf der Konsole gelingt es auch problemlos, lediglich alle Sicherheits-Patches zu installieren (Listing 1, letzte Zeile). Dabei listet zypper lp wieder alle vorliegenden Patches, Grep filtert sie nach security, und Cut schneidet diesmal nur die Spalte mit dem Namen des Patches heraus. Xargs verbindet die Ausgabezeilen schließlich zu einer durch Leerzeichen getrennten Liste und übergibt sie Zypper mit dem zusätzlichen Parameter -t patch (Typ patch, kein normales Paket).

Um alle Patches unabhängig von der Kategorie zu installieren, genügt ein schlichtes zypper patch. Das Kommando zypper patches dagegen listet alle verfügbaren Patches, nicht nur die für Ihr System relevanten. Das erkennen Sie unschwer in der rechten Spalte Status an den Zuständen nicht erforderlich (Paket nicht installiert) oder angewendet (Paket bereits aufgefrischt).

Manuell installieren Sie einzelne Patches mit zypper -t patch Patch-Name, mehrere Patch-Namen trennen Sie mit Leerzeichen. Der Befehl zypper if Patch-Name zeigt ausführlichere Informationen zu einem Patch. Die Angabe Konflikte nennt dabei die Paketversionen, die der Patch ersetzen soll.

Nicht alle für Leap ausgelieferten Updates decken auch einen Patch ab: Manche Auffrischungen sind nicht wichtig genug, um in der Business-Sparte ein Ticket zu erhalten, aus denen dann auch für OpenSuse ein Patch entsteht.

Das gängige Vorgehen für OpenSuse-Leap-Anwender besteht daher darin, mit zypper ref und zypper up alle verfügbaren Updates einzuspielen und sich dabei nicht um die Patches mit den ausführlichen Problembeschreibungen zu kümmern. Auch Anwender, die ihr System möglichst wenig antasten möchten und nur Sicherheits-Patches einspielen wollen, sind bei OpenSuse Leap gut aufgehoben.

Fazit

Beim Thema Updates gibt sich OpenSuse zwar etwas komplizierter als die Mitbewerber, was aber beileibe keinen Nachteil darstellt. Es bedeutet vielmehr, dass OpenSuse ausgefeilte technische Möglichkeiten zum Zurückrollen von Updates und zur gezielten Auswahl von Aktualisierungen mit unterschiedlicher Wichtigkeit anbietet. Das Ausreizen dieser Features erfordert jedoch ein wenig Einarbeitung. Zudem müssen Umsteiger von OpenSuse Leap auf den Rolling-Release-Zweig Tumbleweed komplett umlernen. (jlu)