BEZEICHNUNG¶

sysupdate.d - Definitionsdateien für automatische Aktualisierungen übertragen

ÜBERSICHT¶

/etc/sysupdate.d/*.conf
/run/sysupdate.d/*.conf
/usr/lib/sysupdate.d/*.conf


    

BESCHREIBUNG¶

sysupdate.d/*.conf-Dateien beschreiben, wie bestimmte Ressourcen auf dem lokalen System von einer fernen Quelle aktualisiert werden sollen. Jede solcher Dateien definiert eine solche Übertragung: typischerweise eine ferne HTTP/HTTPS-Ressource als Quelle und eine lokale Datei, ein lokales Verzeichnis oder eine lokale Partition als Ziel. Dies kann als einfacher, automatischer, atomarer Aktualisierungsmechanismus für das Betriebssystem selbst, für Container, portable Dienste oder System-Erweiterungsabbilder verwandt werden — kann aber tatsächlich zur Aktualisierung jeder Art von Datei von einer fernen Quelle verwandt werden.

Der Befehl systemd-sysupdate(8) liest diese Dateien und verwendet sie, um zu bestimmen, welche lokalen Ressourcen aktualisiert werden sollen und führt dann die Aktualisierung durch.

Sowohl die ferne HTTP/HTTPS-Quelle als auch das lokale Ziel existiert typischerweise in mehreren, gleichzeitigen Versionen, um flexible Aktualisierungsschemata zu implementieren, z.B. A/B-Aktualisierungen (oder eine Obermenge davon, z.B. A/B/C, A/B/C/D, …).

Jede Datei *.conf definiert eine Übertragung, d.h. beschreibt eine zu aktualisierende Ressource. Typischerweise werden mehrerer dieser Dateien zusammen definiert (d.h. mehrere solche Übertragungen) und diese werden durch einen gemeinsamen Versionskennzeichner zusammengebunden, um mehrere Ressourcen auf einmal in einer Aktualisierungsaktion zu aktualisieren, beispielsweise um einen Kernel, ein Wurzeldateisystem und eine Verity-Partition in einer einzelnen, kombinierten, synchronisierten Aktion zu aktualisieren, so dass nur eine kombinierte Aktualisierung aller drei zusammen eine komplette Aktualisierung bilden.

Jede Datei *.conf enthält drei Abschnitte: [Transfer], [Source] und [Target].

GRUNDLEGENDER AKTIONSMODUS¶

Plattenbasierte Betriebssystemaktualisierungen bestehen typischerweise aus mehreren verschiedenen Ressourcen, die zusammen aktualisiert werden müssen. Beispielsweise könnte eine sichere Betriebssystemaktualisierung aus einem Wurzeldateisystem-Abbild bestehen, das in eine Partition abgelegt werden muss, einem passenden Verity-Integritätsdaten-Partitionsabbild und einem Kernel-Abbild, das zum Starten in die Kombination beider Partitionen vorbereitet ist. Die ersten zwei Ressourcen sind Dateien, die heruntergeladen und in eine Plattenpartition abgelegt werden, das Letztere ist eine Datei, die heruntergeladen und in einer regulären Datei im Systemstart-Dateisystem abgelegt wird (z.B. der EFI-System-Partition). Während einer Aktualisierung eines hypothetischen Betriebssystems »foobarOS« auf die hypothetische Version 47 sollten die folgenden Aktionen stattfinden:

Die versionsunabhängige Verallgemeinerung davon wäre Folgendes (mit der besonderen Markierung »@v« als Platzhalter für die Versionskennzeichnung):

Eine Aktualisierung kann nur abgeschlossen werden, falls die relevanten URLs ihre Ressourcen für die gleiche Version bereitstellen, d.h. für den gleichen Wert von »@v«.

Obiges Vorgehen kann in drei *.conf-Dateien in sysupdate.d/ übersetzt werden, je eine für jede Übertragung. Die Dateien *.conf konfigurieren die Art des Herunterladens und wohin das Heruntergeladene geschrieben werden soll (d.h. ob in eine Partition oder eine Datei im Dateisystem). Das wichtigste ist, dass die Dateien die oben gezeigte URL, den Partitionsnamen und die Dateinamenmuster enthalten, die beschreiben, wie diese Ressourcen in der Quelle heißen und wie sie auf dem Ziel benannt werden sollen.

Um die verfügbaren Versionen aufzuzählen und Kandidaten für die Aktualisierung herauszufinden, ist ein Mechanismus zur Auflistung geeigneter Dateien notwendig:

Übertragungen erfolgen in alphabetischer Reihenfolge der .conf-Dateinamen, in denen sie enthalten sind. Zuerst werden die Ressourcendaten direkt in die Zieldatei/das Zielverzeichnis/die Zielpartition heruntergeladen. Sobald dieses für alle definierten Übertragungen abgeschlossen ist, werden in einem zweiten Schritt die Dateien/Verzeichnisse/Partitionen in ihre endgültigen Namen, wie in MatchPattern= vom Ziel definiert, umbenannt, wieder in der Reihenfolge, die die .conf-Übertragungen diktieren. Dieser Schritt ist nicht atomar, allerdings wird garantiert, dass er in strenger Reihenfolge unter Beachtung geeigneter Plattensynchronisierung erfolgt. Bei der Aktualisierung eines Betriebssystems definiert eine der Übertragungen typischerweise den Einstiegspunkt beim Systemstart. Daher ist es im Allgemeinen eine gute Idee, die Ressourcen mittels der Übertragungskonfigurationsdateinamen so zu sortieren, dass der Einstiegspunkt zuletzt geschrieben wird, um sicherzustellen, dass jede ungewöhnliche Beendigung keinen Einstiegspunkt zurücklässt, dessen Hinterlegung noch nicht etabliert wurde. Im obigen Beispiel wäre es daher sinnvoll, das EFI-Kernel-Abbild zuletzt zu etablieren und daher der Übertragungskonfigurationsdatei den alphabetisch betrachtet hintersten Namen zu geben.

Ein erweitertes, gegenüber oben spezielleres Beispiel finden Sie weiter unten.

RESSOURCENTYPEN¶

Jede Übertragungsdatei definiert eine Quellressource, die zu einer Zielressource übertragen werden soll. Es werden die folgenden Ressourcentypen unterstützt:

Wie bereits dargestellt, wird nur eine Untermenge der Kombinationen der Quell- und Zielressourcentypen unterstützt:

Tabelle 1. Ressourcentypen

ÜBEREINSTIMMUNGSMUSTER¶

Sowohl die Quell- als auch die Zielressourcen existieren typischerweise in mehreren Versionen gleichzeitig. Eine Aktualisierungsaktion erfolgt immer dann, wenn die neuste der Quellversionen neuer als die neuste der Zielversionen ist. Um die neuste Version einer Ressource zu ermitteln, wird eine Auflistung eines Verzeichnisses, der Partitionen oder eines Manifestes verwandt. Dann wird eine Teilmenge der in Frage kommenden Einträge daraus ausgewählt und der Versionskennzeichner wird aus den Dateinamen oder Partitionsbezeichnungen dieser ausgewählten Einträge herausgelöst. Auswahl der Teilmenge und das Herauslösen des Versionskennzeichners (sowie möglicherweise weiterer Metadaten) erfolgt mittels Übereinstimmungsmustern, die in den Abschnitten [Source] und [Target] über MatchPattern= konfiguriert werden. Diese Muster sind Zeichenketten, die beschreiben, wie Dateien oder Partitionen benannt sind, mit benannten Platzhaltern für bestimmte Felder wie den Versionskennzeichner. Die folgenden Platzhalter sind definiert:

Tabelle 2. Platzhalter für Übereinstimmungsmuster

Von diesen Platzhaltern muss nur »@v« in einem gültigen Muster vorhanden sein, alle anderen Platzhalter sind optional. Jeder Platzhalter darf höchstens einmal in jedem Muster verwandt werden. Ein typischer Platzhalter, der auf ein Dateisystemquellabbild passt, könnte »MatchPattern=foobar_@v.raw.xz« sein, d.h. alle Dateien, deren Namen mit »foobar_« beginnt und denen eine Versionskennung folgt und eine Endung ».raw.xz«.

Verwechseln Sie den »@«-Mustervergleichsplatzhalterpräfix nicht mit dem »%«-Kennzeichnerexpansionspräfix. Ersterer kapselt einen variablen Anteil einer Vergleichsmusterzeichenkette, Letzterer ist eine einfache Abkürzung, die erweitert wird, wenn Ergänzungsdateien vorhanden sind. Details zu Kennzeichnern finden Sie nachfolgend.

[TRANSFER]-ABSCHNITT-OPTIONEN¶

Dieser Abschnitt definiert allgemeine Eigenschaften dieser Übertragung:

MinVersion=

ProtectVersion=

Verify=

[SOURCE]-ABSCHNITT-OPTIONEN¶

Dieser Abschnitt definiert Eigenschaften der Übertragungsquelle.

Type=

Path=

MatchPattern=

[TARGET]-ABSCHNITT-OPTIONEN¶

Dieser Abschnitt definiert Eigenschaften des Übertragungsziels.

Type=

Path=

PathRelativeTo=

MatchPattern=

MatchPartitionType=

PartitionUUID=, PartitionFlags=, PartitionNoAuto=, PartitionGrowFileSystem=

ReadOnly=

Mode=

TriesDone=, TriesLeft=

InstancesMax=

RemoveTemporary=

CurrentSymlink=

KENNZEICHNER¶

In den Einstellungen MinVersion=, ProtectVersion=, Path=, MatchPattern= und CurrentSymlink= können Kennzeichner verwandt werden. Die folgenden Expansionen werden verstanden:

Tabelle 3. Verfügbare Kennzeichner

Bringen Sie das Kennzeichnerpräfix »%« nicht mit dem Mustervergleichs-Platzhalterpräfix »@« durcheinander. Das erstere ist eine einfache Abkürzung, die expandiert wird, während Ergänzungsdateien ausgewertet werden, letzteres kapselt einen variablen Anteil einer Mustervergleichszeichenkette. Details zu Mustervergleichs-Platzhaltern finden sie weiter oben.

BEISPIELE¶

Beispiel 1. Aktualisierungen für ein Verity-aktiviertes Sicheres Betriebssystem

Mit den folgenden drei Dateien definieren wir eine Wurzeldateisystempartition, eine passende Verity-Partition und ein vereinigtes Kernel-Abbild, um gemeinsam zu aktualisieren. Dieses Beispiel ist eine Erweiterung des vorher in dieser Handbuchseite diskutierten Beispiels.

# /usr/lib/sysupdate.d/50-verity.conf
[Transfer]
ProtectVersion=%A
[Source]
Type=url-file
Path=https://download.example.com/
MatchPattern=foobarOS_@v_@u.verity.xz
[Target]
Type=partition
Path=auto
MatchPattern=foobarOS_@v_verity
MatchPartitionType=root-verity
PartitionFlags=0
ReadOnly=1

Vorstehendes definiert den Aktualisierungsmechanismus für die Verity-Partition des Wurzeldateisystems. Verity-Partitionsabbilder werden von »https://download.example.com/foobarOS_@v_@u.verity.xz« heruntergeladen und in eine geeignete lokale Partition geschrieben, die schreibgeschützt markiert ist. Unter der Annahme, dass diese Aktualisierung aus dem Abbild selbst heraus ausgeführt wird, wird die aktuelle Abbildversion (d.h. der »%A«-Kennzeichner) als geschützt markiert, um sicherzustellen, dass sie beim Systemstart nicht beschädigt wird. Beachten Sie, dass die Partitions-UUID für die Ziel-Partition im Quelldateinamen kodiert ist. Fixierung der Partitions-UUID kann nützlich sein, um sicherzustellen, dass der »roothash=« auf der Kernelbefehlszeile ausreichend ist, um sowohl die Verity- als auch die Wurzeldateisystempartition genau zu bestimmen und auch den Verity-Hash auf Wurzelebene zu kodieren (unter der Annahme, dass die UUID in dem Dateinamen auf den Hash der obersten Stufe passt, wie das systemd-gpt-auto-generator(8) vorschlägt).

# /usr/lib/sysupdate.d/60-root.conf
[Transfer]
ProtectVersion=%A
[Source]
Type=url-file
Path=https://download.example.com/
MatchPattern=foobarOS_@v_@u.root.xz
[Target]
Type=partition
Path=auto
MatchPattern=foobarOS_@v
MatchPartitionType=root
PartitionFlags=0
ReadOnly=1

Obiges definiert eine passende Transferdefinition für das Wurzeldateisystem.

# /usr/lib/sysupdate.d/70-kernel.conf
[Transfer]
ProtectVersion=%A
[Source]
Type=url-file
Path=https://download.example.com/
MatchPattern=foobarOS_@v.efi.xz
[Target]
Type=regular-file
Path=/EFI/Linux
PathRelativeTo=boot
MatchPattern=foobarOS_@v+@l-@d.efi \


             foobarOS_@v+@l.efi \


             foobarOS_@v.efi
Mode=0444
TriesLeft=3
TriesDone=0
InstancesMax=2

Obiges installiert ein vereinigtes Kernel-Abbild in die Partition $BOOT, gemäß der Systemladerspezifikation[2] Typ #2. Dies definiert drei mögliche Muster für die Namen der Kernel-Abbilder, gemäß der Informationen in Automatische Systemstartbeurteilung[3] und stellt bei der Installation neuer Kernel sicher, dass sie mit drei verbliebenen Versuchen eingerichtet sind. Es werden nicht mehr als zwei Kernel parallel behalten.

Mit dieser Installation würde der Webserver die folgenden Dateien für eine hypothetische Version 7 des Betriebssystems ausliefern:

Für jede neue Veröffentlichung des Betriebssystems würden die letzteren drei Dateien mit einer aktualisierten Version hinzugefügt. Das SHA256SUMS-Manifest sollte dann entsprechend aktualisiert werden und alle Dateien für alle Versionen aufführen, die entsprechend zum Herunterladen angeboten werden sollen.

Beispiel 2. Aktualisierungen für ein Container-Abbild in einem einfachen Verzeichnis

[Source]
Type=url-tar
Path=https://download.example.com/
MatchPattern=myContainer_@v.tar.gz
[Target]
Type=subvolume
Path=/var/lib/machines
MatchPattern=myContainer_@v
CurrentSymlink=myContainer

Bei Aktualisierungen lädt dies »https://download.example.com/myContainer_@v.tar.gz« herunter und dekomprimiert/entpackt es nach /var/lib/machines/myContainer_@v. Nach jeder Aktualisierung wird ein Symlink /var/lib/machines/myContainer erstellt/aktualisiert, der immer auf die neuste Aktualisierung zeigt.

SIEHE AUCH¶

systemd(1), systemd-sysupdate(8), systemd-repart(8)

ANMERKUNGEN¶

1.

Spezifikation für auffindbare Partitionen

2.

Systemladerspezifikation

3.

Automatische Systemstartbeurteilung

ÜBERSETZUNG¶

Die deutsche Übersetzung dieser Handbuchseite wurde von Helge Kreutzmann <debian@helgefjell.de> erstellt.

Diese Übersetzung ist Freie Dokumentation; lesen Sie die GNU General Public License Version 3 oder neuer bezüglich der Copyright-Bedingungen. Es wird KEINE HAFTUNG übernommen.

Wenn Sie Fehler in der Übersetzung dieser Handbuchseite finden, schicken Sie bitte eine E-Mail an die Mailingliste der Übersetzer.