Es ist ärgerlich, wegen eines kleinen Bugfix ein 50 MByte großes Paket neu herunterladen zu müssen. Abhilfe schafft der Delta-RPM-Mechanismus von Suse. Delta-RPMs enthalten neben einem vollständigen Header ein binäres Diff des Hauptinhalts. Seit neuestem stellen die Tools auch Deltas von ISO-Images her.

Die Idee ist denkbar einfach: Statt bei jedem Update das volle RPM-Paket herunterzuladen, holt sich der Anwender eine Datei, die lediglich die Neuerungen enthält – das Delta. Erste Ansätze dazu finden sich bereits 1998 auf den Mailinglisten der RPM-Entwickler. Durchgesetzt hat sich die Technologie damals jedoch nicht. Das liegt zum Teil daran, dass das Erstellen und Anwenden von Deltas für die damaligen PCs zu rechen- und zu speicherintensiv war. Für die Version 9.2 hat Suse Linux das Konzept der Deltas wieder aufgenommen und fest in die Distribution integriert – inklusive Support für ISO-Dateien.

Beim Delta-RPM lädt der Anwender anstelle eines vollständigen oder eines Patch-RPM ein so genanntes Delta-RPM herunter. Es beinhaltet neben einem vollständigen Header die Unterschiede zum Originalpaket als Binary. Für ein Sicherheitsupdate etwa von Acrobat Reader fallen so bei Suse-Benutzern gerade mal 2,7 MByte an Downloaddaten an. Zum Vergleich: Das vollständige RPM umfasst 35,3 MByte, auch das Patch-RPM ist noch 21,4 MByte groß.

Das Konzept der Delta-RPMs hat inzwischen auch Mandriva (früher Mandrake) überzeugt. Der Distributor bietet in der Version 10.2 Updates per Delta-RPM an. Den Sourcecode hostet Suse unter [1]. Ein Test-Repository für Fedora Core 3, das aber einen anderen Ansatz benutzt, findet sich unter [2].

Schnellstart

Eigene Delta-RPMs herstellen ist kein Problem. Aus den Paketen »alt.rpm« und »neu.rpm« erzeugt der Befehl

makedeltarpm alt.rpm neu.rpm Delta.rpm

das Delta-RPM. Dies lädt der Benutzer anschließend auf seinen Client-Rechner und erstellt über den Befehl »applydeltarpm Delta.rpm neu.rpm« das neue RPM-Paket. Das lässt sich nun auf gewohnte Weise installieren – es handelt sich ja um ein vollständiges RPM-Paket. In der Regel übernimmt den zweiten Schritt dabei nicht der Benutzer selbst, sondern ein grafisches Tool wie Rpmdrake bei Mandriva oder Yast bei Suse (siehe Abbildung 1). Unter Suse Linux besteht zudem noch die Möglichkeit, die neuen Pakete zu speichern, um diese beispielsweise auf einem zweiten Rechner zu installieren.

Spielt beim Download jedes Byte eine Rolle, kann der Systemadministrator über die Option »-s Sequenz-ID« neben dem Delta-Paket auch eine Art Signatur (Sequence ID) erstellen. Die resultierende Datei ist lediglich einige Byte groß. Überprüft der Benutzer diese Datei mit dem Befehl »applydeltarpm -s Sequenz-ID«, weiß er noch vor dem Download des eigentlichen Delta, ob es zum aktuellen System passt. Die Sequenz-ID zum schnellen Test ist auch im Delta selbst enthalten. Den schematischen Ablauf beim Erstellen und Anwenden von Delta-RPMs zeigen Abbildung 2 und 3.

Aufbau von RPM-Paketen

RPM-Pakete bestehen aus vier Teilen. Der Vorspann (Lead) enthält in erster Linie Informationen zum Dateityp, die zum Beispiel der Befehl »file« auswertet. Im zweiten Teil stehen die MD5-Summen und digitale Unterschriften (Signature). Der dritte Teil (Header) liefert wichtige Metadateien und -verzeichnisse. Sie geben unter anderem über den Inhalt, den Paketbauer und die Abhängigkeiten des Pakets Auskunft. Weiter gehören dazu Skripte, die das RPM-Tool vor und nach der Installation eines Pakets ausführt. Der vierte Teil enthält das CPIO-Archiv »CONTENTS.cpio« (auch Payload genannt). Dieses Archiv enthält die eigentlichen Daten in komprimierter Form.

Funktionsweise

Ein Delta-RPM weist den gleichen Aufbau auf wie ein echtes RPM-Paket. Das CPIO-Archiv enthält hier aber keine ganzen Dateien, sondern nur Binärschnipsel. Um sie zu erzeugen, packt das Programm zunächst alle Files, außer den Konfigurationsdateien, in ein Pseudo-Archiv. Dann führt »makedeltarpm« ein binäres Diff zwischen dem Pseudo-Archiv und dem Payload des neuen Pakets durch und schreibt danach das Delta. Das Programm benutzt dazu einen eigenen Algorithmus, eine Kombination von Xdelta [3] und Bsdiff [4]. Xdelta ist ein besonders schneller Algorithmus zum Erstellen von binären Diffs, Bsdiff bringt sehr gute Komprimierung.

Abbildung 1: Das Yast Online Update lädt zunächst sämtliche Deltas herunter, überprüft sie und wendet dann das Delta an. Erst danach installiert Yast das fertige RPM-Paket und löscht die Ausgangsdatei.

Um aus einem Delta ein neues RPM zu erstellen, benutzt »applydeltarpm« die bereits installierten Dateien. Der Befehl vergleicht anschließend die MD5-Summe des erstellten Pakets und gibt bei Nichtübereinstimmung eine entsprechende Fehlermeldung aus. Gründe für das Scheitern können gelöschte oder modifizierte Dateien sein. In diesem Fall lässt sich das neue RPM nur noch über das Originalpaket erstellen.

Änderungen an Konfigurationsdateien wirken sich auf die Funktionsweise von »applydeltarpm« nicht aus. Diese behandelt das Tool separat. Die Arbeit von »makedeltarpm« und »applydeltarpm« lässt sich über einige Parameter noch verfeinern, siehe Tabelle 1.

Vor- und Nachteile

Der Hauptvorteil von Delta-RPMs besteht in der Dateigröße. Ein Kernel-Update per Delta umfasst zum Beispiel nur 2 MByte statt des 17 MByte großen RPM-Pakets. Ein weiterer Vorteil von Delta-RPMs gegenüber einem einfachen binären Diff sind die Header-Informationen. Das Delta verhält sich wie ein gewöhnliches RPM-Paket und lässt Abfragen wie »rpm -qlp« oder »rpm -qip« zu.

Die Nachteile betreffen in erster Linie Rechner mit schwachem Prozessor und wenig Hauptspeicher: Beim Erstellen und Anwenden von Deltas müssen zahlreiche Dateien im CPIO-Archiv neu komprimiert werden. Das ist eine sehr rechenintensive Aufgabe. Ein Delta-RPM erstellen beansprucht den dreifachen Speicherplatz des unkomprimierten Payloads. Bei großen Paketen kann dieser Vorgang den ganzen Hauptspeicher einnehmen. Ein Auslagern auf die Swap-Partition verlangsamt den Prozess stark.

Sicherheitsaspekte

Ein weiterer Nachteil von Deltas gegenüber Patch-RPMs ist, dass sich Delta-RPMs nicht direkt installieren lassen. Der Umweg über »applydeltarpm« ist in erster Linie sicherheitstechnisch bedingt. Für einen Angreifer ist es möglich, ein von Suse signiertes Delta-RPM zu verändern. Könnte der Benutzer dieses Delta auf seinem Rechner installieren, ohne daraus ein vollständiges RPM zu bauen, hätte der Übeltäter seinen Code eingeschleust. So kann der Systemadministrator aber vor der Installation über »rpm –checksig« die Integrität des RPM-Pakets noch überprüfen.

Das Yast Online Update wählt aber einen etwas anderen Weg: YOU lädt mit jedem Delta, Patch oder Update ein Patch-File herunter und speichert es im Verzeichnis »/var/lib/YaST2/you/mnt/i386/update/Version/patches/«. Das File enthält unter anderem die Sequenz-ID des Delta, dessen MD5-Summe und die MD5-Summe des vollständigen Pakets.

YOU überprüft zuerst anhand der Sequenz-ID, ob das Delta überhaupt passt. Dann lädt es dieses herunter und wendet es an. Nachdem das Online-Update das neue RPM aus dem Delta erstellt hat, überprüft es dessen MD5-Summe mit der im Patch-File angegebenen. Stimmen beide überein, installiert YOU das Paket.

Delta oder RPM?

Ein Delta-RPM von einem echten RPM zu unterscheiden ist nicht einfach, wenn das Delta-RPM über den Dateinamen nicht als solches gekennzeichnet ist. So meldet zwar »rpm« unter Suse Linux beim Installieren eines Delta, dass aus ihm zuerst ein echtes RPM erzeugt werden muss. Wie dies funktioniert, teilt die Fehlermeldung allerdings nicht mit. Unter Fedora Core merkt »rpm« zum Beispiel erst bei dem Versuch, das CPIO-Archiv auszupacken, dass etwas nicht stimmt, und verabschiedet sich mit der Fehlermeldung »cpio: Bad magic«.

Abbildung 2: Für ein Delta-RPM sind das alte und das neue RPM-Paket erforderlich. Der Parameter »-s« legt die Sequenz-ID für den Schnellcheck an.

Delta-ISOs

Seit Version 2.3 bringen die Delta-RPM-Tools auch zwei Programme mit, um aus ISO-Abbilddateien Deltas zu erstellen: »makedeltaiso« und »applydeltaiso«. Während Delta-RPMs in erster Linie die Download-Zeiten für Heimbenutzer verkürzen, verfolgen Delta-ISOs das gleiche Ziel für Betatester und Business-Kunden: Sie müssen beim Erscheinen einer neuen Version nicht mehr die komplette Distribution herunterladen, sondern nur noch die Deltas.

Für einen Betatester bedeutet dies konkret, dass er für den zweiten Test nicht mehr sechs ISO-Dateien zu 650 MByte herunterladen muss, sondern – je nach Umfang der Änderungen – nur noch rund 200 MByte. Das Anwenden eines Delta dauert pro CD rund zehn Minuten. Bei einer DVD sind Apply-Zeiten von einer halben Stunde keine Seltenheit. Deutlich schneller arbeiten 64-Bit-Rechner. Bei diesen rechenintensiven Prozessen zeigt sich der Vorteil der neuen Architektur.

Die beiden Programme »makedeltaiso« und »applydeltaiso« arbeiten dabei in zwei Schritten. Zuerst erstellen sie ein Delta von allen Daten, ohne die CPIO-Archive. Anschließend folgen das Auslesen und das Vergleichen der Payload-Informationen. Beim Anwenden des Delta liest »applydeltaiso« die Unterschiede direkt aus der ISO-Datei aus und stellt das neue Abbild her.

Abbildung 3: Per Sequenz-ID ist prüfbar, ob das Paket zu einem System passt. Meldet der Befehl keinen Fehler, erstellt »applydeltarpm« das vollständige RPM.

Fortsetzung folgt

Der Hauptentwickler Michael Schröder arbeitet bereits an der nächsten Version der Delta-RPM-Tools. Da die Delta-Technik bereits ziemlich ausgereift ist, geht die Entwicklung in Richtung Zusatztools. Die nächste Release bringt unter anderem ein Tool zum Synchronisieren von RPM-Bäumen mit Hilfe von Delta-RPMs, Unterstützung für kombinierte Deltas (ein großes Delta aus mehreren Deltas) und RPM-only-Deltas. Letztere bringen nochmals verkleinerte Dateigrößen, lassen sich aber nur mit dem Original-RPM wiederherstellen. Für Experimentierfreudige steht unter [5] eine Betaversion zum Download bereit.