Übersicht

OS-Support-Perioden

Abkürzungen der SUSE-Produktbezeichnungen

SUSE Linux Enterprise, openSUSE

SLE = SuSE Linux Enterprise (Server, Desktop, SDK = Software Development Kit, HAE = High Availability Extension); SP = ServicePack; * = Termin in Planung

Von Zeit zu Zeit gibt es Übersichtsgrafiken zur Supportdauer der jeweiligen SLE-Channel - siehe SLE Lifecycle (Bild muss noch eingefügt werden).

Timeline-Grafiken

Timeline von SUSE Linux Enterprise u.a.: siehe https://www.suse.com/lifecycle/

Timeline von openSUSE: siehe http://de.wikipedia.org/wiki/OpenSUSE ; daraus entnommen ist folgende Grafik:

Ist ein OS-Upgrade notwendig?

Zum Testen, ob ein OS-Upgrade notwendig ist, wird zunächst das Installationsverzeichnis /nfs/ des Software-Management-Servers auf /ldist/ gemountet. Meist existiert hierfür ein /etc/fstab-Eintrag, sodass folgende Kommandos genügen:

myacc@myhost:~ # sudo -i
root@myhost:~ # [ -d /ldist/updates ] || mount /ldist

Jetzt kann folgendes Testskript aufgerufen werden:

root@myhost:~ # /ldist/updates/chk-upd.sh

Die Ausgabe des chk-upd.sh-Kommandos beschreibt die Aktualität von Betriebssystem (OS) und Kernel.

Was ist beim OS-Upgrade zu tun?

0. Definition und Beispiel

• MajorRelease bezeichnet die OS-Versionsnummer "vor" dem Punkt "."
• ServicePack bezeichnet die OS-Versionsnummer "nach" dem Punkt "."

Beim Upgrade auf eine höhere OS-Versionsnummer gibt es folgende Optionen:

• MajorRelease-Upgrade (MRU)
• ServicePack-Upgrade (SPU)

SLE-15.6 bezeichent beispielsweise das MajorRelease 15 mit ServicePack 6. Häufig wird diese OS-Version auch mit SLE-15-SP6 bezeichnet oder, wenn es sich um SUSE Linux Enterprise Server oder Desktop handelt, mit SLES-15-SP6 oder SLED-15-SP6.

Bei den Installationsquellen, auch Repositories oder kurz Repos genannt, wird zwischen Standard-Repos und Fremd-Repos unterschieden.

• RPM-Pakete aus den Standard-Repos bzw. Standard-Pakete werden direkt von SUSE für die jeweilige OS-Version erstellt und bei Bedarf bis zum Ende der OS-Supportlaufzeit aktualisiert;
• RPM-Pakete aus Fremd-Repos bzw. Fremd-Pakete werden entsprechend nicht (direkt) von SUSE, sondern durch Dritte (Firmen, Maintainer, etc.) bereitgestellt.

Ist die Notwendigkeit gegeben, das bestehende OS durch ein aktuelles, im SUSE-Support befindliches OS zu ersetzen, gibt es grundsätzlich zwei Verfahrenswege 1. oder 2.:

1. Neuinstallation oder Dienstmigration auf ein neues System

Eine Neuinstallation des Systems ist dann sinnvoll, wenn folgende zwei Kriterien erfüllt sind:

• es gibt keine aktuellen ServicePack-Upgrades (SPUs) mehr für das bestehende MajorRelease (Versionslinie).
  Folgende MajorReleases werden von SUSE nicht mehr unterstützt: SLE-10.x, SLE-11.x; SuSE-11.x, SuSE-12.x, SuSE-13.x, SuSE-42.x;
• falls es einen, von SUSE unterstützen Upgrade-Mechanismus auf ein aktuelles MajorRelease gibt, ist dennoch zu erwarten, dass auf dem System befindliche Dienste nach dem Upgrade nicht mehr startbar sind und/oder eine Neukonfiguration zu viel Zeit in Anspruch nehmen würde.

Wird der Wechsel auf ein neues MajorRelease seitens SUSE nicht unterstützt, wenn also folglich kein Upgrade-Mechanismus (MRU, siehe 2.1) existiert, gibt es keine Alternative zur Neuinstallation.

2. Upgrade der bestehenden Installation

Wird das MajorRelease des Betriebssystems noch unterstützt, ist ein ServicePack-Upgrade (SPU) gegenüber einer Neuinstallation empfehlenswert. Gibt es keine Unterstützung mehr für ein MajorRelease, kann ein MajorRelease-Upgrade (MRU) versucht werden. SPUs und MRUs können u.a. mittels folgender Methoden durchgeführt werden:

2.0 Vorbereitung

2.0.1 Dokumentation der aktivierten Dienste

Oft ist es hilfreich, den IST-Stand der bestehenden Installation zu dokumentieren, um nach einem Upgrade mit anschließendem Reboot prüfen zu können, welche Dienste weiterhin starten oder womöglich manuelle Nacharbeit erfordern. Zur Dokumentation empfehlen sich folgende zwei Kommandos:

2.0.1.1 Statussicherung aller aktiven Prozesse

root@myhost:~ # ps auxwwf > /tmp/ps-auxwwf

2.0.1.2 Statussicherung aller geöffneten Ports

root@myhost:~ # /ldist/updates/chk-tcp.sh -v > /tmp/chk-tcp-v

2.0.2 Prüfen auf Fremd-Pakete

Bevor es mit einem Upgrade losgehen kann, muss die bestehende Installation in einen "konsistenten" Zustand gebracht werden.

Hierbei ist zu prüfen, ob Softwarepakete aus Fremd-Repos – hierzu zählen auch veraltete SUSE-Repos – installiert wurden. Falls ja, besitzen die so bezeichneten Fremd-Pakete ein, vom Standard abweichendes VENDOR-Label. Zur Analyse, ob und falls ja, welche Fremd-Pakete installiert sind, kann folgendes Skript gestartet werden:

root@myhost:~ # /ldist/bin/getXrpm.sh

Mit der gewonnenen Information hat man einen Anhaltspunkt darüber, ob und falls ja, bei welchen Paketen Abhängigkeitskonflikte während des geplanten Upgrades auftreten können.

Nicht mehr notwendige Fremd-Pakete sollten vor dem Upgrade deinstalliert werden. Zum Deinstallieren empfiehlt sich ein Blick auf die in Schritt 2.3.1 beschriebenen Möglichkeiten.

Es sollten sämtliche Fremd-Repos deaktiviert werden. Dies kann entweder durch Reorganisation aller Standard-Repos (Empfehlung) in Schritt 2.0.3 oder manuell in Schritt 2.0.4 erfolgen:

2.0.3 Rerorganisation aller Standard-Repos (Empfehlung)

Hierbei wird zunächst die bestehende Repo-Konfiguration in das Unterverzeichnis /etc/zypp/repos.d.<timestamp>/ verschoben und eine neue Konfiguration mit allen Standard-Repos in /etc/zypp/repos.d/ eingefügt. Je nach MajorRelease SLE-12 oder SLE-15 wird eines der folgenden Skripte ausgeführt:

Bei einer bestehenden Installation mit SLE-12:

root@myhost:~ # /ldist/install/set-sles12-repos -a

Bei einer bestehenden Installation mit SLE-15:

root@myhost:~ # /ldist/install/set-sles15-repos -a

2.0.4 Manuelles Deaktivieren aller Fremd-Repos

Falls Schritt 2.0.3 durchgeführt wurde, ist die bisher verwendete Repo-Konfiguration in das Unterverzeichnis /etc/zypp/repos.d.<timestamp>/ verschoben und hier keine Aktion notwendig.

Falls Schritt 2.0.3 nicht durchgeführt wurde, wird zunächst durch Auflisten aller Repos geprüft, ob Fremd-Repos eingebunden sind. Falls ja, erfolgt die Deaktivierung der jeweiligen Fremd-Repos entweder mit Angabe der Repo-Nummer, des Repo-Namens oder der Repo-URL:

root@myhost:~ # zypper lr -u
[...]
root@myhost:~ # zypper mr -dR [Repo-Number|-Name|-URL]

Nach dem Upgrade müssen die Fremd-Repos meist mit aktualisierter URL bzw. Versionsnummer neu aktiviert werden. Doch zunächst weiter mit der Vorbereitung:

2.0.5 Aktualisieren der bestehenden Installation

Sind nur mehr die SUSE-Standard-Repos aktiviert, erfolgt, sofern noch nicht geschehen, die Anhebung der installierten Pakete auf die jeweils aktuellste Version. Hierzu wird folgender Zypper-Befehl ausgeführt; etwaige Aktualisierungsvorschläge werden mit Ja/Yes beantwortet:

root@myhost:~ # zypper dup

Ist die bestehende Installation bis auf etwaige Fremdpakete aktualisiert, kann mit dem nächsten Schritt 2.1 (Empfehlung) oder Schritt 2.2 fortgesetzt werden.

2.1 Halbautomatisches OS-Upgrade (Empfehlung)

Für das SPU = ServicePack-Upgrade und das MRU = MajorRelease-Upgrade existieren im Unterverzeichnis /ldist/install/upgrade/ folgende LRZ-Upgrade-Skripte (letzte Spalte):

*) Upgrade-Ziel wird nicht mehr von SUSE unterstützt.

Bemerkung: Für ausgesuchte Upgrade-Ziele existieren SUSE-Informationen, welcher Upgrade-Start, d.h. welche OS-Version als Vorbedingung für den jeweiligen Upgrade installiert sein muss:

*) Upgrade-Ziel wird nicht mehr von SUSE unterstützt.

Die LRZ-Upgrade-Skripte führen – mit Ausnahme der MRUs – auf Basis des Software-Tools Zypper die im Abschnitt 2.2 genannten Schritte "halbautomatisch", d.h. ohne oder nur mit wenigen interaktiven Abfragen, durch. Die für den SPU oder MRU notwendigen Kommandos sehen wie folgt aus:

2.1.1 ServicePack-Upgrade (SPU)

Für SLE-12 bzw. SLE-15 erfolgt der aktuellste SPU durch das folgende Skript:

root@myhost:~ # /ldist/install/upgrade/sle-12-sp4-sp5

bzw.

root@myhost:~ # /ldist/install/upgrade/sle-15-sp5-sp6

2.1.2 MajorRelease-Upgrade (MRU)

Analog verhält es sich mit dem MRU, der auf einer Konsole gestartet werden muss; beachte hierzu auch nachfolgende Bemerkungen:

root@myhost:~ # /ldist/install/upgrade/sle-12-sp5-15-sp6 -T

Bemerkungen (SPU = ServicePack-Upgrade; MRU = MajorRelease-Upgrade):

• Ein SPU über mehrere SPs hinweg, also z.B. von SLE-12-SP1 auf SLE-12-SP3 oder noch größere "Versionssprünge" wurden seitens ITS teilweise getestet – siehe verfügbare LRZ-Upgrade-Skripten. Grundsätzlich sollte es keine Probleme geben.
• Ein SPU kann grundsätzlich auch über einen SSH-Zugang bewerkstelligt werden. Zum Verfolgen von Boot-Meldungen empfiehlt sich allerdings der Konsol-Zugang.
• Beim MRU ist ein Konsol-Login Pflicht, denn das OS-Upgrade erfolgt nach (automatischem) Neustart mittels Installationsumgebung des neuen MajorRelease. In der Regel sind dabei auch (wenige) manuelle Interaktionen notwendig.
• Vor dem MRU sollte ein ServicePack eingespielt sein, das sich entweder noch im Support befindet, also vom Distributor SUSE mit regelmäßigen Updates versorgt wird, oder das nach Ablauf einer MajorRelease-Supportphase zuletzt noch unterstützt wurde.

2.2 Manuelles ServicePack-Upgrade (SPU)

Aufgrund des höheren Zeitaufwands wird diese Methode 2.2 nicht empfohlen!

2.2.1 Vorbemerkung

Falls die halbautomatische Methode 2.1 möglich ist, sollte diese den Vorzug gegenüber 2.2 haben. Zusätzliche Anpassungen, deren Notwendigkeit sich erst im Praxisbetrieb bereits aktualisierter Hosts zeigt, erweitern stetig die in 2.1 beschriebene "Halbautomatik".

2.2.2 Anhebung der Sub-Versionsnummer

der RPM-Quellverzeichnisse, z.B. von /nfs/SLES12.4x64 auf /nfs/SLES12.5x64 im YaST-Dialog "Software" > "Installationsquelle wechseln":

myacc@myhost:~ # sudo -i yast2 inst_source

2.2.3 Aktualisieren sämtlicher RPM-Pakete

Erst Aktualisieren des RPMs zypper:

root@myhost:~ # zypper in zypper

Anschließend werden alle restlichen RPMs (per "Dist-Upgrade"-Option) aktualisiert.
Um sicher zu gehen, dass auch sämtliche RPM-Pakete aktualisiert wurden, empfiehlt sich nach Ablauf des Upgrades ein erneutes Ausführen der "Dist-Upgrade"-Option:

root@myhost:~ # zypper dup
[...]
root@myhost:~ # zypper dup

2.3 Nacharbeit

Nach erfolgreich durchgeführtem Upgrade, d.h. Schritt 2.1 (Empfehlung) oder Schritt 2.2, gilt es, das neu installierte OS in einen konsistenten Zustand zu bringen.
Zunächst empfiehlt sich nach dem o.g. /ldist/-Mount ein erneuter Blick auf "abweichende" Pakete mittels o.g. Skript:

myacc@myhost:~ # sudo -i
root@myhost:~ # [ -d /ldist/updates ] || mount /ldist

root@myhost:~ # /ldist/bin/getXrpm.sh

2.3.1 Entfernen veralteter Pakete

Es sollten alle, nicht mehr zur OS-Version passenden Pakete, sofern noch vorhanden, entfernt werden.
Welche Pakete nicht mehr passend sind, zeigt sich bei SLE beispielsweise mit folgenden Befehl:

root@myhost:~ # /ldist/bin/getXrpm.sh -as 'SUSE Linux Enterprise'

Bei openSUSE ist folgender Befehl sinnvoll:

root@myhost:~ # /ldist/bin/getXrpm.sh -as 'openSUSE Leap'

Die Deinstallation der gefundenen Pakete erfolgt dann entweder durch Verwenden der '-e'-Erase- und '-n'-NoDependency-Option oder durch Erweiterung des jeweiligen vorgenannten Befehls mittels 'xargs'-Pipe:

root@myhost:~ # /ldist/bin/getXrpm.sh -aens '<search string>'
oder
root@myhost:~ # /ldist/bin/getXrpm.sh -as '<search string>' | xargs rpm --nodeps -e

Das Ergebnis der RPM-Deinstallation wird wiederum durch Ausführen des Analyse-Skripts (ohne zusätzliche Optionen) sichtbar:

root@myhost:~ # /ldist/bin/getXrpm.sh

2.3.2 Reaktivierung optionaler Fremd-Pakete

Etwaige Fremd-Pakete werden jetzt auf den aktuellen Stand gebracht. Hierzu müssen die passenden Fremd-Repos bzw. deren URLs gefunden und als zusätzliche Installationsquellen eingebunden werden.

Tipp: Falls vor dem Upgrade o.g. Schritt 2.0.1 durchgeführt wurde, können in /etc/zypp/repos.d.<timestamp>/ gesicherte Fremd-Repos das Auffinden aktueller Installationsquellen erleichtern. Nicht selten genügt es, lediglich die OS-Versionsnummer im Namen und in der URL eines Fremd-Repos zu aktualisieren.

Zusätzliche (Fremd-) Repos werden mit folgendem Zypper-Befehl aktiviert:

root@myhost:~ # zypper ar -fc [Repo-URL] [Repo-Name]

2.3.3 Konsistenzprüfung und Aktualisierung der OS-Installation

Abschließend erfolgt die Konsistenzprüfung mit eventueller Paket-Nachinstalltion wiederum mittels Dist-Upgrade:

root@myhost:~ # zypper dup

2.3.4 Reaktivieren und Prüfen der Dienste

Zuletzt gilt es, die gewünschten Dienste wieder zu reaktivieren. Nicht selten müssen dabei die jeweiligen Konfigurationsdateien angepasst bzw. modernisiert werden. Ob die Reaktivierung funktioniert oder Nacharbeit notwendig ist, zeigt ein Vergleich zwischen den, in 2.0.1 gesicherten Dateiinhalten und der Augabe des neuen IST-Standes:

root@myhost:~ # cat /tmp/ps-auxwwf
root@myhost:~ # ps auxwwf

root@myhost:~ # cat /tmp/chk-tcp-v
root@myhost:~ # /ldist/updates/chk-tcp.sh -v

3. Migration der bestehenden Installation

Die Paketauswahl für SLE-15-SP3|SP4|SP5|SP6 ist (größtenteils) binär-kompatibel mit openSUSE-Leap-15.3|15.4|15.5|15.6. Deshalb besteht grundsätzlich die Möglichkeit, die bestehende Installation auf das jeweils andere Betriebssystem zu wechseln. SLES ist bekanntlich lizenzpflichtig. Wird der professionelle Support nicht benötigt, muss man SLES nicht gleich durch Debian, Ubuntu o.Ä. ersetzen, sondern kann auf openSUSE wechseln.

Für die Migration von SLES auf openSUSE oder umgekehrt existieren im Unterverzeichnis /ldist/install/upgrade/ folgende LRZ-Migrate-Skripts:

*) Migrate-Ziel wird nicht mehr von SUSE unterstützt.

Das LRZ-Migrate-Skript (MIG = OS-Migrate) besitzt ähnliche Eigenschaften wie ein SPU, wie in Abschnitt 2 beschrieben. Nach Skript-Ausführung erfolgt ein (einmaliger) Reboot ins neue Betriebssystem.

root@myhost:~ # /ldist/install/upgrade/sle-sus-15-sp6

bzw.

root@myhost:~ # /ldist/install/upgrade/sus-sle-15-sp6