Patch-Verwaltung

aus openSUSE, der freien Wissensdatenbank

Patches

Systemeinrichtung

Ein installiertes System besteht aus Paketen die Dateien beinhalten. Die Systemeinrichtung wird durch alle auf der Festplatte installierten Dateien festgelegt. Idealerweise definiert der Satz installierter Pakete die komplette Systemkonfiguration.

Allerdings enthält die Systemkonfiguration auch Dateien, die nicht Teil eines Pakets sind. Beispielsweise alles unter /etc/sysconfig.

Aber auch mit allen Dateien ist das System nicht komplett beschrieben. Man muss auch die Umgebung in der das System arbeitet mit einbeziehen. Wie Nutzer damit interagieren, welche Netzwerkressourcen es nutz oder anbietet, usw.

Fehler

Wenn sich das System nicht korrekt verhält (also einen Fehler hat), muss die Systemkonfiguration geändert werden. Entweder die installierte Software, die Konfiguration oder seine Einbindung in die Arbeitsumgebung.

Veränderungen definieren

Um solche Änderungen sauber zu definieren und zu verfolgen, brauchen wir eine klare Definition von Veränderung. An dieser Stelle kommen Patches ins Spiel.

Ein Patch definiert eine Änderung am System. Es gibt zwei Klassen von Änderungen, solche, die sich auf Dateien beziehen und solche die das nicht tun. Letztes können Anweisungen an den Nutzer sein, sein Nutzungsschema so zu ändern, dass Fehler vermieden werden.

Veränderungen anwenden

Änderungen können automatisch oder manuell angewandt werden. Einige Änderungen müssen manuell vorgenommen werden, um Datenkonsistenz sicherzustellen (bspw. der Neustart einer Anwendung).

Die meisten Veränderungen können durch RPM-Pakete ausgerückt werden. Änderungen an nicht-paketierten Dateien können durch Skripte angewandt werden. Dies können RPM-Skripte sein, aber sie gehören nicht wirklich zu einem paket. RPM-Skripte können außerdem nicht so gut kontrolliert werden, und Fehler in Deinstallationsskripten bleiben komplett unentdeckt.

Das wirkliche Problem sind nicht-automatisierte Änderungen, wie das Ändern des Nutztungsverhaltens oder der Neustart einer Anwendung. Hier ist eine Nachricht an den Systemadministrator (die anerkannt werden muss) der beste vorstellbare Ansatz.

Die alles kann folgendermaßen betrachtet werden:

(*) Manuelle Änderungen an Dateien sollten nicht benötigt werden, da sie zu Fehlerträchtig sind. Eine Kombination aus Skript und Benachrichtigung ist eine bessere Lösung.

Warum nicht nur (aktualisierte) Pakete?

Sie mögen sich fragen, warum wir nicht allein auf Aktualisierungspakete vertrauen. Mit der Ausnahme von Benachrichtigungen sind Paketaktualisierungen tatsächlich ausreichend Eindrucksstark, um die oben erwähnten Änderungen anzuwenden.

Allerdings sind Paketaktualisierungen nur aus einer UI-Sicht nutzerunfreundlicht, da sie

• den Grund nicht anzeigen
  

Sie möchten bestimmt wissen, ob die Aktualisierung eine kritische Sicherheitslücke stopft oder nur kosmetisch ist (bspw. ein Tippfehler). Diese kritische Information ist normalerweise nicht in einem Paket enthalten.

• an Post-Aktualisierungsaktionen scheitern
  

Einige Aktualisierungen bedürfen nach ihrer Anwendung besonderer Aktionen. Das typische Beispiel ist eine Aktualisierung von Kernel oder glibc, die einen Neustart benötigen um in Kraft zu treten. Aktualisierungen anderer Komponenten (bspw. der Aktualisierungssoftware selbst) benötigen eventuell den Neustart dieser Komponente.

• die Änderungen nicht sichtbar machen
  Paketverwaltungen zeigen den Namen des Pakets, seine Version und eine Zusammenfassung an. Vielleicht noch die Beschreibung. Nichts davon enthält eine Beschreibung der Veränderungen. Sie könnte im Änderungsprotokoll des Pakets stehen, aber die ist aufwändig zu bekommen und hart zu lesen.
• Aktualisierungen zu einer Änderung gruppiert
  Wenn mehrere Pakete aktualisiert werden müssen, entweder weil sie alle eine Fehlerbehebung enthalten oder weil die Abhängigkeiten eine kombinierte Aktualisierung erfordern, ist dies in der Paketverwaltung nicht ersichtlich.

Patches als Softwareelemente erster Klasse mit einer passenden Paketverwaltung zu haben, greift diese Probleme auf. Die Patch-Zusammenfassung und die Beschreibung konzentrieren sich auf die behobenen Fehler, Paketnamen und Versionen sind zweitrangig. Patches gruppieren außerdem zugehörige Paketaktualisierungen und machen die Änderungen für den Administrator besser sichtbar.

Implementierung

Code9

Code9 (SUSE Linux 9.x, SLE9) bietet Aktualisierungen (aktualisierte RPMs) über Patches. Patches werden als Container genutzt, die Metainformationen (Patch-Priorität, Beschreibung, usw.) und (Verknüpfungen zu) neue(n) RPMs enthalten. Es gibt keinen Weg, ohne den Patch auf die RPMs zuzugreifen.

Patches und ihre RPMs werden außerdem als einzelne, getrente Elemente behandelt. Das hat zwei Unzulänglichkeiten

• Keine Abhängigkeitsauflösung von Paketen. Alle Abhängigkeiten müssen im Patch enthalten sein.
• Keine Unterstützung für Werkzeuge von Dritten. Aktualisierungen können nur über yast-online-update eingespielt werden.

Code10

Code10 (openSUSE 10.x, SLE10) trennt Patches (liefern Metainformationen) und Aktualisierungen (neuere RPMs). Diese Trennung erlaubt das Empfangen und Installieren von Paketaktualisierungen mit Werkzeugen von Drittanbietern, ohne Patches zu benötigen. Sie unterstützt außerdem eine komplette Abhängigkeitenauflösung, die es einem Aktualisierungspaket erlaubt, zusätzliche Abhängigkeiten einzubringen.

Indes werden Paketaktualisierungen und Patches (die Paketaktualisierungen referenzieren) nicht vermischt und passen gut. Dies liegt am auf ZENworks basierenden Aktualisierungs-Stack, der, auf einer zentralen Instanz beruhend (dem ZENwork Linux Management Server), nur passende Aktualisierungen anbietet. Auf diesem Weg kann der Code10-Aktualisierungs-Stack 'blind' jede verfügbare Aktualisierung installieren, ohne Abhängigkeitskonflikte fürchten zu müssen.

Allerdings ist die echte Welt nicht so einfach und Paketdepots von Dritten können die Feier schnell verderben. Dies ist der Grund dafür, weshalb Code10 nur nach solchen Aktualisierungen sucht, die von Patch-Metainformationen begleitet werden. Sowohl rug als auch zen-updater zeigen in ihrer Aktualisierungsanicht Standardmäßig nur Patches an.

Code11

Code11 (openSUSE 11.x, SLE11) trennt Patches (die Metainformationen ausliefern) und Aktualisierungen (neuere RPMs) noch weiter, und macht Patch-Metadaten zu einer komplett optionalen (Bequemlichhkeits-) Information. Lesen Sie Code11 Patches & Aktualisierungen für eine komplette Beschreibung.