oracular (7) systemd.offline-updates.7.gz

Provided by: manpages-de_4.23.1-1_all bug

BEZEICHNUNG

       systemd.offline-updates - Implementierung von Offline-Aktualisierungen in Systemd

OFFLINE SYSTEM-AKTUALISIERUNGEN IMPLEMENTIEREN

       Diese Handbuchseite beschreibt, wie die »offline« Systemaktualisierungen mit Systemd realisiert werden.
       Unter dem Begriff »offline« Betriebssystemaktualisierungen verstehen wir Paketinstallationen und
       -aktualisierungen, die ausgeführt werden, ohne dass das System in einen besonderen
       Systemaktualisierungsmodus gestartet wurde, um Probleme in Bezug auf Konflikte bei Bibliotheken und
       Diensten, die derzeit laufen, mit denen auf der Platte zu vermeiden. Dieses Dokument wurde vom GNOME
       Design-Whiteboard[1] inspiriert.

       Die Logik:

        1. Der Paketverwalter bereitet Systemaktualisierungen vor, indem er alle offline zu aktualisierenden
           (.rpm- oder .deb- oder was auch immer) Pakete in ein spezielles Verzeichnis /var/lib/system-update
           (oder ein anderes Verzeichnis nach Wahl des Paket-/Upgrade-Verwalters) herunterlädt.

        2. Wenn der Benutzer die Aktualisierung bestätigt hat, wird der Symlink /system-update oder
           /etc/system-update, der auf /var/lib/system-update (oder wo auch immer das Verzeichnis mit den
           Upgrade-Dateien sich befindet) zeigt, erstellt, und das System wird neu gestartet. Dieser Symlink ist
           im Wurzelverzeichnis, da er sehr früh im Systemstartprozess geprüft werden muss, zu einem Zeitpunkt,
           an dem /var/ noch nicht verfügbar ist.

        3. Sehr früh im Systemstartprozess prüft systemd-system-update-generator(8) ob /system-update oder
           /etc/system-update existiert. Falls das der Fall ist, wird (temporär und nur für diesen Systemstart)
           default.target auf system-update.target umgelenkt (d.h. ein Symlink angelegt). Letzteres ist ein
           besonderes Ziel, das das Basissystem (d.h. sysinit.target, so dass alle Dateisysteme eingehängt sind,
           aber nicht viel mehr) und die Systemaktualisierungs-Units hereinzieht.

        4. Das System fährt jetzt fort, in default.target und damit in system-update.target zu starten. Dieses
           Ziel zieht alle Systemaktualisierungs-Units herein. Nur ein Dienst sollte Aktualisierungen
           durchführen (siehe den nächsten Punkt) und alle anderen sollten sich sauber mit einem Rückgabecode
           »success« und ohne etwas weiteres durchzuführen beenden. Aktualisierungsdienste sollten nach
           sysinit.target angeordnet sein, so dass die Aktualisierung beginnt, nachdem alle Dateisysteme
           eingehängt wurden.

        5. Im ersten Schritt sollte ein Aktualisierungsdienst prüfen, ob der Symlink /system-update oder
           /etc/system-update auf dem vom Aktualisierungsdienst verwandten Ort zeigt. Falls er nicht existiert
           oder an einen anderen Ort zeigt, muss sich der Dienst fehlerfrei beenden. Es ist möglich, dass
           mehrere Aktualisierungsdienste installiert sind und mehrere Aktualisierungsdienste parallel gestartet
           sind und nur derjenige, der dem Werkzeug entspricht, das den Symlink vor dem Neustart erstellte,
           sollte irgendwelche Aktionen durchführen. Es ist nicht sicher, mehrere Aktualisierungen parallel
           durchzuführen.

        6. Der Aktualisierungsdienst sollte jetzt seine Aufgabe erledigen. Falls zutreffend und möglich, sollte
           er einen Dateisystemschnappschuss erstellen, dann alle Pakete installieren. Nach dem Abschluss
           (unabhängig davon, ob die Aktualisierung gelungen oder fehlgeschlagen ist) muss die Maschine neu
           gestartet werden, beispielsweise durch Aufruf von systemctl reboot. Im Fehlerfall sollte das Skript
           zusätzlich auf den alten Dateisystemschnappschuss (ohne den Symlink) zurückkehren.

        7. Das Upgrade-Skript sollte sich nur beenden, wenn die Aktualisierung abgeschlossen ist. Es wird
           erwartet, dass der Dienst, der das Upgrade durchführt, einen Systemneustart auslöst, nachdem er
           fertig ist. Falls das system-update.target erfolgreich erreicht wurde, d.h. alle
           Aktualisierungsdienste ausgeführt wurden und der Symlink /system-update oder /etc/system-update immer
           noch existiert, wird dieser entfernt und als Sicherheitsmaßnahme die Maschine neu gestartet.

        8. Nach einem Neustart, nun dass der Symlink /system-update und /etc/system-update verschwunden ist,
           wird der Generator default.target nicht mehr umleiten und das System nun wieder in das Standardziel
           starten.

EMPFEHLUNGEN

        1. Um für mehr Robustheit zu sorgen, empfehlen wir, das Aktualisierungsskript mittels eines Symlinks
           .wants/ in dem Distributionspaket in system-update.target einzuhängen, statt in
           Postinst-Skriptstücken im Paket von systemctl enable abzuhängen. Für Ihre Aktualisierungsskripte
           sollten Sie konkreter eine Datei .service ohne Abschnitt »[Install]« erstellen und dann einen Symlink
           der Art /usr/lib/systemd/system/system-update.target.wants/foobar.service → ../foobar.service zu
           Ihrem Paket hinzufügen.

        2. Stellen Sie sicher, dass der Symlink /system-update und /etc/system-update in Ihrem
           Aktualisierungsskript so früh wie möglich entfernt wird, um im Fehlerfall Neustartschleifen zu
           vermeiden.

        3. Verwenden Sie FailureAction=reboot in der Dienstedatei Ihres Aktualisierungsskriptes, um
           sicherzustellen, dass automatisch ein Neustart ausgelöst wird, falls die Aktualisierung fehlschlägt.
           FailureAction= stellt sicher, dass die festgelegte Unit aktiviert ist, falls Ihr Skript sich unsauber
           beendet (mit einem von Null verschiedenen Fehler-Code oder einem Signal/Speicherauszug). Falls Ihr
           Skript sich erfolgreich beendet, sollten Sie den Systemneustart in Ihrem Code auslösen,
           beispielsweise durch den Aufruf Reboot() von logind oder dem Aufruf von systemctl reboot. Siehe
           org.freedesktop.login1(5) für Details über das Logind-D-Bus-API.

        4. Der Aktualisierungsdienst sollte DefaultDependencies=no, Requires=sysinit.target,
           After=sysinit.target, After=system-update-pre.target, Before=system-update.target und explizit alle
           benötigten Dienste hereinziehen.

        5. Es kann wünschenswert sein, immer eine Hilfs-Unit beim Starten in den offline-updates-Modus zu
           betreiben, die selbst keine Aktualisierungen installiert. Um dies zu erledigen, erstellen Sie eine
           .service-Datei mit Wants=system-update-pre.target und Before=system-update-pre.target und fügen Sie
           einen Symlink auf diese Datei unter /usr/lib/systemd/system-update.target.wants hinzu..

SIEHE AUCH

       systemd(1), systemd.generator(7), systemd-system-update-generator(8), dnf.plugin.system-upgrade(8)

ANMERKUNGEN

        1. GNOME Design-Whiteboard
           https://wiki.gnome.org/Design/OS/SoftwareUpdates

Ü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⟩.