Zum Inhalt springenZur Seitennavigation springen: vorherige Seite [Zugriffstaste p]/nächste Seite [Zugriffstaste n]
Bezieht sich auf SUSE Linux Enterprise Server 12 SP3

18 Aufrüsten von SUSE Linux Enterprise

SUSE® Linux Enterprise (SLE) ermöglicht die Aktualisierung eines vorhandenen Systems auf die neue Version, zum Beispiel von SLE 11 SP4 zu SLE 12. 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 aufrüsten.

18.1 Unterstützte Aufrüstungspfade auf SLE 12 SP3

Wichtig
Wichtig: Architekturübergreifende Aufrüstungen werden nicht unterstützt

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

Insbesondere SLE 11 unter POWER (Big Endian) auf SLE 12 SP2 unter POWER (neu: Little Endian) wird nicht unterstützt.

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

Ist eine architekturübergreifende Aufrüstung erforderlich, so muss eine Neuinstallation ausgeführt werden.

Vor der Migration beachten Sie Abschnitt 18.3, „Vorbereiten des Systems“.

Anmerkung
Anmerkung: Überspringen von Service Packs

Die Installation aller Service Packs in der richtigen Reihenfolge ist der sicherste Aufrüstungspfad. In bestimmten Fällen können ein oder zwei Service Packs bei der Aufrüstung übersprungen werden. Es wird jedoch empfohlen, keine Service Packs zu überspringen.

Anmerkung
Anmerkung: Aufrüsten von Hauptversionen

Beim Aufrüsten auf eine neue Hauptversion (z. B. von SUSE Linux Enterprise 11 auf SUSE Linux Enterprise 12) wird eine Neuinstallation empfohlen.

Aufrüsten von SUSE Linux Enterprise 10 (mit beliebigem Service Pack)

Es gibt keinen unterstützten direkten Migrationspfad zu SUSE Linux Enterprise 12. In diesem Fall wird eine Neuinstallation empfohlen.

Aufrüsten von SUSE Linux Enterprise 11 GA, SP1 oder SP2

Es gibt keinen unterstützten direkten Migrationspfad zu SUSE Linux Enterprise 12. Zum Aufrüsten auf SLE 12 SP3 muss mindestens SLE 11 SP4 vorliegen.

Falls Sie keine Neuinstallation ausführen können, rüsten Sie zunächst das installierte SLE 11-Service Pack auf SLE 11 SP4 auf. Diese Schritte werden im SUSE Linux Enterprise 11-Bereitstellungshandbuch beschrieben.

Fahren Sie anschließend mit Abschnitt 18.2, „Online- und Offline-Aufrüstung“ fort.

Aufrüsten von SUSE Linux Enterprise 11 SP4

Das Aufrüsten von SLE 11 auf SLE 12 SP3 wird nur im Offline-Modus unterstützt. Weitere Informationen finden Sie unter Abschnitt 18.2, „Online- und Offline-Aufrüstung“.

Aufrüsten von SUSE Linux Enterprise 12 GA auf SP3

Eine direkte Aufrüstung von SLE 12 GA auf SP3 wird nicht unterstützt. Rüsten Sie zunächst auf SLE 12 SP2 auf.

Aufrüsten von SUSE Linux Enterprise 12 SP1 oder SP2 auf SP3

Die Aufrüstung von SUSE Linux Enterprise 12 SP1 oder SP2 auf SP3 wird unterstützt.

Aufrüsten von SUSE Linux Enterprise 12 LTSS GA, SP1 oder SP2 auf SP3

Die Aktualisierung einer früheren SLE 12-LTSS-Version auf SP3 wird unterstützt.

Überblick über die kürzesten Aufrüstungspfade
Abbildung 18.1: Überblick über die kürzesten Aufrüstungspfade

18.2 Online- und Offline-Aufrüstung

SUSE unterstützt zwei verschiedene Aufrüstungs- und Migrationsmethoden. Weitere Informationen zu diesen Begriffen finden Sie unter Abschnitt 17.1, „Terminologie“. Die folgenden Methoden werden unterstützt:

Online

Alle Aufrüstungen, die vom laufenden System aus gestartet werden, gelten als Online-Aufrüstungen. Beispiele: Verbindung über through SUSE Customer Center, Subscription Management Tool (SMT), SUSE Manager mit zypper oder YaST.

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

Offline

Bei den Offline-Methoden wird in der Regel ein anderes Betriebssystem gebootet, von dem aus die installierte SLE-Version aufgerüstet wird. Beispiele: DVD, Flash-Laufwerk, ISO-Image, AutoYaST, einfaches RPM oder PXE-Boot.

Die Aufrüstung von SUSE Linux Enterprise 11 SP4 auf SUSE Linux Enterprise 12 SP3 wird ausschließlich als Offline-Aufrüstung unterstützt. Weitere Informationen hierzu finden Sie unter Kapitel 19, Offline-Aktualisierungen

Die Aufrüstung einer beliebigen SUSE Linux Enterprise 12-LTSS-Version oder von SUSE Linux Enterprise 12 SP1 oder SP2 auf SP3 wird mit allen Offline- und Online-Methoden unterstützt. Weitere Informationen hierzu finden Sie unter Kapitel 19, Offline-Aktualisierungen und Kapitel 20, Online-Aufrüstung.

18.3 Vorbereiten des Systems

Vor Beginn der Aufrüstung muss das System ordnungsgemäß vorbereitet werden. Zur Vorbereitung gehören unter anderem das Sichern der Daten und das Lesen der Versionshinweise.

18.3.1 Lesen Sie die Versionshinweise

In den Versionshinweisen finden Sie zusätzliche Informationen zu den Änderungen, die seit der vorigen Version von SUSE Linux Enterprise Server vorgenommen wurden. 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?

In den Versionshinweisen finden Sie auch Informationen, die erst nach der Fertigstellung des Handbuchs bekannt wurden. Auch bekannte Probleme werden beschrieben.

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

Die Versionshinweise befinden sich lokal im Verzeichnis /usr/share/doc/release-notes sowie online unter https://www.suse.com/releasenotes/.

18.3.2 Anlegen einer Sicherungskopie

Kopieren Sie die bestehenden Konfigurationsdateien vor der Aktualisierung auf ein separates Medium (wie ein Bandlaufwerk oder eine externe Festplatte), um die Daten zu sichern. 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 Leseberechtigung 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.

18.3.2.1 Auflisten installierter Pakete und Repositorys

Eine Liste der installierten Pakete ist häufig von Nutzen, beispielsweise bei einer Neuinstallation einer neuen SLE-Hauptversion oder beim Zurücksetzen des Systems auf die bisherige Version.

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.

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

root # zypper lr -e repositories.bak

Erstellen Sie außerdem die Datei installed-software.bak mit einer Liste aller installierten Pakete:

root # rpm -qa --queryformat '%{NAME}\n' > installed-software.bak

Erstellen Sie Sicherungskopien beider Dateien. Die Repositorys und die installierten Pakete können mit den folgenden Befehlen wiederhergestellt werden:

root # zypper ar repositories.bak
root # zypper install $(cat installed-software.bak)

18.3.3 Migration der MySQL-Datenbank

Ab SUSE Linux Enterprise 12 hat SUSE von MySQL auf MariaDB umgestellt. Bevor Sie die Aufrüstung 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 unter https://dev.mysql.com/doc/refman/5.5/en/mysqldump.html.

  3. Legen Sie die Dump-Datei, die Konfigurationsdatei /etc/my.cnf und das Verzeichnis /etc/mysql/ zur späteren Untersuchung (NICHT Installation!) an einem sicheren Speicherort ab.

  4. Führen Sie die Aufrüstung aus. Nach der Aufrüstung 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 mysql

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

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

    root # mysql -u root -p

18.3.4 Migration der PostgreSQL-Datenbank

SLE11 SP3 und SLE12 GA erhalten eine neuere Version der PostgreSQL-Datenbank als Wartungsaktualisierung. 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 Befehl pg_upgrade ausgeführt. Dieser Befehl ist eine alternative Methode zur bewährten Methode mit Erstellen eines Speicherauszugs und Neuladen. Im Vergleich zu Speicherauszug und Neuladen ist die Migration mit pg_upgrade weniger zeitaufwändig.

Die Dateien der verschiedenen PostgreSQL-Versionen sind jeweils in verschiedenen versionsabhängigen Verzeichnissen gespeichert. Nach der Aktualisierung gelten die folgenden neuen Verzeichnisse:

SLE11 SP3/SP4

/usr/lib/postgresql91/ to /usr/lib/postgresql94/

SLE12 GA

/usr/lib/postgresql93/ to /usr/lib/postgresql94/

So führen Sie die Datenbankmigration aus:

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

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

    • Erstellen Sie eine Sicherung der vorhandenen Datenbank.

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

    • Installieren Sie das Paket postgresql94-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 an:

    root # /usr/sbin/rcpostgresql stop
  3. Benennen Sie das alte Datenverzeichnis um:

    root # mv /var/lib/pgsql/data /var/lib/pgsql/data.old
  4. Erstellen Sie ein neues Datenverzeichnis:

    root # mkdir -p /var/lib/pgsql/data
  5. Wenn Sie die Konfigurationsdateien in der alten Version geändert hatten, kopieren Sie die Dateien postgresql.conf und pg_hba.conf in das neue Verzeichnis data:

    root # cp /var/lib/pgsql/data.old/*.conf \
         /var/lib/pgsql/data
  6. 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
  7. Starten Sie den Migrationsvorgang und ersetzen Sie den Platzhalter OLD durch die ältere Version:

    root # pg_upgrade \
       --old-datadir "/var/lib/pgsql/data.old" \
       --new-datadir "/var/lib/pgsql/data" \
       --old-bindir "/usr/lib/postgresqlOLD/bin/" \
       --new-bindir "/usr/lib/postgresql94/bin/"
  8. Starten Sie die neue Datenbankinstanz:

    root # /usr/sbin/rcpostgresql start
  9. Überprüfen Sie, ob die Migration erfolgreich war. Für diesen Schritt gibt es kein automatisiertes Tool. Der Umfang und die Elemente für den Test sind abhängig von Ihrem jeweiligen Anwendungsfall.

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

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

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

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

18.3.7 Prüfen des Skripts clientSetup4SMT.sh auf SMT-Clients

Wenn Sie Ihr bei einem SMT-Server registriertes Clientbetriebssystem migrieren möchten, müssen Sie prüfen, ob die Version des Skripts clientSetup4SMT.sh auf dem 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.

18.3.8 Festplattenspeicher

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

18.3.8.1 Ermitteln des freien Speicherplatzes auf Nicht-Btrfs-Dateisystemen

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

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

18.3.8.2 Ermitteln des freien Speicherplatzes auf Btrfs-Root-Dateisystemen

Wenn Sie Btrfs als Root-Dateisysteme auf dem Computer nutzen, muss ausreichend freier Speicherplatz zur Verfügung stehen. Im schlimmsten Fall belegt eine Aufrüstung ebenso viel Speicherplatz wie das aktuelle Root-Dateisystem (ohne /.snapshot) für einen neuen Snapshot. Mit diesem Befehl rufen Sie den verfügbaren Speicherplatz ab:

root # df -h /

Prüfen Sie auch den verfügbaren Platz auf allen anderen eingehängten Partitionen. 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.

18.3.9 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 die Aufrüstung 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 in Abschnitt 14.1, „Aktivieren und Konfigurieren der Multiversions-Unterstützung“.

18.4 Aufrüstung auf IBM z Systems

Für die Aufrüstung einer SUSE Linux Enterprise-Installation auf z Systems muss der Kernel-Parameter Upgrade=1 angegeben werden, z. B. in der parmfile. Weitere Informationen hierzu finden Sie in Abschnitt 4.3, „Die Parmfile – Automatisierte Systemkonfiguration“.

18.5 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 der Aufrüstung auftreten. Wenn der Anzeige-Manager nach dem Upgrade einen X-Server starten soll, ändern Sie die Einstellung von DISPLAYMANAGER_STARTS_XSERVER in /etc/sysconfig/displaymanager wie folgt:

DISPLAYMANAGER_STARTS_XSERVER="yes"
Diese Seite drucken