Provided by: manpages-de_4.25.1-1_all 
BEZEICHNUNG
sysupdate.d - Definitionsdateien für automatische Aktualisierungen übertragen
ÜBERSICHT
/etc/sysupdate.d/*.transfer
/run/sysupdate.d/*.transfer
/usr/local/lib/sysupdate.d/*.transfer
/usr/lib/sysupdate.d/*.transfer
BESCHREIBUNG
Diese 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 *.transfer 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. Eine solche Sammlung an Übertragungen wird ein Ziel genannt. systemd-sysupdate(8)
agiert immer auf einem einzelnen Ziel.
Übertragungen können in Gruppen zusammengefasst werden, die durch den Systemadministrator individuell
(de)aktiviert werden können, genannt »Optionale Funktionalitäten« (siehe sysupdate.features(5)).
Jede Datei *.transfer 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:
1. Eine Datei »https://download.example.com/foobarOS_47.root.xz« sollte heruntergeladen, dekomprimiert
und in eine bisher unbenutzte Partition mit dem GPT-Partitionstyp UUID
4f68bce3-e8cd-4db1-96e7-fbcaf984b709 für x86-64 geschrieben werden, wie in Spezifikation für
auffindbare Partitionen[1] beschrieben.
2. Entsprechend sollte eine Datei »https://download.example.com/foobarOS_47.verity.xz« heruntergeladen,
dekomprimiert und in eine bisher unbenutzte Partition mit dem GPT-Partitionstyp UUID
2c7357ed-ebd2-46d9-aec1-23d437ec2bf5 geschrieben werden (d.h. dem Partitionstyp für
Verity-Integritätsinformationen für x86-64-Wurzeldateisysteme).
3. Schließlich sollte eine Datei »https://download.example.com/foobarOS_47.efi.xz« (ein gemäß der
Systemladerspezifikation[2] Type #2 zusammengefasster Kernel) heruntergeladen, dekomprimiert und in
das $BOOT-Dateisystem geschrieben werden, d.h. nach EFI/Linux/foobarOS_47.efi in das ESP oder die
XBOOTLDR-Partition.
Die versionsunabhängige Verallgemeinerung davon wäre Folgendes (mit der besonderen Markierung »@v« als
Platzhalter für die Versionskennzeichnung):
1. Eine Übertragung einer Datei »https://download.example.com/foobarOS_@v.root.xz« → eine lokale, bisher
leere GPT-Partition vom Typ 4f68bce3-e8cd-4db1-96e7-fbcaf984b709 mit der Bezeichnung, die auf
»foobarOS_@v« gesetzt ist.
2. Eine Übertragung einer Datei »https://download.example.com/foobarOS_@v.verity.xz« → eine lokale,
bisher leere GPT-Partition vom Typ 2c7357ed-ebd2-46d9-aec1-23d437ec2bf5 mit der Bezeichnung, die auf
»foobarOS_@v_verity« gesetzt ist.
3. Eine Übertragung einer Datei »https://download.example.com/foobarOS_@v.efi.xz« → eine lokale Datei
$BOOT/EFI/Linux/foobarOS_@v.efi.
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 *.transfer-Dateien in sysupdate.d/ übersetzt werden, je eine für jede
Übertragung. Die Dateien *.transfer 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:
• Für Partitionen: die umgebende GPT-Partitionstabelle enthält eine Liste von definierten Partitionen,
einschließlich einer Partitionstyp-UUID und einer Partitionsbezeichnung (in diesem Schema spielt die
Partitionsbezeichnung eine Rolle für Partitionen ähnlich wie der Dateiname für eine reguläre Datei).
• Für reguläre Dateien: die Verzeichnisauflistung des Verzeichnisses, in dem sich die Dateien befinden,
zeigt die existierenden Dateien direkt an.
• Für HTTP/HTTPS-Quellen wird ein einfaches Schema verwandt: eine Manifest-Datei SHA256SUMS, die dem in
sha256sum(1) definierten Format folgt, listet Dateinamen und ihre SHA256-Hashes auf.
Übertragungen erfolgen in alphabetischer Reihenfolge der .transfer-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 .transfer-Ü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:
1. Ressourcen vom Typ »url-file« kapseln eine Datei auf einem Webserver und werden über eine HTTP- oder
HTTPS-URL referenziert. Wenn eine Aktualisierung stattfindet, wird die Datei heruntergeladen und
dekomprimiert und dann in die Zieldatei oder -partition geschrieben. Dieser Ressourcentyp ist nur für
Quellen verfügbar, nicht für Ziele. Die Liste der verfügbaren Versionen einer Ressource dieses Typs
wird in SHA256SUMS-Manifest-Dateien kodiert, zusammen mit losgelösten SHA256SUMS.gpg-Signaturen.
2. Der Ressourcentyp »url-tar« ist ähnlich, aber die Datei muss ein .tar-Archiv sein. Wenn eine
Aktualisierung stattfindet, dann wird die Datei dekomprimiert und in ein Verzeichnis oder einen
BTRFS-Teildatenträger entpackt. Dieser Ressourcentyp ist nur für Quellen verfügbar, nicht für Ziele.
Wie bei »url-file« erfolgt die Versionsaufzählung von »url-tar« unter Verwendung von
SHA256SUMS-Dateien, authentifiziert mittels SHA256SUMS.gpg.
3. Der Ressourcentyp »regular-file« kapselt eine lokale reguläre Datei auf Platte. Wenn eine
Aktualisierung stattfindet, dann wird die Datei dekomprimiert und in eine Zieldatei oder -partition
geschrieben. Dieser Ressourcentyp ist sowohl als Quelle als auch als Ziel verfügbar. Während der
Aktualisierung erfolgt keine Integritäts- oder Authentizitätprüfung für Ressourcen dieses Typs.
4. Der Ressourcentyp »partition« ist ähnlich zu »regular-file« und kapselt eine GPT-Partition auf
Platte. Beim Aktualisieren muss die Partition bereits existieren und über einen korrekten
GPT-Partitionstypen verfügen. Eine Partition, deren GPT-Partitionsbezeichnung auf »_empty« gesetzt
ist, wird als leer betrachtet und als ein Kandidat, in dem eine frisch heruntergeladene Ressource
hinein abgelegt wird. Die GPT-Partitionsbezeichnung wird zum Speichern von Versionsinformationen
verwandt, sobald eine Partition aktualisiert wird. Dieser Ressourcentyp ist nur für Zielressourcen
verfügbar.
5. Der Ressourcentyp »tar« kapselt lokale .tar-Archiv-Dateien. Wenn eine Aktualisierung stattfindet,
dann werden die Dateien dekomprimiert und in ein Zielverzeichnis oder einen BTRFS-Teildatenträger
entpackt. Das Verhalten von »tar« und »url-tar« ist im Allgemeinen ähnlich, aber Letzteres lädt von
fernen Quellen herunter und führt Integritäts- und Authentifizierungsprüfungen durch, während das bei
ersterem nicht der Fall ist. Der Ressourcentyp »tar« ist nur für Quellressourcen verfügbar.
6. Der Ressourcentyp »directory« kapselt lokale Verzeichnisbäume. Dieser Typ ist sowohl als Quellen- als
auch als Zielressource verfügbar. Falls eine Aktualisierung bei einer Quellressource von diesem Typ
stattfindet, erfolgt eine rekursive Kopie des Verzeichnisses.
7. Der Ressourcentyp »subvolume« ist identisch zu »directory«, außer dass bei der Verwendung als Ziel
der Dateibaum in einen Btrfs-Teildatenträger statt in ein einfaches Verzeichnis abgelegt wird, falls
das zugrundeliegende Dateisystem dies unterstützt (d.h. Btrfs ist).
Wie bereits dargestellt, wird nur eine Untermenge der Kombinationen der Quell- und Zielressourcentypen
unterstützt:
Tabelle 1. Ressourcentypen
┌─────────────┬───────────────────────┬────────────┬───────────────┬───────────────┬─────────────────┬────────────┬──────────────┐
│Kennzeichner │ Beschreibung │ Als Quelle │ Wenn als │ Wenn als │ Wenn als │ Als Ziel │ Wenn als │
│ │ │ verwendbar │ Quelle │ Quelle │ Quelle │ verwendbar │ Ziel │
│ │ │ │ verwandt: │ verwandt: │ verwandt: │ │ verwandt: │
│ │ │ │ Kompatible │ Integrität + │ Dekomprimierung │ │ Kompatible │
│ │ │ │ Ziele │ Authentizität │ │ │ Quellen │
├─────────────┼───────────────────────┼────────────┼───────────────┼───────────────┼─────────────────┼────────────┼──────────────┤
│url-file │ HTTP/HTTPS-Dateien │ ja │ regular-file, │ ja │ ja │ nein │ - │
│ │ │ │ partition │ │ │ │ │
├─────────────┼───────────────────────┼────────────┼───────────────┼───────────────┼─────────────────┼────────────┼──────────────┤
│url-tar │ HTTP/HTTPS │ ja │ directory, │ ja │ ja │ nein │ - │
│ │ .tar-Archive │ │ subvolume │ │ │ │ │
├─────────────┼───────────────────────┼────────────┼───────────────┼───────────────┼─────────────────┼────────────┼──────────────┤
│regular-file │ Lokale Dateien │ ja │ regular-file, │ nein │ ja │ ja │ url-file, │
│ │ │ │ partition │ │ │ │ regular-file │
├─────────────┼───────────────────────┼────────────┼───────────────┼───────────────┼─────────────────┼────────────┼──────────────┤
│partition │ Lokale │ nein │ - │ - │ - │ ja │ url-file, │
│ │ GPT-Partitionen │ │ │ │ │ │ regular-file │
├─────────────┼───────────────────────┼────────────┼───────────────┼───────────────┼─────────────────┼────────────┼──────────────┤
│tar │ Lokales │ ja │ directory, │ nein │ ja │ nein │ - │
│ │ .tar-Archiv │ │ subvolume │ │ │ │ │
├─────────────┼───────────────────────┼────────────┼───────────────┼───────────────┼─────────────────┼────────────┼──────────────┤
│directory │ Lokales │ ja │ directory, │ nein │ nein │ ja │ url-tar, │
│ │ Verzeichnis │ │ subvolume │ │ │ │ tar, │
│ │ │ │ │ │ │ │ directory, │
│ │ │ │ │ │ │ │ subvolume │
├─────────────┼───────────────────────┼────────────┼───────────────┼───────────────┼─────────────────┼────────────┼──────────────┤
│subvolume │ Lokaler │ ja │ directory, │ nein │ nein │ ja │ url-tar, │
│ │ Btrfs-Teildatenträger │ │ subvolume │ │ │ │ tar, │
│ │ │ │ │ │ │ │ directory, │
│ │ │ │ │ │ │ │ subvolume │
└─────────────┴───────────────────────┴────────────┴───────────────┴───────────────┴─────────────────┴────────────┴──────────────┘
Ü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
┌────────────┬───────────────────────┬───────────────────────────┬───────────────────────────┐
│Platzhalter │ Beschreibung │ Format │ Hinweise │
├────────────┼───────────────────────┼───────────────────────────┼───────────────────────────┤
│"@v" │ Versionskennzeichner │ Gültige │ Verpflichtend │
│ │ │ Versionszeichenkette │ │
├────────────┼───────────────────────┼───────────────────────────┼───────────────────────────┤
│"@u" │ GPT-Partitions-UUID │ Gültige │ nur relevant, falls │
│ │ │ 128-bit-UUID-Zeichenkette │ als Zielressourcentyp │
│ │ │ │ partition ausgewählt │
│ │ │ │ wurde │
├────────────┼───────────────────────┼───────────────────────────┼───────────────────────────┤
│"@f" │ GPT-Partitions-Flags │ formatierte hexadezimale │ nur relevant, falls │
│ │ │ Ganzzahl │ als Zielressourcentyp │
│ │ │ │ partition ausgewählt │
│ │ │ │ wurde │
├────────────┼───────────────────────┼───────────────────────────┼───────────────────────────┤
│"@a" │ GPT Partitions-Flag │ Entweder »0« oder »1« │ Steuert das Bit NoAuto │
│ │ NoAuto │ │ der │
│ │ │ │ GPT-Partitions-Flags, │
│ │ │ │ gemäß der │
│ │ │ │ Spezifikation für │
│ │ │ │ auffindbare │
│ │ │ │ Partitionen[1]; nur │
│ │ │ │ relevant, falls der │
│ │ │ │ ausgewählte │
│ │ │ │ Zielressourcentyp │
│ │ │ │ partition ist │
├────────────┼───────────────────────┼───────────────────────────┼───────────────────────────┤
│"@g" │ GPT Partitions-Flag │ Entweder »0« oder »1« │ Steuert das Bit │
│ │ GrowFileSystem │ │ GrowFileSystem der │
│ │ │ │ GPT-Partitions-Flags, │
│ │ │ │ gemäß der │
│ │ │ │ Spezifikation für │
│ │ │ │ auffindbare │
│ │ │ │ Partitionen[1]; nur │
│ │ │ │ relevant, falls der │
│ │ │ │ ausgewählte │
│ │ │ │ Zielressourcentyp │
│ │ │ │ partition ist │
├────────────┼───────────────────────┼───────────────────────────┼───────────────────────────┤
│"@r" │ Schreibgeschützt-Flag │ Entweder »0« oder »1« │ Steuert das Bit │
│ │ │ │ ReadOnly der │
│ │ │ │ GPT-Partitions-Flags, │
│ │ │ │ gemäß der │
│ │ │ │ Spezifikation für │
│ │ │ │ auffindbare │
│ │ │ │ Partitionen[1]; und │
│ │ │ │ andere ausgabebezogene │
│ │ │ │ Schreibschutz-Flags; │
│ │ │ │ siehe nachfolgendes │
│ │ │ │ ReadOnly= │
├────────────┼───────────────────────┼───────────────────────────┼───────────────────────────┤
│"@t" │ Dateiveränderungszeit │ Formatierte dezimale │ nur relevant, falls │
│ │ │ Ganzzahl µs seit dem │ der ausgewählte │
│ │ │ Beginn der │ Zielressourcentyp │
│ │ │ Unix-Zeitrechnung │ regular-file ist │
│ │ │ (»Epoch«, 1. Januar 1970) │ │
├────────────┼───────────────────────┼───────────────────────────┼───────────────────────────┤
│"@m" │ Dateizugriffsmodus │ Formatierte oktale │ nur relevant, falls │
│ │ │ Ganzzahl, auf UNIX-Art │ der ausgewählte │
│ │ │ │ Zielressourcentyp │
│ │ │ │ regular-file ist │
├────────────┼───────────────────────┼───────────────────────────┼───────────────────────────┤
│"@s" │ Dateigröße nach │ Formatierte dezimale │ nützlich zum Messen │
│ │ Dekomprimierung │ Ganzzahl │ des Fortschritts und │
│ │ │ │ zur Verbesserung der │
│ │ │ │ Partitionszuweisungslogik │
├────────────┼───────────────────────┼───────────────────────────┼───────────────────────────┤
│"@d" │ Erfolgte Versuche │ Formatierte dezimale │ nützlich beim Umgang mit │
│ │ │ Ganzzahl │ Kernel-Abbilddateien, │
│ │ │ │ gemäß der Automatische │
│ │ │ │ Systemstartbeurteilung[3] │
├────────────┼───────────────────────┼───────────────────────────┼───────────────────────────┤
│"@l" │ Verbliebene Versuche │ Formatierte dezimale │ nützlich beim Umgang mit │
│ │ │ Ganzzahl │ Kernel-Abbilddateien, │
│ │ │ │ gemäß der Automatische │
│ │ │ │ Systemstartbeurteilung[3] │
├────────────┼───────────────────────┼───────────────────────────┼───────────────────────────┤
│"@h" │ SHA256-Hash der │ 64 hexadezimale Zeichen │ Der SHA256-Hash der │
│ │ komprimierten Datei │ │ komprimierten Datei; für │
│ │ │ │ url-file und url-tar │
│ │ │ │ nicht nützlich, da dort │
│ │ │ │ der SHA256-Hash bereits │
│ │ │ │ in der Manifest-Datei │
│ │ │ │ enthalten ist │
└────────────┴───────────────────────┴───────────────────────────┴───────────────────────────┘
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=
Gibt die minimale Version an, die notwendig ist, damit diese Übertragung stattfinden kann. Falls die
Quell- oder Zielmuster in dieser Übertragungsdefinition auf Dateien passen, die älter als diese
Version sind, werden diese als veraltet betrachtet und niemals für eine Aktualisierungsaktion
berücksichtigt.
Hinzugefügt in Version 251.
ProtectVersion=
Akzeptiert eine oder mehrere Versionszeichenketten, die als »geschützt« markiert werden sollen.
Geschützte Versionen werden niemals entfernt, um Platz für neue, aktualisierte Versionen zu schaffen.
Dies ist nützlich, um sicherzustellen, dass die derzeit gestartete Betriebssystemversion (oder ihr
zugeordnete Hilfsressourcen) nicht während Aktualisierungen ersetzt/überschrieben werden, um
Beschädigungen des Dateisystems zur Laufzeit zu vermeiden.
Wie viele Einstellungen in diesen Konfigurationsdateien unterstützt diese Einstellung
Kennzeichnererweiterungen. Es ist besonders nützlich, diese Einstellung auf entweder die Kennzeichner
»%A«, »%B« oder »%w« zu setzen, um sich automatisch auf die aktuelle Betriebssystemversion des
laufenden Systems zu beziehen. Details zu den unterstützten Kennzeichnern finden Sie nachfolgend.
Hinzugefügt in Version 251.
Verify=
Akzeptiert einen logischen Wert, standardmäßig ja. Steuert, ob heruntergeladene Ressourcen
kryptographisch überprüft werden sollen (insbesondere: GPG-Signaturen für heruntergeladene
SHA256SUMS-Manifestdateien über ihre abgetrennten Signaturdateien SHA256SUMS.gpg im Zusammenspiel mit
dem Systemschlüsselbund /usr/lib/systemd/import-pubring.gpg oder /etc/systemd/import-pubring.gpg
validiert werden).
Diese Option ist wesentlich, um Integritätsgarantien für heruntergeladene Ressourcen bereitzustellen
und sollte daher außerhalb von Testumgebungen aktiviert bleiben.
Beachten Sie, dass die heruntergeladenen Nutzlastdateien bedingungslos gegen die in dem Manifest
aufgeführten SHA256-Hashes geprüft werden. Diese Option steuert nur, ob die Signaturen dieser
Manifeste verifiziert werden.
Diese Option ist nur wirksam, falls der ausgewählte Ressourcentyp url-file oder url-tar ist, da
Integritäts- und Authentizitätsprüfung nur für Übertragungen von fernen Rechnern verfügbar ist.
Hinzugefügt in Version 251.
ChangeLog=
Akzeptiert optional eine für Menschen lesbare URL zu einem Webauftritt, der ein Änderungsprotokoll
der zu aktualisierenden Ressource enthält.
Dies kann in einer einzelnen Übertragungsdefinition mehrfach gesetzt werden. Falls mehrfach gesetzt,
werden die Werte in eine Liste von URLs zusammengestellt. Wird ein Wert mit der leeren Zeichenkette
hinzugefügt, dann wird die Liste von allen bestehenden Werten bereinigt.
Diese Einstellung unterstützt die Kennzeichner-Expansion. Details zu den unterstützten Kennzeichnern
finden sie nachfolgend. Diese Einstellung wird auch das Platzhaltermuster »@v« expandieren. Details
finden Sie weiter oben.
Hinzugefügt in Version 257.
AppStream=
Akzeptiert optional eine URL zu einer AppStream-Katalog[4]-XML-Datei. Dies kann von
Software-Verwaltungsprogrammen (wie »GNOME Software« oder »KDE Discover«) verwandt werden, um
umfangreiche Metadaten über die zu aktualisierenden Ressourcen bereitzustellen. Dazu gehören
Anzeigenamen, Verlaufsprotokolle, Icons und weiteres. Der festgelegte Katalog muss besondere
Metadaten[5] enthalten, damit er von Software-Verwaltungsprogrammen korrekt systemd-sysupdate(8)
zugeordnet wird.
Diese Einstellung unterstützt die Kennzeichner-Expansion. Details zu den unterstützten Kennzeichnern
finden Sie weiter unten.
Hinzugefügt in Version 257.
Features=
Eine Leerzeichen-getrennte Liste von sysupdate.features(5), zu der diese Übertragung (nach Namen)
gehört. Diese Option kann mehr als einmal angegeben werden, dann werden die festgelegten
Funktionalitätslisten zusammengeführt. Falls dieser Option die leere Zeichenkette zugewiesen wird,
wird die Liste zurückgesetzt und alle vorherigen Zuweisungen haben keine Auswirkung. Beispiel:
»Features=foo bar« legt fest, dass die Übertragung zu »foo.feature« und »bar.feature« gehört.
Falls die Liste der Funktionalitäten leer ist, dann wird diese Übertragung immer verwandt. Falls
diese Übertragung zu mehr als einer Funktionalität gehört, dann wird sie verwandt, wenn irgend eine
der aufgeführten Funktionalitäten aktiviert ist. Ein Name, der keiner definierten Funktionalität
entspricht, wird zu einer impliziten Funktionalität aufgelöst, die immer deaktiviert ist.
Hinzugefügt in Version 257.
RequisiteFeatures=
Dies ist wie Features=, außer dass alle hier aufgeführten Funktionalitäten aktiviert sein müssen,
damit die Übertragung aktiviert ist. Falls beide Optionen festgelegt sind, dann gelten sie beide: die
Übertragung wird nur aktiviert, falls alle hier festgelegten Funktionalitäten aktiviert sind und
mindestens eine der in Features= aufgeführten Funktionalitäten aktiviert ist.
Hinzugefügt in Version 257.
[SOURCE]-ABSCHNITT-OPTIONEN
Dieser Abschnitt definiert Eigenschaften der Übertragungsquelle.
Type=
Legt den Ressourcentyp für die Quelle der Übertragung fest. Akzeptiert entweder url-file, url-tar,
tar, regular-file, directory oder subvolume. Details zu den Ressourcentypen sind oben beschrieben.
Diese Option ist verpflichtend.
Beachten Sie, dass wie oben dargestellt nur bestimmte Kombinationen von Quell- und
Zielressourcentypen unterstützt werden.
Hinzugefügt in Version 251.
Path=
Legt fest, wo die Quellversionen dieser Ressource zu finden sind.
Falls der Quelltyp als url-file oder url-tar ausgewählt wurde, muss dies eine HTTP/HTTPS-URL sein.
Der URL wird /SHA256SUMS angehängt, um die Manifest-Datei zu erlangen, /SHA256SUMS.gpg, um die
abgetrennte Signaturdatei dafür zu erlangen und den in der Manifestdatei aufgeführten Dateinamen,
falls eine Aktualisierung ausgeführt wird und eine Ressource heruntergeladen werden soll.
Für alle anderen Quellressourcentypen muss dies ein lokaler Pfad im Dateisystem sein, der sich auf
ein lokales Verzeichnis bezieht, in dem die Versionen dieser Ressource gefunden werden können.
Hinzugefügt in Version 251.
MatchPattern=
Gibt eine oder mehrere Dateinamenübereinstimmungslisten als Quelle für diese Übertragung an, die eine
Teilmenge der Dateien auswählen, die Aktualisierungskandidaten sind. Siehe oben für Details zu
Übereinstimmungsmustern.
Diese Option ist verpflichtend. Jedes aufgeführte Muster muss mindestens den Platzhalter »@v«
enthalten, so dass ein Versionskennzeichner aus dem Dateinamen ausgelesen werden kann. Alle anderen
Platzhalter sind optional.
Falls der Quelltyp regular-file oder directory ist, darf das Muster Schrägstrichzeichen enthalten. In
diesem Fall stimmt es mit der Datei oder dem Verzeichnis in dem entsprechenden Unterverzeichnis
überein. Beispielsweise wird »MatchPattern=foo_@v/bar.efi« mit »bar.efi« im Verzeichnis »foo_1«
übereinstimmen.
Hinzugefügt in Version 251.
[TARGET]-ABSCHNITT-OPTIONEN
Dieser Abschnitt definiert Eigenschaften des Übertragungsziels.
Type=
Legt den Ressourcentypen für das Ziel der Übertragung fest. Akzeptiert entweder partition,
regular-file, directory oder subvolume. Siehe oben für Details zu Ressourcentypen. Diese Option ist
verpflichtend.
Beachten Sie, dass wie oben dargestellt nur bestimmte Kombinationen von Quell- und
Zielressourcentypen unterstützt werden.
Hinzugefügt in Version 251.
Path=
Legt einen Dateisystempfad fest, unter dem nach bereits installierten Versionen gesucht oder in den
frisch für diese konfigurierte Ressource heruntergeladene Versionen abgelegt werden sollen. Falls
Type= auf partition gesetzt ist, wird ein Pfad zu einem (vollständigen) Plattengeräteknoten oder die
besondere Zeichenkette »auto« erwartet. Bei »auto« wird das Blockgerät, das das Wurzeldateisystem des
derzeit gestarteten Systems enthält, automatisch bestimmt und verwandt. Falls Type= auf regular-file,
directory oder subvolume gesetzt ist, muss sich dies auf einen Pfad im lokalen Dateisystem beziehen,
der das Verzeichnis referenziert, unter dem die Versionsdateien oder Verzeichnisse gefunden oder
diese darin abgelegt werden können.
Beachten Sie, dass dieser Mechanismus nicht zur Erstellung oder Entfernung von Partitionen verwandt
werden kann, falls Type= auf partition gesetzt ist. Partitionen müssen bereits existieren und die
besondere Partitionsbezeichnung »_empty« wird verwandt, um leere Partitionen anzuzeigen. Um beim
ersten Starten automatisch geeignete Partitionen zu erstellen, verwenden Sie bitte ein Werkzeug wie
systemd-repart(8).
Hinzugefügt in Version 251.
PathRelativeTo=
Legt den Ankerpunkt fest, zu dem Path= relativ sein soll. Akzeptiert entweder root, esp, xbootldr,
boot oder directory. Falls nicht angegeben standardmäßig root.
Falls auf boot, esp, xbootldr gesetzt, wird der festgelegte Path= relativ zu dem Einhängepunkt der
entsprechenden Partition aufgelöst, wie in der Systemladerspezifikation[2] festgelegt.
Falls auf boot gesetzt wird der festgelegte Path= relativ zu dem Einhängepunkt der Partition $BOOT
(d.h. dem ESP oder XBOOTLDR) aufgelöst, wie in der Systemladerspezifikation[2] festgelegt.
Falls auf explicit gesetzt, wird der festgelegte Path= relativ zu dem mit --transfer-source=
festgelegten Verzeichnis beim Aufruf mit systemd-sysupdate(8) aufgelöst.
Die Werte esp, xbootldr und boot werden nur unterstützt, falls Type= auf regular-file oder directory
gesetzt ist.
Hinzugefügt in Version 254.
MatchPattern=
Gibt eine oder mehrere Dateinamen- oder Partitionsbezeichnungsübereinstimmungsmuster als Ziel für
diese Übertragung an, die eine Teilmenge der Dateien oder Partitionen auswählen, die
Aktualisierungskandidaten sind. Siehe oben für Details zu Übereinstimmungsmustern.
Diese Option ist verpflichtend. Jedes aufgeführte Muster muss mindestens den Platzhalter »@v«
enthalten, so dass ein Versionskennzeichner aus dem Dateinamen ausgelesen werden kann. Alle anderen
Platzhalter sind optional.
Diese Muster werden sowohl zum Vergleich bestehender installierter Versionen als auch für die
Bestimmung des Namens von neu zu installierenden Versionen verwandt. Falls mehrere Muster festgelegt
sind, wird das erste festgelegte zur Benennung neu installierter Versionen verwandt.
Falls der Zieltyp regular-file oder directory ist, darf das Muster Schrägstrichzeichen enthalten. In
diesem Fall stimmt es mit der Datei oder dem Verzeichnis in dem entsprechenden Unterverzeichnis
überein. Beispielsweise wird »MatchPattern=foo_@v/bar.efi« mit »bar.efi« im Verzeichnis »foo_1«
übereinstimmen. Verzeichnisse und Pfade werden bei der Installation der Datei erstellt. Leere
Verzeichnisse werden beim Entfernen der Datei entfernt.
Hinzugefügt in Version 251.
MatchPartitionType=
Legt den zu ermittelnden GPT-Partitionstypen fest, falls der Ziel-Type= als partition ausgewählt
wurde. Es werden nur Partitionen von diesem Typ betrachtet, alle anderen Partitionen werden
ignoriert. Falls nicht angegeben, wird der GPT-Partitionstyp linux-generic verwandt. Akzeptiert
entweder eine direkte Typ-UUID oder eine symbolische Typbezeichnung. Siehe die Einstellung Type= in
repart.d(5) für eine Liste unterstützter Typbezeichnungen.
Hinzugefügt in Version 251.
PartitionUUID=, PartitionFlags=, PartitionNoAuto=, PartitionGrowFileSystem=
Wenn der Ziel-Type= als partition ausgewählt ist, wählt dies die GPT-Partitions-UUID und die
Partitions-Flags, die für die aktualisierten Partitionen zu verwenden sind. Erwartet eine gültige
UUID-Zeichenkette, eine hexadezimale Ganzzahl bzw. logische Werte. Falls nicht gesetzt, aber das
Quellvergleichsmuster Platzhalter für diese Felder enthält (d.h. »@u«, »@f«, »@a« oder »@g«), dann
werden die Werte von diesen Mustern verwandt. Falls weder mit Platzhaltern noch diesen expliziten
Einstellungen konfiguriert, werden die Werte nicht verändert. Falls sowohl die globalen
Flag-Einstellungen PartitionFlags= als auch die individuellen Flag-Einstellungen PartitionNoAuto= und
PartitionGrowFileSystem= verwandt werden (oder die Platzhalter für sie), dann setzen letztere erstere
außer Kraft, d.h. das individuelle Flag-Bit setzt die globalen Flag-Werte außer Kraft. Siehe die
Spezifikation für auffindbare Partitionen[1] für Details über diese Schalter.
Beachten Sie, dass diese Einstellungen nicht für Vergleiche verwandt werden. Sie werden nur bei
frisch geschriebenen Partitionen wirksam, falls eine Übertragung stattfindet.
Hinzugefügt in Version 251.
ReadOnly=
Steuert, ob die entstandene Datei, der Teildatenträger oder die Partition schreibgeschützt markiert
werden soll. Falls der Zieltyp partition ist, steuert dies das Partitions-Flag ReadOnly, gemäß der
Spezifikation für auffindbare Partitionen[1], ähnlich den oben beschriebenen Flags PartitionNoAuto=
und PartitionGrowFileSystem=. Falls der Zieltyp regular-file ist, wird das Schreib-Bit vom
Zugriffsmodus entfernt. Falls der Zieltyp subvolume ist, wird der Teildatenträger als Ganzes
schreibgeschützt markiert. Falls schließlich der Ziel-Type= als directory ausgewählt wird, dann wird
das Dateiattribut »immutable« gesetzt, siehe chattr(1) für Details.
Hinzugefügt in Version 251.
Mode=
Der für frisch erstellte Dateien zu verwendende UNIX-Dateizugriffsmodus, falls der Zielressourcentyp
als regular-file ausgewählt wird. Erwartet eine oktale Ganzzahl, in typischer UNIX-Art. Falls nicht
gesetzt, aber das Quellvergleichsmuster einen Platzhalter für dieses Feld enthält (d.h. »@t«), wird
der Wert von diesem Muster verwandt.
Beachten Sie, dass diese Einstellung nicht für Vergleiche verwandt wird. Sie wird nur bei frisch
geschriebenen Dateien wirksam, falls eine Übertragung stattfindet.
Hinzugefügt in Version 251.
TriesDone=, TriesLeft=
Diese Optionen akzeptieren positive dezimale Ganzzahlen und steuern die Anzahl der erfolgten und
verbleibenden Versuche für diese Datei. Diese Einstellungen sind zur Verwaltung von Kernelabbildern
nützlich, gemäß des in Automatische Systemstartbeurteilung[3] definierten Schematas und werden nur
wirksam, falls das Zielmuster die Platzhalter »@d« oder »@l« enthält.
Hinzugefügt in Version 251.
InstancesMax=
Akzeptiert eine dezimale Ganzahl gleich oder größer als 2. Dies konfiguriert, wie viele Versionen
einer Ressource gleichzeitig zu behalten sind. Immer wenn eine neue Aktualisierung eingeleitet wird,
wird sicher gestellt, dass nicht mehr als die Anzahl an hier angegebenen Versionen minus eine im Ziel
existieren. Sämtliche überschüssige Versionen werden gelöscht (falls der Ziel-Type= regular-file,
directory, subvolume verwandt wird) oder geleert (falls der Ziel-Type= partition verwandt wird;
Leeren bedeutet in diesem Fall einfach, dass die Partitionsbezeichnung auf die besondere Zeichenkette
»_empty« gesetzt wird; beachten Sie, dass keine Partitionen tatsächlich entfernt werden). Nach
Abschluss einer Aktualisierung ist die Anzahl der gleichzeitigen Versionen der Zielressource gleich
oder unterhalb der hier festgelegten Anzahl.
Beachten Sie, dass diese Einstellung für jede Übertragung anders gesetzt werden kann. Allerdings wird
im Allgemeinen empfohlen, diese Einstellung für alle Übertragungen identisch zu behalten, da
andernfalls unvollständige Kombinationen von Dateien oder Partitionen installiert verbleiben könnten.
Falls der Ziel-Type= als partition ausgewählt ist, wird die Anzahl der gleichzeitig zu behaltenden
Versionen zusätzlich durch die Anzahl der Partitionsplätze des richtigen Typs in der
Partitionstabelle beschränkt. Das bedeutet, falls es nur zwei Partitionsplätze für den ausgewählten
Partitionstyp gibt, hat das Setzen dieser Variable auf Werte größer als 2 keine Auswirkung, da
sowieso nicht mehr als 2 Versionen gleichzeitig in dem Abbild gespeichert werden können.
Hinzugefügt in Version 251.
RemoveTemporary=
Akzeptiert ein logisches Argument. Falls diese Option vor dem Einleiten einer Aktualisierung
aktiviert ist (was die Vorgabe ist), werden alle verbliebenen unvollständigen Aktualisierungen von
vorherigen Versuchen aus dem Zielverzeichnis entfernt. Dies wird nur wirksam, falls der
Ziel-Ressourcen-Type= als regular-file, directory oder subvolume ausgewählt ist.
Hinzugefügt in Version 251.
CurrentSymlink=
Akzeptiert einen Symlinknamen als Argument. Falls diese Option verwandt wird, wird als letzter
Schritt der Aktualisierung ein Symlink unter dem festgelegten Namen erstellt/aktualisiert, der auf
die abgeschlossene Aktualisierung zeigt. Dies ist nützlich, um immer einen stabilen Namen zu haben,
der auf die neuste Version der Ressource zeigt. Dies wird nur unterstützt, falls der Ziel-Type= als
regular-file, directory oder subvolume ausgewählt ist.
Hinzugefügt in Version 251.
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
┌─────────────┬────────────────────────────────┬───────────────────────────────────────────┐
│Kennzeichner │ Bedeutung │ Details │
├─────────────┼────────────────────────────────┼───────────────────────────────────────────┤
│"%a" │ Architektur │ Eine kurze Zeichenkette, die │
│ │ │ die Architektur des lokalen │
│ │ │ Systems identifiziert. Eine │
│ │ │ Zeichenkette wie x86, x86-64 │
│ │ │ oder arm64. Siehe die für │
│ │ │ ConditionArchitecture= in │
│ │ │ systemd.unit(5) definierten │
│ │ │ Architekturen für die │
│ │ │ vollständige Liste. │
├─────────────┼────────────────────────────────┼───────────────────────────────────────────┤
│"%A" │ Betriebssystemabbildversion │ Die │
│ │ │ Betriebssystemabbildversionskennzeichnung │
│ │ │ des laufenden Systems, wie │
│ │ │ aus dem Feld IMAGE_VERSION= │
│ │ │ in /etc/os-release │
│ │ │ ausgelesen. Falls nicht │
│ │ │ gesetzt, wird es zur leeren │
│ │ │ Zeichenkette aufgelöst. │
│ │ │ Siehe os-release(5) für │
│ │ │ weitere Informationen. │
├─────────────┼────────────────────────────────┼───────────────────────────────────────────┤
│"%b" │ Boot-Kennung │ Die Boot-Kennung des laufenden Systems, │
│ │ │ formatiert als Zeichenkette. Siehe │
│ │ │ random(4) für weitere Informationen. │
├─────────────┼────────────────────────────────┼───────────────────────────────────────────┤
│"%B" │ Betriebssystembaukennung │ Die Betriebssystembaukennung des │
│ │ │ laufenden Systems, wie aus dem Feld │
│ │ │ BUILD_ID= in /etc/os-release ausgelesen. │
│ │ │ Falls nicht gesetzt, wird es zur leeren │
│ │ │ Zeichenkette aufgelöst. Siehe │
│ │ │ os-release(5) für weitere Informationen. │
├─────────────┼────────────────────────────────┼───────────────────────────────────────────┤
│"%H" │ Rechnername │ Der Rechnername des laufenden Systems. │
├─────────────┼────────────────────────────────┼───────────────────────────────────────────┤
│"%l" │ Kurzer Rechnername │ Die Rechnername des laufenden Systems, │
│ │ │ abgeschnitten am ersten Punkt, um alle │
│ │ │ Domain-Komponenten zu entfernen. │
├─────────────┼────────────────────────────────┼───────────────────────────────────────────┤
│"%m" │ Maschinenkennung │ Die Maschinenkennung des laufenden │
│ │ │ Systems, formatiert als Zeichenkette. │
│ │ │ Siehe machine-id(5) für weitere │
│ │ │ Informationen. │
├─────────────┼────────────────────────────────┼───────────────────────────────────────────┤
│"%M" │ Betriebssystemabbildkennung │ Die Betriebssystemabbildkennung des │
│ │ │ laufenden Systems, wie aus dem Feld │
│ │ │ IMAGE_ID= in /etc/os-release ausgelesen. │
│ │ │ Falls nicht gesetzt, wird es die leere │
│ │ │ Zeichenkette. Siehe os-release(5) für │
│ │ │ weitere Informationen. │
├─────────────┼────────────────────────────────┼───────────────────────────────────────────┤
│"%o" │ Betriebssystemkennung │ Die Betriebssystemkennung des laufenden │
│ │ │ Systems, wie aus dem Feld ID= in │
│ │ │ /etc/os-release ausgelesen. Siehe │
│ │ │ os-release(5) für weitere Informationen. │
├─────────────┼────────────────────────────────┼───────────────────────────────────────────┤
│"%v" │ Kernelveröffentlichung │ Identisch zur Ausgabe von uname -r. │
├─────────────┼────────────────────────────────┼───────────────────────────────────────────┤
│"%w" │ Betriebssystemversionskennung │ Die Betriebssystemversionskennzeichnung │
│ │ │ des laufenden Systems, wie aus dem Feld │
│ │ │ VERSION_ID= in /etc/os-release │
│ │ │ ausgelesen. Falls nicht gesetzt, wird es │
│ │ │ die leere Zeichenkette. Siehe │
│ │ │ os-release(5) für weitere Informationen. │
├─────────────┼────────────────────────────────┼───────────────────────────────────────────┤
│"%W" │ Betriebssystemvariantenkennung │ Die Betriebssystemvariantenkennung des │
│ │ │ laufenden Systems, wie aus dem Feld │
│ │ │ VARIANT_ID= in /etc/os-release │
│ │ │ ausgelesen. Falls nicht gesetzt, wird es │
│ │ │ die leere Zeichenkette. Siehe │
│ │ │ os-release(5) für weitere Informationen. │
├─────────────┼────────────────────────────────┼───────────────────────────────────────────┤
│"%T" │ Verzeichnis für temporäre │ Dies ist entweder /tmp oder der Pfad, auf │
│ │ Dateien │ den »$TMPDIR«, »$TEMP« oder »$TMP« │
│ │ │ gesetzt ist. (Beachten Sie, dass das │
│ │ │ Verzeichnis ohne abschließenden │
│ │ │ Schrägstrich angegeben werden kann.) │
├─────────────┼────────────────────────────────┼───────────────────────────────────────────┤
│"%V" │ Verzeichnis für größere und │ Dies ist entweder /var/tmp oder der Pfad, │
│ │ dauerhafte temporäre Dateien │ auf den »$TMPDIR«, »$TEMP« oder »$TMP« │
│ │ │ gesetzt ist. (Beachten Sie, dass das │
│ │ │ Verzeichnis ohne abschließenden │
│ │ │ Schrägstrich angegeben werden kann.) │
├─────────────┼────────────────────────────────┼───────────────────────────────────────────┤
│"%%" │ Einzelnes Prozentzeichen │ Verwenden Sie »%%« anstelle von »%«, um │
│ │ │ ein einzelnes Prozentzeichen anzugeben. │
└─────────────┴────────────────────────────────┴───────────────────────────────────────────┘
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.transfer
[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.transfer
[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.transfer
[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:
• SHA256SUMS — Die Manifest-Datei, die die verfügbaren Dateien und ihre SHA256-Hashes enthält
• SHA256SUMS.gpg — Die abgetrennte kryptographische Signatur für die Manifest-Datei
• foobarOS_7_8b8186b1-2b4e-4eb6-ad39-8d4d18d2a8fb.verity.xz — Das Verity-Abbild für Version 7
• foobarOS_7_f4d1234f-3ebf-47c4-b31d-4052982f9a2f.root.xz — Das Wurzeldateisystemabbild für Version 7
• foobarOS_7_efi.xz – Das vereinigte Kernel-Abbild für Version 7
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
https://uapi-group.org/specifications/specs/discoverable_partitions_specification
2. Systemladerspezifikation
https://uapi-group.org/specifications/specs/boot_loader_specification
3. Automatische Systemstartbeurteilung
https://systemd.io/AUTOMATIC_BOOT_ASSESSMENT
4. AppStream-Katalog
https://www.freedesktop.org/software/appstream/docs/chap-CatalogData.html
5. besondere Metadaten
https://systemd.io/APPSTREAM_BUNDLE
Ü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 ⟨https://www.gnu.org/licenses/gpl-3.0.html⟩ 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 ⟨debian-l10n-german@lists.debian.org⟩.