In diesem Kapitel werden verschiedene Begriffe verwendet. Lesen Sie zum besseren Verständnis der Informationen die unten stehenden Definitionen:

Für SUSE-Produkte gelten die folgenden Produktlebenszyklen:

SUSE unterstützt ältere Service Packs für sechs Monate nach Bereitstellung des neuen Service Packs. In Abbildung 1.1, „Hauptversionen und Service Packs“ werden einige der genannten Aspekte veranschaulicht.

Abbildung 1.1: Hauptversionen und Service Packs #

 

Wenn Sie zusätzliche Zeit zum Gestalten, Validieren und Testen Ihrer Upgradepläne benötigen, können Sie Ihren Support mit dem Long Term Service Pack Support um weitere 12 bis 36 Monate (in Intervallen von 12 Monaten) verlängern. So erhalten Sie insgesamt 2 bis 5 Jahre Support für jedes Service Pack. Weitere Informationen finden Sie unter Abbildung 1.2, „Langfristiger Service Pack-Support“.

Abbildung 1.2: Langfristiger Service Pack-Support #

 

Weitere Informationen hierzu finden Sie im https://www.suse.com/products/long-term-service-pack-support/.

Weitere Informationen zu den Lebenszyklen, der Veröffentlichungshäufigkeit sowie den überlappenden Supportzeitraum finden sie unter https://www.suse.com/lifecycle.

Im Article “Modules and Extensions Quick Start” finden Sie eine Liste der Module mit ihren Abhängigkeiten und Lebenszyklen.

SUSE Linux Enterprise Desktop kann regelmäßig nach Supportstatus-Aktualisierungen aller installierten Produkte suchen und bei Änderungen einen Bericht per Email versenden. Installieren Sie zypper-lifecycle-plugin mit zypper in zypper-lifecycle-plugin, um den Bericht zu generieren.

Aktivieren Sie die Berichterzeugung auf dem System mit systemctl:

> sudo systemctl enable lifecycle-report.timer

Der Empfänger und der Betreff der Bericht-E-Mail sowie das Intervall für die Berichtgenerierung können mit einem beliebigen Texteditor in der Datei /etc/sysconfig/lifecycle-report konfiguriert werden. Die Einstellungen MAIL_TO und MAIL_SUBJ definieren den Empfänger und den Betreff der Email und DAYS bezeichnet das Intervall, in dem die Berichte erzeugt werden sollen.

Änderungen des Supportstatus werden erst nach Eintreten einer Änderung im Bericht sichtbar, nicht schon im Voraus. Wird eine Änderung unmittelbar nach dem Erzeugen des letzten Berichts vorgenommen, kann es bis zu 14 Tage dauern, bis Sie über diese Änderung informiert werden. Berücksichtigen Sie diesen Punkt, wenn Sie die Option DAYS festlegen. Ändern Sie die folgenden Konfigurationseinträge gemäß Ihren Anforderungen:

MAIL_TO='root@localhost'
MAIL_SUBJ='Lifecycle report'
DAYS=14

Der aktuelle Bericht befindet sich in der Datei /var/lib/lifecycle/report. Die Datei umfasst zwei Abschnitte. Im ersten Abschnitt finden Sie Informationen zum Supportende für die verwendeten Produkte. Der zweite Abschnitt listet Pakete mit dem zugehörigen Datum des Supportendes und der eventuellen Verfügbarkeit von Aktualisierungen auf.

Der Bereich für erweiterte Supportstufen beginnt in Jahr 10 und endet in Jahr 13. Sie umfassen fortlaufende L3-Diagnose auf technischer Ebene und rückwirkende Behebung kritischer Fehler. Mit diesen Supportstufen erhalten Sie Aktualisierungen für root-Sicherheitsanfälligkeiten im Kernel und andere root-Sicherheitsanfälligen als direkt ausführbare Datei, die ohne Eingreifen des Benutzers abgearbeitet wird. Darüber hinaus werden vorhandene Workloads, Softwarestapel und Hardware mit einer limitierten Paketausschlussliste unterstützt. Einen Überblick finden Sie in Tabelle 1.1, „Sicherheitsaktualisierungen und Fehlerbehebungen“.

¹ Weitere Informationen zur SUSE Linux Enterprise-Aktualisierungsrichtlinie finden Sie im folgenden knowledgebase article.

Beim Registrieren erhält das System verschiedene Repositorys aus dem SUSE Custom Center (siehe https://scc.suse.com/) oder von einem lokalen Registrierungs-Proxy wie SMT. Die Repository-Namen sind bestimmten URIs im Customer Center zugeordnet. Zum Auflisten aller verfügbaren Repositorys auf dem System geben Sie das folgende zypper-Kommando ein:

# zypper repos -u

Hiermit erhalten Sie eine Liste aller verfügbaren Repositorys auf dem System. Für jedes Repository werden der Alias und der Name aufgeführt, und es ist angegeben, ob das Repository aktiviert ist und jeweils auf den neuesten Stand gebracht wird. Mit der Option -u erhalten Sie außerdem die URI, von der es stammt.

Zum Registrieren des Computers führen Sie SUSEConnect aus, beispielsweise:

# SUSEConnect -r REGCODE

Über SUSEConnect können Sie die Registrierung des Computers auch wieder aufheben:

# SUSEConnect --de-register

Mit dem folgenden Kommando können die lokal installierten Produkte und deren Status geprüft werden:

# SUSEConnect -s

Die Version einer SLE-Installation lässt sich anhand des Inhalts der Datei /etc/os-release ermitteln.

zypper bietet eine maschinenlesbare XML-Ausgabe:

> zypper --no-remote --no-refresh --xmlout --non-interactive products -i
<?xml version='1.0'?>
<stream>
<product-list>
<product name="SLES" version="15" release="0" epoch="0" arch="x86_64" vendor="SUSE" summary="SUSE Linux Enterprise Server 15" repo="@System" productline="sles" registerrelease="" shortname="SLES15" flavor="" isbase="true" installed="true"><endoflife time_t="0" text="0"/><registerflavor/><description>SUSE Linux Enterprise offers [...]</description></product>
</product-list>
</stream>

Upgrades zwischen zwei Hauptversionen von SUSE Linux Enterprise Desktop werden von SUSE unterstützt. Ob es besser ist, ein Upgrade durchzuführen oder eine Neuinstallation vorzunehmen, hängt von Ihrem spezifischen Szenario ab. Upgrades bedeuten zwar weniger Arbeit, doch bei Neuinstallationen wird sichergestellt, dass Sie von allen neuen Funktionen einer Version profitieren, wie zum Beispiel Änderungen am Festplattenlayout, speziellen Dateisystemfunktionen und anderen Verbesserungen. Um Ihr System optimal nutzen zu können, empfiehlt SUSE daher in den meisten Szenarien eine Neuinstallation.

In beiden Fällen – sowohl bei einem Upgrade als auch bei einer Neuinstallation – muss der Kunde prüfen, ob die Systemeinstellungen und Standardwerte noch den Anforderungen entsprechen.

Bei Aktualisierungen von einem Service Pack einer bestimmten Version auf ein anderes des gleichen Codestreams empfiehlt SUSE, sie an Ort und Stelle vorzunehmen und keine Neuinstallation durchzuführen. Dennoch kann es auch in diesem Fall für einen Kunden Gründe und Szenarien für eine Neuinstallation geben. Die Entscheidung, was besser geeignet ist, kann nur der Kunde treffen.

Vor der Migration beachten Sie Kapitel 3, Vorbereiten des Upgrades.

Wichtig: Architekturübergreifende Upgrades werden nicht unterstützt

Architekturübergreifende Upgrades wie von einer 32-Bit-Version von SUSE Linux Enterprise Desktop auf die 64-Bit-Version oder das Upgrade von Big Endian auf Little Endian werden nicht unterstützt.

Da SUSE Linux Enterprise 15 nur in der 64-Bit-Version verfügbar ist, werden Upgrades von 32-Bit-Systemen von SUSE Linux Enterprise 11 auf SUSE Linux Enterprise 15 und höher nicht unterstützt.

Ist ein architekturübergreifendes Upgrade erforderlich, so muss eine Neuinstallation ausgeführt werden.

Anmerkung: Überspringen von Service Packs

Das Überspringen von Service Packs wird unter SUSE Linux Enterprise Desktop nicht unterstützt. Alle Service Packs müssen nacheinander installiert werden.

Abbildung 2.1: Überblick über die unterstützten Upgrade-Pfade #

 

Warnung: Upgrade von Datenbanken

Die hier beschriebenen Upgrade-Pfade gelten nur für SUSE Linux Enterprise als Betriebssystem eines Rechners, nicht für alle Anwendungen, die darauf ausgeführt werden. Bei Workloads wie PostgreSQL- oder MariaDB-Datenbanken können vorläufige Betriebssystem-Upgrades erforderlich sein, um Ihre Anwendungen zu aktualisieren.

Lesen Sie vor dem Upgrade des Betriebssystems die Release Notes für Informationen zu den Datenbankversionen. Wenn eine neue Hauptversion ausgeliefert wird, finden Sie die Anweisungen für ein Upgrade im Kapitel 3, Vorbereiten des Upgrades.

SUSE unterstützt zwei verschiedene Upgrade- und Migrationsmethoden. Weitere Informationen zu diesen Begriffen finden Sie im Abschnitt 1.1, „Terminologie“. Die folgenden Methoden werden unterstützt:

Wichtig: SUSE Manager-Clients

Wenn Ihr Rechner mit SUSE Manager verwaltet wird, aktualisieren Sie das Programm entsprechend der Beschreibung in der Dokumentation zu SUSE Manager. Das Verfahren zur Client Migration ist im SUSE Manager Upgrade Guide beschrieben, das unter https://documentation.suse.com/suma/ verfügbar ist.

Ein Upgraden des Systems wird nur von der jeweils letzten Patch-Stufe aus unterstützt. Prüfen Sie, ob die neuesten Systemaktualisierungen installiert sind. Führen Sie hierzu entweder zypper patch aus oder starten Sie das YaST-Modul Online-Update.

Anmerkung: Neuer 4096-Bit-Signierschlüssel für SUSE Linux Enterprise 15

Mitte 2023 wurde die SUSE Linux Enterprise 15-Produktfamilie von einem RSA 2048-Bit-Signierschlüssel auf einen neuen RSA 4096-Bit-Schlüssel umgestellt. Diese Änderung betrifft RPM-Pakete, Paket-Repositorys und ISO-Signaturen. Alte Repositorys, die nicht mehr aktualisiert werden, und RPMs, die bis zum Zeitpunkt der Umstellung veröffentlicht wurden, bleiben mit dem alten 2048-Bit-Schlüssel signiert.

Wenn Sie Ihr System aktualisieren, wird der neue Schlüssel automatisch in den RPM-Schlüsselring aus dem suse-build-key-Paket auf SLE 15 SP 4 und SP5 sowie den LTSS-Versionen von SLE 15 SP1, SP2 und SP3 importiert.

Wenn der Schlüssel noch nicht importiert wurde, können Sie ihn manuell importieren mit:

> sudo rpm --import /usr/lib/rpm/gnupg/keys/gpg-pubkey-3fa1d6ce-63c9481c.asc

Wenn Sie eine ältere Version von SLE verwenden oder den neuen Schlüssel nicht importiert haben, werden Sie während des Upgrades aufgefordert, ihm zu vertrauen. Versichern Sie sich, dass der Fingerabdruck übereinstimmt:

pub   rsa4096/0xF74F09BC3FA1D6CE 2023-01-19 [SC] [expires: 2027-01-18]
Key fingerprint = 7F00 9157 B127 B994 D5CF  BE76 F74F 09BC 3FA1 D6CE
uid           SUSE Package Signing Key <build@suse.de>

Zusätzlich wurde ein 4096-Bit-RSA-Reserveschlüssel für Disaster Recovery-Zwecke importiert:

pub   rsa4096/0xA1BFC02BD588DC46 2023-01-19 [SC] [expires: 2033-01-16]
Key fingerprint = B56E 5601 41D8 F654 2DFF  3BF9 A1BF C02B D588 DC46
uid           SUSE Package Signing Key (reserve key) <build@suse.de>

Dieser Schlüssel kann manuell importiert werden mit:

> sudo rpm --import /usr/lib/rpm/gnupg/keys/gpg-pubkey-d588dc46-63c939db.asc

Beide Schlüssel finden Sie auch auf dem Installationsmedium und auf der SUSE-Website unter https://www.suse.com/support/security/keys/.

Eine Liste aller Änderungen, neuen Funktionen und bekannten Probleme finden Sie in den release notes. Die Versionshinweise finden Sie auch auf den Installationsmedien im Verzeichnis docu.

Die Versionshinweise enthalten in der Regel nur die Änderungen zwischen zwei aufeinander folgenden Versionen. Falls Sie mindestens ein Service Pack überspringen, beachten Sie auch die Versionshinweise der übersprungenen Service Packs.

Lesen Sie die Versionshinweise, um zu prüfen, ob Folgendes zutrifft:

Sichern Sie vor dem Upgrade Ihre Daten, indem Sie die vorhandenen Konfigurationsdateien auf ein separates Medium (z. B. Bandgerät, externe Festplatte usw.) kopieren. Dies gilt hauptsächlich für die in /etc gespeicherten Dateien sowie für bestimmte Verzeichnisse und Dateien in /var und /opt. Zudem empfiehlt es sich, die Benutzerdaten in /home (den HOME-Verzeichnissen) auf ein Sicherungsmedium zu schreiben.

Melden Sie sich zur Sicherung dieser Daten als root an. Nur der Benutzer root verfügt über die Berechtigungen für alle lokalen Dateien.

Wenn Sie in YaST den Installationsmodus Vorhandenes System aktualisieren ausgewählt haben, können Sie später wahlweise eine (System-)Sicherung ausführen. Sie können alle geänderten Dateien und die Dateien aus dem Verzeichnis /etc/sysconfig einschließen. Dies ist allerdings keine vollständige Sicherung, da alle anderen wichtigen, oben genannten Verzeichnisse außer Acht gelassen werden. Die Sicherungskopie befindet sich im Verzeichnis /var/adm/backup.

Software weist normalerweise von Version zu Version mehr Umfang auf. Folglich sollten Sie vor dem Aktualisieren den verfügbaren Partitionsspeicher überprüfen. Wenn Sie befürchten, dass der Speicherplatz nicht ausreicht, sichern Sie Ihre Daten und erhöhen Sie dann den verfügbaren Speicherplatz, indem Sie beispielsweise die Größe von Partitionen ändern. Es gibt keine Faustregel hinsichtlich des Speicherplatzes einzelner Partitionen. Die Platzanforderungen hängen von Ihrem bestimmten Partitionsprofil und von der ausgewählten Software ab.

Anmerkung: Automatische Prüfung des verfügbaren Speicherplatzes in YaST

YaST prüft während des Aktualisierungsvorgangs den freien verfügbaren Speicherplatz und zeigt dem Benutzer eine Warnmeldung an, wenn die verfügbare Menge möglicherweise nicht für die Installation ausreicht. Wenn Sie die Aktualisierung in diesem Fall dennoch durchführen, kann das System unbrauchbar werden! Sie sollten die Warnmeldung nur dann ignorieren und mit der Aktualisierung fortfahren, wenn Sie genau wissen, was Sie tun (da Sie dies in einem Vorabtest abgeklärt haben).

Filesystem     Size  Used Avail Use% Mounted on
     /dev/sda3       74G   22G   53G  29% /
     tmpfs          506M     0  506M   0% /dev/shm
     /dev/sda5      116G  5.8G  111G   5% /home
     /dev/sda1       39G  1.6G   37G   4% /windows/C
     /dev/sda2      4.6G  2.6G  2.1G  57% /windows/D

Sie können eine Liste der installierten Pakete speichern; beispielsweise bei einer Neuinstallation einer neuen SLE-Hauptversion oder beim Zurücksetzen des Systems auf die bisherige Version.

Anmerkung

Denken Sie daran, dass nicht alle installierten Pakete oder verwendeten Repositorys in neueren Versionen von SUSE Linux Enterprise vorliegen. Einige Elemente wurden unter Umständen umbenannt, andere ersetzt. Außerdem könnten bestimmte Pakete weiterhin zu Legacy-Zwecken verfügbar sein, während standardmäßig ein anderes Paket herangezogen wird. Aus diesem Grund müssen die Dateien ggf. manuell bearbeitet werden. Dies können Sie mit einem beliebigen Texteditor durchführen.

Wenn Sie ein SUSE Linux Enterprise Desktop-System mit LTSS (Long Term Service Pack Support) auf eine Version aktualisieren, die noch unter allgemeinem Support steht, schlägt das Upgrade mit dem Fehler No migration available fehl. Dies geschieht, weil zypper migration versucht, alle Repositorys zu migrieren, es aber noch kein LTSS-Repository für die neue Version gibt.

Deaktivieren Sie zur Behebung dieses Problems die LTSS-Erweiterung vor dem Upgrade.

Als Sicherheitsmaßnahme werden MD5-gestützte Zertifikate in Java nicht mehr unterstützt. Wenn Sie über als MD5 erstellte Zertifikate verfügen, erstellen Sie diese mit folgenden Schritten neu:

Wenn Ihr Rechner als VM-Hostserver für KVM oder Xen fungiert, müssen Sie vor der Aktualisierung alle aktiven VM-Gäste ordnungsgemäß herunterfahren. Andernfalls können Sie nach der Aktualisierung wahrscheinlich nicht mehr auf die Gäste zugreifen.

Beachten Sie Folgendes, wenn der Rechner, für den ein Upgrade durchgeführt werden soll, als Client bei einem SMT-Server registriert ist:

Prüfen Sie, ob die Version des Skripts clientSetup4SMT.sh auf Ihrem Host aktuell ist. clientSetup4SMT.sh aus älteren Versionen von SMT kann nicht zum Verwalten von SMT 12-Clients verwendet werden. Wenn Sie auf Ihrem SMT-Server regelmäßig Software-Patches anwenden, finden Sie die neueste Version von clientSetup4SMT.sh immer unter <SMT_HOSTNAME>/repo/tools/clientSetup4SMT.sh.

Prozedur 3.1 Starten Sie danach den Upgradevorgang neu.

Auf Systemen, die mit SUSE Linux Enterprise Desktop 12 oder älter installiert wurden, kann die Standard-Kernel-Kommandozeile in /etc/default/grub einen Parameter resume enthalten, der den Namen eines Geräteknotens wie /dev/sda1 verwendet, um auf das Hibernation-Gerät (Suspend-to-Disk) zu verweisen. Da die Namen von Geräteknoten nicht beständig sind und sich zwischen Neustarts ändern können, ist es sehr empfehlenswert, dies zu korrigieren. Andernfalls kann das aufgerüstete System beim Neustart hängenbleiben.

Wenn das System den Ruhezustand nicht verwendet, können Sie den Parameter resume einfach entfernen und die Boot-Konfiguration aktualisieren.

Vor dem Upgrade des Systems lesen Sie bitte zunächst Kapitel 3, Vorbereiten des Upgrades.

Zum Upgraden des Systems booten Sie von einer Installationsquelle, ebenso wie bei einer Neuinstallation. Im Bootbildschirm wählen Sie dabei jedoch Upgrade (statt Installation). Das Upgrade kann wie folgt gestartet werden:

Im nachfolgenden Verfahren wird das Booten von DVD beschrieben. Sie können jedoch auch ein anderes lokales Installationsmedium verwenden, z. B. ein ISO-Image auf einem USB-Massenspeichergerät. Das Medium und die Bootmethode sind abhängig von der Systemarchitektur und von der Ausstattung des Systems (herkömmliches BIOS oder UEFI).

Zum Upgraden über eine Netzwerkinstallationsquelle müssen die folgenden Anforderungen erfüllt sein:

Vor dem Upgrade des Systems beachten Sie Kapitel 3, Vorbereiten des Upgrades Gehen Sie folgendermaßen vor, um eine automatische Migration auszuführen:

Anmerkung: SUSE Customer Center und Internetverbindung

Wenn das System, das aufgerüstet werden soll, im SUSE Customer Center registriert ist, muss für die folgende Vorgehensweise eine Internetverbindung bestehen.

1. Nach dem Booten (von einem Installationsmedium oder über das Netzwerk) wählen Sie im Bootbildschirm die Option Upgrade.

   

   Warnung: Möglicher Datenverlust durch falsche Auswahl

   Achten Sie darauf, zu diesem Zeitpunkt Upgrade auszuwählen. Falls Sie versehentlich Installation auswählen, wird Ihre Datenpartition mit einer Neuinstallation überschrieben.

   YaST startet das Installationssystem.

2. Wählen Sie im Begrüßungsbildschirm die Optionen Sprache und Tastatur. Fahren Sie mit Weiter fort.

   YaST sucht auf den Partitionen nach bereits installierten SUSE Linux Enterprise-Systemen.

3. Wählen Sie im Bildschirm Zum Upgraden auswählen die Partition zum Upgraden aus und klicken Sie auf Weiter.

4. YaST hängt die ausgewählte Partition ein und zeigt die Lizenzvereinbarung für das upgegradete Produkt an. Akzeptieren Sie die Lizenz, damit Sie den Vorgang fortsetzen können.

5. Passen Sie am Bildschirm Zuvor verwendete Repositorys den Status der Repositorys an. Standardmäßig werden alle Repositorys entfernt. Wenn Sie keine benutzerdefinierten Repositorys hinzugefügt haben, dürfen Sie die Einstellungen nicht ändern. Die Upgrade-Pakete werden von DVD installiert. Sie können optional im nächsten Schritt die standardmäßigen Online-Repositorys aktivieren.

   Bei benutzerdefinierten Repositorys haben Sie zwei Wahlmöglichkeiten:

   • Belassen Sie das Repository im Status „Entfernt“. Software, die von diesem Repository installiert wurde, wird beim Upgrade entfernt. Verwenden Sie diese Methode, wenn keine Version des Repositorys verfügbar ist, die der neuen Version entspricht.

   • Aktualisieren und aktivieren Sie das Repository, falls es der neuen Version entspricht. Ändern Sie deren URL durch Klicken auf das Repository in der Liste. Klicken Sie dann auf Ändern. Aktivieren Sie das Repository mit Status wechseln, bis der Status auf Aktivieren festgelegt ist.

   Behalten Sie keine Repositorys der vorigen Version bei, da das System dann möglicherweise instabil wird oder gar nicht mehr funktioniert. Klicken Sie danach zum Fortfahren auf Weiter.

6. Der nächste Schritt ist davon abhängig, ob das aufgerüstete System im SUSE Customer Center registriert wurde.

   1. Wenn das System nicht im SUSE Customer Center registriert ist, zeigt YaST eine Popup-Meldung an und schlägt ein zweites Installationsmedium vor, das Image SLE-15-SP6-Full-ARCH-GM-media1.iso.

      Sollte dieses Medium nicht zur Verfügung stehen, ist ein Upgrade des Systems ohne Registrierung nicht möglich.

   2. Wenn das System im SUSE Customer Center registriert ist, zeigt YaST die möglichen Migrationsziele und eine Zusammenfassung an.

      Wählen Sie ein Migrationsziel in der Liste aus und setzen Sie den Vorgang mit Weiter fort.

7. Im nächsten Dialogfeld können Sie optional ein zusätzliches Installationsmedium hinzufügen. Wenn Sie zusätzliche Installationsmedien besitzen, aktivieren Sie die Option Ich möchte ein zusätzliches Add-on-Produkt installieren und geben Sie den Medientyp an.

8. Prüfen Sie die Installationseinstellungen für das Upgrade.

9. Wenn die Einstellungen Ihren Anforderungen entsprechen, starten Sie den Installations- und Löschvorgang mit Aktualisieren.

   

   Tipp: Upgrade-Fehler auf SMT-Clients

   Handelt es sich bei dem Rechner, der upgegradet werden soll, um einen SMT-Client und das Upgrade wird nicht ausgeführt, schlagen Sie das Verfahren in Prozedur 3.1, „Aufheben einer Registrierung von SUSE Linux Enterprise Client bei einem SMT-Server“ nach und starten Sie den Upgradevorgang dann neu.

10. Führen Sie nach einem erfolgreichen Upgrade die Schritte nach dem Upgrade aus, die in Kapitel 6, Das Upgrade abschließen beschrieben sind.

SUSE Manager ist eine Serverlösung für die Bereitstellung von Aktualisierungen, Patches und Sicherheitsreparaturen für SUSE Linux Enterprise-Clients. Hier finden Sie eine Reihe von Werkzeugen und eine webgestützte Bedienoberfläche für Verwaltungsaufgaben. Weitere Informationen zu SUSE Manager finden Sie unter https://www.suse.com/products/suse-manager/.

Sie können ein Upgrade des Systems mit SUSE Manager durchführen. Die AutoYaST-Technologie ermöglicht Upgrades von einer Hauptversion zur nächsten.

Wenn Ihr Rechner mit SUSE Manager verwaltet wird, aktualisieren Sie das Programm entsprechend der Beschreibung in der Dokumentation zu SUSE Manager. Das Verfahren zur Client Migration ist im SUSE Manager Upgrade Guide beschrieben, das unter https://documentation.suse.com/suma/ verfügbar ist.

Bei einem Service Pack-Upgrade muss die Konfiguration auf dem Registrierungsserver geändert werden, um den Zugriff auf die neuen Repositorys zu ermöglichen. Wenn ein Upgradevorgang unterbrochen oder (durch Wiederherstellung auf Basis einer Sicherung oder eines Snapshots) rückgängig gemacht wird, stimmen die Informationen auf dem Registrierungsserver nicht mehr mit dem Status des Systems überein. Dies kann dazu führen, dass Sie nicht auf die Aktualisierungs-Repositorys zugreifen können oder die falschen Repositorys auf dem Client verwendet werden.

Wenn über Snapper ein Rollback erfolgt, benachrichtigt das System den Registrierungsserver, um sicherzustellen, dass während des Bootvorgangs der Zugriff auf die richtigen Repositorys eingerichtet wird. Wenn das System mit einer anderen Methode wiederhergestellt wurde oder wenn bei der Kommunikation mit dem Registrierungsserver ein Fehler auftritt, lösen Sie das Rollback auf dem Client manuell aus. Ein Rollback muss beispielsweise manuell ausgelöst werden, wenn der Server aufgrund von Netzwerkproblemen nicht erreichbar war. Mit dem folgenden Befehl führen Sie ein Rollback aus:

> sudo snapper rollback

Es wird empfohlen, grundsätzlich zu prüfen, ob die richtigen Repositorys auf dem System eingerichtet wurden. Dies gilt insbesondere nach der Aktualisierung des Service mit:

> sudo zypper ref -s

Diese Funktionalität ist im Paket rollback-helper verfügbar.

Falls das System vor dem Upgrade noch nicht registriert war, können Sie das System jederzeit mit dem Modul Produktregistrierung in YaST registrieren.

Die Registrierung der Systeme bietet die folgenden Vorteile:

SUSE veröffentlicht in regelmäßigen Abständen neue Service Packs für die SUSE Linux Enterprise-Produktfamilie. Um den Kunden die Migration auf ein neues Service Pack zu erleichtern und die Ausfallzeiten so kurz wie möglich zu halten, unterstützt SUSE eine Online-Migration bei laufendem System.

Ab SLE 12 werden anstelle von YaST-Wagon die YaST-Migration (GUI) und die Zypper-Migration (Befehlszeile) verwendet. Das hat folgende Vorteile:

Warnung: Keine Unterstützung der Online-Migration für Hauptversionen

Die Online-Migration wird ausschließlich bei der Migration auf ein anderes Service Pack unterstützt. Beim Upgraden auf neue Hauptversionen wird die Online-Migration nicht unterstützt. Weitere Informationen finden Sie unter Kapitel 2, Upgrade-Pfade und -Methoden.

Upgraden Sie per Offline-Migration auf eine neue Hauptversion. Weitere Informationen finden Sie unter Kapitel 4, Offline-Upgrade.

Wichtig: Upgrade von SUSE Manager-Clients

Ein SUSE Manager-Client kann weder per YaST-Online-Migration noch per zypper migration aufgerüstet werden. Verwenden Sie stattdessen das Verfahren zur Client Migration. Eine Beschreibung hierzu finden Sie im SUSE Manager Upgrade Guide.

Eine Service Pack-Migration kann mit YaST, zypper oder AutoYAST ausgeführt werden.

Vor dem Start einer Service Pack-Migration muss das System beim SUSE Customer Center oder bei einem lokalen RMT-Server registriert werden. Auch SUSE Manager kann verwendet werden.

Unabhängig von der Methode besteht eine Service Pack-Migration jedoch immer aus den folgenden Schritten:

Die Liste der Migrationsziele ist abhängig von den installierten und registrierten Produkten. Falls Sie eine Erweiterung installiert haben, für die das neue Service Pack noch nicht zur Verfügung steht, wird Ihnen unter Umständen gar kein Migrationsziel angeboten.

Die Liste der Migrationsziele, die für Ihren Host verfügbar sind, wird immer aus dem SUSE Customer Center abgerufen und hängt von den installierten Produkten oder Erweiterungen ab.

Während des Migrationsvorgangs kann eine Service Pack-Migration nur in ganz bestimmten Phasen abgebrochen werden:

Für eine Service Pack-Migration mit YaST verwenden Sie das Tool für die Online-Migration. YaST installiert standardmäßig keine Pakete aus Repositorys von Drittanbietern. Wurde ein Paket aus einem Repository eines Drittanbieters installiert, verhindert YaST, dass das Paket durch das gleiche Paket aus SUSE ersetzt wird.

Anmerkung: Reduzieren des Installationsumfangs

Bei der Service Pack-Migration installiert YaST alle empfohlenen Pakete. Vor allem bei benutzerdefinierten Minimalinstallationen kann dies den Installationsumfang auf dem System beträchtlich erhöhen.

Möchten Sie dieses Standardverhalten ändern und nur erforderliche Pakete erlauben, passen Sie die Option solver.onlyRequires in /etc/zypp/zypp.conf an.

solver.onlyRequires = true

Bearbeiten Sie zusätzlich die Datei /etc/zypp/zypper.conf und ändern Sie die Option installRecommends.

installRecommends=false

Dadurch ändert sich das Verhalten sämtlicher Paketvorgänge, z. B. Installationen von Patches oder neuen Paketen. Mit dem Parameter --no-recommends können Sie das Verhalten von Zypper für einen einzelnen Aufruf ändern.

Gehen Sie wie folgt vor, um die Service Pack-Migration zu starten:

Für eine Service Pack-Migration mit verwenden Sie das Kommandozeilenwerkzeug zypper migrationzypper im Paket zypper-migration-plugin.

Anmerkung: Reduzieren des Installationsumfangs

Bei der Service Pack-Migration installiert YaST alle empfohlenen Pakete. Vor allem bei benutzerdefinierten Minimalinstallationen kann dies den Installationsumfang auf dem System beträchtlich erhöhen.

Möchten Sie dieses Standardverhalten ändern und nur erforderliche Pakete erlauben, passen Sie die Option solver.onlyRequires in /etc/zypp/zypp.conf an.

solver.onlyRequires = true

Bearbeiten Sie zusätzlich die Datei /etc/zypp/zypper.conf und ändern Sie die Option installRecommends.

installRecommends=false

Dadurch ändert sich das Verhalten sämtlicher Paketvorgänge, z. B. Installationen von Patches oder neuen Paketen. Mit dem Parameter --no-recommends können Sie das Verhalten von Zypper für einen einzelnen Aufruf ändern.

Gehen Sie wie folgt vor, um die Service Pack-Migration zu starten:

Falls Ihr System nicht registriert ist, weil Sie keinen Zugriff auf das Internet oder einen Registrierungsserver haben, ist die Migration zu einem neuen Service Pack mit YaST Migration oder zypper migration nicht möglich. In diesem Fall können Sie mit Zypper und einigen manuellen Interaktionen trotzdem zu einem neuen Service Pack migrieren.

Wichtig: Nur für nicht registrierte Systeme

Dieser Migrationspfad zu einem neuen Service Pack wird nur für nicht registrierte Systeme unterstützt, die keinen Zugriff auf das Internet oder einen Registrierungsserver haben. Dies ist möglicherweise bei Rechnern in einem speziell geschützten Netzwerk der Fall. Ein registriertes System können Sie mit YaST oder Zypper migrieren.

Wichtig: Installationsquellen

Dieser Migrationspfad setzt voraus, dass das System, das Sie migrieren möchten, Zugriff auf die Installationsquellen hat. Dies kann beispielsweise durch die Einrichtung eines RMT-Servers oder eines SLP-Servers geschehen.

Das System muss zudem Zugriff auf ein aktuelles Aktualisierungs-Repository für die installierte Produktversion haben.

Falls ein Service Pack nicht ordnungsgemäß ausgeführt wurde, unterstützt SUSE Linux Enterprise die Zurücksetzung des Systems auf den Zustand vor Beginn der Service Pack-Migration. Voraussetzung hierfür ist eine Btrfs-root-Partition mit aktivierten Snapshots (Standard seit SLES 12). Ausführliche Informationen finden Sie unter Book “Verwaltungshandbuch”, Chapter 10 “Systemwiederherstellung und Snapshot-Verwaltung mit Snapper”.

Damit haben Sie das System wieder auf den Zustand zurückgesetzt, der vor Beginn der Service Pack-Migration vorlag.

SUSE Manager ist eine Serverlösung für die Bereitstellung von Aktualisierungen, Patches und Sicherheitsreparaturen für SUSE Linux Enterprise-Clients. Hier finden Sie eine Reihe von Werkzeugen und eine webgestützte Bedienoberfläche für Verwaltungsaufgaben. Weitere Informationen zu SUSE Manager finden Sie unter https://www.suse.com/products/suse-manager/.

Bei der SP-Migration können Sie von einem bestimmten Service Pack (SP) auf ein anderes in derselben Hauptversion migrieren (z. B. von SLES 15 GA auf 15 SP6).

Wenn Ihr Rechner mit SUSE Manager verwaltet wird, aktualisieren Sie das Programm entsprechend der Beschreibung in der Dokumentation zu SUSE Manager. Das Verfahren zur Client Migration ist im SUSE Manager Upgrade Guide beschrieben, das unter https://documentation.suse.com/suma/ verfügbar ist.

Prüfen Sie mit zypper packages auf verwaiste und nicht benötigte Pakete.

Verwaiste Pakete sind in keinem der konfigurierten Repositorys mehr verfügbar. Sie können nicht mehr aktualisiert werden und werden nicht mehr unterstützt.

Eine Liste der verwaisten Pakete erhalten Sie durch Ausführen von:

> zypper packages --orphaned

Nicht benötigte Pakete sind Abhängigkeiten von Paketen, die entweder explizit vom Benutzer oder implizit als Teil eines Schemas oder Produkts installiert wurden und die in der Zwischenzeit entfernt wurden. Sie werden in der Regel nicht mehr benötigt und sollten ebenfalls entfernt werden.

Eine Liste der nicht benötigten Pakete erhalten Sie durch Ausführen von:

> zypper packages --unneeded

Tipp

Um nicht benötigte Pakete zu vermeiden, verwenden Sie zypper rm mit der Option ‑‑clean-deps oder YaST mit Optionen › Beim Löschen von Paketen bereinigen.

Sie können beide Listen in einer kombinieren:

> zypper packages --orphaned --unneeded

Ermitteln Sie anhand dieser Listen, welche Pakete noch benötigt werden und welche Pakete sicher entfernt werden können.

Warnung: Entfernen Sie keine Pakete, die Sie benötigen

Wenn Pakete umbenannt oder aus einem Schema oder Produkt entfernt werden, kann es sein, dass zypper sie nicht mehr als explizit installiert betrachtet und sie als nicht mehr benötigt markiert, obwohl sie für Ihre Installation immer noch wichtig sind.

Prüfen Sie sorgfältig die Liste der Pakete, die Sie entfernen.

Wenn Sie alle verwaisten und nicht mehr benötigten Pakete mit einem einzigen Befehl entfernen möchten, führen Sie folgendes Kommando aus:

> sudo zypper rm $(zypper --no-refresh packages --orphaned --unneeded | gawk '{print $5}' | tail -n +5)

Schließen Sie ein einzelnes Paket oder Schema von der Deinstallation aus:

> sudo zypper rm $(zypper --no-refresh packages --orphaned --unneeded | gawk '{print $5}' | tail -n +5 | grep -v PACKAGE_TO_EXCLUDE)

Schließen Sie mehrere in einer Textdatei definierte Pakete aus, getrennt durch einen Zeilenumbruch:

> sudo zypper rm $(zypper --no-refresh packages --orphaned --unneeded | gawk '{print $5}' | tail -n +5 | grep -v -f /PACKAGES/TO/KEEP.txt)

Suchen Sie nach *.rpmnew- und *.rpmsave-Dateien. Wenn ein Upgrade Änderungen an einer Standardkonfigurationsdatei enthält, die nach der Paketinstallation geändert wurde, wird einer dieser Dateitypen erstellt, anstatt die Datei zu überschreiben. Die Datei *.rpmnew enthält die neue Standardkonfiguration und lässt Ihre Originaldatei unverändert. *.rpmsave ist eine Kopie der geänderten Konfiguration, die durch die neue Standarddatei ersetzt wurde.

Wenn Sie eine dieser Dateien finden, prüfen Sie deren Inhalt und fügen Sie die gewünschten Änderungen zusammen. Sie müssen nicht das gesamte Dateisystem durchsuchen, sondern nur das Verzeichnis /etc. Verwenden Sie den folgenden Befehl:

> find /etc/ -name "*.rpmnew" -o -name "*.rpmsave"

SUSE Linux Enterprise Desktop 15 verwendet standardmäßig Python 3.6. Python 3.9 wurde in SLED 15 SP3 als neuere Alternative hinzugefügt. Diese Version wird ab SLED 15 SP4 nicht mehr unterstützt. Stattdessen sind aktuelle Python-Versionen mit wichtigen Updates und Sicherheits-Fixes über das Python 3-Modul verfügbar.

Wenn Sie Python 3.9 unter SUSE Linux Enterprise Desktop 15 SP installiert haben, aktivieren Sie das Python 3-Modul mit:

> sudo SUSEConnect -p sle-module-python3/15.6/x86_64.

Alternativ können Sie zur Standard-Python-Version zurückkehren, indem Sie bei zypper remove -u python39 entfernen.

SUSE Linux Enterprise Desktop unterstützt das „On-Disk-Format“ (v5) des XFS-Dateisystems. Die wichtigsten Vorteile dieses Formats sind automatische Prüfsummen aller XFS-Metadaten, die Unterstützung von Dateitypen sowie einer größeren Anzahl von Zugriffskontrolllisten für eine Datei.

Dieses Format von SUSE Linux Enterprise-Kerneln, die älter als Version 3.12 sind, von xfsprogs, die älter als Version 3.2.0 sind, und von GRUB 2-Versionen, die vor SUSE Linux Enterprise 12 veröffentlicht wurden, werden nicht unterstützt.

Wichtig: V4 wird außer Kraft gesetzt

XFS setzt Dateisysteme mit dem V4-Format außer Kraft. Dieses Dateisystemformat wurde mit folgendem Befehl erstellt:

> sudo mkfs.xfs -m crc=0 DEVICE

Das Format wurde in SLE 11 und älteren Versionen verwendet und erzeugt derzeit eine Warnmeldung von dmesg:

Deprecated V4 format (crc=0) will not be supported after September 2030

Wenn Sie die obige Meldung in der Ausgabe des dmesg-Befehls sehen, sollten Sie für Ihr Dateisystem eine Aktualisierung auf das V5-Format vornehmen:

1. Sichern Sie Ihre Daten auf einem anderen Gerät.

2. Erstellen Sie das Dateisystem auf dem Gerät.

   > sudo mkfs.xfs -m crc=1 DEVICE

3. Stellen Sie die Daten aus der Sicherung auf dem aktualisierten Gerät wieder her.

Upstream-Entwickler befassen sich hauptsächlich damit, die Software weiterzuentwickeln. In vielen Fällen beheben sie Fehler, während sie gleichzeitig neue Funktionen einbauen, die noch nicht eingehend getestet wurden und daher ihrerseits neue Fehler verursachen.

Distributionsentwickler müssen daher zwischen Folgendem unterscheiden:

In den meisten Fällen beachten Distributionsentwickler nicht alle Upstream-Änderungen, sobald ein Paket in eine veröffentlichte Distribution eingebunden ist. Häufig bleiben sie bei der Upstream-Version, die sie ursprünglich veröffentlicht hatten, und sie erstellen auf Patches auf der Grundlage der Upstream-Änderungen, mit denen dann Fehler behoben werden sollen. Dies wird als Rückportierung bezeichnet.

Im Allgemeinen stellen Distributionsentwickler nur in zwei Fällen eine neuere Software-Version bereit:

Bei SUSE wird die Rückportierung umfassend genutzt, damit die verschiedenen Anforderungen an Unternehmenssoftware in ein gesundes Gleichgewicht gebracht werden können. Beispiele für die wichtigsten Punkte:

Es gilt die allgemeine Richtlinie, dass keine neuen Upstream-Versionen eines Pakets in unsere Unternehmensprodukte eingeführt werden. Diese Regel ist allerdings nicht ohne Ausnahmen. Bei bestimmten Arten von Paketen, insbesondere bei Antiviren-Software, wiegen die Sicherheitsaspekte schwerer als die konservative Vorgehensweise, die mit Blick auf die Qualitätssicherung aus einzuhalten wäre. Für Pakete in dieser Klasse werden gelegentlich neuere Versionen in eine veröffentliche Version einer Unternehmensproduktlinie eingeführt.

Gelegentlich wird auch bei anderen Arten von Paketen entschieden, eine neue Version einzuführen, statt eine Rückportierung vorzunehmen. Dies ist dann der Fall, wenn eine Rückportierung wirtschaftlich nicht praktikabel ist oder wenn äußerst relevante technische Argumente für die Einführung der neueren Version sprechen.

Aufgrund der verbreiteten Praxis der Rückportierungen ist es nicht möglich, aus einem einfachen Vergleich der Versionsnummern festzustellen, ob ein SUSE-Paket eine Korrektur für ein bestimmtes Problem enthält oder eine bestimmte Funktion in dieses Paket eingefügt wurde. Durch die Rückportierung gibt der Upstream-Teil der Versionsnummer eines SUSE-Pakets lediglich an, auf welcher Upstream-Version das SUSE-Paket basiert. Das Paket enthält unter Umständen Fehlerkorrekturen und Funktionen, die in der zugehörigen Upstream-Version fehlen, jedoch in das SUSE-Paket rückportiert wurden.

Diese eingeschränkte Aussagefähigkeit der Versionsnummern durch die Rückportierung macht sich insbesondere bei Sicherheitssuchwerkzeugen negativ bemerkbar. Einige Werkzeuge für die Suche nach Sicherheitslücken (oder bestimmte Tests in diesen Werkzeugen) beruhen ausschließlich auf den Versionsinformationen. Wenn Rückportierungen zum Einsatz kommen, liefern diese Tools und Tests daher häufig „falsch-positive“ Ergebnisse (eine Software wird irrtümlich als anfällig eingestuft). Achten Sie daher in allen Berichten von Sicherheits-Scan-Tools darauf, ob ein Eintrag auf der Grundlage einer Versionsnummer entstanden ist oder nach einem tatsächlichen Test auf Schwachstellen.

Informationen über rückportierte Fehlerbehebungen und Funktionen werden an mehreren Stellen gespeichert: