Zum Inhalt springen
documentation.suse.com / Upgradehandbuch
SUSE Linux Enterprise Server 15 SP3

Upgradehandbuch

Dieses Handbuch führt Sie durch das Upgrade von SUSE Linux Enterprise Server. Wenn Sie SUSE Linux Enterprise Server als Basissystem für andere SLE-Produkte oder -Erweiterungen verwenden, finden Sie in deren Produktdokumentation auch Informationen zum Upgrade, die speziell für dieses Produkt oder diese Erweiterung gelten.

Veröffentlicht: 29. September 2024

Copyright © 2006–2024 SUSE LLC und Mitwirkende. Alle Rechte vorbehalten.

Es wird die Genehmigung erteilt, dieses Dokument unter den Bedingungen der GNU Free Documentation License, Version 1.2 oder (optional) Version 1.3 zu vervielfältigen, zu verbreiten und/oder zu verändern; die unveränderlichen Abschnitte hierbei sind der Urheberrechtshinweis und die Lizenzbedingungen. Eine Kopie dieser Lizenz (Version 1.2) finden Sie im Abschnitt GNU Free Documentation License.

Die SUSE-Marken finden Sie unter https://www.suse.com/company/legal/. Alle anderen Marken von Drittanbietern sind Besitz ihrer jeweiligen Eigentümer. Markensymbole (®, ™ usw.) kennzeichnen Marken von SUSE und der Tochtergesellschaften. Sternchen (*) kennzeichnen Marken von Drittanbietern.

Alle Informationen in diesem Buch wurden mit größter Sorgfalt zusammengestellt. Doch auch dadurch kann hundertprozentige Richtigkeit nicht gewährleistet werden. Weder SUSE LLC noch ihre Tochtergesellschaften noch die Autoren noch die Übersetzer können für mögliche Fehler und deren Folgen haftbar gemacht werden.

Vorwort

1 Verfügbare Dokumentation

Online-Dokumentation

Die Online-Dokumentation zu diesem Produkt ist unter https://documentation.suse.com/#sles verfügbar. Durchsuchen Sie die Dokumentation oder laden Sie sie in verschiedenen Formaten herunter.

Die Online-Dokumentation für andere Produkte finden Sie unter https://documentation.suse.com/.

Anmerkung
Anmerkung: Neueste Aktualisierungen

Die neuesten Aktualisierungen der Dokumentation sind normalerweise in der englischen Version der Dokumentation verfügbar.

Versionshinweise

Die Versionshinweise finden Sie unter https://www.suse.com/releasenotes/.

In Ihrem System

Für die Offline-Nutzung finden Sie die Dokumentation in Ihrem installierten System unter /usr/share/doc. Viele Kommandos sind auch detailliert auf den Handbuchseiten beschrieben. Führen Sie zu deren Anzeige man gefolgt von einem bestimmten Kommandonamen aus. Sollte das man-Kommando nicht auf Ihrem System installiert sein, müssen Sie es mit sudo zypper install man installieren.

2 Verbessern der Dokumentation

Ihr Feedback und Beiträge zu dieser Dokumentation sind willkommen. Mehrere Kanäle stehen zur Verfügung:

Serviceanforderungen und Support

Informationen zu Diensten und Support-Optionen, die für Ihr Produkt verfügbar sind, finden Sie unter https://www.suse.com/support/.

Zum Öffnen einer Service-Anforderung benötigen Sie ein Abonnement beim SUSE Customer Center. Gehen Sie zu https://scc.suse.com/support/requests, melden Sie sich an und klicken Sie auf Neu erstellen.

Fehlerberichte

Melden Sie Probleme mit der Dokumentation unter https://bugzilla.suse.com/. Zur Vereinfachung dieses Vorgangs können Sie die Links Report Documentation Bug (Fehler in der Dokumentation melden) neben den Überschriften in der HTML-Version dieses Dokuments verwenden. Dadurch wird das richtige Produkt und die Kategorie in Bugzilla vorab ausgewählt und ein Link zum aktuellen Abschnitt hinzugefügt. Sie können somit sofort mit der Eingabe Ihres Berichts beginnen. Ein Bugzilla-Konto ist erforderlich.

Beiträge

Verwenden Sie für einen Beitrag zu dieser Dokumentation die Links Edit Source (Quelle bearbeiten) neben den Überschriften in der HTML-Version dieses Dokuments. Sie führen Sie zum Quellcode auf GitHub, wo Sie eine Pull-Anforderung öffnen können. Ein GitHub-Konto ist erforderlich.

Weitere Informationen zur Dokumentationsumgebung für diese Dokumentation finden Sie in der README des Repositorys.

Email

Alternativ können Sie Emails mit Fehlerberichten und Feedback zur Dokumentation an <> senden. Geben Sie auf jeden Fall auch den Titel der Dokumentation, die Produktversion und das Datum der Veröffentlichung der Dokumentation an. Beziehen Sie sich auf die entsprechende Abschnittsnummer und den Titel (oder geben Sie die URL an) und fügen Sie eine kurze Beschreibung des Problems hinzu.

3 Konventionen in der Dokumentation

In der vorliegenden Dokumentation werden die folgenden Hinweise und typografischen Konventionen verwendet:

  • /etc/passwd: Verzeichnis- und Dateinamen

  • PLATZHALTER: Ersetzen Sie PLATZHALTER durch den tatsächlichen Wert.

  • PATH: die Umgebungsvariable PATH

  • ls, --help: Kommandos, Optionen und Parameter

  • Benutzer: Benutzer oder Gruppen

  • Paketname: Name eines Pakets

  • Alt, AltF1: Eine Taste oder Tastenkombination. Tastennamen werden wie auf der Tastatur in Großbuchstaben dargestellt.

  • Datei, Datei › Speichern unter: Menüelemente, Schaltflächen

  • AMD/Intel Dieser Absatz ist nur für die AMD64-/Intel-64-Architektur relevant. Die Pfeile kennzeichnen den Anfang und das Ende des Textblocks.

    IBM Z, POWER Dieser Absatz ist nur für die Architekturen IBM Z und POWER relevant. Die Pfeile kennzeichnen den Anfang und das Ende des Textblocks.

  • Tanzende Pinguine (Kapitel Pinguine, ↑Zusätzliches Handbuch): Dies ist ein Verweis auf ein Kapitel in einem anderen Handbuch.

  • Kommandos, die mit root-Privilegien ausgeführt werden müssen. Diesen Kommandos kann zur Ausführung als nicht privilegierter Benutzer auch häufig das Präfix sudo vorangestellt sein.

    root # command
    tux > sudo command
  • Kommandos, die von Benutzern ohne Privilegien ausgeführt werden können.

    tux > command
  • Hinweise

    Warnung
    Warnung: Warnhinweis

    Wichtige Informationen, die Sie kennen müssen, bevor Sie fortfahren. Warnt vor Sicherheitsrisiken, potenziellen Datenverlusten, Beschädigung der Hardware oder physischen Gefahren.

    Wichtig
    Wichtig: Wichtiger Hinweis

    Wichtige Informationen, die Sie beachten sollten, bevor Sie den Vorgang fortsetzen.

    Anmerkung
    Anmerkung: Anmerkung

    Ergänzende Informationen, beispielsweise zu unterschiedlichen Softwareversionen.

    Tipp
    Tipp: Tipp

    Hilfreiche Informationen, etwa als Richtlinie oder praktische Empfehlung.

4 Support

Im Folgenden finden Sie die Supportbestimmung für SUSE Linux Enterprise Server sowie allgemeine Informationen über Technologievorschauen. Details über den Produktlebenszyklus finden Sie im Kapitel 2, Lebenszyklus und Support.

Wenn Sie Anspruch auf Support haben, finden Sie Details zum Sammeln von Informationen für ein Support-Ticket im Book “Verwaltungshandbuch”, Chapter 39 “Erfassen der Systeminformationen für den Support”.

4.1 Supportbestimmung für SUSE Linux Enterprise Server

Sie benötigen ein entsprechendes Abonnement bei SUSE, um Support zu erhalten. Gehen Sie zur Anzeige der für Sie verfügbaren spezifischen Support-Angebote zu https://www.suse.com/support/ und wählen Sie das betreffende Produkt aus.

Die Support-Stufen sind folgendermaßen definiert:

L1

Problemermittlung: Technischer Support mit Informationen zur Kompatibilität, Nutzungs-Support, kontinuierliche Wartung, Informationssammlung und einfache Problembehandlung anhand der verfügbaren Dokumentation.

L2

Problemisolierung: Technischer Support zur Datenanalyse, Reproduktion von Kundenproblemen, Isolierung von Problembereichen und Lösung für Probleme, die in Stufe 1 nicht gelöst wurden sowie Vorbereitung für Stufe 3.

L3

Problembehebung: Technischer Support zur Lösung von Problemen durch technische Maßnahmen zur Behebung von Produktfehlern, die durch den Support der Stufe 2 erkannt wurden.

Vertragskunden und Partner erhalten SUSE Linux Enterprise Server mit L3-Support für alle Pakete, ausgenommen:

  • Technologievorschauen

  • Audio, Grafik, Schriftarten und Artwork

  • Pakete, für die ein zusätzlicher Kundenvertrag erforderlich ist

  • Einige Pakete, die im Lieferumfang von Modul Workstation Extension enthalten sind, erhalten nur L2-Support.

  • Pakete mit Namen endend auf -devel (die Header-Dateien und ähnliche Entwicklerressourcen enthalten) werden nur zusammen mit den entsprechenden Hauptpaketen unterstützt.

SUSE unterstützt nur die Nutzung von Originalpaketen. Also unveränderte und nicht kompilierte Pakete.

4.2 Technologievorschauen

Mit Technologievorschauen sind Pakete, Stacks oder Funktionen gemeint, die SUSE bereitstellt, um einen kurzen Einblick in bevorstehende Innovationen zu geben. Durch die Vorschauen haben Sie die Möglichkeit, neue Technologien in Ihrer Umgebung zu testen. Über Ihr Feedback würden wir uns sehr freuen. Wenn Sie eine Technologievorschau testen, kontaktieren Sie Ihre Ansprechpartner bei SUSE und teilen Sie ihnen Ihre Erfahrungen und Anwendungsfälle mit. Ihr Input ist für zukünftige Entwicklungen sehr hilfreich.

Technologievorschauen haben jedoch die folgenden Einschränkungen:

  • Technologievorschauen befinden sich noch in Entwicklung. Daher sind die Funktionen möglicherweise unvollständig oder auf andere Weise nicht für die Produktionsnutzung geeignet.

  • Technologievorschauen werden nicht unterstützt.

  • Technologievorschauen sind möglicherweise nur für bestimmte Hardwarearchitekturen verfügbar.

  • Details und Funktionen von Technologievorschauen sind Änderungen unterworfen. Upgrades auf Folgeversionen sind demnach nicht möglich und erfordern eine Neuinstallation.

  • Technologievorschauen können jederzeit verworfen werden. Zum Beispiel wenn SUSE erkennt, dass eine Vorschau nicht den Kunden- oder Marktanforderungen entspricht oder nachweislich nicht den Unternehmensstandards entspricht. SUSE ist nicht verpflichtet, eine unterstützte Version dieser Technologie in der Zukunft bereitzustellen.

Eine Übersicht der Technologievorschauen, die im Lieferumfang Ihres Produkts enthalten sind, finden Sie in den Versionshinweisen unter https://www.suse.com/releasenotes/.

1 Upgrade-Pfade und -Methoden

SUSE® Linux Enterprise (SLE) ermöglicht das Upgrade eines vorhandenen Systems auf die neue Version, zum Beispiel von SLE 12 SP4 auf das aktuelle Service Pack für SLE 15. Es ist keine neue Installation erforderlich. Bestehende Daten wie Home- und Datenverzeichnisse sowie Systemkonfigurationen bleiben erhalten. Sie können die Aktualisierung von einem lokalen CD- oder DVD-Laufwerk oder von einer zentralen Netzwerkinstallationsquelle durchführen.

In diesem Kapitel erfahren Sie, wie Sie das SUSE Linux Enterprise-System manuell per DVD, über das Netzwerk, mit einem automatisierten Prozess oder mit SUSE Manager upgraden.

1.1 Upgrade im Vergleich zu Neuinstallation

Upgrades zwischen zwei Hauptversionen von SUSE Linux Enterprise Server 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.

1.2 Unterstützte Upgrade-Pfade auf SLES 15 SP3

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

Wichtig
Wichtig: Architekturübergreifende Upgrades werden nicht unterstützt

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

Insbesondere SLE 11 unter POWER (Big Endian) auf SLE 15 SP3 unter POWER (neu: Little Endian) wird 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
Anmerkung: Überspringen von Service Packs

Der einfachste Upgrade-Pfad ist die sukzessive Installation aller Service Packs. Für die SUSE Linux Enterprise 15-Produktlinie (GA und die folgenden Service Packs) wird das Überspringen eines Service Packs beim Upgrade unterstützt. Beispielsweise wird ein Upgrade von SLE 15 GA auf 15 SP2 oder von SLE 15 SP1 auf 15 SP3 unterstützt.

Überblick über die unterstützten Upgrade-Pfade
Abbildung 1.1: Überblick über die unterstützten Upgrade-Pfade
Warnung
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. Wenn Sie Workloads wie PostgreSQL- oder MariaDB-Datenbanken haben, können zwischenzeitliche Betriebssystem-Upgrades erforderlich sein, um Ihre Datenbanken zu aktualisieren.

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

Unterstützte Upgrade-Pfade pro Version
Upgrade von SUSE Linux Enterprise Server 11 GA/SP1/SP2/SP3/SP4

Ein direktes Upgrade von SLES 11 SP4 oder älteren Service Packs wird nicht unterstützt. Sie benötigen mindestens SLES 11 SP4 LTSS, bevor Sie mit SLES 15 SP3 fortfahren können.

Falls Sie keine Neuinstallation ausführen können, führen Sie zunächst ein Upgrade des installierten SLES 11-Service Packs auf SLES 11 SP4 LTSS durch. Dieses Upgrade ist im SLES 11 SP4 Bereitstellungshandbuch beschrieben.

Upgrade von SUSE Linux Enterprise Server 11 SP4 LTSS

Ein Upgrade von SLES 11 SP4 wird nur im Offline-Modus unterstützt. Weitere Informationen finden Sie im Kapitel 4, Offline-Upgrade.

Upgrade von SUSE Linux Enterprise Server 12 GA/SP1/SP2/SP3/SP4

Ein direktes Upgrade von SLES 12 SP4 oder älteren Service Packs wird nicht unterstützt. Sie benötigen mindestens SLES 12 SP5, bevor Sie mit SLES 15 SP3 fortfahren können.

Falls Sie keine Neuinstallation ausführen können, rüsten Sie zunächst das installierte·SLES 12-Service Pack auf SLES 12 SP5 auf. Dieses Upgrade ist im SLES 12 SP5 Bereitstellungshandbuch beschrieben.

Upgrade von SUSE Linux Enterprise Server 12 LTSS/SP4 LTSS

Ein Upgrade von SLES 12 SP3 oder SP4 wird nur als Offline-Upgrade unterstützt. Weitere Informationen finden Sie im Kapitel 4, Offline-Upgrade.

Upgrade von SUSE Linux Enterprise Server 12 SP5

Ein Upgrade von SLES 12 SP5 wird nur im Offline-Modus unterstützt. Weitere Informationen finden Sie im Kapitel 4, Offline-Upgrade.

Upgrade von SUSE Linux Enterprise Server 15 GA

Ein direktes Upgrade von SLES 15 GA wird nicht unterstützt. Sie benötigen mindestens SLES 15 SP1, bevor Sie mit SLES 15 SP3 fortfahren können.

Upgrade von SUSE Linux Enterprise Server 15 SP1 / SP2

Ein Upgrade von SLES 15 SP1 oder SP2 wird sowohl online als auch offline unterstützt. Weitere Informationen finden Sie im Abschnitt 1.3, „Online- und Offline-Upgrade“.

Upgrade von SUSE Linux Enterprise-Gästen in der öffentlichen Cloud

Anleitungen für ein Upgrade von SLE-Gästen in öffentlichen Clouds finden Sie im Using the SUSE Distribution Migration System (Verwenden des SUSE Distribution Migration Systems).

Upgrade von openSUSE Leap 15

Ein Upgrade von openSUSE Leap 15 wird unterstützt. Weitere Informationen hierzu finden Sie im Abschnitt 5.9, „Upgrade von openSUSE Leap zu SUSE Linux Enterprise Server. Für ein Upgrade wird nur die Serverinstallation von Leap unterstützt.

1.3 Online- und Offline-Upgrade

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

Online

Upgrades, die vom laufenden Betriebssystem selbst ausgeführt werden (System aktiv). Beispiele: Online-Aktualisierung mit Zypper oder YaST, verbunden über das SUSE Customer Center oder Repository Mirroring Tool (RMT), Salt Policy über SUSE Manager.

Weitere Informationen finden Sie im Kapitel 5, Online-Upgrade.

Zur Migration auf andere Service Packs derselben Hauptversion wird Abschnitt 5.4, „Upgraden mit dem Werkzeug für die Online-Migration (YaST)“ oder Abschnitt 5.5, „Upgraden mit zypper“ empfohlen.

Offline

Eine Offline-Aufrüstung impliziert, dass das aufzurüstende Betriebssystem nicht ausgeführt wird (System nicht aktiv). Stattdessen wird das Installationsprogramm für das Zielbetriebssystem gebootet (zum Beispiel von einem Installationsmedium, über das Netzwerk oder einen lokalen Bootloader) und führt das Upgrade durch.

Weitere Informationen finden Sie im Kapitel 4, Offline-Upgrade.

Wichtig
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 wird im SUSE Manager-Upgrade-Handbuch beschrieben. Es ist verfügbar unter https://documentation.suse.com/suma/.

2 Lebenszyklus und Support

In diesem Kapitel finden Sie Hintergrundinformationen zur Terminologie, zu den Lebenszyklen und Service-Pack-Versionen der SUSE-Produkte sowie zu den empfohlenen Upgraderichtlinien.

2.1 Terminologie

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

Rückportierung

Bei der Rückportierung werden bestimmte Änderungen aus einer neueren Software-Version auf eine ältere Version angewendet. Dies ist am häufigsten beim Beheben von Sicherheitslücken in älteren Software-Komponenten der Fall. In der Regel gehört dieser Vorgang auch zu einem Wartungsmodell, bei dem Verbesserungen oder (seltener) neue Funktionen bereitgestellt werden.

Delta-RPM

Ein Delta-RPM besteht nur aus der binären diff zwischen zwei definierten Versionen eines Pakets und hat daher die kleinste Downloadgröße. Vor der Installation muss das vollständige RPM-Paket auf dem lokalen Rechner neu aufgebaut werden.

Downstream

Bildlicher Ausdruck, wie Software in der Open-Source-Welt entwickelt wird (vgl. Upstream). Mit Downstream werden Personen oder Organisationen wie SUSE bezeichnet, die den Upstream-Quellcode in andere Software integrieren und so eine Distribution zusammenstellen, die dann von den Endbenutzern verwendet wird. So wandert die Software in Downstream-Richtung von den Entwicklern über die Integratoren bis hin zu den Endbenutzern.

Erweiterungen, Add-on-Produkt

Erweiterungen und Add-on-Produkte von Drittanbietern bieten zusätzliche Funktionen, die den Nutzwert von SUSE Linux Enterprise Server. Sie werden von SUSE und SUSE-Partnern bereitgestellt und werden zusätzlich zum Basisprodukt SUSE Linux Enterprise Server registriert und installiert.

LTSS

LTSS ist die Abkürzung für Long Term Service Pack Support, der als Erweiterung für SUSE Linux Enterprise Server erhältlich ist.

Hauptversion, Version zur allgemeinen Verfügung (General Availability, GA)

Die Hauptversion von SUSE Linux Enterprise (oder von einem beliebigen Softwareprodukt) ist eine neue Version mit neuen Funktionen und Tools. Sie setzt vorher veraltete Komponenten außer Kraft und führt Änderungen ein, die nicht rückwärtskompatibel sind. Hauptversionen sind beispielsweise SUSE Linux Enterprise 12 oder 15.

Migration

Aktualisierung auf ein Service Pack (SP), bei der die erforderlichen Patches über die Online-Aktualisierungswerkzeuge oder ein Installationsmedium installiert werden. Dadurch werden alle Pakete des installierten Systems auf den neuesten Stand gebracht.

Migrationsziele

Gruppe kompatibler Produkte, auf die ein System migriert werden kann (mit Version der Produkte/Erweiterungen und URL des Repositorys). Die Migrationsziele können sich im Lauf der Zeit ändern und sind abhängig von den installierten Erweiterungen. Mehrere Migrationsziele können ausgewählt werden, wie zum Beispiel SLE 15 SP1 und SES 6.

Module

Module sind vollständig unterstützte Bestandteile von SUSE Linux Enterprise Server, die allerdings einen anderen Lebenszyklus aufweisen. Die Module besitzen einen klar definierten Umfang und werden ausschließlich über einen Online-Kanal bereitgestellt. Diese Kanäle können Sie nur dann abonnieren, wenn Sie sich beim SUSE Customer Center, beim RMT (Repository Mirroring Tool) oder beim SUSE Manager registriert haben.

Paket

Ein Paket ist eine komprimierte Datei im RPM-Format, die die Dateien für ein bestimmtes Programm enthält oder auch optionale Komponenten wie Konfigurationen, Beispiele und Dokumentation.

Patch

Ein Patch enthält mindestens ein Paket und kann per Delta-RPMs angewendet werden. Unter Umständen werden auch Abhängigkeiten zu Paketen aufgebaut, die noch nicht installiert wurden.

Service Packs (SP)

Kombinieren mehrere Patches zu einem "Paket", das einfach zu installieren bzw. bereitzustellen ist. Service Packs sind nummeriert und enthalten üblicherweise Sicherheits-Fixes, Upgrades oder Programmerweiterungen.

Upstream

Bildlicher Ausdruck, wie Software in der Open-Source-Welt entwickelt wird (vgl. Downstream). Mit Upstream wird das ursprüngliche Projekt, der Autor oder der Betreuer einer Software bezeichnet, die als Quellcode verteilt wird. Rückmeldungen, Patches, Funktionsoptimierungen und andere Verbesserungen wandern von den Endbenutzern oder Beteiligten zu den Upstream-Entwicklern. Diese entscheiden, ob die Anforderung integriert oder abgelehnt wird.

Wenn die Projektmitglieder entscheiden, die Anforderung zu integrieren, wird diese in den neuen Versionen der Software auftreten. Eine akzeptierte Anforderung bietet Nutzen für alle Beteiligten.

Falls eine Anforderung abgelehnt wird, kommen hierfür unterschiedliche Gründe in Betracht. Die Anforderung weist einen Status auf, der nicht den Richtlinien des Projekts entspricht, sie ist ungültig, wurde bereits integriert oder liegt nicht im Interesse oder im Gesamtplan des Projekts. Eine nicht akzeptierte Anforderung erschwert die Arbeit für die Upstream-Entwickler, da sie ihre Patches mit dem Upstream-Code synchron halten müssen. Diese Vorgehensweise wird daher weitestgehend vermieden, ist jedoch in einigen Fällen unumgänglich.

Aktualisierung

Installation einer neueren Unterversion eines Pakets, die in der Regel Sicherheitsverbesserungen oder Fehlerbehebungen enthält.

Upgrade

Installation einer neueren Hauptversion eines Pakets oder einer Distribution, die neue Funktionen enthält. In Abschnitt 1.3, „Online- und Offline-Upgrade“ finden Sie Informationen zu den Unterschieden zwischen den Upgrade-Optionen.

2.2 Produktlebenszyklus

Für die SUSE-Produkte gelten die folgenden Lebenszyklen:

  • SUSE Linux Enterprise Server hat einen Lebenszyklus von 13 Jahren: 10 Jahre allgemeiner Support und drei Jahre erweiterter Support.

  • SUSE Linux Enterprise Desktop hat einen Lebenszyklus von 10 Jahren: Sieben Jahre allgemeiner Support und drei Jahre erweiterter Support.

  • Hauptversionen werden alle vier Jahre veröffentlicht. Service Packs werden alle 12 bis 14 Monate bereitgestellt.

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

Hauptversionen und Service Packs
Abbildung 2.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 im Abbildung 2.2, „Langfristiger Service Pack-Support“.

Langfristiger Service Pack-Support
Abbildung 2.2: Langfristiger Service Pack-Support

Weitere Informationen 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 im https://www.suse.com/lifecycle.

2.3 Abhängigkeiten und Lebenszyklen der Module

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

2.4 Erzeugen eines periodischen Lebenszyklusberichts

SUSE Linux Enterprise Server kann regelmäßig nach Supportstatus-Aktualisierungen aller installierten Produkte suchen und bei Änderungen einen Bericht per E-Mail versenden. Zum Erzeugen des Berichts installieren Sie zypper-lifecycle-plugin mit zypper in zypper-lifecycle-plugin.

Aktivieren Sie die Berichterzeugung auf dem System mit systemctl:

root # systemctl enable lifecycle-report

Der Empfänger und der Betreff der Bericht-Email sowie das Intervall für die Berichterzeugung 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 E-Mail 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.

2.5 Supportstufen

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 2.1, „Sicherheitsaktualisierungen und Fehlerbehebungen“.

Tabelle 2.1: Sicherheitsaktualisierungen und Fehlerbehebungen
 

Allgemeiner Support für den neuesten Service Pack (SP)

Allgemeiner Support für einen älteren SP, mit LTSS

Erweiterter Support mit LTSS

Funktion

Jahr 1 bis 5

Jahr 6 bis 7

Jahr 8 bis 10

Jahr 4 bis 10

Jahr 10 bis 13

Technischer Support

Ja

Ja

Ja

Ja

Ja

Zugriff auf Patches und Reparaturen

Ja

Ja

Ja

Ja

Ja

Zugriff auf Dokumentation und Wissensdatenbank

Ja

Ja

Ja

Ja

Ja

Support für vorhandene Stacks und Workloads

Ja

Ja

Ja

Ja

Ja

Support für neue Bereitstellungen

Ja

Ja

Eingeschränkt (basierend auf Partner- und Kundenanforderungen)

Eingeschränkt (basierend auf Partner- und Kundenanforderungen)

Nein

Verbesserungsanfragen

Ja

Eingeschränkt (basierend auf Partner- und Kundenanforderungen)

Eingeschränkt (basierend auf Partner- und Kundenanforderungen)

Nein

Nein

Hardwareaktivierung und -optimierung

Ja

Eingeschränkt (basierend auf Partner- und Kundenanforderungen)

Eingeschränkt (basierend auf Partner- und Kundenanforderungen)

Nein

Nein

Treiberaktualisierungen über SUSE SolidDriver Program (früher PLDP)

Ja

Ja

Eingeschränkt (basierend auf Partner- und Kundenanforderungen)

Eingeschränkt (basierend auf Partner- und Kundenanforderungen)

Nein

Rückportierung von Reparaturen aus einem früheren SP

Ja

Ja

Eingeschränkt (basierend auf Partner- und Kundenanforderungen)

Nicht zutreffend

Nicht zutreffend

Sicherheitsaktualisierungen

Alle

Alle

Alle

Nur kritische

Nur kritische

Fehlerhafte Auflösung

Ja

Ja

Eingeschränkt (nur Fehler der Sicherheitsstufe 1 und 2)

Eingeschränkt (nur Fehler der Sicherheitsstufe 1 und 2)

Eingeschränkt (nur Fehler der Sicherheitsstufe 1 und 2)

1 Weitere Informationen zur SUSE Linux Enterprise-Aktualisierungsrichtlinie finden Sie im folgenden Artikel in der Wissendatenbank.

2.6 Registrieren von Computern und Aufheben der Registrierung mit SUSEConnect

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:

root # 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 der Kanal stammt.

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

root # SUSEConnect -r REGCODE

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

root # SUSEConnect --de-register

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

root # SUSEConnect -s

2.7 Ermitteln der SLE-Version

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

zypper bietet eine maschinenlesbare XML-Ausgabe:

tux > 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>

3 Vorbereiten des Upgrades

Vor Beginn des Upgrades muss das System ordnungsgemäß vorbereitet werden. Zur Vorbereitung gehören unter anderem das Sichern der Daten und das Lesen der Versionshinweise. Im folgenden Kapitel werden Sie durch diese Schritte geführt.

3.1 Prüfen, ob das aktuelle System auf dem neuesten Stand 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.

3.2 Die Versionshinweise lesen

Eine Liste aller Änderungen, neuen Funktionen und bekannten Probleme finden Sie in den Versionshinweisen. 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.

Informieren Sie sich in den Versionshinweisen über Folgendes:

  • Sind bei der Hardware besondere Überlegungen zu beachten?

  • Wurden erhebliche Änderungen an den verwendeten Software-Paketen vorgenommen?

  • Gelten besondere Vorsichtsmaßnahmen für die vorliegende Installation?

3.3 Eine Sicherung erstellen

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.

3.4 Auflisten installierter Pakete und Repositorys

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

  1. Erstellen Sie die Datei repositories.bak-repo mit einer Liste aller verwendeten Repositorys.

    root # zypper lr -e repositories.bak
  2. Erstellen Sie außerdem die Datei installed-software.bak mit einer Liste aller installierten Pakete:

    root # rpm -qa --queryformat '%{NAME}\n' >
         installed-software.bak
  3. Erstellen Sie Sicherungskopien beider Dateien. Die Repositorys und die installierten Pakete können mit den folgenden Befehlen wiederhergestellt werden:

    root # zypper ar repositories.bak.repo
    root # zypper install $(cat installed-software.bak)
    Anmerkung
    Anmerkung: Bei einer Aktualisierung auf eine neue Hauptversion erhöht sich die Anzahl der Pakete

    Ein System, das auf eine neue Hauptversion upgegradet wurde (SLE X+1), enthält eventuell mehr Pakete als das ursprüngliche System (SLE X). Die Anzahl der Pakete ist außerdem höher als bei einer Neuinstallation von SLE X+1 mit derselben Schemaauswahl. Hierfür sind folgende Gründe zu nennen:

    • Die Pakete wurden aufgeteilt, sodass Sie die gewünschte Paketauswahl noch genauer festlegen können. Zum Beispiel wurden 37 texlive -Pakete aus SLE 11 auf 3000 Pakete in SLE 15 aufgeteilt.

    • Wenn ein Paket aufgeteilt wurde, werden bei einem Upgrade alle neuen Pakete installiert, damit in jedem Fall derselbe Funktionsumfang wie in der früheren Version zur Verfügung steht. Bei einer Neuinstallation von SLE X+1 werden jedoch unter Umständen nicht mehr alle Pakete standardmäßig installiert.

    • Ältere Pakete aus SLE X werden ggf. aus Kompatibilitätsgründen beibehalten.

    • Die Paketabhängigkeiten und der Schemaumfang haben sich unter Umständen geändert.

3.5 Upgrade von SUSE Linux Enterprise Server 11 SP4

Wenn Sie MySQL-, PostgreSQL- oder Java MD5-gestützte Zertifikate in SUSE Linux Enterprise Server 11 SP4 verwenden, bereiten Sie das System gemäß den nachfolgenden Abschnitten vor. Beachten Sie darüber hinaus die anderen Abschnitte dieses Kapitels für weitere erforderliche Vorbereitungen.

3.5.1 Migration der PostgreSQL-Datenbank

Wenn Sie eine PostgreSQL-Datenbank unter SUSE Linux Enterprise Server 11 verwenden, müssen Sie ein Upgrade Ihrer Datenbank durchführen. Weitere Informationen finden Sie im Abschnitt 3.6, „Migration der PostgreSQL-Datenbank“.

3.5.2 Migration der MySQL-Datenbank

Ab SUSE Linux Enterprise 12 hat SUSE von MySQL auf MariaDB umgestellt. Bevor Sie das Upgrade starten, wird dringend empfohlen, die Datenbank zu sichern.

So führen Sie die Datenbankmigration aus:

  1. Melden Sie sich auf dem SUSE Linux Enterprise 11-Computer an.

  2. Erstellen Sie eine Dump-Datei:

    root # mysqldump -u root -p --all-databases > mysql_backup.sql

    Standardmäßig wird die Datenbank INFORMATION_SCHEMA oder performance_schema nicht im Speicherauszug mit mysqldump berücksichtigt. Weitere Einzelheiten finden Sie im https://dev.mysql.com/doc/refman/5.5/en/mysqldump.html.

  3. Speichern Sie Ihre Dump-Datei, die Konfigurationsdatei /etc/my.cnf sowie das Verzeichnis /etc/mysql/ an einem sicheren Speicherort, um sie später als Referenz (nicht zur Installation!) zu verwenden .

  4. Führen Sie das Upgrade von SUSE Linux Enterprise Server durch. Nach dem Upgrade ist die bisherige Konfigurationsdatei /etc/my.cnf unverändert. Die neue Konfiguration finden Sie in der Datei /etc/my.cnf.rpmnew.

  5. Konfigurieren Sie die MariaDB-Datenbank je nach Bedarf. Bearbeiten Sie dabei nicht die bisherige Konfigurationsdatei und das frühere Verzeichnis, sondern nutzen Sie diese nur als Vorlage, und passen Sie die Einstellungen entsprechend an.

  6. Starten Sie den MariaDB-Server:

    root # systemctl start mariadb

    Soll der MariaDB-Server bei jedem Booten gestartet werden, aktivieren Sie den Dienst:

    root # systemctl enable mariadb
  7. Prüfen Sie, ob MariaDB ordnungsgemäß ausgeführt wird. Stellen Sie hierzu eine Verbindung zur Datenbank her:

    root # mariadb -u root -p

3.5.3 Erstellen von Nicht-MD5-Server-Zertifikaten für Java-Anwendungen

Beim Update von SP1 auf SP2 wurden MD5-basierte Zertifikate im Rahmen eines Sicherheits-Fixes deaktiviert. Wenn Sie über als MD5 erstellte Zertifikate verfügen, erstellen Sie diese mit folgenden Schritten neu:

  1. Öffnen Sie ein Terminal und melden Sie sich als root an.

  2. Erstellen Sie einen privaten Schlüssel:

    root # openssl genrsa -out server.key 1024

    Wenn Sie einen Schlüssel mit höherer Sicherheit wünschen, ersetzen Sie 1024 durch eine höhere Zahl, z. B. 4096.

  3. Erstellen Sie einen Zertifizierungsantrag (CSR):

    root # openssl req -new -key server.key -out server.csr
  4. Führen Sie eine Eigensignierung des Zertifikats durch:

    root # openssl x509 -req -days 365 -in server.csr -signkey server.key -out server.crt
  5. Erstellen Sie die PEM-Datei:

    root # cat server.key server.crt > server.pem
  6. Legen Sie die Dateien server.crt, server.csr, server.key und server.pem in den jeweiligen Verzeichnissen ab, in denen die Schlüssel gefunden werden können. Für Tomcat beispielsweise lautet das Verzeichnis /etc/tomcat/ssl/.

3.6 Migration der PostgreSQL-Datenbank

Im Lieferumfang von SUSE Linux Enterprise Server 15 SP3 sind die PostgreSQL-Datenbankversionen 10, 12 und 13 enthalten. Version 13 ist die Standardversion. Die Versionen 10 und 12 werden weiterhin über das Legacy-Modul für Upgrades von früheren Versionen von SUSE Linux Enterprise Server bereitgestellt.

Aufgrund der erforderlichen Migrationsschritte für die Datenbank ist kein automatischer Upgradevorgang verfügbar. Die Umstellung auf die neue Version muss daher manuell erfolgen.

Der Migrationsvorgang wird mit dem Kommando pg_upgrade ausgeführt. Dieses Kommando ist eine alternative Methode zur bewährten Methode eines Dumps und Neuladens. Im Vergleich zu Dump und Neuladen ist die Migration mit pg_upgrade weniger zeitaufwändig.

Die Programmdateien aller PostgreSQL-Versionen werden in unterschiedlichen, versionsabhängigen Verzeichnissen abgelegt. Beispielsweise in /usr/lib/postgresql96/ für Version 9.6, in /usr/lib/postgresql10/ für Version 10 und in /usr/lib/postgres12/ für Version 12. Beachten Sie, dass sich die Versionsrichtlinien von PostgreSQL zwischen den Hauptversionen 9.6 und 10 geändert haben. Weitere Informationen finden Sie im https://www.postgresql.org/support/versioning/.

Wichtig
Wichtig: Aufrüstung von SLE 11

Wenn Sie von SLE 11 aufrüsten, wird postgresql94 nicht deinstalliert und kann nicht für die Datenbankmigration zu einer höheren PostgreSQL-Version verwendet werden. Stellen Sie in diesem Fall also sicher, dass Sie die PostgreSQL-Datenbank vor der Aufrüstung des Systems migrieren.

Im unten geschilderten Verfahren finden Sie die Schritte für die Datenbankmigration von Version 9.6 zu Version 10. Werden als Ausgangspunkt oder Ziel andere Versionen verwendet, ersetzen Sie die Versionsnummern entsprechend.

So führen Sie die Datenbankmigration aus:

  1. Prüfen Sie, ob die folgenden Voraussetzungen erfüllt sind:

    • Upgraden Sie alle Pakete der alten PostgreSQL-Version per Wartungsaktualisierung auf die aktuelle Version, sofern Sie dies noch nicht erledigt haben.

    • Erstellen Sie eine Sicherung der vorhandenen Datenbank.

    • Installieren Sie die Pakete der neuen PostgreSQL-Hauptversion. Bei SLE 15 SP3 installieren Sie postgresql10-server und alle Pakete, von denen dieses Paket abhängig ist.

    • Installieren Sie das Paket postgresql10-contrib (enthält den Befehl pg_upgrade).

    • Prüfen Sie, ob ausreichend freier Speicherplatz im PostgreSQL-Datenbereich verfügbar ist (standardmäßig /var/lib/pgsql/data). Falls der Speicherplatz nicht ausreicht, versuchen Sie, die einzelnen Datenbanken mit dem folgenden SQL-Befehl zu verkleinern (kann sehr lange dauern!):

      VACUUM FULL
  2. Halten Sie den PostgreSQL-Server mit einer der folgenden Optionen an:

    root # /usr/sbin/rcpostgresql stop

    oder

    root # systemctl stop postgresql.service

    (abhängig von der SLE-Version, die Sie als Ausgangsversion der Aufrüstung nutzen).

  3. Benennen Sie das alte Datenverzeichnis um:

    root # mv /var/lib/pgsql/data /var/lib/pgsql/data.old
  4. Initialisieren Sie die neue Datenbankinstanz manuell mit initdb oder starten und stoppen Sie PostgreSQL, wodurch die Instanz automatisch initialisiert wird:

    root # /usr/sbin/rcpostgresql start
    root # /usr/sbin/rcpostgresql stop

    oder

    root # systemctl start postgresql.service
    root # systemctl stop postgresql.service

    (abhängig von der SLE-Version, die Sie als Ausgangsversion der Aufrüstung nutzen).

  5. Sollten Sie in der alten Version die Konfigurationsdateien bearbeitet haben, ziehen Sie in Betracht, diese Änderungen in die neuen Konfigurationsdateien zu übernehmen. Dieser Umstand könnte sich auf die Dateien postgresql.auto.conf, postgresql.conf, pg_hba.conf und pg_ident.conf auswirken. Die alten Versionen dieser Dateien finden sich unter /var/lib/pgsql/data.old/, die neuen Versionen unter /var/lib/pgsql/data.

    Beachten Sie, dass wir nicht empfehlen, die alten Konfigurationsdateien zu kopieren, da so möglicherweise neue Optionen, neue Standardeinstellungen und geänderte Kommentare überschrieben werden.

  6. Beginnen Sie als Benutzer postgres mit der Migration:

    root # su - postgres
    postgres > pg_upgrade \
     --old-datadir "/var/lib/pgsql/data.old" \
     --new-datadir "/var/lib/pgsql/data" \
     --old-bindir "/usr/lib/postgresql96/bin/" \
     --new-bindir "/usr/lib/postgresql10/bin/"
  7. Starten Sie Ihre neue Datenbank über eine der folgenden Optionen:

    root # /usr/sbin/rcpostgresql start

    oder

    root # systemctl start postgresql.service

    (abhängig von der SLE-Version, die Sie als Ausgangsversion der Aufrüstung nutzen).

  8. Überprüfen Sie, ob die Migration erfolgreich war. Der Testumfang hängt von Ihrem Anwendungsfall ab. Zur Automatisierung dieses Schritts steht kein allgemeines Tool zur Verfügung.

  9. Entfernen Sie alle alten PostgreSQL-Pakete und das alte Datenverzeichnis:

    root # zypper search -s postgresql96 | xargs zypper rm -u
    root # rm -rf /var/lib/pgsql/data.old

Weitere Informationen zum Upgrade von Datenbanken oder zur Verwendung alternativer Methoden wie der logischen Reproduktion finden Sie in der offiziellen PostgreSQL-Dokumentation unter https://www.postgresql.org/docs/10/upgrading.html.

3.7 Herunterfahren von VM-Gästen

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.

3.8 Anpassen der Einrichtung Ihres SMT-Clients

Beachten Sie Folgendes, wenn der Rechner, der upgegradet werden soll, als Client bei einem SMT-Server registriert werden soll:

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.

Falls das Upgrade Ihres Rechners auf eine höhere Version von SUSE Linux Enterprise Server nicht ausgeführt werden kann, heben Sie die Registrierung des Rechners beim SMT-Server wie in Prozedur 3.1 beschrieben auf. Starten Sie danach den Upgradevorgang neu.

Vorgehen 3.1: Aufheben einer Registrierung von SUSE Linux Enterprise Client bei einem SMT-Server
  1. Melden Sie sich beim Client-Rechner an.

  2. Der folgende Schritt hängt vom aktuellen Betriebssystem des Client ab:

    • Für SUSE Linux Enterprise 11 führen Sie folgende Kommandos aus:

      tux > sudo suse_register -E
      tux > sudo rm -f /etc/SUSEConnect
      tux > sudo rm -rf /etc/zypp/credentials.d/*
      tux > sudo rm -rf /etc/zypp/repos.d/*
      tux > sudo rm -f /etc/zypp/services.d/*
      tux > sudo rm -f /var/cache/SuseRegister/*
      tux > sudo rm -f /etc/suseRegister*
      tux > sudo rm -f /var/cache/SuseRegister/lastzmdconfig.cache
      tux > sudo rm -f /etc/zmd/deviceid
      tux > sudo rm -f /etc/zmd/secret
    • Für SUSE Linux Enterprise 12 führen Sie folgende Kommandos aus:

      tux > sudo SUSEConnect --de-register
      tux > sudo SUSEConnect --cleanup
      tux > sudo rm -f /etc/SUSEConnect
      tux > sudo rm -rf /etc/zypp/credentials.d/*
      tux > sudo rm -rf /etc/zypp/repos.d/*
      tux > sudo rm -f /etc/zypp/services.d/*
  3. Melden Sie sich beim SMT-Server an.

  4. Prüfen Sie, ob die Registrierung des Client aufgehoben wurde, indem Sie alle Client-Registrierungen aufrufen:

    tux > sudo smt-list-registrations
  5. Wird der Hostname des Client in der Ausgabe dieses Kommandos noch aufgelistet, rufen Sie die Eindeutige ID des Client in der ersten Spalte ab. (Der Client ist möglicherweise mit mehreren IDs aufgeführt.)

  6. Löschen Sie die Registrierung für diesen Client:

    tux > sudo smt-delete-registration -g UNIQUE_ID
  7. Sollte der Client mit mehreren IDs aufgeführt sein, wiederholen Sie den obigen Schritt für jede einzelne ID.

  8. Prüfen Sie danach, ob die Registrierung des Client nun aufgehoben wurde, indem Sie das folgende Kommando erneut ausführen:

    tux > sudo smt-list-registrations

3.9 Speicherplatz

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
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).

3.9.1 Ermitteln des freien Speicherplatzes auf Nicht-Btrfs-Dateisystemen

Listen Sie mit dem Kommando df den verfügbaren Speicherplatz auf. In Beispiel 3.1, „Über df -h angezeigte Liste“ ist beispielsweise /dev/sda3 die root-Partition (eingehängt als /).

Beispiel 3.1: Über df -h angezeigte Liste
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       44G    4G   40G   9% /data

3.9.2 Ermitteln des freien Speicherplatzes auf Btrfs-root-Dateisystemen

In einem Btrfs-Dateisystem kann die Ausgabe von df irreführend sein, weil ein Btrfs-Dateisystem zusätzlich zum Speicherplatz, den die Rohdaten zuordnen, auch Speicherplatz für Metadaten zuordnet und verwendet.

Folglich meldet ein Btrfs-Dateisystem womöglich, dass es keinen Speicherplatz mehr hat, obwohl anscheinend noch genügend vorhanden ist. In diesem Fall ist der gesamte Speicherplatz, der den Metadaten zugeordnet ist, belegt. Details zur Prüfung auf belegten und verfügbaren Speicherplatz in einem Btrfs-Dateisystem finden Sie im Book “Storage Administration Guide”, Chapter 1 “Overview of file systems in Linux”, Section 1.2.2.3 “Checking for free space”. Weitere Informationen finden Sie im man 8 btrfs-filesystem und https://btrfs.wiki.kernel.org/index.php/FAQ.

Wenn Sie Btrfs als Root-Dateisysteme auf dem Computer nutzen, muss ausreichend freier Speicherplatz zur Verfügung stehen. Prüfen Sie den verfügbaren Speicherplatz auf allen eingehängten Partitionen. Im schlimmsten Fall belegt ein Upgrade ebenso viel Speicherplatz wie das aktuelle root-Dateisystem (ohne /.snapshot) für einen neuen Snapshot.

Die folgenden Empfehlungen haben sich bewährt:

  • Bei allen Dateisystemen (auch Btrfs) benötigen Sie ausreichend freien Speicherplatz, damit Sie große RPMs herunterladen und installieren können. Der Speicherplatz der alten RPMs wird erst dann freigegeben, wenn die neuen RPMs installiert sind.

  • Bei Btrfs mit Snapshots benötigen Sie mindestens so viel freien Speicherplatz, wie von der aktuellen Installation belegt wird. Es wird mindestens der doppelte freie Speicherplatz empfohlen, wie von der aktuellen Installation belegt wird.

    Falls nicht ausreichend freier Speicherplatz verfügbar ist, können Sie ältere Snapshots mit snapper löschen:

    root # snapper list
    root # snapper delete NUMBER

    Dies reicht jedoch nicht in allen Fällen aus. Vor der Migration belegen die meisten Snapshots nur wenig Platz.

3.10 Änderungen der AutoYaST-Profile von SLE 12 bis 15

Informationen zur Migration von AutoYaST-Profilen finden Sie im Book “AutoYaST Guide”, .

3.11 Upgraden eines Subscription Management Tool-(SMT-)Servers

Für einen Server mit SMT ist ein besonderes Upgradeverfahren erforderlich. Weitere Informationen finden Sie im Book “Repository Mirroring Tool Guide”, Chapter 3 “Migrate from SMT to RMT” im Handbuch zum Repository Management Tool.

3.12 Vorübergehende Deaktivierung der Unterstützung mehrerer Kernel-Versionen

SUSE Linux Enterprise Server ermöglicht die Installation mehrerer Kernel-Versionen. Hierfür müssen die entsprechenden Einstellungen in /etc/zypp/zypp.conf aktiviert werden. Für das Upgrade auf ein Service Pack muss diese Funktion vorübergehend deaktiviert werden. Sobald die Aktualisierung erfolgreich abgeschlossen wurde, kann die Unterstützung mehrerer Versionen wieder aktiviert werden. Zur Deaktivierung der Unterstützung mehrerer Versionen müssen die entsprechenden Zeilen in der Datei /etc/zypp/zypp.conf auf Kommentar gesetzt werden. Das Ergebnis sollte wie folgt aussehen:

#multiversion = provides:multiversion(kernel)
#multiversion.kernels = latest,running

Wenn Sie diese Funktion nach einer erfolgreichen Aktualisierung wieder aktivieren möchten, entfernen Sie die Kommentarzeichen. Weitere Informationen zur Unterstützung mehrerer Versionen finden Sie im Book “Bereitstellungshandbuch”, Chapter 23 “Installieren von mehreren Kernel-Versionen”, Section 23.1 “Aktivieren und Konfigurieren der Multiversions-Unterstützung”.

3.13 Upgraden auf IBM Z

Für das Upgrade einer SUSE Linux Enterprise-Installation auf IBM Z muss der Kernel-Parameter Upgrade=1 angegeben werden, z. B. in der parmfile. Weitere Informationen hierzu finden Sie im Abschnitt 5.6, „Die Parmfile – Automatisierte Systemkonfiguration“.

3.14 IBM POWER: Starten eines X-Servers

Unter SLES 12 für IBM POWER ist der Anzeige-Manager so konfiguriert, dass ein lokaler X-Server nicht standardmäßig gestartet wird. Diese Einstellung wurde in SLES 12 SP1 rückgängig gemacht, sodass der Anzeige-Manager jetzt einen X-Server startet.

Die SUSE Linux Enterprise Server-Einstellung wird nicht automatisch geändert, damit keine Probleme im Rahmen des Upgrades auftreten. Wenn der Anzeige-Manager nach dem Upgrade einen X-Server starten soll, ändern Sie die Einstellung wie folgt von DISPLAYMANAGER_STARTS_XSERVER zu /etc/sysconfig/displaymanager:

DISPLAYMANAGER_STARTS_XSERVER="yes"

4 Offline-Upgrade

In diesem Kapitel finden Sie Anweisungen zum Upgraden einer vorhandenen SUSE Linux Enterprise-Installation mithilfe von YaST, das von einem Installationsmedium gebootet wird. Das YaST-Installationsprogramm kann beispielsweise von einer DVD oder über das Netzwerk bzw. auch von der Festplatte, auf der sich das System befindet, gestartet werden.

4.1 Konzeptübersicht

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:

4.2 Starten des Upgrades über ein Installationsmedium

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).

Vorgehen 4.1: Manuelles Upgraden von SUSE Linux Enterprise Server 15 SP3
  1. Wählen Sie ein Bootmedium aus und bereiten Sie es vor, siehe Book “Bereitstellungshandbuch.

  2. Legen Sie die Unified Installer DVD für SUSE Linux Enterprise Server 15 SP3 ein und booten Sie Ihren Rechner. Ein Begrüßungsbildschirm wird geöffnet, gefolgt vom Bootbildschirm.

  3. Optional: Fügen Sie die Boot-Option media_upgrade=1 hinzu, um zu erzwingen, dass das Installationsprogramm nur Pakete von der DVD installiert und nicht von Netzwerkressourcen.

  4. Starten Sie das System und wählen Sie im Bootmenü die Option Upgrade.

  5. Fahren Sie gemäß Abschnitt 4.4, „Upgraden von SUSE Linux Enterprise“ mit der Installation fort.

4.3 Starten des Upgrades über eine Netzwerkquelle

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

Anforderungen für das Upgraden von einer Netzwerkinstallationsquelle
Netzwerkinstallationsquelle

Eine Netzwerkinstallationsquelle ist gemäß Book “Bereitstellungshandbuch”, Chapter 16 “Einrichten einer Netzwerkinstallationsquelle” eingerichtet.

Netzwerkverbindung und Netzwerkdienste

Sowohl der Installationsserver als auch der Zielcomputer müssen eine funktionsfähige Netzwerkverbindung haben. Erforderliche Netzwerkdienste:

  • Domänennamen-Service

  • DHCP (nur beim Booten über PXE; IP-Adresse kann manuell bei der Einrichtung festgelegt werden)

  • OpenSLP (optional)

Bootmedium

Eine bootfähige SUSE Linux Enterprise-DVD, ein ISO-Image oder eine funktionsfähige PXE-Einrichtung. Weitere Informationen zum Booten über PXE finden Sie im Book “Bereitstellungshandbuch”, Chapter 17 “Vorbereiten der Netzwerk-Boot-Umgebung”, Section 17.4 “Vorbereiten des Zielsystems für PXE-Boot”. Detaillierte Informationen zum Starten des Upgrades von einem Remote-Server finden Sie im Book “Bereitstellungshandbuch”, Chapter 11 “Ferninstallation”.

4.3.1 Manuelles Upgraden von einer Netzwerkinstallationsquelle – Booten von DVD

In diesem Verfahren wird das Booten von DVD als Beispiel beschrieben. Sie können jedoch auch ein anderes lokales Installationsmedium verwenden, z. B. ein ISO-Image auf einem USB-Massenspeichergerät. Das Verfahren zum Auswählen der Bootmethode und zum Starten des Systems vom Medium hängt von der Systemarchitektur und davon ab, ob der Computer mit einem herkömmlichen BIOS oder mit UEFI ausgestattet ist. Weitere Informationen finden Sie im den nachfolgenden Links.

  1. Legen Sie die Unified Installer DVD für SUSE Linux Enterprise Server 15 SP3 ein und booten Sie Ihren Rechner. Ein Begrüßungsbildschirm wird geöffnet, gefolgt vom Bootbildschirm.

  2. Wählen Sie die gewünschte Netzwerkinstallationsquelle aus (FTP, HTTP, NFS, SMB oder SLP). Diese Auswahl erhalten Sie in der Regel mit F4. Falls der Computer mit UEFI statt mit einem herkömmlichen BIOS ausgestattet ist, müssen Sie ggf. die Bootparameter manuell anpassen. Weitere Informationen hierzu finden Sie im Book “Bereitstellungshandbuch”, Chapter 7 “Boot-Parameter” und im Book “Bereitstellungshandbuch”, Chapter 8 “Installationsschritte”.

  3. Fahren Sie gemäß Abschnitt 4.4, „Upgraden von SUSE Linux Enterprise“ mit der Installation fort.

4.3.2 Manuelles Upgraden von einer Netzwerkinstallationsquelle – Booten über PXE

So führen Sie das Upgrade von einer Netzwerkinstallationsquelle mit dem PXE-Boot aus:

  1. Passen Sie das Setup Ihres DHCP-Servers an, damit die für den PXE-Boot erforderlichen Adressinformationen angegeben werden. Weitere Informationen finden Sie im Book “Bereitstellungshandbuch”, Chapter 17 “Vorbereiten der Netzwerk-Boot-Umgebung”, Section 17.1.1 “Dynamische Adressenzuweisung”.

  2. Richten Sie einen TFTP-Server ein, auf dem das Boot-Image für das Booten über PXE abgelegt wird. Verwenden Sie dazu die Installations-DVD für SUSE Linux Enterprise Server 15 SP3 oder befolgen Sie die Anweisungen im Book “Bereitstellungshandbuch”, Chapter 17 “Vorbereiten der Netzwerk-Boot-Umgebung”, Section 17.2 “Einrichten eines TFTP-Servers”.

  3. Bereiten Sie den PXE-Boot und Wake-on-LAN auf dem Zielcomputer vor.

  4. Starten Sie den Boot des Zielsystems und verwenden Sie VNC, um sich entfernt mit der auf diesem Computer ausgeführten Installationsroutine zu verbinden. Weitere Informationen finden Sie im Book “Bereitstellungshandbuch”, Chapter 11 “Ferninstallation”, Section 11.3 “Überwachen der Installation über VNC”.

  5. Fahren Sie gemäß Abschnitt 4.4, „Upgraden von SUSE Linux Enterprise“ mit der Installation fort.

4.4 Upgraden von SUSE Linux Enterprise

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

Anmerkung
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
    Warnung: Möglicher Datenverlust durch falsche Auswahl

    Vergewissern Sie sich, dass Sie zu diesem Zeitpunkt Upgrade ausgewählt haben. 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-SP3-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
    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 Prüfungen nach dem Upgrade durch, die in Abschnitt 4.4.1, „Prüfungen nach dem Upgrade“ beschrieben sind.

4.4.1 Prüfungen nach dem Upgrade

  • Prüfen Sie, ob verwaiste Pakete vorhanden sind. Während eines Upgrade-Vorgangs können Pakete umbenannt, entfernt, zusammengeführt oder aufgeteilt werden. Dies kann dazu führen, dass bestimmte Pakete verwaist sind und nicht mehr unterstützt werden. Verwaiste Pakete werden nicht automatisch entfernt. Mit dem folgenden Kommando erhalten Sie eine entsprechende Liste:

    tux > zypper packages --orphaned --unneeded

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

  • Suchen Sie nach *.rpmnew und *.rpmsave, untersuchen Sie deren Inhalt und führen Sie gewünschte Änderungen zusammen, falls möglich. Wenn ein Upgrade Änderungen an einer Standardkonfigurationsdatei umfasst, schreibt das Paket eine dieser Dateitypen statt die Konfigurationsdatei zu überschreiben. Die Datei *.rpmnew enthält die neue Standardkonfiguration und lässt Ihre Originaldatei unverändert. *.rpmsave ist eine Kopie der ursprünglichen Konfiguration, die durch die neue Standarddatei ersetzt wurde.

    Sie brauchen nicht das gesamte Dateisystem nach *.rpmnew- und *.rpmsave-Dateien zu durchsuchen. Die wichtigsten Dateien sind im Verzeichnis /etc gespeichert. Listen Sie sie mit folgendem Kommando auf:

    tux > find /etc -print | egrep "rpmnew$|rpmsave$"

4.5 Upgraden mit AutoYaST

Das Upgrade kann bei Bedarf automatisch ausgeführt werden. Weitere Informationen finden Sie im Book “AutoYaST Guide”, Chapter 4 “Configuration and installation options”, Section 4.10 “Upgrade”.

4.6 Upgraden mit SUSE Manager

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 im https://www.suse.com/products/suse-manager/.

Mit SUSE Manager können Sie das System upgraden. Mit der integrierten AutoYaST-Technologie sind Upgrades von einer Hauptversion zur nächst höheren möglich.

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 wird im SUSE Manager-Upgrade-Handbuch beschrieben. Es ist verfügbar unter https://documentation.suse.com/suma/.

4.7 Aktualisieren des Registrierungsstatus nach einem Rollback

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 aufgetreten ist, 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:

tux > 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:

tux > sudo zypper ref -s

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

4.8 Registrieren des Systems

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:

  • Recht für Support

  • Bereitstellung von Sicherheitsaktualisierungen und Fehlerbehebungen

  • Zugang zum SUSE Customer Center

  1. Starten Sie YaST und wählen Sie Software › Produktregistrierung. Das Dialogfeld Registrierung wird geöffnet.

  2. Geben Sie die Email-Adresse für das SUSE-Konto ein, mit dem Sie oder Ihr Unternehmen die Abonnements verwalten. Falls Sie noch kein SUSE-Konto besitzen, wechseln Sie zur SUSE Customer Center-Startseite (https://scc.suse.com/), und erstellen Sie dort ein Konto.

  3. Geben Sie den Registrierungscode ein, den Sie zusammen mit Ihrem Exemplar von SUSE Linux Enterprise Server erhalten haben.

  4. Wenn ein oder mehrere lokale Registrierungsserver in Ihrem Netzwerk verfügbar sind, können Sie einen Server aus einer Liste auswählen.

  5. Starten Sie die Registrierung mit Weiter.

    Nach erfolgter Registrierung zeigt YaST eine Liste der verfügbaren Erweiterungen, Add-ons und Module für Ihr System an. Zum Auswählen und Installieren eines Elements fahren Sie mit Book “Bereitstellungshandbuch”, Chapter 22 “Installieren von Modulen, Erweiterungen und Add-on-Produkten von Drittanbietern”, Section 22.1 “Installieren von Modulen und Erweiterungen über Online-Kanäle” fort.

5 Online-Upgrade

Für das Upgrade eines laufenden Systems auf ein neues Service Pack bietet SUSE ein intuitives grafisches Werkzeug und ein Befehlszeilenwerkzeug. Diese Funktionen unterstützen das Rollback von Service Packs und vieles mehr. In diesem Kapitel wird die Ausführung eines Service Pack-Upgrades mit diesen Werkzeugen Schritt für Schritt erläutert.

5.1 Konzeptübersicht

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:

  • Das System befindet sich bis zur Aktualisierung des ersten RPM stets in einem definierten Status.

  • Der Vorgang kann bis zur Aktualisierung des ersten RPM jederzeit abgebrochen werden.

  • Unkomplizierte Wiederherstellung bei einem Fehler.

  • Es ist möglich, anhand von Systemwerkzeugen ein Rollback durchzuführen, was eine Sicherung und Wiederherstellung überflüssig macht.

  • Verwendung aller aktiven Repositorys.

  • Möglichkeit zum Überspringen eines Service Packs

Warnung
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 im Kapitel 1, Upgrade-Pfade und -Methoden.

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

Wichtig
Wichtig: Upgrade von SUSE Manager-Clients

Ein SUSE Manager-Client kann weder per YaST-Online-Migration noch per Zypper-Migration aufgerüstet werden. Nehmen Sie stattdessen die Client-Migration vor. Eine Beschreibung finden Sie im SUSE Manager-Upgrade-Handbuch.

5.2 Workflow der Service Pack-Migration

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:

  1. Suchen von möglichen Migrationszielen auf den registrierten Systemen

  2. Auswahl eines Migrationsziels

  3. Anfordern und Aktivieren neuer Repositorys

  4. Ausführen der Migration

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.

5.3 Abbrechen einer Service Pack-Migration

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

  1. Bis zum Beginn des Paketupgrades erfolgen auf dem System nur minimale Änderungen, beispielsweise für Services und Repositorys. Stellen Sie /etc/zypp/repos.d/* wieder her, um zum vorherigen Zustand zurückzukehren.

  2. Nach Beginn des Paketupgrades können Sie mithilfe eines Snapper-Snapshots zum vorherigen Zustand zurückkehren (siehe Book “Verwaltungshandbuch”, Chapter 7 “Systemwiederherstellung und Snapshot-Verwaltung mit Snapper”).

  3. Nach der Auswahl des Migrationsziels ändert das SUSE Customer Center die Repository-Daten. Wenn Sie diesen Zustand manuell zurücksetzen möchten, verwenden Sie SUSEConnect --rollback.

5.4 Upgraden mit dem Werkzeug für die Online-Migration (YaST)

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
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. Wenn Sie das Verhalten von Zypper für einen einzelnen Aufruf ändern möchten, fügen Sie in Ihrer Kommandozeile den Parameter --no-recommends hinzu.

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

  1. Deaktivieren Sie alle nicht verwendeten Erweiterungen des Registrierungsservers, damit künftig keine Abhängigkeitskonflikte auftreten. Falls Sie eine Erweiterung übersehen, erkennt YaST später die nicht verwendeten Erweiterungs-Repositorys, die dann automatisch deaktiviert werden.

  2. Wenn Sie bei einer GNOME-Sitzung auf dem zu aktualisierenden Computer angemeldet sind, wechseln Sie zu einer Textkonsole. Die Aktualisierung aus einer GNOME-Sitzung heraus wird nicht empfohlen. Dies gilt nicht, wenn Sie über einen Remote-Computer angemeldet sind (es sei denn, Sie führen eine VNC-Sitzung mit GNOME aus).

  3. Führen Sie die YaST-Online-Aktualisierung aus, um die neuesten Paketaktualisierungen für Ihr System zu erhalten.

  4. Installieren Sie das Paket yast2-migration und seine abhängigen Komponenten (in YaST unter Software ›  Software installieren oder löschen).

  5. Starten Sie YaST neu, damit das neu installierte Modul im Kontrollzentrum angezeigt wird.

  6. Wählen Sie in YaST die Option Online-Migration. (Je nach der upzugradenden Version von SUSE Linux Enterprise Server befindet sich dieses Modul unter System oder Software.) YaST zeigt die möglichen Migrationsziele und eine Zusammenfassung an. Falls für Ihr System mehrere Migrationsziele verfügbar sind, wählen Sie eines davon in der Liste aus.

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

  8. Falls das Migrationstool Aktualisierungs-Repositorys anbietet, sollten Sie mit Ja fortfahren.

  9. Falls das Tool für die Online-Migration alte Repositorys von DVD oder einem lokalen Server findet, empfiehlt es sich dringend, diese zu deaktivieren. Alte Repositorys stammen aus einem früheren SP. Alle alten Repositorys vom SUSE Customer Center oder aus RMT werden automatisch entfernt.

  10. Prüfen Sie die Zusammenfassung und klicken Sie dann auf Weiter, um mit der Migration fortzufahren. Bestätigen Sie die Migration mit Aktualisierung starten.

  11. Starten Sie Ihr System nach einer erfolgreichen Migration neu.

5.5 Upgraden mit zypper

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

Anmerkung
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. Wenn Sie das Verhalten von Zypper für einen einzelnen Aufruf ändern möchten, fügen Sie in Ihrer Kommandozeile den Parameter --no-recommends hinzu.

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

  1. Wenn Sie bei einer GNOME-Sitzung auf dem zu aktualisierenden Computer angemeldet sind, wechseln Sie zu einer Textkonsole. Die Aktualisierung aus einer GNOME-Sitzung heraus wird nicht empfohlen. Dies gilt nicht, wenn Sie über einen Remote-Computer angemeldet sind (es sei denn, Sie führen eine VNC-Sitzung mit GNOME aus).

  2. Falls noch nicht erfolgt, registrieren Sie Ihren SUSE Linux Enterprise-Rechner:

    tux > sudo SUSEConnect --regcode YOUR_REGISTRATION_CODE
  3. Migration starten:

    tux > sudo zypper migration

    Beachten Sie folgende Hinweise zum Migrationsvorgang:

    • Falls für Ihr System mehrere Migrationsziele verfügbar sind, können Sie in Zypper einen SP in der Liste auswählen. Dies entspricht dem Überspringen eines oder mehrerer SPs. Denken Sie daran, dass die Online-Migration für Basisprodukte (SLES, SLED) nur zwischen den SPs einer Hauptversion verfügbar ist.

    • Zypper verwendet standardmäßig die Option --no-allow-vendor-change, die an zypper dup weitergeleitet wird. Wurde ein Paket aus einem Repository eines Drittanbieters installiert, verhindert diese Option, dass das Paket durch das gleiche Paket aus SUSE ersetzt wird.

    • Falls Zypper alte Repositorys von DVD oder einem lokalen Server findet, empfiehlt es sich dringend, diese zu deaktivieren. Alte SUSE Customer Center- oder RMT-Repository werden automatisch entfernt.

  4. Prüfen Sie alle Änderungen, insbesondere die Pakete, die entfernt werden. Geben Sie y ein, um fortzufahren (die Anzahl der Pakete, die aktualisiert werden können, ist von System zu System unterschiedlich):

    266 packages to upgrade, 54 to downgrade, 17 new, 8 to reinstall, 5 to remove, 1 to change arch.
    Overall download size: 285.1 MiB. Already cached: 0 B  After the operation, additional 139.8 MiB will be used.
    Continue? [y/n/? shows all options] (y):

    Verwenden Sie zum Blättern in Ihrer Shell die Tasten UmschalttasteBild ↑ oder UmschalttasteBild ↓.

  5. Starten Sie Ihr System nach einer erfolgreichen Migration neu.

5.6 Upgraden mit einfachem Zypper

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
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
Wichtig: Installationsquellen

Bei diesem Migrationspfad müssen Sie die Installationsquellen für das neue Service Pack an einem Ort angeben, auf den der zu migrierende Rechner Zugriff hat. Sie erreichen dies beispielsweise durch Einrichten eines RMT-Servers auf einem SLP-Server.

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

  1. Wenn Sie bei einer Grafiksitzung auf dem zu migrierenden Rechner angemeldet sind, müssen Sie sich von dieser Sitzung abmelden und zu einer Textkonsole wechseln. Von der Aktualisierung aus einer Grafiksitzung heraus wird abgeraten. Dies gilt nicht, wenn Sie über einen Remote-Computer angemeldet sind (es sei denn, Sie führen eine VNC-Sitzung mit X aus).

  2. Aktualisieren Sie die Paketverwaltungstools mit den alten SUSE Linux Enterprise-Repositorys:

    tux > sudo zypper patch --updatestack-only
  3. Rufen Sie eine Liste der Pakete ab, denen aktuell kein Repository zugewiesen ist (verwaiste Pakete). Diese Pakete werden nicht migriert, und ihre Funktionstüchtigkeit nach der Migration kann nicht garantiert werden, weil andere Pakete, auf die sie sich verlassen, möglicherweise so verändert wurden, dass sie nicht mehr kompatibel sind. Rufen Sie die Liste ab mit:

    tux > sudo zypper packages --orphaned

    Gehen Sie die Liste sorgfältig durch und entfernen Sie alle verwaisten Pakete, die nicht mehr benötigt werden. Machen Sie sich eine Notiz zu allen verbleibenden verwaisten Pakete. Sie benötigen Sie später zu Vergleichszwecken.

  4. Rufen Sie eine Liste aller Repositorys ab, die das System aktuell abonniert hat. Führen Sie dazu folgendes Kommando aus:

    tux > sudo zypper repos -u

    Aktualisieren Sie die einzelnen Repository-URLs so, dass ihre Produktversionsnummer 15-SP3 lautet. Wenn die URL eines Repositorys beispielsweise so aussieht

    http://rmt.example.com/repo/SUSE/Products/SLE-15-SP2-Product-SLES/x86_64/product/

    ändern Sie sie zu

    http://rmt.example.com/repo/SUSE/Products/SLE-15-SP3-Product-SLES/x86_64/product/

    Dies muss bei allen aktivierten Repositorys erfolgen. Sie könnten dies auch für Repositorys tun, die derzeit deaktiviert sind. Dadurch werden falsche Installationsquellen im System verhindert, wenn diese Repositorys zu einem späteren Zeitpunkt aktiviert werden.

    Zum Ändern der Repository-URLs stehen Ihnen folgende Optionen zur Verfügung:

    1. YaST › Software › Software-Repositorys: Wählen Sie ein Repository aus und klicken Sie auf Bearbeiten, um die erforderliche Änderung vorzunehmen. Wiederholen Sie diesen Vorgang für alle Repositorys.

    2. Zypper: Entfernen Sie das alte Repository mit

      tux > sudo zypper removerepo OLD_REPO_ID

      Fügen Sie dann das entsprechende neue Repository hinzu mit

       tux > sudo zypper addrepo -f URL NAME-15-SP3
    3. Bearbeiten von Repository-Konfigurationsdateien in /etc/zypp/repos.d: Jedes Repository wird durch eine Konfigurationsdatei dargestellt. Der Wert für den Parameter baseurl muss in jeder Datei geändert werden.

  5. Prüfen Sie Ihre Änderungen durch Ausführen von zypper repos -u und aktualisieren Sie die Repositorys mit folgendem Kommando:

    tux > sudo zypper refresh -f -s

    Falls ein Repository nicht aktualisiert werden kann, prüfen Sie nach, ob Sie die falsche URL eingegeben haben. Wenn das Problem nicht behoben werden kann, empfiehlt es sich, das fehlerhafte Repository zu deaktivieren.

    Wenn alle Repositorys korrekt konfiguriert sind, führen Sie folgendes Kommando erneut aus:

    tux > sudo zypper refresh -f -s

    Damit stellen Sie sicher, dass alle Repositorys aktuell sind.

  6. Vor dem Start der Migration sollte ein Testlauf durchgeführt werden:

    tux > sudo zypper dup -D --no-allow-vendor-change --no-recommends

    Mit dem Parameter -D wird ein Probelauf durchgeführt, der die Migration simuliert, ohne das System tatsächlich zu ändern. Falls Probleme auftreten, sollten sie behoben werden, bevor Sie fortfahren. Falls der Testlauf erfolgreich ist, führen Sie die echte Migration mit folgendem Kommando durch:

    tux > sudo zypper dup --no-allow-vendor-change --no-recommends

    -no-allow-vendor-change stellt sicher, dass Drittanbieter-RPMs nicht die RPMs des Basissystems überschreiben. Die Option --no-recommends sorgt dafür, dass Pakete, die während der Erstinstallation abgewählt wurden, nicht erneut hinzugefügt werden.

  7. Führen Sie nach Abschluss der Migration und dem Booten des Systems in der neuen Service Pack-Version die Prüfung nach verwaisten Paketen erneut aus:

    tux > sudo zypper packages --orphaned

    Vergleichen Sie die neue Liste mit der Liste, die Sie vor Beginn der Migration generiert haben. Falls neue Pakete in der Liste auftauchen, liegt es womöglich daran, dass sie zu einem anderen Modul im neuen Service Pack verschoben wurden. Falls dieses Modul in der früheren Installation nicht enthalten war, konnte das Paket nicht aktualisiert werden.

    Unter https://scc.suse.com/packages können Sie prüfen, zu welchem Modul ein Paket gehört. Fügen Sie die fehlenden Module mit zypper addrepo oder dem Modul „YaST Software Repositories“ hinzu und aktualisieren Sie danach die verwaisten Pakete mit dem Kommando:

    tux > sudo zypper install --no-recommends LIST OF PACKAGES
  8. Die Migration zu einem neuen Service Pack ist abgeschlossen.

5.7 Rollback eines Service Packs

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). Weitere Informationen finden Sie im Book “Verwaltungshandbuch”, Chapter 7 “Systemwiederherstellung und Snapshot-Verwaltung mit Snapper”.

  1. Rufen Sie eine Liste sämtlicher Snapper-Snapshots ab:

    tux > sudo snapper list

    Suchen Sie in der Ausgabe nach dem Snapshot, der unmittelbar vor Beginn der Service Pack-Migration gestartet wurde. Die Spalte Beschreibung zeigt eine zugehörige Erläuterung und der Snapshot wird in der Spalte Benutzerdaten als wichtig gekennzeichnet. Notieren Sie die Snapshot-Nummer in der Spalte Nr. und das entsprechende Datum in der Spalte Datum.

  2. Booten Sie das System neu. Wählen Sie im Bootmenü die Option Bootloader von einem schreibgeschützten Snapshot starten und wählen Sie den Snapshot mit dem notierten Datum und der Nummer aus dem vorangegangenen Schritt aus. Ein zweites Bootmenü (das Bootmenü aus dem Snapshot) wird geladen. Wählen Sie den Eintrag aus, der mit SLES 15 SP3 beginnt, und booten Sie ihn.

  3. Das System bootet im vorherigen Zustand, wobei die Systempartition schreibgeschützt eingehängt ist. Melden Sie sich als root an und prüfen Sie, ob Sie den richtigen Snapshot ausgewählt haben. Prüfen Sie außerdem, ob alle Vorgänge wie erwartet ablaufen. Beachten Sie, dass der Funktionsumfang ggf. eingeschränkt ist, da das root-Dateisystem schreibgeschützt eingehängt wurde.

    Falls Probleme auftreten oder Sie den falschen Snapshot gebootet haben, booten Sie das System neu und wählen Sie einen anderen Snapshot zum Booten aus. Bis zu diesem Zeitpunkt wurden noch keine permanenten Änderungen vorgenommen. Falls der richtige Snapshot ausgewählt wurde und dieser Snapshot einwandfrei arbeitet, lassen Sie die Änderungen mit dem folgenden Befehl dauerhaft in Kraft treten:

    tux > sudo snapper rollback

    Booten Sie anschließend neu. Wählen Sie im Bootbildschirm den Standard-Booteintrag. Das neu eingesetzte System wird erneut gebootet.

  4. Prüfen Sie, ob die Repository-Konfiguration ordnungsgemäß zurückgesetzt wurde. Prüfen Sie außerdem, ob alle Produkte fehlerfrei registriert wurden. Falls eine dieser Bedingungen nicht erfüllt ist, kann das System später eventuell nicht mehr aktualisiert werden oder das System wird mit den falschen Paket-Repositorys aktualisiert.

    Prüfen Sie vor Beginn dieses Verfahrens, ob das System auf das Internet zugreifen kann.

    1. Aktualisieren Sie die Dienste und Repositorys mit

      tux > sudo zypper ref -fs
    2. Erstellen Sie eine Liste der aktiven Repositorys mit

      tux > sudo zypper lr

      Prüfen Sie die Ausgabe dieses Befehls sorgfältig. Es sollten keine Dienste und Repositorys aufgelistet werden, die für die Aktualisierung eingefügt wurden. Bei einem Rollback von SLES 15 SP3 auf SLES 15 GA muss die Liste beispielsweise die SLES15-GA-Repositorys enthalten, also nicht die SLES15-SP3-Repositorys.

      Falls falsche Repositorys aufgelistet werden, löschen Sie diese Repositorys und ersetzen Sie sie ggf. durch die richtigen Versionen für die Produkt- oder Service Pack-Version. Eine Liste der Repositorys für die unterstützten Migrationspfade finden finden Sie im Abschnitt 2.3, „Abhängigkeiten und Lebenszyklen der Module“. (Beachten Sie, dass kein manuelles Eingreifen erforderlich sein sollte, da die Repositorys automatisch aktualisiert werden sollten. Als bewährte Vorgehensweise sollten sie jedoch überprüft und notwendige Korrekturen vorgenommen werden.)

    3. Prüfen Sie abschließend den Registrierungsstatus aller installierten Produkte mit

      tux > sudo SUSEConnect --status

      Alle Produkte sollten als Registriert aufgeführt werden. Ist dies nicht der Fall, reparieren Sie die Registrierung mit

      tux > sudo SUSEConnect --rollback

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

5.8 Upgraden mit SUSE Manager

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 im 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 SP3).

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 wird im SUSE Manager-Upgrade-Handbuch beschrieben. Es ist verfügbar unter https://documentation.suse.com/suma/.

5.9 Upgrade von openSUSE Leap zu SUSE Linux Enterprise Server

Sie können ein Upgrade einer openSUSE Leap-Installation zu SUSE Linux Enterprise Server durchführen. Das Verfahren ist ähnlich wie in Abschnitt 5.4, „Upgraden mit dem Werkzeug für die Online-Migration (YaST)“ beschrieben, erfordert aber einige zusätzliche Schritte. Vor Ausführung dieses Vorgangs in einem Produktionssystem sollten Sie ihn zunächst auf einem Testsystem ausführen, der Ihre Produktionseinrichtung reproduziert.

Informationen darüber, welche openSUSE Leap-Versionen für die Migration unterstützt werden, finden Sie in Abschnitt 1.2, „Unterstützte Upgrade-Pfade auf SLES 15 SP3.

Warnung
Warnung: Nicht alle openSUSE-Pakete können migriert werden

openSUSE stellt mehr Pakete zur Verfügung als SUSE Linux Enterprise Server. Die meisten der zusätzlichen Pakete sind über SUSE Package Hub verfügbar und werden migriert. Alle zusätzlichen Pakete, die nicht über SUSE Package Hub verfügbar sind, erhalten nach der Migration keine Aktualisierungen mehr und sollten daher im Anschluss entfernt werden.

Überprüfen Sie, ob die SUSE Linux Enterprise Server- und SUSE Package Hub-Repositorys alle erforderlichen Pakete für Ihr System enthalten. Weitere Informationen zum SUSE Package Hub finden Sie im Book “Bereitstellungshandbuch”, Chapter 22 “Installieren von Modulen, Erweiterungen und Add-on-Produkten von Drittanbietern”, Section 22.3 “SUSE Package Hub”.

Vorgehen 5.1: Upgrade von openSUSE Leap zu SUSE Linux Enterprise Server

Führen Sie zum Migrieren von openSUSE Leap zu SUSE Linux Enterprise Server die folgenden Schritte aus:

  1. Wechseln Sie zu einem TTY, beispielsweise durch Drücken von StrgAltF1. Melden Sie sich dann als root-Benutzer an.

  2. Installieren Sie die Pakete yast2-registration und rollback-helper :

    root # zypper in yast2-registration rollback-helper
  3. Aktivieren Sie den rollback-helper-Dienst:

    root # systemctl enable rollback
  4. Registrieren Sie das System beim SUSE Customer Center:

    root # yast2 registration
  5. Führen Sie die Migration durch:

    root # yast2 migration

    Bei Paketkonflikten präsentiert YaST eine Liste mit Auflösungen, aus der Sie wählen können.

  6. Entfernen Sie bezuglose („verwaiste“) Pakete:

    root # zypper rm $(zypper --no-refresh packages --orphaned | gawk '{print $5}' | tail -n +5)
  7. Booten Sie das System neu:

    root # reboot

Sie haben Ihr System nun erfolgreich zu SUSE Linux Enterprise Server migriert.

Wenn Sie nach der Migration auf ein Problem stoßen, können Sie die Migration wie ein Service Pack-Upgrade rückgängig machen. Anleitungen finden Sie im Abschnitt 5.7, „Rollback eines Service Packs“.

6 Rückportierungen des Quellcodes

SUSE verwendet häufig Rückportierungen, z. B. für die Migration aktueller Softwarereparaturen und -funktionen in veröffentlichte SUSE Linux Enterprise-Pakete. In diesem Kapitel wird erläutert, weshalb es irreführend sein kann, Versionsnummern zu vergleichen, um die Fähigkeiten und die Sicherheit von SUSE Linux Enterprise-Softwarepaketen zu beurteilen. Darüber hinaus wird in diesem Kapitel erläutert, wie SUSE die Systemsoftware sicher und aktuell hält und dabei die Kompatibilität für Ihre Anwendungssoftware beibehält, die Sie zusätzlich zu den SUSE Linux Enterprise-Produkten ausführen. Sie erfahren außerdem, wie Sie überprüfen können, welche öffentlichen Sicherheitsprobleme in Ihrer SUSE Linux Enterprise-Systemsoftware berücksichtigt wurden, und wie Sie den aktuellen Status Ihrer Software ermitteln.

6.1 Argumente für die Rückportierung

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:

  • Fehlerbehebungen mit begrenztem Risiko von Funktionsstörungen und

  • Änderungen, die die bestehenden Funktionen stören.

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:

  • wenn die Änderungen zwischen ihren Paketen und den Upstream-Versionen so groß geworden sind, dass eine Rückportierung nicht mehr praktikabel ist, oder

  • für Software, die schon an sich rasch veraltet, beispielsweise Anti-Malware-Software.

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 sollen stabile Schnittstellen (APIs) erzielt werden, auf die die Software-Hersteller sich verlassen können, wenn sie Produkte für die gemeinsame Verwendung mit den Unternehmensprodukten von SUSE bauen.

  • Die Pakete, die in den Unternehmensprodukten von SUSE zum Einsatz kommen, sollen die höchstmögliche Qualität aufweisen und gründlich getestet werden, und das nicht nur in sich selbst, sondern auch als Bestandteil des gesamten Unternehmensprodukts.

  • Die Zertifizierungen der Unternehmensprodukte von SUSE durch andere Hersteller, z. B. Zertifizierungen für Oracle- oder SAP-Produkte, sollen aufrechterhalten werden.

  • So können sich die SUSE-Entwickler voll und ganz auf die nächste Produktversion konzentrieren, müssen also nicht unzählige Versionen im Auge behalten.

  • Es soll klar ersichtlich sein, was in einer bestimmten Unternehmensversion vorhanden ist, damit unser Kundendienst genaue und zeitnahe Informationen dazu bereitstellen kann.

6.2 Argumente gegen die Rückportierung

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.

6.3 Auswirkungen der Rückportierungen auf die Interpretation der Versionsnummern

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.

6.4 Prüfen auf behobene Fehler sowie auf Funktionen nach einer Rückportierung

Informationen zu rückportierten Fehlerkorrekturen und Funktionen finden Sie an mehreren Stellen:

  • Changelog des Pakets:

    tux > rpm -q --changelog name-of-installed-package
    tux > rpm -qp --changelog packagefile.rpm

    Die Ausgabe dokumentiert den Änderungsverlauf des Pakets in Kurzform.

  • Das Changelog des Pakets enthält beispielsweise Einträge wie bsc#1234 (Bugzilla Suse. Com, die sich auf Fehler im Bugzilla-Fehlerverfolgungssystem beziehen oder mit anderen Fehlerüberwachungssystemen verknüpft sind. Aus Vertraulichkeitsgründen sind nicht alle Informationen frei für alle Benutzer zugänglich.

  • Ein Paket kann eine Datei /usr/share/doc/PACKAGENAME/README.SuSE umfassen, in der Sie allgemeine Informationen zum betreffenden SUSE-Paket finden.

  • Das RPM-Quellpaket enthält die Patches, die während der regulären binären RPMs als separate Dateien angewendet werden können. Wenn Sie das Lesen des Quellcodes beherrschen, können Sie diese Dateien interpretieren. Im Book “Verwaltungshandbuch”, Chapter 6 “Verwalten von Software mit Kommandozeilenwerkzeugen”, Section 6.1.3.5 “Installieren oder Herunterladen von Quellpaketen” finden Sie die Installationsquellen für die SUSE Linux Enterprise-Software. Im Book “Verwaltungshandbuch”, Chapter 6 “Verwalten von Software mit Kommandozeilenwerkzeugen”, Section 6.2.5 “Installieren und Kompilieren von Quellpaketen” finden Sie Informationen zum Erstellen von Paketen unter SUSE Linux Enterprise. Weitere Informationen zu den Software-Paket-Builds für SUSE Linux Enterprise finden Sie im Handbuch Maximum RPM.

  • In den SUSE-Sicherheitsmitteilungen finden Sie Korrekturen zu Sicherheitsfehlern. Die Fehler werden häufig mit standardisierten Kennungen wie CAN-2005-2495 bezeichnet, die im Rahmen des CVE-Projekts (Common Vulnerabilities and Exposures, häufige Sicherheitslücken und Gefährdungen) vergeben werden.