Ü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?

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 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 OS-Upgrade, genauer gesagt ein ServicePack-Upgrade gegenüber einer Neuinstallation empfehlenswet. Dies kann u.a. mittels folgender Methoden erfolgen:

2.0 Vorbereitung

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 Fremdquellen installiert wurden. Falls ja, besitzen die so bezeichneten Fremdpakete ein, vom Standard abweichendes VENDOR-Label. Zur Analyse, ob und falls ja, welche Fremdpakete installiert sind, kann folgendes Hilfsskript gestartet werden:

root@myhost:~ # /ldist/updates/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. Sämtliche Fremdquellen sollten vor dem Upgrade deaktiviert werden. Dies geschieht nach Auflisten aller Installationsquellen durch Deaktivieren der jeweiligen Fremdquellen:

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

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

Sind nur mehr die SUSE-Standard-Installationsquellen aktriviert, 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 oder Schritt 2.2 (Empfehlung) fortgesetzt werden.

2.1 Halbautomatisch (Empfehlung)

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

*) 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:

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

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

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-sp4-sp5

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

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 Manuell (zeitaufwändiger)

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

Schritt A 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

Schritt B1 Aktualisieren sämtlicher RPM-Pakete im YaST-Dialog "Software" > "Software installieren oder löschen":

myacc@myhost:~ # sudo -i yast2 sw_single

Bei SLE-10 werden z.B. alle installierten Pakete per Auswahl im Hauptmenü: "Filter" > "Installierte Pakete" aufgelistet und dann durch Wahl von "Aktionen" > "Alle aufgelisteten Pakete..." > "Aktualisieren, wenn neuere Version verfügbar" aktualisiert, nachdem man die Auswahl durch den "Übernehmen"-Button bestätigt hat.

oder mit zwischenzeitlich besserer Methode!

Schritt B2 Aktualisieren sämtlicher RPM-Pakete mittels Zypper:

Erst Aktualisieren des RPMs zypper:

root@myhost:~ # zypper in zypper

Anschließend werden alle restlichen RPMs (per "Dist-Upgrade"-Option) aktualisiert

root@myhost:~ # zypper dup

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

2.3 Nacharbeit

Nach erfolgreich durchgeführtem Upgrade, d.h. Schritt 2.1 oder Schritt 2.2 (Empfehlung), gilt es, etwaige Fremdpakete auf den aktuellen Stand zu bringen. Hierzu müssen die passenden Fremdquellen bzw. deren URLs gefunden und als neue Installationsquelle eingebunden werden. Letzteres geschieht mit folgendem Zypper-Befehl:

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

Die Aktualisierung der gesamten Installation kann dann wiederum mittels Dist-Upgrade erfolgen:

root@myhost:~ # zypper dup

Zuletzt gilt es, die gewünschten Dienste wieder zu reaktivieren. Nicht selten müssen dabei die jeweiligen Konfigurationsdateien angepasst bzw. modernisiert werden.

3. Migration der bestehenden Installation

Die Paketauswahl für SLE-15-SP3|SP4|SP5 ist (größtenteils) binär-kompatibel mit openSUSE-Leap-15.3|15.4|15.5. 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:

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

bzw.

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