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 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 .
Mitte 2023 wurde die SUSE Linux Enterprise 15-Produktfamilie von einem RSA 2048-Bit-Signierschlüssel auf einen neuen RSA 4096-Bit-Schlüssel umgestellt. Diese Änderung betrifft RPM-Pakete, Paket-Repositorys und ISO-Signaturen. Alte Repositorys, die nicht mehr aktualisiert werden, und RPMs, die bis zum Zeitpunkt der Umstellung veröffentlicht wurden, bleiben mit dem alten 2048-Bit-Schlüssel signiert.
Wenn Sie Ihr System aktualisieren, wird der neue Schlüssel automatisch in den RPM-Schlüsselring aus dem suse-build-key-Paket auf SLE 15 SP 4 und SP5 sowie den LTSS-Versionen von SLE 15 SP1, SP2 und SP3 importiert.
Wenn der Schlüssel noch nicht importiert wurde, können Sie ihn manuell importieren mit:
>
sudo
rpm --import /usr/lib/rpm/gnupg/keys/gpg-pubkey-3fa1d6ce-63c9481c.asc
Wenn Sie eine ältere Version von SLE verwenden oder den neuen Schlüssel nicht importiert haben, werden Sie während des Upgrades aufgefordert, ihm zu vertrauen. Versichern Sie sich, dass der Fingerabdruck übereinstimmt:
pub rsa4096/0xF74F09BC3FA1D6CE 2023-01-19 [SC] [expires: 2027-01-18] Key fingerprint = 7F00 9157 B127 B994 D5CF BE76 F74F 09BC 3FA1 D6CE uid SUSE Package Signing Key <build@suse.de>
Zusätzlich wurde ein 4096-Bit-RSA-Reserveschlüssel für Disaster Recovery-Zwecke importiert:
pub rsa4096/0xA1BFC02BD588DC46 2023-01-19 [SC] [expires: 2033-01-16] Key fingerprint = B56E 5601 41D8 F654 2DFF 3BF9 A1BF C02B D588 DC46 uid SUSE Package Signing Key (reserve key) <build@suse.de>
Dieser Schlüssel kann manuell importiert werden mit:
>
sudo
rpm --import /usr/lib/rpm/gnupg/keys/gpg-pubkey-d588dc46-63c939db.asc
Beide Schlüssel finden Sie auch auf dem Installationsmedium und auf der SUSE-Website unter https://www.suse.com/support/security/keys/.
3.2 Lesen Sie die Versionshinweise #
Eine Liste aller Änderungen, neuen Funktionen und bekannten Probleme finden Sie in den release notes. Die Versionshinweise finden Sie auch auf den Installationsmedien im Verzeichnis docu
.
Die Versionshinweise enthalten in der Regel nur die Änderungen zwischen zwei aufeinander folgenden Versionen. Falls Sie mindestens ein Service Pack überspringen, beachten Sie auch die Versionshinweise der übersprungenen Service Packs.
Lesen Sie die Versionshinweise, um zu prüfen, ob Folgendes zutrifft:
Sind bei der Hardware besondere Überlegungen zu beachten?
Wurden erhebliche Änderungen an den aktuell verwendeten Softwarepaketen vorgenommen?
Erfordert Ihre Installation besondere Vorsichtsmaßnahmen?
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 /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 Verfügbaren Speicherplatz prüfen #
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).
3.4.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 /
).
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 39G 1.6G 37G 4% /windows/C /dev/sda2 4.6G 2.6G 2.1G 57% /windows/D
3.4.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. Weitere Informationen finden Sie unter man 8
btrfs-filesystem
und https://btrfs.wiki.kernel.org/index.php/FAQ.
Wenn Sie Btrfs als root-Dateisysteme auf dem Rechner 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:#
snapper
list#
snapper
delete NUMBERDies reicht jedoch nicht in allen Fällen aus. Vor der Migration belegen die meisten Snapshots nur wenig Platz.
3.5 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.
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.#
zypper
lr -e repositories.bakErstellen Sie außerdem die Datei
installed-software.bak
mit einer Liste aller installierten Pakete:#
rpm
-qa --queryformat '%{NAME}\n' > installed-software.bakErstellen Sie Sicherungskopien beider Dateien. Die Repositorys und die installierten Pakete können mit den folgenden Befehlen wiederhergestellt werden:
#
zypper
ar repositories.bak.repo#
zypper
install $(cat installed-software.bak)Anmerkung: Bei einer Aktualisierung auf eine neue Hauptversion erhöht sich die Anzahl der PaketeEin 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. Beispielsweise wurden 37 texlive-Pakete aus SLE 11 auf mehr als 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.6 LTSS-Erweiterung deaktivieren #
Wenn Sie ein SUSE Linux Enterprise Desktop-System mit LTSS (Long Term Service Pack Support) auf eine Version aktualisieren, die noch unter allgemeinem Support steht, schlägt das Upgrade mit dem Fehler No migration available
fehl. Dies geschieht, weil zypper migration
versucht, alle Repositorys zu migrieren, es aber noch kein LTSS-Repository für die neue Version gibt.
Deaktivieren Sie zur Behebung dieses Problems die LTSS-Erweiterung vor dem Upgrade.
Prüfen Sie, ob die LTSS-Erweiterung aktiviert ist:
>
sudo
SUSEConnect --list-extensions | grep LTSS SUSE Linux Enterprise Server LTSS 12 SP4 x86_64 (Installed) Deactivate with: SUSEConnect -d -p SLES-LTSS/12.4/x86_64Deaktivieren Sie die LTSS-Erweiterung mit dem Befehl aus der
SUSEConnect
-Ausgabe oben:>
sudo
SUSEConnect -d -p SLES-LTSS/12.4/x86_64 Deregistered SUSE Linux Enterprise Server LTSS 12 SP4 x86_64 To server: https://scc.suse.com/Prüfen Sie, ob das LTSS-Repository bei
zypper lr
nicht mehr vorhanden ist.
3.7 Erstellen von Nicht-MD5-Server-Zertifikaten für Java-Anwendungen #
Als Sicherheitsmaßnahme werden MD5-gestützte Zertifikate in Java nicht mehr unterstützt. Wenn Sie über als MD5 erstellte Zertifikate verfügen, erstellen Sie diese mit folgenden Schritten neu:
Öffnen Sie ein Terminal und melden Sie sich als
root
an.Erstellen Sie einen privaten Schlüssel:
#
openssl
genrsa -out server.key 1024Wenn 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):
#
openssl
req -new -key server.key -out server.csrFühren Sie eine Eigensignierung des Zertifikats durch:
#
openssl
x509 -req -days 365 -in server.csr -signkey server.key -out server.crtErstellen Sie die PEM-Datei:
#
cat
server.key server.crt > server.pemLegen Sie die Dateien
server.crt
,server.csr
,server.key
undserver.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.8 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.9 Einrichtung Ihres SMT-Clients anpassen #
Beachten Sie Folgendes, wenn der Rechner, für den ein Upgrade durchgeführt werden soll, als Client bei einem SMT-Server registriert ist:
Prüfen Sie, ob die Version des Skripts clientSetup4SMT.sh
auf Ihrem Host aktuell ist. clientSetup4SMT.sh
aus älteren Versionen von SMT kann nicht zum Verwalten von SMT 12-Clients verwendet werden. Wenn Sie auf Ihrem SMT-Server regelmäßig Software-Patches anwenden, finden Sie die neueste Version von clientSetup4SMT.sh
immer unter <SMT_HOSTNAME>/repo/tools/clientSetup4SMT.sh
.
Prozedur 3.1 Starten Sie danach den Upgradevorgang neu.
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:
>
sudo
suse_register -E>
sudo
rm -f /etc/SUSEConnect>
sudo
rm -rf /etc/zypp/credentials.d/*>
sudo
rm -rf /etc/zypp/repos.d/*>
sudo
rm -f /etc/zypp/services.d/*>
sudo
rm -f /var/cache/SuseRegister/*>
sudo
rm -f /etc/suseRegister*>
sudo
rm -f /var/cache/SuseRegister/lastzmdconfig.cache>
sudo
rm -f /etc/zmd/deviceid>
sudo
rm -f /etc/zmd/secretFür SUSE Linux Enterprise 12 führen Sie folgende Kommandos aus:
>
sudo
SUSEConnect --de-register>
sudo
SUSEConnect --cleanup>
sudo
rm -f /etc/SUSEConnect>
sudo
rm -rf /etc/zypp/credentials.d/*>
sudo
rm -rf /etc/zypp/repos.d/*>
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:
>
sudo
smt-list-registrationsWird der Hostname des Client in der Ausgabe dieses Kommandos noch aufgelistet, rufen Sie die
Unique 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:
>
sudo
smt-delete-registration -g UNIQUE_IDSollte 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:
>
sudo
smt-list-registrations
3.10 Passen Sie den Boot-Parameter resume
an #
Auf Systemen, die mit SUSE Linux Enterprise Desktop 12 oder älter installiert wurden, kann die Standard-Kernel-Kommandozeile in /etc/default/grub
einen Parameter resume enthalten, der den Namen eines Geräteknotens wie /dev/sda1
verwendet, um auf das Hibernation-Gerät (Suspend-to-Disk) zu verweisen. Da die Namen von Geräteknoten nicht beständig sind und sich zwischen Neustarts ändern können, ist es sehr empfehlenswert, dies zu korrigieren. Andernfalls kann das aufgerüstete System beim Neustart hängenbleiben.
Suchen Sie das Gerät für den Ruhezustand:
>
sudo
grep resume /etc/default/grub
GRUB_CMDLINE_LINUX_DEFAULT="resume=/dev/sda1 splash=silent quiet showopts"Das Gerät für den Ruhezustand ist
/dev/sda1
. Wenn das Kommando nichts zurückgibt, ist der Ruhezustand nicht konfiguriert.Rufen Sie die UUID für
/dev/sda1
ab:>
sudo
blkid /dev/vda1
/dev/vda1: UUID="a1d1f2e0-b0ee-4be2-83d5-78a98c585827" TYPE="swap" PARTUUID="000134b5-01"Die UUID für
/dev/sda1
lauteta1d1f2e0-b0ee-4be2-83d5-78a98c585827
.Bearbeiten Sie
/etc/default/grub
und passen Sie den Parameter resume an. Ersetzen Sie/dev/sda1
durchUUID=a1d1f2e0-b0ee-4be2-83d5-78a98c585827
. Das Ergebnis sieht folgendermaßen aus:GRUB_CMDLINE_LINUX_DEFAULT="resume=UUID=a1d1f2e0-b0ee-4be2-83d5-78a98c585827 splash=silent quiet showopts"
Aktualisieren Sie die Konfiguration des Grub-Bootmanagers:
>
sudo
grub2-mkconfig -o /boot/grub2/grub.cfg
Wenn das System den Ruhezustand nicht verwendet, können Sie den Parameter resume einfach entfernen und die Boot-Konfiguration aktualisieren.