18 Lebenszyklus und Support #
In diesem Kapitel finden Sie Hintergrundinformationen zur Terminologie, zu den Lebenszyklen und Service Pack-Versionen der SUSE-Produkte sowie zu den empfohlenen Aufrüstungsrichtlinien.
18.1 Terminologie #
In diesem Kapitel werden verschiedene Begriffe verwendet. Lesen Sie zum besseren Verständnis der Informationen die unten stehenden Definitionen:
- Rückportierung
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.
- Delta-RPM
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.
- Downstream
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, Add-on-Produkte
Erweiterungen und Add-on-Produkte von Drittanbietern bieten zusätzliche Funktionen, die den Nutzwert von SUSE Linux Enterprise Server. Sie werden von SUSE und SUSE-Partnern bereitgestellt und werden zusätzlich zum Basisprodukt SUSE Linux Enterprise Server registriert und installiert.
- LTSS
LTSS ist die Abkürzung für Long Term Service Pack Support, der als Erweiterung für SUSE Linux Enterprise Server erhältlich ist.
- Hauptversion, Version zur allgemeinen Verfügung (General Availability, GA)
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. Hauptversionen sind beispielsweise SUSE Linux Enterprise 11 oder 12.
- Migration
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.
- Migrationsziele
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
Module sind vollständig unterstützte Bestandteile von SUSE Linux Enterprise Server, 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.
- Paket
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.- Patch
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.
- Service Packs (SP)
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.
- Upstream
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.
- Aktualisierung
Installation einer neueren Unterversion eines Pakets, die in der Regel Sicherheitsverbesserungen oder Fehlerbehebungen enthält.
- Upgrade
Installation einer neueren Hauptversion eines Pakets oder einer Distribution, die neue Funktionen enthält.
18.2 Produktlebenszyklus #
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 18.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 18.2, „Langfristiger Service Pack-Support“).
Weitere Informationen finden Sie unter https://www.suse.com/products/long-term-service-pack-support/.
Weitere Informationen zu den Lebenszyklen aller Produkte finden Sie in https://www.suse.com/lifecycle/.
18.3 Modullebenszyklen #
Mit SUSE Linux Enterprise 12 wurden modulare Pakete eingeführt. Die Module bestehen aus eindeutigen Paketsätzen, die jeweils in einem separaten Wartungskanal gruppiert sind und abhängig von den Service Pack-Lebenszyklen aktualisiert werden. So erhalten Sie zeitnah und auf einfache Weise Zugang zu den aktuellen Technologien in Bereichen, in denen Innovationen in schnellem Tempo erfolgen. Weitere Informationen zum Lebenszyklus der Module finden Sie unter https://scc.suse.com/docs/lifecycle/sle/12/modules.
18.4 Erzeugen eines periodischen Lebenszyklusberichts #
SUSE Linux Enterprise Server kann regelmäßig nach Supportstatus-Aktualisierungen aller installierten Produkte suchen und bei Änderungen einen Bericht per E-Mail versenden. Zum Erzeugen des Berichts installieren Sie zypper-lifecycle-plugin
mit zypper in zypper-lifecycle-plugin
.
Aktivieren Sie die Berichterzeugung auf dem System mit systemctl
:
root #
systemctl
enable lifecycle-report
Der Empfänger und der Betreff der Bericht-E-Mail sowie das Intervall für die Berichterzeugung können mit einem beliebigen Texteditor in der Datei /etc/sysconfig/lifecycle-report
konfiguriert werden. Die Einstellungen MAIL_TO
und MAIL_SUBJ
definieren den Empfänger und den Betreff der E-Mail und DAYS
bezeichnet das Intervall, in dem die Berichte erzeugt werden sollen.
Änderungen des Supportstatus werden erst nach Eintreten einer Änderung im Bericht sichtbar, nicht schon im Voraus. Wird eine Änderung unmittelbar nach dem Erzeugen des letzten Berichts vorgenommen, kann es bis zu 14 Tage dauern, bis Sie über diese Änderung informiert werden. Berücksichtigen Sie diesen Punkt, wenn Sie die Option DAYS
festlegen. Ändern Sie die folgenden Konfigurationseinträge gemäß Ihren Anforderungen:
MAIL_TO='root@localhost' MAIL_SUBJ='Lifecycle report' DAYS=14
Der aktuelle Bericht befindet sich in der Datei /var/lib/lifecycle/report
. Die Datei umfasst zwei Abschnitte. Im ersten Abschnitt finden Sie Informationen zum Supportende für die verwendeten Produkte. Der zweite Abschnitt listet Pakete mit dem zugehörigen Datum des Supportendes und der eventuellen Verfügbarkeit von Aktualisierungen auf.
18.5 Supportstufen #
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. Mit diesen Supportstufen erhalten Sie Aktualisierungen für Root-Sicherheitsanfälligkeiten im Kernel und andere Root-Sicherheitsanfälligen als direkt ausführbare Datei, die ohne Eingreifen des Benutzers abgearbeitet wird. Darüber hinaus werden vorhandene Workloads, Softwarestapel und Hardware mit einer limitierten Paketausschlussliste unterstützt. Einen Überblick finden Sie in Tabelle 18.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 |
Rückportierung 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) |
18.6 Repository-Modell #
Das Repository-Layout entspricht den Produktlebenszyklen. In den nachfolgenden Abschnitten werden alle relevanten Repositorys aufgelistet.
- Updates
Wartungspakete für Pakete im entsprechenden
Core
- oderPool
-Repository.- Pool
Enthält alle binären RPMs vom Installationsmedium, dazu Schemadaten und Supportstatus-Metadaten.
- Debuginfo-Pool, Debuginfo-Updates
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.
Mit der Aktualisierung auf SUSE Linux Enterprise 12 sind nur zwei Repositorys verfügbar: SLES12-GA-Pool
und SLES12-GA-Updates
. Ältere Repositorys aus SUSE Linux Enterprise 11 sind nicht länger verfügbar.
18.6.1 Erforderliche Repositorys für SUSE Linux Enterprise Server #
- SLES 12
SLES12-GA-Pool
SLES12-GA-Updates
- SLES 12 SP1
SLES12-SP1-Pool
SLES12-SP1-Updates
- SLES 12 SP2
SLES12-SP2-Pool
SLES12-SP2-Updates
- SLES 12 SP3
SLES12-SP3-Pool
SLES12-SP3-Updates
- SLES 12 SP4
SLES12-SP4-Pool
SLES12-SP4-Updates
- SLES 12 SP5
SLES12-SP5-Pool
SLES12-SP5-Updates
18.6.2 Optionale Repositorys für SUSE Linux Enterprise Server #
- SLES 12
SLES12-GA-Debuginfo-Core
SLES12-GA-Debuginfo-Updates
- SLES 12 SP1
SLES12-SP1-Debuginfo-Core
SLES12-SP1-Debuginfo-Updates
- SLES 12 SP2
SLES12-SP2-Debuginfo-Core
SLES12-SP2-Debuginfo-Updates
- SLES 12 SP3
SLES12-SP3-Debuginfo-Core
SLES12-SP3-Debuginfo-Updates
- SLES 12 SP4
SLES12-SP4-Debuginfo-Core
SLES12-SP4-Debuginfo-Updates
- SLES 12 SP5
SLES12-SP5-Debuginfo-Core
SLES12-SP5-Debuginfo-Updates
18.6.3 Modulspezifische Repositorys für SUSE Linux Enterprise Server #
Die nachfolgende Liste enthält lediglich die Haupt-Repositorys für die einzelnen Module, nicht jedoch die Debuginfo
- oder Source
-Repositorys.
- Verfügbare Module für SLES 12 GA/SP1/SP2/SP3/SP4/SP5
ASM(Advanced Systems Management)-Modul: CFEngine, Puppet und das Machinery-Werkzeug
SLE-Module-Adv-Systems-Management12-Pool
SLE-Module-Adv-Systems-Management12-Updates
Zertifizierungsmodul: FIPS 140-2 zertifikationsspezifische Pakete (nicht für AArch64 und POWER erhältlich)
SLE-Module-Certifications12-Pool
SLE-Module-Certifications12-Updates
Container-Modul: Docker Open Source Engine, Tools, vorverpackte Images
SLE-Module-Containers12-Pool
SLE-Module-Containers12-Updates
Legacy-Modul: Sendmail, bisheriger IMAP-Stapel, bisheriges Java ... (nicht für AArch64 verfügbar)
SLE-Module-Legacy12-Pool
SLE-Module-Legacy12-Updates
Modul für öffentliche Cloud: Initialisierungscode und Werkzeuge für öffentliche Cloud
SLE-Module-Public-Cloud12-Pool
SLE-Module-Public-Cloud12-Updates
Toolchain-Modul: GNU Compiler Collection (GCC)
SLE-Module-Toolchain12-Pool
SLE-Module-Toolchain12-Updates
Web- und Skriptmodul: PHP, Python, Ruby on Rails
SLE-Module-Web-Scripting12-Pool
SLE-Module-Web-Scripting12-Updates
- Verfügbare Module für SLES 12 SP2/SP3/SP4/SP5
HPC-Modul: Werkzeuge und Bibliotheken für Hochleistungs-Computing
SLE-Module-HPC12-Pool
SLE-Module-HPC12-Updates
18.6.4 Erforderliche Repositorys für SUSE Linux Enterprise Desktop #
- SLED 12
SLED12-GA-Pool
SLED12-GA-Updates
- SLED 12 SP1
SLED12-SP1-Pool
SLED12-SP1-Updates
- SLED 12 SP2
SLED12-SP2-Pool
SLED12-SP2-Updates
- SLED 12 SP3
SLED12-SP3-Pool
SLED12-SP3-Updates
- SLED 12 SP4
SLED12-SP4-Pool
SLED12-SP4-Updates
- SLED 12 SP5
SLED12-SP5-Pool
SLED12-SP5-Updates
18.6.5 Optionale Repositorys für SUSE Linux Enterprise Desktop #
- SLED 12
SLED12-GA-Debuginfo-Core
SLED12-GA-Debuginfo-Updates
- SLED 12 SP1
SLED12-SP1-Debuginfo-Core
SLED12-SP1-Debuginfo-Updates
- SLED 12 SP2
SLED12-SP2-Debuginfo-Core
SLED12-SP2-Debuginfo-Updates
- SLED 12 SP3
SLED12-SP3-Debuginfo-Core
SLED12-SP3-Debuginfo-Updates
- SLED 12 SP4
SLED12-SP4-Debuginfo-Core
SLED12-SP4-Debuginfo-Updates
- SLED 12 SP5
SLED12-SP5-Debuginfo-Core
SLED12-SP5-Debuginfo-Updates
18.6.6 Registrieren und Aufheben der Registrierung von Repositorys bei SUSEConnect #
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 #
zypper
repos -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