SYSUPDATE.D(5) sysupdate.d SYSUPDATE.D(5) BEZEICHNUNG sysupdate.d - Definitionsdateien fur automatische Aktualisierungen ubertragen UBERSICHT /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 Ubertragung: 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 fur das Betriebssystem selbst, fur Container, portable Dienste oder System-Erweiterungsabbilder verwandt werden -- kann aber tatsachlich 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 fuhrt 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 Ubertragung, d.h. beschreibt eine zu aktualisierende Ressource. Typischerweise werden mehrerer dieser Dateien zusammen definiert (d.h. mehrere solche Ubertragungen) 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 enthalt drei Abschnitte: [Transfer], [Source] und [Target]. GRUNDLEGENDER AKTIONSMODUS Plattenbasierte Betriebssystemaktualisierungen bestehen typischerweise aus mehreren verschiedenen Ressourcen, die zusammen aktualisiert werden mussen. Beispielsweise konnte eine sichere Betriebssystemaktualisierung aus einem Wurzeldateisystem-Abbild bestehen, das in eine Partition abgelegt werden muss, einem passenden Verity-Integritatsdaten-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 regularen Datei im Systemstart-Dateisystem abgelegt wird (z.B. der EFI-System-Partition). Wahrend 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 fur x86-64 geschrieben werden, wie in Spezifikation fur 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 fur Verity-Integritatsinformationen fur x86-64-Wurzeldateisysteme). 3. Schliesslich sollte eine Datei >>https://download.example.com/foobarOS_47.efi.xz<< (ein gemass 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 versionsunabhangige Verallgemeinerung davon ware Folgendes (mit der besonderen Markierung >>@v<< als Platzhalter fur die Versionskennzeichnung): 1. Eine Ubertragung 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 Ubertragung 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 Ubertragung 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 fur die gleiche Version bereitstellen, d.h. fur den gleichen Wert von >>@v<<. Obiges Vorgehen kann in drei *.conf-Dateien in sysupdate.d/ ubersetzt werden, je eine fur jede Ubertragung. 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 heissen und wie sie auf dem Ziel benannt werden sollen. Um die verfugbaren Versionen aufzuzahlen und Kandidaten fur die Aktualisierung herauszufinden, ist ein Mechanismus zur Auflistung geeigneter Dateien notwendig: o Fur Partitionen: die umgebende GPT-Partitionstabelle enthalt eine Liste von definierten Partitionen, einschliesslich einer Partitionstyp-UUID und einer Partitionsbezeichnung (in diesem Schema spielt die Partitionsbezeichnung eine Rolle fur Partitionen ahnlich wie der Dateiname fur eine regulare Datei). o Fur regulare Dateien: die Verzeichnisauflistung des Verzeichnisses, in dem sich die Dateien befinden, zeigt die existierenden Dateien direkt an. o Fur 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. Ubertragungen 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 fur alle definierten Ubertragungen abgeschlossen ist, werden in einem zweiten Schritt die Dateien/Verzeichnisse/Partitionen in ihre endgultigen Namen, wie in MatchPattern= vom Ziel definiert, umbenannt, wieder in der Reihenfolge, die die .conf-Ubertragungen 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 Ubertragungen typischerweise den Einstiegspunkt beim Systemstart. Daher ist es im Allgemeinen eine gute Idee, die Ressourcen mittels der Ubertragungskonfigurationsdateinamen so zu sortieren, dass der Einstiegspunkt zuletzt geschrieben wird, um sicherzustellen, dass jede ungewohnliche Beendigung keinen Einstiegspunkt zurucklasst, dessen Hinterlegung noch nicht etabliert wurde. Im obigen Beispiel ware es daher sinnvoll, das EFI-Kernel-Abbild zuletzt zu etablieren und daher der Ubertragungskonfigurationsdatei den alphabetisch betrachtet hintersten Namen zu geben. Ein erweitertes, gegenuber oben spezielleres Beispiel finden Sie weiter unten. RESSOURCENTYPEN Jede Ubertragungsdatei definiert eine Quellressource, die zu einer Zielressource ubertragen werden soll. Es werden die folgenden Ressourcentypen unterstutzt: 1. Ressourcen vom Typ >>url-file<< kapseln eine Datei auf einem Webserver und werden uber 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 fur Quellen verfugbar, nicht fur Ziele. Die Liste der verfugbaren Versionen einer Ressource dieses Typs wird in SHA256SUMS-Manifest-Dateien kodiert, zusammen mit losgelosten SHA256SUMS.gpg-Signaturen. 2. Der Ressourcentyp >>url-tar<< ist ahnlich, aber die Datei muss ein .tar-Archiv sein. Wenn eine Aktualisierung stattfindet, dann wird die Datei dekomprimiert und in ein Verzeichnis oder einen BTRFS-Teildatentrager entpackt. Dieser Ressourcentyp ist nur fur Quellen verfugbar, nicht fur Ziele. Wie bei >>url-file<< erfolgt die Versionsaufzahlung von >>url-tar<< unter Verwendung von SHA256SUMS-Dateien, authentifiziert mittels SHA256SUMS.gpg. 3. Der Ressourcentyp >>regular-file<< kapselt eine lokale regulare 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 verfugbar. Wahrend der Aktualisierung erfolgt keine Integritats- oder Authentizitatprufung fur Ressourcen dieses Typs. 4. Der Ressourcentyp >>partition<< ist ahnlich zu >>regular-file<< und kapselt eine GPT-Partition auf Platte. Beim Aktualisieren muss die Partition bereits existieren und uber einen korrekten GPT-Partitionstypen verfugen. 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 fur Zielressourcen verfugbar. 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-Teildatentrager entpackt. Das Verhalten von >>tar<< und >>url-tar<< ist im Allgemeinen ahnlich, aber Letzteres ladt von fernen Quellen herunter und fuhrt Integritats- und Authentifizierungsprufungen durch, wahrend das bei ersterem nicht der Fall ist. Der Ressourcentyp >>tar<< ist nur fur Quellressourcen verfugbar. 6. Der Ressourcentyp >>directory<< kapselt lokale Verzeichnisbaume. Dieser Typ ist sowohl als Quellen- als auch als Zielressource verfugbar. Falls eine Aktualisierung bei einer Quellressource von diesem Typ stattfindet, erfolgt eine rekursive Kopie des Verzeichnisses. 7. Der Ressourcentyp >>subvolume<< ist identisch zu >>directory<<, ausser dass bei der Verwendung als Ziel der Dateibaum in einen Btrfs-Teildatentrager statt in ein einfaches Verzeichnis abgelegt wird, falls das zugrundeliegende Dateisystem dies unterstutzt (d.h. Btrfs ist). Wie bereits dargestellt, wird nur eine Untermenge der Kombinationen der Quell- und Zielressourcentypen unterstutzt: Tabelle 1. Ressourcentypen +-------------+-------------------------+------------+---------------+-----------------+-----------------+------------+--------------+ |Kennzeichner | Beschreibung | Als Quelle | Wenn als | Wenn als Quelle | Wenn als Quelle | Als Ziel | Wenn als | | | | verwendbar | Quelle | verwandt: | verwandt: | verwendbar | Ziel | | | | | verwandt: | Integritat + | Dekomprimierung | | verwandt: | | | | | Kompatible | Authentizitat | | | Kompatible | | | | | Ziele | | | | Quellen | +-------------+-------------------------+------------+---------------+-----------------+-----------------+------------+--------------+ |url-file | HTTP/HTTPS-Dateien | ja | regular-file, | ja | ja | nein | - | | | | | partition | | | | | +-------------+-------------------------+------------+---------------+-----------------+-----------------+------------+--------------+ |url-tar | HTTP/HTTPS .tar-Archive | ja | directory, | ja | ja | nein | - | | | | | subvolume | | | | | +-------------+-------------------------+------------+---------------+-----------------+-----------------+------------+--------------+ |regular-file | Lokale Dateien | ja | regular-file, | nein | ja | ja | url-file, | | | | | partition | | | | regular-file | +-------------+-------------------------+------------+---------------+-----------------+-----------------+------------+--------------+ |partition | Lokale GPT-Partitionen | nein | - | - | - | ja | url-file, | | | | | | | | | regular-file | +-------------+-------------------------+------------+---------------+-----------------+-----------------+------------+--------------+ |tar | Lokales .tar-Archiv | ja | directory, | nein | ja | nein | - | | | | | subvolume | | | | | +-------------+-------------------------+------------+---------------+-----------------+-----------------+------------+--------------+ |directory | Lokales Verzeichnis | ja | directory, | nein | nein | ja | url-tar, | | | | | subvolume | | | | tar, | | | | | | | | | directory, | | | | | | | | | subvolume | +-------------+-------------------------+------------+---------------+-----------------+-----------------+------------+--------------+ |subvolume | Lokaler | ja | directory, | nein | nein | ja | url-tar, | | | Btrfs-Teildatentrager | | subvolume | | | | tar, | | | | | | | | | directory, | | | | | | | | | subvolume | +-------------+-------------------------+------------+---------------+-----------------+-----------------+------------+--------------+ UBEREINSTIMMUNGSMUSTER 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 Eintrage daraus ausgewahlt und der Versionskennzeichner wird aus den Dateinamen oder Partitionsbezeichnungen dieser ausgewahlten Eintrage herausgelost. Auswahl der Teilmenge und das Herauslosen des Versionskennzeichners (sowie moglicherweise weiterer Metadaten) erfolgt mittels Ubereinstimmungsmustern, die in den Abschnitten [Source] und [Target] uber MatchPattern= konfiguriert werden. Diese Muster sind Zeichenketten, die beschreiben, wie Dateien oder Partitionen benannt sind, mit benannten Platzhaltern fur bestimmte Felder wie den Versionskennzeichner. Die folgenden Platzhalter sind definiert: Tabelle 2. Platzhalter fur Ubereinstimmungsmuster +------------+-------------------------+---------------------------+---------------------------+ |Platzhalter | Beschreibung | Format | Hinweise | +------------+-------------------------+---------------------------+---------------------------+ |"@v" | Versionskennzeichner | Gultige | Verpflichtend | | | | Versionszeichenkette | | +------------+-------------------------+---------------------------+---------------------------+ |"@u" | GPT-Partitions-UUID | Gultige | nur relevant, falls als | | | | 128-bit-UUID-Zeichenkette | Zielressourcentyp | | | | | partition ausgewahlt | | | | | wurde | +------------+-------------------------+---------------------------+---------------------------+ |"@f" | GPT-Partitions-Flags | formatierte hexadezimale | nur relevant, falls als | | | | Ganzzahl | Zielressourcentyp | | | | | partition ausgewahlt | | | | | wurde | +------------+-------------------------+---------------------------+---------------------------+ |"@a" | GPT Partitions-Flag | Entweder >>0<< oder >>1<< | Steuert das Bit NoAuto | | | NoAuto | | der GPT-Partitions-Flags, | | | | | gemass der Spezifikation | | | | | fur auffindbare | | | | | Partitionen[1]; nur | | | | | relevant, falls der | | | | | ausgewahlte | | | | | Zielressourcentyp | | | | | partition ist | +------------+-------------------------+---------------------------+---------------------------+ |"@g" | GPT Partitions-Flag | Entweder >>0<< oder >>1<< | Steuert das Bit | | | GrowFileSystem | | GrowFileSystem der | | | | | GPT-Partitions-Flags, | | | | | gemass der Spezifikation | | | | | fur auffindbare | | | | | Partitionen[1]; nur | | | | | relevant, falls der | | | | | ausgewahlte | | | | | Zielressourcentyp | | | | | partition ist | +------------+-------------------------+---------------------------+---------------------------+ |"@r" | Schreibgeschutzt-Flag | Entweder >>0<< oder >>1<< | Steuert das Bit ReadOnly | | | | | der GPT-Partitions-Flags, | | | | | gemass der Spezifikation | | | | | fur auffindbare | | | | | Partitionen[1]; und | | | | | andere ausgabebezogene | | | | | Schreibschutz-Flags; | | | | | siehe nachfolgendes | | | | | ReadOnly= | +------------+-------------------------+---------------------------+---------------------------+ |"@t" | Dateiveranderungszeit | Formatierte dezimale | nur relevant, falls der | | | | Ganzzahl s seit | ausgewahlte | | | | dem Beginn der | Zielressourcentyp | | | | Unix-Zeitrechnung | regular-file ist | | | | (>>Epoch<<, 1. Januar | | | | | 1970) | | +------------+-------------------------+---------------------------+---------------------------+ |"@m" | Dateizugriffsmodus | Formatierte oktale | nur relevant, falls der | | | | Ganzzahl, auf UNIX-Art | ausgewahlte | | | | | Zielressourcentyp | | | | | regular-file ist | +------------+-------------------------+---------------------------+---------------------------+ |"@s" | Dateigrosse nach | Formatierte dezimale | nutzlich zum Messen des | | | Dekomprimierung | Ganzzahl | Fortschritts und zur | | | | | Verbesserung der | | | | | Partitionszuweisungslogik | +------------+-------------------------+---------------------------+---------------------------+ |"@d" | Erfolgte Versuche | Formatierte dezimale | nutzlich beim Umgang mit | | | | Ganzzahl | Kernel-Abbilddateien, | | | | | gemass der Automatische | | | | | Systemstartbeurteilung[3] | +------------+-------------------------+---------------------------+---------------------------+ |"@l" | Verbliebene Versuche | Formatierte dezimale | nutzlich beim Umgang mit | | | | Ganzzahl | Kernel-Abbilddateien, | | | | | gemass der Automatische | | | | | Systemstartbeurteilung[3] | +------------+-------------------------+---------------------------+---------------------------+ |"@h" | SHA256-Hash der | 64 hexadezimale Zeichen | Der SHA256-Hash der | | | komprimierten Datei | | komprimierten Datei; fur | | | | | url-file und url-tar | | | | | nicht nutzlich, da dort | | | | | der SHA256-Hash bereits | | | | | in der Manifest-Datei | | | | | enthalten ist | +------------+-------------------------+---------------------------+---------------------------+ Von diesen Platzhaltern muss nur >>@v<< in einem gultigen Muster vorhanden sein, alle anderen Platzhalter sind optional. Jeder Platzhalter darf hochstens einmal in jedem Muster verwandt werden. Ein typischer Platzhalter, der auf ein Dateisystemquellabbild passt, konnte >>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 >>@<<-Mustervergleichsplatzhalterprafix nicht mit dem >>%<<-Kennzeichnerexpansionsprafix. Ersterer kapselt einen variablen Anteil einer Vergleichsmusterzeichenkette, Letzterer ist eine einfache Abkurzung, die erweitert wird, wenn Erganzungsdateien vorhanden sind. Details zu Kennzeichnern finden Sie nachfolgend. [TRANSFER]-ABSCHNITT-OPTIONEN Dieser Abschnitt definiert allgemeine Eigenschaften dieser Ubertragung: MinVersion= Gibt die minimale Version an, die notwendig ist, damit diese Ubertragung stattfinden kann. Falls die Quell- oder Zielmuster in dieser Ubertragungsdefinition auf Dateien passen, die alter als diese Version sind, werden diese als veraltet betrachtet und niemals fur eine Aktualisierungsaktion berucksichtigt. Hinzugefugt in Version 251. ProtectVersion= Akzeptiert eine oder mehrere Versionszeichenketten, die als >>geschutzt<< markiert werden sollen. Geschutzte Versionen werden niemals entfernt, um Platz fur neue, aktualisierte Versionen zu schaffen. Dies ist nutzlich, um sicherzustellen, dass die derzeit gestartete Betriebssystemversion (oder ihr zugeordnete Hilfsressourcen) nicht wahrend Aktualisierungen ersetzt/uberschrieben werden, um Beschadigungen des Dateisystems zur Laufzeit zu vermeiden. Wie viele Einstellungen in diesen Konfigurationsdateien unterstutzt diese Einstellung Kennzeichnererweiterungen. Es ist besonders nutzlich, 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 unterstutzten Kennzeichnern finden Sie nachfolgend. Hinzugefugt in Version 251. Verify= Akzeptiert einen logischen Wert, standardmassig ja. Steuert, ob heruntergeladene Ressourcen kryptographisch uberpruft werden sollen (insbesondere: GPG-Signaturen fur heruntergeladene SHA256SUMS-Manifestdateien uber ihre abgetrennten Signaturdateien SHA256SUMS.gpg im Zusammenspiel mit dem Systemschlusselbund /usr/lib/systemd/import-pubring.gpg oder /etc/systemd/import-pubring.gpg validiert werden). Diese Option ist wesentlich, um Integritatsgarantien fur heruntergeladene Ressourcen bereitzustellen und sollte daher ausserhalb von Testumgebungen aktiviert bleiben. Beachten Sie, dass die heruntergeladenen Nutzlastdateien bedingungslos gegen die in dem Manifest aufgefuhrten SHA256-Hashes gepruft werden. Diese Option steuert nur, ob die Signaturen dieser Manifeste verifiziert werden. Diese Option ist nur wirksam, falls der ausgewahlte Ressourcentyp url-file oder url-tar ist, da Integritats- und Authentizitatsprufung nur fur Ubertragungen von fernen Rechnern verfugbar ist. Hinzugefugt in Version 251. [SOURCE]-ABSCHNITT-OPTIONEN Dieser Abschnitt definiert Eigenschaften der Ubertragungsquelle. Type= Legt den Ressourcentyp fur die Quelle der Ubertragung 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 unterstutzt werden. Hinzugefugt in Version 251. Path= Legt fest, wo die Quellversionen dieser Ressource zu finden sind. Falls der Quelltyp als url-file oder url-tar ausgewahlt wurde, muss dies eine HTTP/HTTPS-URL sein. Der URL wird /SHA256SUMS angehangt, um die Manifest-Datei zu erlangen, /SHA256SUMS.gpg, um die abgetrennte Signaturdatei dafur zu erlangen und den in der Manifestdatei aufgefuhrten Dateinamen, falls eine Aktualisierung ausgefuhrt wird und eine Ressource heruntergeladen werden soll. Fur 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 konnen. Hinzugefugt in Version 251. MatchPattern= Gibt eine oder mehrere Dateinamenubereinstimmungslisten als Quelle fur diese Ubertragung an, die eine Teilmenge der Dateien auswahlen, die Aktualisierungskandidaten sind. Siehe oben fur Details zu Ubereinstimmungsmustern. Diese Option ist verpflichtend. Jedes aufgefuhrte 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 Schragstrichzeichen enthalten. In diesem Fall stimmt es mit der Datei oder dem Verzeichnis in dem entsprechenden Unterverzeichnis uberein. Beispielsweise wird >>MatchPattern=foo_@v/bar.efi<< mit >>bar.efi<< im Verzeichnis >>foo_1<< ubereinstimmen. Hinzugefugt in Version 251. [TARGET]-ABSCHNITT-OPTIONEN Dieser Abschnitt definiert Eigenschaften des Ubertragungsziels. Type= Legt den Ressourcentypen fur das Ziel der Ubertragung fest. Akzeptiert entweder partition, regular-file, directory oder subvolume. Siehe oben fur Details zu Ressourcentypen. Diese Option ist verpflichtend. Beachten Sie, dass wie oben dargestellt nur bestimmte Kombinationen von Quell- und Zielressourcentypen unterstutzt werden. Hinzugefugt in Version 251. Path= Legt einen Dateisystempfad fest, unter dem nach bereits installierten Versionen gesucht oder in den frisch fur diese konfigurierte Ressource heruntergeladene Versionen abgelegt werden sollen. Falls Type= auf partition gesetzt ist, wird ein Pfad zu einem (vollstandigen) Plattengerateknoten oder die besondere Zeichenkette >>auto<< erwartet. Bei >>auto<< wird das Blockgerat, das das Wurzeldateisystem des derzeit gestarteten Systems enthalt, 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 konnen. Beachten Sie, dass dieser Mechanismus nicht zur Erstellung oder Entfernung von Partitionen verwandt werden kann, falls Type= auf partition gesetzt ist. Partitionen mussen 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). Hinzugefugt in Version 251. PathRelativeTo= Legt die Partition fest, zu der Path= relativ sein soll. Akzeptiert entweder root, esp, xbootldr oder boot. Falls nicht angegeben standardmassig root. Falls auf boot gesetzt wird der festgelegte Path= relativ zu dem Einhangepunkt der Partition $BOOT (d.h. dem ESP oder XBOOTLDR) aufgelost, wie in der Systemladerspezifikation[2] festgelegt. Die Werte esp, xbootldr und boot werden nur unterstutzt, falls Type= auf regular-file oder directory gesetzt ist. Hinzugefugt in Version 254. MatchPattern= Gibt eine oder mehrere Dateinamen- oder Partitionsbezeichnungsubereinstimmungsmuster als Ziel fur diese Ubertragung an, die eine Teilmenge der Dateien oder Partitionen auswahlen, die Aktualisierungskandidaten sind. Siehe oben fur Details zu Ubereinstimmungsmustern. Diese Option ist verpflichtend. Jedes aufgefuhrte 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 fur 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 Schragstrichzeichen enthalten. In diesem Fall stimmt es mit der Datei oder dem Verzeichnis in dem entsprechenden Unterverzeichnis uberein. Beispielsweise wird >>MatchPattern=foo_@v/bar.efi<< mit >>bar.efi<< im Verzeichnis >>foo_1<< ubereinstimmen. Verzeichnisse und Pfade werden bei der Installation der Datei erstellt. Leere Verzeichnisse werden beim Entfernen der Datei entfernt. Hinzugefugt in Version 251. MatchPartitionType= Legt den zu ermittelnden GPT-Partitionstypen fest, falls der Ziel-Type= als partition ausgewahlt 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) fur eine Liste unterstutzter Typbezeichnungen. Hinzugefugt in Version 251. PartitionUUID=, PartitionFlags=, PartitionNoAuto=, PartitionGrowFileSystem= Wenn der Ziel-Type= als partition ausgewahlt ist, wahlt dies die GPT-Partitions-UUID und die Partitions-Flags, die fur die aktualisierten Partitionen zu verwenden sind. Erwartet eine gultige UUID-Zeichenkette, eine hexadezimale Ganzzahl bzw. logische Werte. Falls nicht gesetzt, aber das Quellvergleichsmuster Platzhalter fur diese Felder enthalt (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 verandert. Falls sowohl die globalen Flag-Einstellungen PartitionFlags= als auch die individuellen Flag-Einstellungen PartitionNoAuto= und PartitionGrowFileSystem= verwandt werden (oder die Platzhalter fur sie), dann setzen letztere erstere ausser Kraft, d.h. das individuelle Flag-Bit setzt die globalen Flag-Werte ausser Kraft. Siehe die Spezifikation fur auffindbare Partitionen[1] fur Details uber diese Schalter. Beachten Sie, dass diese Einstellungen nicht fur Vergleiche verwandt werden. Sie werden nur bei frisch geschriebenen Partitionen wirksam, falls eine Ubertragung stattfindet. Hinzugefugt in Version 251. ReadOnly= Steuert, ob die entstandene Datei, der Teildatentrager oder die Partition schreibgeschutzt markiert werden soll. Falls der Zieltyp partition ist, steuert dies das Partitions-Flag ReadOnly, gemass der Spezifikation fur auffindbare Partitionen[1], ahnlich 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 Teildatentrager als Ganzes schreibgeschutzt markiert. Falls schliesslich der Ziel-Type= als directory ausgewahlt wird, dann wird das Dateiattribut >>immutable<< gesetzt, siehe chattr(1) fur Details. Hinzugefugt in Version 251. Mode= Der fur frisch erstellte Dateien zu verwendende UNIX-Dateizugriffsmodus, falls der Zielressourcentyp als regular-file ausgewahlt wird. Erwartet eine oktale Ganzzahl, in typischer UNIX-Art. Falls nicht gesetzt, aber das Quellvergleichsmuster einen Platzhalter fur dieses Feld enthalt (d.h. >>@t<<), wird der Wert von diesem Muster verwandt. Beachten Sie, dass diese Einstellung nicht fur Vergleiche verwandt wird. Sie wird nur bei frisch geschriebenen Dateien wirksam, falls eine Ubertragung stattfindet. Hinzugefugt in Version 251. TriesDone=, TriesLeft= Diese Optionen akzeptieren positive dezimale Ganzzahlen und steuern die Anzahl der erfolgten und verbleibenden Versuche fur diese Datei. Diese Einstellungen sind zur Verwaltung von Kernelabbildern nutzlich, gemass des in Automatische Systemstartbeurteilung[3] definierten Schematas und werden nur wirksam, falls das Zielmuster die Platzhalter >>@d<< oder >>@l<< enthalt. Hinzugefugt in Version 251. InstancesMax= Akzeptiert eine dezimale Ganzahl gleich oder grosser 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. Samtliche uberschussige Versionen werden geloscht (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 tatsachlich 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 fur jede Ubertragung anders gesetzt werden kann. Allerdings wird im Allgemeinen empfohlen, diese Einstellung fur alle Ubertragungen identisch zu behalten, da andernfalls unvollstandige Kombinationen von Dateien oder Partitionen installiert verbleiben konnten. Falls der Ziel-Type= als partition ausgewahlt ist, wird die Anzahl der gleichzeitig zu behaltenden Versionen zusatzlich durch die Anzahl der Partitionsplatze des richtigen Typs in der Partitionstabelle beschrankt. Das bedeutet, falls es nur zwei Partitionsplatze fur den ausgewahlten Partitionstyp gibt, hat das Setzen dieser Variable auf Werte grosser als 2 keine Auswirkung, da sowieso nicht mehr als 2 Versionen gleichzeitig in dem Abbild gespeichert werden konnen. Hinzugefugt 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 unvollstandigen Aktualisierungen von vorherigen Versuchen aus dem Zielverzeichnis entfernt. Dies wird nur wirksam, falls der Ziel-Ressourcen-Type= als regular-file, directory oder subvolume ausgewahlt ist. Hinzugefugt 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 nutzlich, um immer einen stabilen Namen zu haben, der auf die neuste Version der Ressource zeigt. Dies wird nur unterstutzt, falls der Ziel-Type= als regular-file, directory oder subvolume ausgewahlt ist. Hinzugefugt in Version 251. KENNZEICHNER In den Einstellungen MinVersion=, ProtectVersion=, Path=, MatchPattern= und CurrentSymlink= konnen Kennzeichner verwandt werden. Die folgenden Expansionen werden verstanden: Tabelle 3. Verfugbare 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 fur | | | | ConditionArchitecture= in systemd.unit(5) | | | | definierten Architekturen fur die | | | | vollstandige 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) fur weitere Informationen. | +-------------+--------------------------------+-------------------------------------------+ |"%b" | Boot-Kennung | Die Boot-Kennung des laufenden Systems, | | | | formatiert als Zeichenkette. Siehe | | | | random(4) fur 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 aufgelost. Siehe | | | | os-release(5) fur 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) fur 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) fur | | | | weitere Informationen. | +-------------+--------------------------------+-------------------------------------------+ |"%o" | Betriebssystemkennung | Die Betriebssystemkennung des laufenden | | | | Systems, wie aus dem Feld ID= in | | | | /etc/os-release ausgelesen. Siehe | | | | os-release(5) fur weitere Informationen. | +-------------+--------------------------------+-------------------------------------------+ |"%v" | Kernelveroffentlichung | 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) fur 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) fur weitere Informationen. | +-------------+--------------------------------+-------------------------------------------+ |"%T" | Verzeichnis fur temporare | Dies ist entweder /tmp oder der Pfad, auf | | | Dateien | den >>$TMPDIR<<, >>$TEMP<< oder >>$TMP<< | | | | gesetzt ist. (Beachten Sie, dass das | | | | Verzeichnis ohne abschliessenden | | | | Schragstrich angegeben werden kann.) | +-------------+--------------------------------+-------------------------------------------+ |"%V" | Verzeichnis fur grossere und | Dies ist entweder /var/tmp oder der Pfad, | | | dauerhafte temporare Dateien | auf den >>$TMPDIR<<, >>$TEMP<< oder | | | | >>$TMP<< gesetzt ist. (Beachten Sie, dass | | | | das Verzeichnis ohne abschliessenden | | | | Schragstrich angegeben werden kann.) | +-------------+--------------------------------+-------------------------------------------+ |"%%" | Einzelnes Prozentzeichen | Verwenden Sie >>%%<< anstelle von >>%<<, | | | | um ein einzelnes Prozentzeichen | | | | anzugeben. | +-------------+--------------------------------+-------------------------------------------+ Bringen Sie das Kennzeichnerprafix >>%<< nicht mit dem Mustervergleichs-Platzhalterprafix >>@<< durcheinander. Das erstere ist eine einfache Abkurzung, die expandiert wird, wahrend Erganzungsdateien ausgewertet werden, letzteres kapselt einen variablen Anteil einer Mustervergleichszeichenkette. Details zu Mustervergleichs-Platzhaltern finden sie weiter oben. BEISPIELE Beispiel 1. Aktualisierungen fur 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 fur 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 schreibgeschutzt markiert ist. Unter der Annahme, dass diese Aktualisierung aus dem Abbild selbst heraus ausgefuhrt wird, wird die aktuelle Abbildversion (d.h. der >>%A<<-Kennzeichner) als geschutzt markiert, um sicherzustellen, dass sie beim Systemstart nicht beschadigt wird. Beachten Sie, dass die Partitions-UUID fur die Ziel-Partition im Quelldateinamen kodiert ist. Fixierung der Partitions-UUID kann nutzlich 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) vorschlagt). # /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 fur 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, gemass der Systemladerspezifikation[2] Typ #2. Dies definiert drei mogliche Muster fur die Namen der Kernel-Abbilder, gemass 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 wurde der Webserver die folgenden Dateien fur eine hypothetische Version 7 des Betriebssystems ausliefern: o SHA256SUMS -- Die Manifest-Datei, die die verfugbaren Dateien und ihre SHA256-Hashes enthalt o SHA256SUMS.gpg -- Die abgetrennte kryptographische Signatur fur die Manifest-Datei o foobarOS_7_8b8186b1-2b4e-4eb6-ad39-8d4d18d2a8fb.verity.xz -- Das Verity-Abbild fur Version 7 o foobarOS_7_f4d1234f-3ebf-47c4-b31d-4052982f9a2f.root.xz -- Das Wurzeldateisystemabbild fur Version 7 o foobarOS_7_efi.xz - Das vereinigte Kernel-Abbild fur Version 7 Fur jede neue Veroffentlichung des Betriebssystems wurden die letzteren drei Dateien mit einer aktualisierten Version hinzugefugt. Das SHA256SUMS-Manifest sollte dann entsprechend aktualisiert werden und alle Dateien fur alle Versionen auffuhren, die entsprechend zum Herunterladen angeboten werden sollen. Beispiel 2. Aktualisierungen fur 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 ladt 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 fur 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 UBERSETZUNG Die deutsche Ubersetzung dieser Handbuchseite wurde von Helge Kreutzmann erstellt. Diese Ubersetzung ist Freie Dokumentation; lesen Sie die GNU General Public License Version 3 oder neuer bezuglich der Copyright-Bedingungen. Es wird KEINE HAFTUNG ubernommen. Wenn Sie Fehler in der Ubersetzung dieser Handbuchseite finden, schicken Sie bitte eine E-Mail an die Mailingliste der Ubersetzer . systemd 255 SYSUPDATE.D(5)