Falls Sie noch nicht mit den Grundlagen der Aktualisierungen, Aufrüstungen und Service Packs für SUSE Linux Enterprise vertraut sind, finden Sie in diesem Kapitel einige Hintergrundinformationen zur Terminologie, zu den SUSE-Produktlebenszyklen und den Service Pack-Versionen sowie zu den empfohlenen Aufrüstungsrichtlinien.
In diesem Kapitel werden verschiedene Begriffe verwendet. Lesen Sie zum besseren Verständnis der Informationen die unten stehenden Definitionen:
Bei der Rückportierung werden bestimmte Änderungen aus einer neueren Software-Version auf eine ältere Version angewendet. Dies ist am häufigsten beim Beheben von Sicherheitslücken in älteren Software-Komponenten der Fall. In der Regel gehört dieser Vorgang auch zu einem Wartungsmodell, bei dem Verbesserungen oder (seltener) neue Funktionen bereitgestellt werden.
Ein Delta-RPM besteht nur aus der binären diff zwischen zwei definierten Versionen eines Pakets und hat daher die kleinste Downloadgröße. Vor der Installation muss das vollständige RPM-Paket auf dem lokalen Rechner neu aufgebaut werden.
Bildlicher Ausdruck, wie Software in der Open-Source-Welt entwickelt wird (vgl. Upstream). Mit Downstream werden Personen oder Organisationen wie SUSE bezeichnet, die den Upstream-Quellcode in andere Software integrieren und so eine Distribution zusammenstellen, die dann von den Endbenutzern verwendet wird. So wandert die Software in Downstream-Richtung von den Entwicklern über die Integratoren bis hin zu den Endbenutzern.
Erweiterungen und Add-on-Produkte von Drittanbietern bieten zusätzliche Funktionen, die den Nutzwert von SUSE Linux Enterprise Desktop. Sie werden von SUSE und SUSE-Partnern bereitgestellt und werden zusätzlich zum Basisprodukt SUSE Linux Enterprise Desktop registriert und installiert.
Die Hauptversion von SUSE Linux Enterprise (oder von einem beliebigen Softwareprodukt) ist eine neue Version mit neuen Funktionen und Tools. Sie setzt vorher veraltete Komponenten außer Kraft und führt Änderungen ein, die nicht rückwärtskompatibel sind.
Aktualisierung auf ein Service Pack (SP), bei der die erforderlichen Patches über die Online-Aktualisierungswerkzeuge oder ein Installationsmedium installiert werden. Dadurch werden alle Pakete des installierten Systems auf den neuesten Stand gebracht.
Gruppe kompatibler Produkte, auf die ein System migriert werden kann (mit Version der Produkte/Erweiterungen und URL des Repositorys). Die Migrationsziele können sich im Lauf der Zeit ändern und sind abhängig von den installierten Erweiterungen. Mehrere Migrationsziele (beispielsweise SLE 12 SP2 und SES2 oder SLE 12 SP2 und SES3) können ausgewählt werden.
Module sind vollständig unterstützte Bestandteile von SUSE Linux Enterprise Desktop, die allerdings einen anderen Lebenszyklus aufweisen. Die Module besitzen einen klar definierten Umfang und werden ausschließlich über einen Online-Kanal bereitgestellt. Diese Kanäle können Sie nur dann abonnieren, wenn Sie sich beim SUSE Customer Center, beim SMT (Subscription Management Tool) oder beim SUSE Manager registriert haben.
Ein Paket ist eine komprimierte Datei im RPM-Format, die die Dateien für ein bestimmtes Programm enthält oder auch optionale Komponenten wie Konfigurationen, Beispiele und Dokumentation.
Ein Patch enthält mindestens ein Paket und kann per Delta-RPMs angewendet werden. Unter Umständen werden auch Abhängigkeiten zu Paketen aufgebaut, die noch nicht installiert wurden.
Kombinieren mehrere Patches zu einem "Paket", das einfach zu installieren bzw. bereitzustellen ist. Service Packs sind nummeriert und enthalten üblicherweise Sicherheits-Fixes, Upgrades oder Programmerweiterungen.
Bildlicher Ausdruck, wie Software in der Open-Source-Welt entwickelt wird (vgl. Downstream). Mit Upstream wird das ursprüngliche Projekt, der Autor oder der Betreuer einer Software bezeichnet, die als Quellcode verteilt wird. Rückmeldungen, Patches, Funktionsoptimierungen und andere Verbesserungen wandern von den Endbenutzern oder Beteiligten zu den Upstream-Entwicklern. Diese entscheiden, ob die Anforderung integriert oder abgelehnt wird.
Wenn die Projektmitglieder entscheiden, die Anforderung zu integrieren, wird diese in den neuen Versionen der Software auftreten. Eine akzeptierte Anforderung bietet Nutzen für alle Beteiligten.
Falls eine Anforderung abgelehnt wird, kommen hierfür unterschiedliche Gründe in Betracht. Die Anforderung weist einen Status auf, der nicht den Richtlinien des Projekts entspricht, sie ist ungültig, wurde bereits integriert oder liegt nicht im Interesse oder im Gesamtplan des Projekts. Eine nicht akzeptierte Anforderung erschwert die Arbeit für die Upstream-Entwickler, da sie ihre Patches mit dem Upstream-Code synchron halten müssen. Diese Vorgehensweise wird daher weitestgehend vermieden, ist jedoch in einigen Fällen unumgänglich.
Installation einer neueren Unterversion eines Pakets, die in der Regel Sicherheitsverbesserungen oder Fehlerbehebungen enthält.
Installation einer neueren Hauptversion eines Pakets oder einer Distribution, die neue Funktionen enthält.
Für die SUSE-Produkte gelten die folgenden Lebenszyklen:
SUSE Linux Enterprise Server hat einen Lebenszyklus von 13 Jahren: 10 Jahre allgemeiner Support und 3 Jahre erweiterter Support.
SUSE Linux Enterprise Desktop hat einen Lebenszyklus von 10 Jahren: 7 Jahre allgemeiner Support und 3 Jahre erweiterter Support.
Hauptversionen werden alle 4 Jahre veröffentlicht. Service Packs werden alle 12 bis 14 Monate bereitgestellt.
SUSE unterstützt ältere Service Packs für 6 Monate nach Bereitstellung des neuen Service Packs. In Abbildung 13.1, „Hauptversionen und Service Packs“ werden einige der genannten Aspekte veranschaulicht.
Wenn Sie mehr Zeit zum Entwickeln, Validieren und Testen Ihrer Upgradepläne benötigen, kann der Long Term Service Pack Support (LTSS) den Support um weitere 12 bis 36 Monate in Zwölf-Monats-Paketen verlängern, wodurch Sie 2 bis 5 Jahre Support für einen bestimmten Service Pack erhalten (siehe Abbildung 13.2, „Langfristiger Service Pack-Support“).
Weitere Informationen finden Sie unter https://www.suse.com/products/long-term-service-pack-support/.
Der Bereich für erweiterte Supportstufen beginnt in Jahr 10 und endet in Jahr 13. Sie umfassen fortlaufende L3-Diagnose auf technischer Ebene und rückwirkende Behebung kritischer Fehler. Diese Supportstufen führen proaktiv Updates für einfache lokale Root-Exploits in Kernel sowie für andere Root-Exploits durch, die direkt ohne Benutzerinteraktion ausgeführt werden können. Darüber hinaus werden vorhandene Workloads, Softwarestapel und Hardware mit einer limitierten Paketausschlussliste unterstützt. Einen Überblick finden Sie in Tabelle 13.1, „Sicherheitsupdates und Fehlerbehebungen“.
|
Allgemeiner Support für den neuesten Service Pack (SP) |
Allgemeiner Support für einen älteren SP, mit LTSS |
Erweiterter Support mit LTSS | |||
|---|---|---|---|---|---|
|
Funktion |
Jahr 1 bis 5 |
Jahr 6 bis 7 |
Jahr 8 bis 10 |
Jahr 4 bis 10 |
Jahr 10 bis 13 |
|
Technischer Support |
Ja |
Ja |
Ja |
Ja |
Ja |
|
Zugriff auf Patches und Reparaturen |
Ja |
Ja |
Ja |
Ja |
Ja |
|
Zugriff auf Dokumentation und Wissensdatenbank |
Ja |
Ja |
Ja |
Ja |
Ja |
|
Support für vorhandene Stacks und Workloads |
Ja |
Ja |
Ja |
Ja |
Ja |
|
Support für neue Bereitstellungen |
Ja |
Ja |
Eingeschränkt (basierend auf Partner- und Kundenanforderungen) |
Eingeschränkt (basierend auf Partner- und Kundenanforderungen) |
Nein |
|
Verbesserungsanfragen |
Ja |
Eingeschränkt (basierend auf Partner- und Kundenanforderungen) |
Eingeschränkt (basierend auf Partner- und Kundenanforderungen) |
Nein |
Nein |
|
Hardwareaktivierung und -optimierung |
Ja |
Eingeschränkt (basierend auf Partner- und Kundenanforderungen) |
Eingeschränkt (basierend auf Partner- und Kundenanforderungen) |
Nein |
Nein |
|
Treiberaktualisierungen über SUSE SolidDriver Program (früher PLDP) |
Ja |
Ja |
Eingeschränkt (basierend auf Partner- und Kundenanforderungen) |
Eingeschränkt (basierend auf Partner- und Kundenanforderungen) |
Nein |
|
Backport von Reparaturen aus einem früheren SP |
Ja |
Ja |
Eingeschränkt (basierend auf Partner- und Kundenanforderungen) |
nicht zutreffend |
nicht zutreffend |
|
Wichtige Sicherheitsaktualisierungen |
Ja |
Ja |
Ja |
Ja |
Ja |
|
Fehlerhafte Auflösung |
Ja |
Ja |
Eingeschränkt (nur Fehler der Sicherheitsstufe 1 und 2) |
Eingeschränkt (nur Fehler der Sicherheitsstufe 1 und 2) |
Eingeschränkt (nur Fehler der Sicherheitsstufe 1 und 2) |
Das Repository-Layout entspricht den Produktlebenszyklen. Tabelle 13.2, „Repository-Layout für SUSE Linux Enterprise 11 SP3/SP4 sowie für SUSE Linux Enterprise 12 SP1“ enthält eine Liste aller relevanten Repositorys.
|
Typ |
SLES |
SLED | ||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Erforderliche Repositorys |
11 SP 3
11 SP4
12
12 SP1
12 SP2
|
11 SP 3
11 SP4
12
12 SP1
12 SP2
| ||||||||||||||||||||
|
Optionale Repositorys |
11 SP 3
12
12 SP1
12 SP2
|
11 SP 3
12
12 SP1
12 SP2
| ||||||||||||||||||||
|
NEU: Modul-spezifische Repositorys |
12/12 SP1/12 SP2
|
12/12 SP1/12 SP2 Derzeit keine Module für SLED |
Wartungspakete für Pakete im entsprechenden Core- oder Pool-Repository.
Enthält alle binären RPMs vom Installationsmedium, dazu Schemadaten und Supportstatus-Metadaten.
Diese Repositorys enthalten statischen Inhalt. Von diesen beiden stehen Aktualisierungen nur für das Repository Debuginfo-Updates zur Verfügung. Aktivieren Sie diese Repositorys, wenn die Bibliotheken mit Informationen zur Fehlersuche installiert werden sollen.
SUSE Linux Enterprise 11 SP3/SP4.
Mit der Aktualisierung auf SP3 sind nur zwei Repositorys verfügbar: SLED11-SP3-Pool und SLED11-SP3-Updates. Seit SP4 sind frühere Repositorys nicht mehr sichtbar.
SUSE Linux Enterprise 12 und SP 1/SP2.
Mit der Aktualisierung auf SUSE Linux Enterprise 12 sind nur zwei Repositorys verfügbar: SLED12-GA-Pool und SLED12-GA-Updates. Frühere Repositorys von SUSE Linux Enterprise 11 sind deaktiviert.
Beim Registrieren erhält das System verschiedene Repositorys aus dem SUSE Custom Center (siehe https://scc.suse.com/) oder von einem lokalen Registrierungs-Proxy wie SMT. Die Repository-Namen sind bestimmten URIs im Customer Center zugeordnet. Zum Auflisten aller verfügbaren Repositorys auf dem System geben Sie das folgende zypper-Kommando ein:
root #zypperrepos -u
Hiermit erhalten Sie eine Liste aller verfügbaren Repositorys auf dem System. Für jedes Repository werden der Alias und der Name aufgeführt, und es ist angegeben, ob das Repository aktiviert ist und jeweils auf den neuesten Stand gebracht wird. Mit der Option -u erhalten Sie außerdem die URI, von der der Kanal stammt.
Zum Registrieren des Computers führen Sie SUSEConnect aus, beispielsweise:
root #SUSEConnect-r REGCODE
Soll die Registrierung des Computers wieder aufgehoben werden, können Sie dies ab SP1 ebenfalls mit SUSEConnect erledigen:
root #SUSEConnect--de-register
Mit dem folgenden Kommando können die lokal installierten Produkte und deren Status geprüft werden:
root #SUSEConnect-s
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.
Um Probleme beim Upgrade zu vermeiden, wird die SLE-12-Einstellung nicht automatisch geändert. 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"