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 .
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 aktuellen Versionshinweise stehen online unter https://www.suse.com/releasenotes/ bereit.
Alternativ finden Sie die Versionshinweise auf der Installations-DVD im Verzeichnis docu
.
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 /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
.
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-repo
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.reporoot #
zypper
install $(cat installed-software.bak)
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 37 texlive -Pakete aus SLE 11 auf 422 Pakete in SLE 12 aufgeteilt.
Wenn ein Paket auf mehrere andere Pakete aufgeteilt wurde, werden bei einem Upgrade alle Neupakete 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.
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.
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:
Melden Sie sich auf dem SUSE Linux Enterprise 11-Computer an.
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.
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.
Führen Sie das Upgrade aus. Nach dem Upgrade ist die bisherige Konfigurationsdatei /etc/my.cnf
unverändert. Die neue Konfiguration finden Sie in der Datei /etc/my.cnf.rpmnew
.
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.
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
Prüfen Sie, ob MariaDB ordnungsgemäß ausgeführt wird. Stellen Sie hierzu eine Verbindung zur Datenbank her:
root #
mysql
-u root -p
Eine neuere Version der PostgreSQL-Datenbank ist im Lieferumfang von SUSE Linux Enterprise Server 15 SP1 enthalten. 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 dem Upgrade gilt nicht mehr das Verzeichnis /usr/lib/postgresql96/
, sondern das Verzeichnis /usr/lib/postgresql10/
.
So führen Sie die Datenbankmigration aus:
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 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
Halten Sie den PostgreSQL-Server an:
root #
systemctl stop postgresql.service
Benennen Sie das alte Datenverzeichnis um:
root #
mv
/var/lib/pgsql/data /var/lib/pgsql/data.old
Initialisieren Sie die neue Datenbankinstanz manuell mit initdb
oder starten und stoppen Sie PostgreSQL, wodurch die Instanz automatisch initialisiert wird:
root #
systemctl start postgresql.serviceroot #
systemctl stop postgresql.service
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, einfach die alten Konfigurationsdateien zu kopieren, da somit möglicherweise neue Optionen, neue Standardeinstellungen und geänderte Kommentare überschrieben werden.
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/"
Starten Sie die neue Datenbankinstanz:
root #
systemctl start postgresql.service
Ü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.
Entfernen Sie alle alten PostgreSQL-Pakete und das alte Datenverzeichnis:
root #
zypper
search -s postgresql94 | xargs zypper rm -uroot #
rm
-rf /var/lib/pgsql/data.old
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:
Öffnen Sie ein Terminal und melden Sie sich als root
an.
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
.
Erstellen Sie einen Zertifizierungsantrag (CSR):
root #
openssl
req -new -key server.key -out server.csr
Führen Sie eine Eigensignierung des Zertifikats durch:
root #
openssl
x509 -req -days 365 -in server.csr -signkey server.key -out server.crt
Erstellen Sie die PEM-Datei:
root #
cat
server.key server.crt > server.pem
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/
.
Wenn Ihr Rechner als VM-Hostserver für KVM oder Xen fungiert, müssen Sie vor der Aktualisierung alle aktiven VM-Gäste ordnungsgemäß herunterfahren. Andernfalls können Sie nach der Aktualisierung wahrscheinlich nicht mehr auf die Gäste zugreifen.
Beachten Sie Folgendes, wenn der Rechner, 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 ist, heben Sie die Registrierung des Rechners beim SMT-Server wie in Prozedur 3.1 beschrieben auf. Starten Sie danach den Upgradevorgang neu.
Melden Sie sich beim Client-Rechner an.
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 -Etux >
sudo
rm -f /etc/SUSEConnecttux >
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.cachetux >
sudo
rm -f /etc/zmd/deviceidtux >
sudo
rm -f /etc/zmd/secret
Für SUSE Linux Enterprise 12 führen Sie folgende Kommandos aus:
tux >
sudo
SUSEConnect --de-registertux >
sudo
SUSEConnect --cleanuptux >
sudo
rm -f /etc/SUSEConnecttux >
sudo
rm -rf /etc/zypp/credentials.d/*tux >
sudo
rm -rf /etc/zypp/repos.d/*tux >
sudo
rm -f /etc/zypp/services.d/*
Melden Sie sich beim SMT-Server an.
Prüfen Sie, ob die Registrierung des Client aufgehoben wurde, indem Sie alle Client-Registrierungen aufrufen:
tux >
sudo
smt-list-registrations
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.)
Löschen Sie die Registrierung für diesen Client:
tux >
sudo
smt-delete-registration -g UNIQUE_ID
Sollte der Client mit mehreren IDs aufgeführt sein, wiederholen Sie den obigen Schritt für jede einzelne ID.
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
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.
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).
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 /
).
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
Wenn Sie Btrfs als Root-Dateisysteme auf dem Computer nutzen, muss ausreichend freier Speicherplatz zur Verfügung stehen. Im schlimmsten Fall belegt ein Upgrade 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
listroot #
snapper
delete NUMBER
Dies reicht jedoch nicht in allen Fällen aus. Vor der Migration belegen die meisten Snapshots nur wenig Platz.
Für einen Server mit SMT ist ein besonderes Upgradeverfahren erforderlich. Weitere Informationen finden Sie unter Chapter 2, Migrate from SMT to RMT im Handbuch zum Repository Management Tool.
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 in Abschnitt 19.1, „Aktivieren und Konfigurieren der Multiversions-Unterstützung“.
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 in Abschnitt 5.4, „Die Parmfile – Automatisierte Systemkonfiguration“.
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 von DISPLAYMANAGER_STARTS_XSERVER
in /etc/sysconfig/displaymanager
wie folgt:
DISPLAYMANAGER_STARTS_XSERVER="yes"