Gilt für SUSE Linux Enterprise Desktop 15 SP6

13 Transaktionsaktualisierungen #

Transaktionsaktualisierungen sind in SUSE Linux Enterprise Desktop für die Aktualisierung von SLES verfügbar, wenn das root-Dateisystem schreibgeschützt ist. Transaktionsaktualisierungen sind atomar – alle Aktualisierungen werden nur angewendet, wenn alle erfolgreich sind – und unterstützen Rollbacks. Es ist kein laufendes System betroffen, da Änderungen erst aktiviert werden, nachdem das System neu gebootet wurde. Da Reboots eine Störung darstellen, muss der Administrator entscheiden, ob ein Reboot kostspieliger ist als die Störung laufender Dienste. Wenn Reboots zu kostspielig sind, sollten Sie keine Transaktionsaktualisierungen verwenden.

Transaktionsaktualisierungen werden täglich vom Skript transactional-update ausgeführt. Das Skript prüft auf verfügbare Aktualisierungen. Falls Aktualisierungen vorhanden sind, erstellt es im Hintergrund einen neuen Snapshot des root-Dateisystems. Danach ruft es die Aktualisierungen von den Versionskanälen ab. Sobald der neue Snapshot aktualisiert wurde, wird er als aktiv gekennzeichnet und wird nach dem nächsten Reboot des Systems zum neuen standardmäßigen root-Dateisystem. Wenn transactional-update automatisch ausgeführt wird (das Standardverhalten), wird das System auch neu gebootet. Sowohl die Zeitdauer für den Aktualisierungsvorgang als auch das Wartungsfenster für den Reboot sind konfigurierbar.

Es können nur Pakete aktualisiert werden, die Teil des Snapshots des root-Dateisystems sind. Sollten die Pakete Dateien enthalten, die nicht Teil des Snapshots sind, dann könnte die Aktualisierung fehlschlagen oder das System beschädigen.

RPMs, die eine Lizenz benötigen, um akzeptiert zu werden, können nicht aktualisiert werden.

13.1 Nutzungsbeschränkungen #

Derzeit gibt es bestimmte Einschränkungen bei der Funktionalität von Transaktionsaktualisierungen. Für die folgenden Pakete kann der Befehl transactional-update nicht verwendet werden:

Die standardmäßige index.html-Seite von nginx ist möglicherweise nicht verfügbar.
tomcat-webapps und tomcat-admin-webapps
phpMyAdmin
sca-appliance-*
mpi-selector
emacs funktioniert mit Ausnahme von Emacs-Spielen
bind und bind-chrootenv
docbook*
sblim-sfcb*
texlive*
iso_ent
openjade
opensp
pcp
plymouth
postgresql-server-10
pulseaudio-gdm-hooks
smartmontools

Die Aktualisierungskomponente des Systeminstallationsprogramms funktioniert nicht bei einem schreibgeschützten Dateisystem, weil es Transaktionsaktualisierungen nicht unterstützt.

Weitere Überlegungen:

Es ist sinnvoll, den Zeitraum zwischen der Aktualisierung des Systems und dem Reboot des Rechners so kurz wie möglich zu halten.
Es kann immer nur eine Aktualisierung angewendet werden. Nach jeder Aktualisierung und nach dem Anwenden der nächsten Aktualisierung muss ein Reboot erfolgen.
update-alternatives sollte nach einer Transaktionsaktualisierung erst nach dem Reboot des Rechners ausgeführt werden.
Erstellen Sie nach einer Transaktionsaktualisierung neue Systembenutzer oder Systemgruppen erst nach einem Reboot. Normale Benutzer und Gruppen (UID > 1000, GID > 1000) können jedoch erstellt werden.
YaST ist noch nicht mit Transaktionsaktualisierungen vertraut. Es funktioniert nicht, wenn ein YaST-Modul zusätzliche Pakete installieren muss. Normale Systemvorgänge, die Konfigurationsdateien in /etc-Arbeit ändern.
Für php7-fastcgi müssen Sie manuell einen symbolischen Link erstellen (/srv/www/cgi-bin/php), der auf /usr/bin/php-cgi zeigt.
ntp ist Teil des Legacy-Moduls für die Migration von älteren SLES-Versionen. Es wird nicht auf einer neueren Installation von SUSE Linux Enterprise Desktop unterstützt und wurde ersetzt durch chrony. Wenn Sie ntp weiterhin verwenden, ist eine Neuinstallation erforderlich, damit die transaktionalen Updates korrekt funktionieren.
sblim-sfcb: Das gesamte sblim-Ökosystem ist mit Transaktionsaktualisierungen kompatibel.
btrfs-defrag aus dem Paket btrfsmaintenance funktioniert nicht mit einem schreibgeschützten Root-Dateisystem.
Für btrfs-balance muss die Variable BTRFS_BALANCE_MOUNTPOINTS in /etc/sysconfig/btrfsmaintenance von / in /.snapshots geändert werden.
Für btrfs-scrub muss die Variable BTRFS_SCRUB_MOUNTPOINTS in /etc/sysconfig/btrfsmaintenance von / in /.snapshots geändert werden.

13.2 Aktivieren von transactional-update #

Sie müssen das Transaktionsserver-Modul bei der Systeminstallation aktivieren und dann die Transaktionsserver-Rolle auswählen. Die spätere Installation von Paketen vom Transaktionsserver-Modul in einem laufenden System wird NICHT unterstützt und könnte das System beschädigen.

Das Ändern des Subvolume-Layouts der Root-Partition oder das Ablegen von Unterverzeichnissen oder Subvolumes der Root-Partition in eigenen Partitionen (außer /home, /var, /srv und /opt) wird nicht unterstützt und kann das System beschädigen.

13.3 Verwalten von automatischen Aktualisierungen #

Automatische Aktualisierungen werden von einem systemd.timer gesteuert, der einmal pro Tag ausgeführt wird. Damit werden alle Aktualisierungen angewendet und rebootmgrd wird informiert, dass der Rechner neu gebootet werden muss. Die Uhrzeit für die Ausführung der Aktualisierung kann angepasst werden. Weitere Informationen hierzu finden Sie unter systemd.timer(5). Informationen zum Anpassen des Wartungsfensters, in dem festgelegt wird, wann rebootmgrd das System neu bootet, finden Sie unter rebootmgrd(8).

Automatische Transaktionsaktualisierungen werden deaktiviert mit dem Befehl:

# systemctl --now disable transactional-update.timer

13.4 Der Befehl `transactional-update` #

Mit dem Befehl transactional-update ist eine atomare Installation oder das Entfernen von Aktualisierungen möglich. Aktualisierungen werden nur dann angewendet, wenn alle erfolgreich installiert werden können. Mit transactional-update wird ein Snapshot von Ihrem System vor Anwenden der Aktualisierung erstellt. Dieser Snapshot kann wiederhergestellt werden. Alle Änderungen werden erst nach dem Reboot aktiv.

--continue

Mit der Option --continue werden mehrere Änderungen an einem bestehenden Snapshot vorgenommen, ohne dass neu gebootet werden muss.

Das standardmäßige Verhalten von transactional-update besteht darin, einen neuen Snapshot vom aktuellen root-Dateisystem zu erstellen. Wenn Sie etwas vergessen, etwa die Installation eines neuen Pakets, müssen Sie einen Reboot ausführen, um die früheren Änderungen anzuwenden. Danach muss der Befehl transactional-update erneut ausgeführt werden, um das vergessene Paket zu installieren, und es muss erneut ein Reboot erfolgen. Sie können den Befehl transactional-update nicht mehrmals ohne Reboot zum Hinzufügen weiterer Änderungen zum Snapshot ausführen. Dadurch würden separate unabhängige Snapshots erstellt werden, die nicht die Änderungen der früheren Snapshots enthalten.

Mit der Option --continue können Sie jedoch so viele Änderungen vornehmen, wie Sie möchten, ohne neu booten zu müssen. Es wird jedes Mal ein neuer Snapshot erstellt, der jeweils alle Änderungen der früheren Snapshots sowie die neuen Änderungen enthält. Wiederholen Sie diesen Vorgang beliebig oft und booten Sie das System neu, sobald der letzte Snapshot alle gewünschten Änderungen enthält. Der letzte Snapshot wird dann das neue Root-Dateisystem.

Als weitere nützliche Funktion der Option --continue können Sie jeden beliebigen vorhandenen Snapshot als Basis für Ihren neuen Snapshot auswählen. Im folgenden Beispiel wird gezeigt, wie transactional-update ausgeführt wird, um ein neues Paket in einem Snapshot basierend auf Snapshot 13 zu installieren. Danach wird es erneut ausgeführt, um ein weiteres Paket zu installieren:

# transactional-update pkg install package_1

# transactional-update --continue 13 pkg install package_2

Die Option --continue [num] ruft snapper create --from auf, siehe Abschnitt 10.6.2, „Erstellen von Snapshots“.

cleanup

Wenn das aktuelle root-Dateisystem mit dem aktiven root-Dateisystem identisch ist (nach einem Reboot, bevor transactional-update einen neuen Snapshot mit Aktualisierungen erstellt), wird für alle alten Snapshots ohne Bereinigungsalgorithmus ein Bereinigungsalgorithmus festgelegt. Dadurch wird sichergestellt, dass alte Snapshots von Snapper gelöscht werden. (Weitere Informationen finden Sie im Abschnitt zu Bereinigungsalgorithmen in Snapper (8).) Dadurch werden auch alle nicht referenzierten (und damit ungenutzten) /etc-Overlay-Verzeichnisse in /var/lib/overlay entfernt:

# transactional-update cleanup

pkg in/install

Installiert einzelne Paket aus den verfügbaren Kanälen mit dem Befehl zypper install. Mit diesem Befehl werden auch PTF(Program Temporary Fix)-RPM-Dateien installiert.

# transactional-update pkg install package_name

oder

# transactional-update pkg install rpm1 rpm2

pkg rm/remove

Entfernt einzelne Pakete vom aktiven Snapshot mit dem Befehl zypper remove. Mit diesem Befehl werden auch PTF-RPM-Dateien entfernt.

# transactional-update pkg remove package_name

pkg up/update

Aktualisiert einzelne Pakete vom aktiven Snapshot mit dem Befehl zypper update. Es können nur Pakete aktualisiert werden, die Teil des Snapshots des Basisdateisystems sind.

# transactional-update pkg update package_name

up/update

Wenn neue Aktualisierungen verfügbar sind, wird ein neuer Snapshot erstellt und mit zypper up/update der Snapshot aktualisiert.

# transactional-update up

dup

Wenn neue Aktualisierungen verfügbar sind, wird ein neuer Snapshot erstellt und mit zypper dup –no-allow-vendor-change der Snapshot aktualisiert. Der Snapshot wird anschließend aktiviert und wird nach einem Reboot zum neuen root-Dateisystem.

# transactional-update dup

patch

Wenn neue Aktualisierungen verfügbar sind, wird ein neuer Snapshot erstellt und mit zypper patch der Snapshot aktualisiert.

# transactional-update patch

rollback

Damit wird das Standard-Subvolume festgelegt. In Systemen mit einem Schreiben-Lesen-Dateisystem wird snapper rollback aufgerufen. In einem Nur-Lesen-Dateisystem ohne Argument wird das aktuelle System als neues standardmäßiges root-Dateisystem festgelegt. Wenn Sie eine Zahl angeben, wird dieser Snapshot als das standardmäßige root-Dateisystem verwendet. In einem Nur-Lesen-Dateisystem werden keine zusätzlichen Snapshots erstellt.

# transactional-update rollback snapshot_number

grub.cfg

Damit wird eine neue GRUB2-Konfiguration erstellt. Manchmal muss die Boot-Konfiguration angepasst werden, beispielsweise durch Hinzufügen zusätzlicher Kernel-Parameter. Bearbeiten Sie /etc/default/grub, führen Sie transactional-update grub.cfg aus und booten Sie dann neu, um die Änderung zu aktivieren. Sie müssen sofort einen Reboot ausführen, da ansonsten die neue GRUB2-Konfiguration bei der nächsten Ausführung von transactional-update mit dem Standardwert überschrieben wird.

# transactional-update grub.cfg

reboot

Dieser Parameter löst nach dem Abschluss der Aktion einen Reboot aus.

# transactional-update dup reboot

--help

Damit wird ein Hilfe-Bildschirm mit Optionen und Unterbefehlen gedruckt.

# transactional-update --help

13.5 Fehlersuche #

Führen Sie bei einem fehlerhaften Upgrade supportconfig aus, um Protokolldaten zu erfassen. Übermitteln Sie die resultierenden Dateien einschließlich /var/log/transactional-update.log an den SUSE-Support.