SYSUPDATE.D(5) | sysupdate.d | SYSUPDATE.D(5) |
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
Kennzeichner | Beschreibung | Als Quelle verwendbar | Wenn als Quelle verwandt: Kompatible Ziele | Wenn als Quelle verwandt: Integrität + Authentizität | Wenn als Quelle verwandt: Dekomprimierung | Als Ziel verwendbar | Wenn als Ziel verwandt: Kompatible Quellen |
url-file | HTTP/HTTPS-Dateien | ja | regular-file, partition | ja | ja | nein | - |
url-tar | HTTP/HTTPS .tar-Archive | ja | directory, subvolume | ja | ja | nein | - |
regular-file | Lokale Dateien | ja | regular-file, partition | nein | ja | ja | url-file, regular-file |
partition | Lokale GPT-Partitionen | nein | - | - | - | ja | url-file, regular-file |
tar | Lokales .tar-Archiv | ja | directory, subvolume | nein | ja | nein | - |
directory | Lokales Verzeichnis | ja | directory, subvolume | nein | nein | ja | url-tar, tar, directory, subvolume |
subvolume | Lokaler Btrfs-Teildatenträger | ja | directory, subvolume | nein | nein | ja | url-tar, 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 Versionszeichenkette | Verpflichtend |
"@u" | GPT-Partitions-UUID | Gültige 128-bit-UUID-Zeichenkette | nur relevant, falls als Zielressourcentyp partition ausgewählt wurde |
"@f" | GPT-Partitions-Flags | formatierte hexadezimale Ganzzahl | nur relevant, falls als Zielressourcentyp partition ausgewählt wurde |
"@a" | GPT Partitions-Flag NoAuto | Entweder »0« oder »1« | Steuert das Bit 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 GrowFileSystem | Entweder »0« oder »1« | Steuert das Bit 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 Ganzzahl µs seit dem Beginn der Unix-Zeitrechnung (»Epoch«, 1. Januar 1970) | nur relevant, falls der ausgewählte Zielressourcentyp regular-file ist |
"@m" | Dateizugriffsmodus | Formatierte oktale Ganzzahl, auf UNIX-Art | nur relevant, falls der ausgewählte Zielressourcentyp regular-file ist |
"@s" | Dateigröße nach Dekomprimierung | Formatierte dezimale Ganzzahl | nützlich zum Messen des Fortschritts und zur Verbesserung der Partitionszuweisungslogik |
"@d" | Erfolgte Versuche | Formatierte dezimale Ganzzahl | nützlich beim Umgang mit Kernel-Abbilddateien, gemäß der Automatische Systemstartbeurteilung[3] |
"@l" | Verbliebene Versuche | Formatierte dezimale Ganzzahl | nützlich beim Umgang mit Kernel-Abbilddateien, gemäß der Automatische Systemstartbeurteilung[3] |
"@h" | SHA256-Hash der komprimierten Datei | 64 hexadezimale Zeichen | Der SHA256-Hash der 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=
Hinzugefügt in Version 251.
ProtectVersion=
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=
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.
[SOURCE]-ABSCHNITT-OPTIONEN¶
Dieser Abschnitt definiert Eigenschaften der Übertragungsquelle.
Type=
Beachten Sie, dass wie oben dargestellt nur bestimmte Kombinationen von Quell- und Zielressourcentypen unterstützt werden.
Hinzugefügt in Version 251.
Path=
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=
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=
Beachten Sie, dass wie oben dargestellt nur bestimmte Kombinationen von Quell- und Zielressourcentypen unterstützt werden.
Hinzugefügt in Version 251.
Path=
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=
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.
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=
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=
Hinzugefügt in Version 251.
PartitionUUID=, PartitionFlags=, PartitionNoAuto=, PartitionGrowFileSystem=
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=
Hinzugefügt in Version 251.
Mode=
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=
Hinzugefügt in Version 251.
InstancesMax=
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=
Hinzugefügt in Version 251.
CurrentSymlink=
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 die leere Zeichenkette. 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 Dateien | Dies ist entweder /tmp oder der Pfad, auf 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 dauerhafte temporäre Dateien | Dies ist entweder /var/tmp oder der Pfad, 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.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¶
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.
systemd 255 |