Zum Inhalt springenZur Seitennavigation springen: vorherige Seite [Zugriffstaste p]/nächste Seite [Zugriffstaste n]
Bezieht sich auf SUSE Linux Enterprise Server 11 SP4

7 Aktualisieren von SUSE Linux Enterprise

SUSE® Linux Enterprise (SLE) bietet die Möglichkeit, ein vorhandenes System ohne komplette Neuinstallation auf die neue Version zu aktualisieren. Es ist keine neue Installation erforderlich. Bestehende Daten, wie Home-Verzeichnisse und Systemkonfigurationen, bleiben erhalten. Während des Lebenszyklus des Produkts können Sie Service Packs anwenden, mit denen Sie die Systemsicherheit erhöhen, Fehler in der Software beheben und Zugriff auf neue Funktionen erhalten. Führen Sie die Installation von einem lokalen CD- oder DVD-Laufwerk oder von einer zentralen Netzwerkinstallationsquelle durch.

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

Deltarpm

Ein deltarpm 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.

Online-Migration

Aktualisierung auf ein Service Pack (SP), bei der die erforderlichen Patches über die Online-Aktualisierungswerkzeuge (statt über die Installationsmedien) installiert werden. Dadurch werden alle Pakete des installierten Systems auf den neuesten Zustand (einschließlich Aktualisierungen) von SP3- plus SP2-Aktualisierungen aktualisiert.

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 deltarpms angewendet werden. Unter Umständen werden auch Abhängigkeiten zu Paketen aufgebaut, die noch nicht installiert wurden.

Service Packs (SP)

Kombiniert mehrere Patches zu einem Formular, 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.

Aufrüstung

Installation einer neueren Hauptversion eines Pakets oder einer Distribution, die neue Funktionen enthält.

7.2 Wartungsmodell für SUSE Linux Enterprise 11

Das neue Wartungsmodell für SUSE Linux Enterprise 11 kombiniert Flexibilität und Kontrolle über Ihre Service Packs. Es bietet folgende Vorteile:

  • Service Packs sind weniger umfangreich und können einfacher getestet und implementiert werden.

  • Ermöglicht eine Beibehaltung älterer Versionen, jedoch mit Support für das gesamte System.

  • Reagiert zwischen Service Packs durch selektive Verbesserungen auf Marktanforderungen und ermöglicht mehr Aktualisierungen im allgemeinen Aktualisierungs-Repository. Durch Auswahl der Verbesserungen werden längere Abstände zwischen Service Packs weniger problematisch.

7.2.1 Hintergrundinformationen

In den letzten Jahren haben die Kunden in ihren Rückmeldungen einen deutlichen Wunsch nach Verbesserungen ausgedrückt. Aus diesem Grund hat SUSE die Bereitstellung von Aktualisierungen an die Benutzer in einigen Punkten überarbeitet:

  • Bei SLES 9 gab es nur ein einziges Aktualisierungs-Repository, in dem alle Aktualisierungen gesammelt wurden; es sollte jedoch nur die letzte Versionsaktualisierung unterstützt werden.

  • Mit SLES 10 SP1 wurde ein SP-spezifisches Repository eingeführt. Dies bedeutet, dass alle Aktualisierungen für ein bestimmtes Service Pack in einem bestimmten Repository bereitstehen. Wenn die Benutzer sich direkt bei Novell Customer Center registriert haben und dann auf ein neueres Service Pack migrieren, verlieren sie den Zugang zu den früheren Repositorys. Benutzer mit SMT oder SUSE Manager konnten und können dagegen weiterhin beliebige SP-Kanäle abonnieren. Der wichtigste Grund für diese Änderung war die geplante sechsmonatige Übergangsfrist (n-1 Service Pack-Support), damit die Kunden das veröffentlichte Service Pack begutachten können und ein gewisses Zeitfenster für die Migration erhalten, in dem sie weiterhin mit ihrem bisherigen SP unterstützt werden.

  • SLES 11 GA und SLES 11 SP1 folgten dem Modell aus SLES 10. Mit SLES 11 SP2 wurde ein neues Repository-Modell mit den folgenden Bestandteilen eingeführt:

    1. Das Aktualisierungs-Repository für SLES 11 SP1 blieb weiterhin abonniert. Alle Aktualisierungen, die auch für SP2 galten, wurden ebenfalls oder ausschließlich im SP1-Aktualisierungs-Repository veröffentlicht. Dies bedeutet, dass die Aktualisierungen nicht gegen die so aufrechterhaltene ABI- und API-Kompatibilität verstoßen.

    2. Das Aktualisierungs-Repository für SLES 11 SP2 enthält ausschließlich die aktuellen und innovative Aktualisierungen, die (aus verschiedenen Gründen) nicht im SP1-Aktualisierungs-Repository bereitgestellt werden können. Darüber hinaus wurde ein Kern-Repository eingeführt, das als Schlupfloch für Pakete fungiert, die weder im SP1- noch im SP2-Aktualisierungs-Repository veröffentlicht wurden.

    3. SLES 11 SP4 wird über ein ähnliches Kanalmodell verfügen wie SLES 10. Das Modell gilt als die schnellste und einfachste Weise, Aktualisierungen für ein bestimmtes Service Pack bereitzustellen. Alle Aktualisierungen werden über einen besonderen Aktualisierungskanal bereitgestellt. Zusätzliche Kanäle werden auf dem Rechner zur Verfügung gestellt, aber die alten Kanäle werden entfernt.

Abbildung 7.1, „Weiterentwicklung der Wartungsbereitstellung (gilt auch für SLED)“ stellt einige der oben genannten Aspekte vor.

Weiterentwicklung der Wartungsbereitstellung (gilt auch für SLED)
Abbildung 7.1: Weiterentwicklung der Wartungsbereitstellung (gilt auch für SLED)

Unsere Produkte haben einen 10-jährigen Lebenszyklus: 10 Jahre allgemeiner Support und 3 Jahre erweiterter Support. Größere Versionen werden alle 4 Jahre und Service Packs alle 18 Monate veröffentlicht. Der langfristige Service Pack-Support (Long Term Service Pack Support) bietet ein erweitertes Fenster bzw. einen verlängerten Lebenszyklus für Hauptversionen Abbildung 7.2, „Langfristiger Service Pack-Support“).

Langfristiger Service Pack-Support
Abbildung 7.2: Langfristiger Service Pack-Support

Der langfristige Service Pack-Support muss explizit abonniert werden – entweder in der Standardversion oder in der Prioritätsversion. Er wirkt sich nicht auf die Bedingungen der L1- oder L2-Verträge aus. Sicherheitsaktualisierungen werden proaktiv behandelt: Dies sind alle nicht durch den Benutzer bedingten Updates aufgrund kritischer Sicherheitslücken, lokaler Root Exploits im Kernel oder anderer Root Exploits, die ohne Benutzerinteraktion direkt ausführbar sind.

7.2.2 Supportstufen

Der Bereich für erweiterte Supportstufen beginnt in Jahr 8 und endet in Jahr 10. 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 7.1, „Sicherheitsupdates und Fehlerbehebungen“.

Tabelle 7.1: Sicherheitsupdates und Fehlerbehebungen
 

– Allgemeiner Support –

Erweiterter Support

Thema

Aktueller SP

SP (n-1) 6 Monate

SP (n-1) mit LTSS

Jahr 6 und 7 mit LTSS

Jahr 8, 9, 10 mit LTSS

L1/L2 Technische Services

Proaktive Wartung

 

 

Treiberaktualisierungen über PLDP

  

Proaktive Sicherheitsupdates

 

L3 Technischer Support

Backports verfügbar

 

7.2.3 Kanalmodell

Beim bisherigen Wartungsmodell waren SUSE Linux Enterprise Server zwei Kanäle zugewiesen: SLES11-SPx-Pool und SLES11-SPx-Updates. Während der Online-Migration auf SPx+1 wurden diese Kanäle vorübergehend durch SLES11-SPx-Online ersetzt.

Mit SUSE Linux Enterprise SP 2 wurde das Kanal-Layout so geändert, dass die Vorteile des neuen Wartungsmodells unterstützt werden. Tabelle 7.2, „Kanal-Layout für SUSE Linux Enterprise 11 SP1, SP2 und SP3“ enthält eine Liste aller Kanäle von SP1 bis SP3.

Tabelle 7.2: Kanal-Layout für SUSE Linux Enterprise 11 SP1, SP2 und SP3

Typ

SLES

SLED

Erforderliche Kanäle

SP1

SLES11-SP1-Pool
SLES11-SP1-Updates

SP2

SLES11-SP1-Pool
SLES11-SP1-Updates
SLES11-SP2-Core
SLES11-SP2-Updates

SP3

SLES11-SP3-Pool
SLES11-SP3-Updates

SP4

SLES11-SP4-Pool
SLES11-SP4-Updates

SP1

SLED11-SP1-Pool
SLED11-SP1-Updates

SP2

SLED11-SP1-Pool
SLED11-SP1-Updates
SLED11-SP2-Core
SLED11-SP2-Updates

SP3

SLED11-SP3-Pool
SLED11-SP3-Updates

SP4

SLED11-SP4-Pool
SLED11-SP4-Updates

Optionale Kanäle

SP1

SLES11-SP1-Debuginfo-Pool
SLES11-SP1-Debuginfo-Updates

SP2

SLES11-SP2-Debuginfo-Core
SLES11-SP2-Debuginfo-Updates
SLES11-Extras
SLES11-SP2-Extension-Store

SP3

SLES11-SP3-Debuginfo-Core
SLES11-SP3-Debuginfo-Updates
SLES11-SP3-Extension-Store
SLES11-Extra

SP4

SLES11-SP4-Debuginfo-Pool
SLES11-SP4-Debuginfo-Updates
SLES11-Extra
SLES11-Security-Module

SP1

SLED11-SP1-Debuginfo-Pool
SLED11-SP1-Debuginfo-Updates

SP2

SLED11-SP2-Debuginfo-Core
SLED11-SP2-Debuginfo-Updates
SLED11-Extras
SLED11-SP2-Extension-Store

SP3

SLED11-SP3-Debuginfo-Core
SLED11-SP3-Debuginfo-Updates
SLED11-SP3-Extension-Store
SLED11-Extra

SP4

SLED11-SP4-Debuginfo-Pool
SLED11-SP4-Debuginfo-Updates

Produktspezifisch (Beispiele)

SLES11-WebYaST-SP2-Pool
SLES11-WebYaST-SP2-Updates
SLED11-MSI-Updates
Beschreibung der erforderlichen Kanäle
Core

Teilmenge des entpackten Installationsmediums. Enthält lediglich die Pakete, die als Core von SPx gelten (etwa 30 % der gesamten Pakete). Die SP-Repositorys enthalten nur Pakete für ein bestimmtes SP und die zugehörigen Themen (beispielsweise Hardware-Befähigung). Nur in SP2.

Updates

Wartungspakete für Pakete im entsprechenden Core- oder Pool-Repository.

Pool

Enthält alle binären RPMs vom Installationsmedium, dazu Schemadaten und Supportstatus-Metadaten.

Beschreibung der optionalen Kanäle
Debuginfo-Pool, Debuginfo-Updates

Diese Kanäle enthalten statischen Inhalt. Dabei wird nur der Kanal Debuginfo-Updates aktualisiert. Aktivieren Sie diese Kanäle, wenn die Bibliotheken mit Informationen zur Fehlersuche installiert werden sollen.

Extension-Store

Zurzeit nicht verwendet. Soll Pakete für (künftige) Add-On-Produkte enthalten. Der Kanal „Extension Store“ ist ab SLES 11 SP4 nicht mehr verfügbar.

LTSS-Updates

Wartungsaktualisierungen für Pakete im entsprechenden Pool-Repository für Installationen mit LTSS (Long Term Support Service). Für diese Kanäle ist ein LTSS-Vertrag erforderlich.

7.2.3.1 Ursprung der Pakete

Einführung von SUSE Linux Enterprise 11 SP3/SP4. Mit der Installation von SP3 stehen nur noch zwei Kanäle zur Verfügung: SLES11-SP3-Pool und SLES11-SP3-Updates. Alle vorherigen Kanäle aus SP2 sind sichtbar, jedoch nicht aktiviert. Diese deaktivierten Kanäle sind nur für Benutzer erforderlich, die besondere Anforderungen stellen.

7.2.3.2 Arbeiten mit Kanälen

Bei der Registrierung erhält das System Kanäle vom Customer Center. Die Kanalnamen sind bestimmten URIs im Customer Center zugeordnet (siehe http://scc.suse.com). Zum Auflisten aller verfügbaren Kanäle auf dem System geben Sie das folgende zypper-Kommando ein:

zypper repos -u

Hiermit erhalten Sie eine Liste aller verfügbaren Kanäle auf dem System. Für jeden Kanal werden der Alias und der Name aufgeführt, und es ist angegeben, ob der Kanal 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 Entfernen alter Kanäle (z. B. aus SP1) geben Sie das Kommando zypper removerepo und den Namen des oder der Kanäle ein. Mit dem folgenden Kommando entfernen Sie beispielsweise die alten Kanäle aus SP1 und SP2:

zypper removerepo SLES11-SP1-Pool SLES11-SP1-Updates \
  SLE11-SP1-Debuginfo-Pool SLE11-SP1-Debuginfo-Updates \
  SLES11-SP2-Core SLES11-SP2-Updates \
  SLE11-SP2-Debuginfo-Core SLES11-SP2-Extension-Store\
  SLE11-SP2-Debuginfo-Updates

Sollen einige Kanäle wieder hinzugefügt werden, melden Sie sich bei http://www.novell.com/ncc an und wählen Sie My Products (Meine Produkte) › Mirror Credentials (Berechtigungen spiegeln) im Menü. Eine Liste mit URIs wird angezeigt; Sie können nur Kanäle aus dieser Produktliste hinzufügen. Mit dem folgenden Kommando (in einer Zeile und ohne den umgekehrten Schrägstrich) fügen Sie beispielsweise den SP2 Extension Store hinzu:

zypper addrepo -n SLES11-SP2-Extension-Store \
 https://nu.novell.com/repo/$RCE/SLES11-SP2-Extension-Store/nu_novell_com:SLES11-SP2-Extension-Store

7.3 Unterstützte Aufrüstungspfade auf SLE SP4

Aufrüsten von SLES 8, SLES 9 und NLD 9

Für diese Versionen werden keine direkten Aufrüstungspfade unterstützt. Stattdessen wird eine Neuinstallation empfohlen.

Aufrüsten von SUSE Linux Enterprise 10 (mit beliebigem Service Pack)

Für die Aufrüstung von SLES 10 GA und SPx oder SLES 11 GA oder SP1 auf SLES 11 SP3 stehen mehrere Aufrüstungspfade zur Auswahl, für die ggf. zusätzliche Aufrüstungsschritte erforderlich sind:

  • SLES 10 GA -> SLES 10 SP1 -> SLES 10 SP2 -> SLES 10 SP3 -> SLES 10 SP4 -> SLES 11 SP3 oder

  • SLES 11 GA -> SLES 11 SP1 -> SLES 11 SP2 -> SLES 11 SP3 -> SLES 11 SP4

Die Aufrüstung von SLES 10 SP4 wird über bootfähige Medien (auch PXE-Boot) unterstützt. Weitere Informationen finden Sie in den Versionshinweisen unter https://www.suse.com/releasenotes/x86_64/SUSE-SLES/11-SP4/#Update.General.Sequence.

Wichtiger Hinweis für SLED-Benutzer: Einige devel-Pakete wurden vom SLED11-SP2-Installationsmedium in das Repository SLED11-Extras verschoben. Damit beim Aufrüsten keine Abhängigkeitskonflikte auftreten, aktualisieren Sie dieses Repository, bevor Sie die eigentliche Aufrüstung starten. Führen Sie yast2 repositories aus und aktivieren Sie dort den Eintrag SLED11-Extras. Unter SLES ist dieser zusätzliche Schritt nicht erforderlich.

Aufrüsten von SUSE Linux Enterprise 11 GA

Es gibt keinen unterstützten direkten Migrationspfad zu SUSE Linux Enterprise 11 SP3. Zunächst müssen Sie SUSE Linux Enterprise 11 GA auf SP1 aktualisieren. Fahren Sie dann mit Abschnitt 7.5, „Aktualisieren von SLE 11 SP1 auf SLE 11 SP2“ und Abschnitt 7.6, „Aktualisieren von SLE 11 SP2 auf SLE 11 SP3“ fort.

Aufrüsten von SUSE Linux Enterprise 11 SP1

Weitere Informationen finden Sie unter Abschnitt 7.5, „Aktualisieren von SLE 11 SP1 auf SLE 11 SP2“.

Aufrüsten von SUSE Linux Enterprise 11 SP2

Weitere Informationen finden Sie unter Abschnitt 7.6, „Aktualisieren von SLE 11 SP2 auf SLE 11 SP3“.

Aufrüsten von SUSE Linux Enterprise 11 SP3

Weitere Informationen finden Sie unter Abschnitt 7.7, „Aktualisieren von SLE 11 SP3 auf SLE 11 SP4“.

Wichtig
Wichtig: Architekturübergreifende Aufrüstungen werden nicht unterstützt

Architekturübergreifende Aufrüstungen (32 Bit auf 64 Bit bzw. 64 Bit auf 32 Bit) werden nicht unterstützt.

7.4 Allgemeine Vorbereitungen für die Aktualisierung

Vor Beginn der Aktualisierung muss das System ordnungsgemäß vorbereitet werden. Zur Vorbereitung gehören unter anderem das Sichern der Daten und das Lesen der Versionshinweise.

7.4.1 Anlegen einer Sicherungskopie

Kopieren Sie die bestehenden Konfigurationsdateien vor der Aktualisierung auf ein separates Medium (wie ein Bandlaufwerk oder eine externe Festplatte), um die Daten zu sichern. Dies gilt hauptsächlich für die in /etc gespeicherten Dateien sowie einige der 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 Leseberechtigung für alle lokalen Dateien.

Wenn Sie in YaST den Installationsmodus Vorhandenes System aktualisieren ausgewählt haben, können Sie später wahlweise eine (System-)Sicherung ausführen. Sie können alle geänderten Dateien und die Dateien aus dem Verzeichnis /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.

7.4.2 Partitionierung und Festplattenspeicher

Notieren Sie sich vor der Aktualisierung die Root-Partition. Mit dem Befehl df / können Sie den Gerätenamen der Root-Partition anzeigen. In Beispiel 7.1, „Über df -h angezeigte Liste“ ist /dev/sda3 die Root-Partition, die Sie sich notieren sollten (eingehängt als /).

Beispiel 7.1: Über 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       44G    4G   40G   9% /data

Software weist normalerweise von Version zu Version mehr Umfang auf. Folglich sollten Sie vor dem Aktualisieren mit df den verfügbaren Partitionsspeicher überprüfen. Wenn Sie befürchten, dass demnächst kein Speicherplatz mehr zur Verfügung steht, sichern Sie die Daten vor der Aktualisierung und partitionieren Sie Ihr System neu. Es gibt keine Faustregel hinsichtlich des Speicherplatzes einzelner Partitionen. Die Platzanforderungen hängen von Ihrem bestimmten Partitionsprofil und von der ausgewählten Software ab.

7.4.3 Virtuelle Computer herunterfahren

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.

7.4.4 Versionsspezifische Anforderungen

Die versionsspezifischen Anforderungen finden Sie in den Versionshinweisen, die der Aktualisierung beiliegen. Dort finden Sie auch weitere Informationen zum Aktualisierungsverfahren.

Die aktuelle Fassung der Versionshinweise mit den neuesten Informationen zu SUSE Linux Enterprise Server finden Sie online unter http://www.suse.com/doc/sles11/#additional.

7.5 Aktualisieren von SLE 11 SP1 auf SLE 11 SP2

Es werden verschiedene Methoden zur Aktualisierung eines Systems mit SUSE Linux Enterprise 11 SP1 auf Service Pack 2 unterstützt. Sie können wahlweise die erforderlichen Patches mit den Online-Aktualisierungswerkzeugen installieren (Online-Migration) oder die Aktualisierung über das Service Pack-Installationsmedium durchführen. Darüber hinaus lassen sich die Aktualisierungen über Server vornehmen, auf denen die Abonnementverwaltung oder SUSE Manager gehostet wird.

Die Online-Migration wird durch die folgenden Werkzeuge unterstützt:

  • YaST Wagon (grafische Bedienoberfläche)

  • zypper (Kommandozeile)

Alternativ können Sie das vollständige Service Pack-Medium (DVD-ISO-Image) herunterladen. Zum Starten der Aktualisierung booten Sie das System vom physischen Service Pack-Medium oder von einer Installationsquelle im Netzwerk.

7.5.1 Online-Migration

Die Aktualisierung des Systems mit der Online-Migration erfolgt aus dem laufenden System heraus. Sie müssen das System nur einmal nach Abschluss der Aktualisierung neu starten.

7.5.1.1 Anforderungen

Für eine Online-Aktualisierung gelten die nachstehenden Anforderungen. Beachten Sie auch Abschnitt 7.4, „Allgemeine Vorbereitungen für die Aktualisierung“.

Produktregistrierung

Um eine Verbindung mit den Aktualisierungskanälen herstellen zu können, muss Ihr Produkt registriert sein. Ist dies nicht der Fall, starten Sie die Registrierung entweder mit dem Modul Novell Customer Center-Konfiguration in YaST oder mit dem Kommandozeilenwerkzeug suse_register.

Durchführung eines Online-Updates

Überprüfen Sie, ob die aktuellen Patches für die zurzeit installierte Version installiert sind. Führen Sie vor der Online-Migration zunächst ein Online-Update aus. Wenn Sie eine grafische Bedienoberfläche nutzen, starten Sie das YaST-Online-Update oder das Aktualisierungs-Miniprogramm. Führen Sie in der Kommandozeile die folgenden Kommandos aus (das letzte Kommando muss zweimal ausgeführt werden):

zypper ref -s
zypper update -t patch
zypper update -t patch

Booten Sie das System bei Bedarf neu.

Unter Kapitel 1, YaST-Online-Aktualisierung oder Abschnitt 6.1.3, „Aktualisieren von Software mit zypper“ finden Sie weitere Informationen zu den Online-Update-Werkzeugen.

Software von Drittanbietern

Wenn Ihr Setup Drittanbieter-Software oder Zusatzsoftware umfasst, sollten Sie dieses Verfahren auf einem anderen Rechner testen, um sicherzustellen, dass beim Update alle Abhängigkeiten erhalten bleiben.

Wichtig
Wichtig: Vollständige Ausführung der Online-Migration wichtig

Die Online-Migration muss stets von Anfang bis Ende ausgeführt werden. Wird eine laufende Online-Migration unterbrochen, so wird die Software des Systems unwiederbringlich beschädigt.

7.5.1.2 Online-Migration mit YaST Wagon

Die erforderlichen Schritte für ein SLES 11 SP1-System finden Sie unter https://www.suse.com/support/kb/doc.php?id=7011872. Das nachfolgende Verfahren gilt für die Online-Migration von SP2 zu SP3.

  1. Wenn alle Anforderungen erfüllt sind (siehe Abschnitt 7.5.1.1, „Anforderungen“), zeigt das Aktualisierungs-Miniprogramm in der Kontrollleiste eine Meldung an, dass eine Aufrüstung für die Distribution verfügbar ist. Klicken Sie darauf, um YaST Wagon zu starten. Alternativ führen Sie /usr/sbin/wagon als root in der Kommandozeile aus.

  2. Bestätigen Sie das Dialogfeld Willkommen mit Weiter.

  3. Wenn Wagon feststellt, dass die Anforderungen nicht erfüllt sind (erforderliche Wartungs-Aktualisierungen sind verfügbar, jedoch noch nicht installiert), wird automatisch eine Selbstaktualisierung gestartet, und Sie müssen das System unter Umständen neu booten. Befolgen Sie die Anweisungen auf dem Bildschirm.

  4. Wählen Sie im nachfolgenden Dialogfeld die Aktualisierungsmethode aus. Mit Customer Center verwenden Sie die Standardeinrichtung (empfohlen).

    Klicken Sie auf Benutzerdefinierte URL und wählen Sie die Software-Kanäle für die Online-Migration aus. Eine Liste der Kanäle wird angezeigt, in der Sie die Kanäle je nach Bedarf manuell aktivieren, deaktivieren, hinzufügen und löschen können. Fügen Sie die Aktualisierungsquelle(n) für SP2 hinzu. Dies sind wahlweise das SP2-Installationsmedium oder die Kanäle SP2-Core und SP2-Updates. Durch Klicken auf OK gelangen Sie zurück zum Dialogfeld Aktualisierungsmodus.

    Zum Prüfen der Änderungen, die im Rahmen des Aktualisierungsvorgangs erfolgt sind, wählen Sie Automatische Repository-Änderungen überprüfen.

    Fahren Sie mit Weiter fort.

  5. Das System wird erneut registriert. Während des Vorgangs werden die Kanäle SP2-Core und SP2-Updates dem System hinzugefügt (weitere Informationen siehe Abschnitt 7.2.3, „Kanalmodell“). Bestätigen Sie das Hinzufügen der Kanäle.

  6. Wenn Sie im Dialogfeld Aktualisierungsmodus die Option Automatische Repository-Änderungen überprüfen ausgewählt haben, wird die Liste der Repositorys angezeigt, und Sie können Kanäle manuell aktivieren, deaktivieren, hinzufügen oder löschen. Klicken Sie abschließend auf OK.

  7. Wählen Sie den Migrationstyp aus:

    Full migration (Vollständige Migration)

    Aktualisiert alle Pakete auf den aktuellen SP2-Stand.

    Minimal Migration (Minimale Migration)

    Aktualisiert eine minimale Gruppe von Paketen auf den aktuellen SP2-Stand.

    Mit Erweitert wählen Sie die Repositorys für die Aufrüstung manuell aus.

    Bestätigen Sie Ihre Auswahl.

  8. Der Bildschirm Einstellungen für Distributionsaktualisierung wird geöffnet. Hier sehen Sie eine Zusammenfassung der Aktualisierungskonfiguration. Die folgenden Abschnitte stehen zur Verfügung:

    Add-on-Produkte

    Sie können Add-on-Produkte zu SUSE Linux Enterprise Server oder Drittanbieterprodukte hier hinzufügen.

    Optionen für das Update

    Liste der Aktionen, die im Rahmen der Aktualisierung ausgeführt werden. Sie können festlegen, ob zunächst alle Pakete heruntergeladen und dann im Ganzen installiert werden sollen (Standardeinstellung, empfohlen) oder ob sie einzeln nacheinander heruntergeladen und installiert werden sollen.

    Pakete

    Statistischer Überblick über die Aktualisierung.

    Sicherung

    Legen Sie die Optionen für die Sicherung fest.

    Klicken Sie zum Fortfahren auf Weiter und dann auf Start The Update (Aktualisierung starten).

    Wichtig
    Wichtig: Abbrechen der Online-Migration

    Auf diesem Bildschirm sowie auf allen vorhergehenden Bildschirmen können Sie die Online-Migration schadlos abbrechen, bevor Sie auf Start The Update (Aktualisierung starten) klicken. Mit Abbrechen können Sie den Aktualisierungsvorgang verlassen und das System in dem Zustand wiederherstellen, den es vor dem Starten von YaST Wagon aufwies. Befolgen Sie die Anweisungen auf dem Bildschirm und führen Sie die Registrierung erneut aus, bevor Sie Wagon beenden, damit die SP2-Kanäle vom System entfernt werden.

  9. Während des Aktualisierungsvorgangs werden die folgenden Schritte ausgeführt:

    1. Die Pakete werden aktualisiert.

    2. SuSEconfig wird ausgeführt.

    3. Das System wird neu gebootet (klicken Sie auf OK).

    4. Das soeben aktualisierte System wird erneut registriert.

  10. Das System wurde erfolgreich auf Service Pack 2 aktualisiert.

7.5.1.3 Online-Migration mit zypper

  1. Wenn alle Anforderungen erfüllt sind (siehe Abschnitt 7.5.1.1, „Anforderungen“), wurden die erforderlichen Produkte für die Online-Migration in /etc/products.d eingefügt. Mit dem folgenden Kommando erhalten Sie eine Liste dieser Produkte:

    zypper se -t product | grep -h -- "-migration" | cut -d'|' -f2

    Dieses Kommando sollte zumindest SUSE_SLES-SP2-migration zurückgeben. Je nach Umfang der Installation werden weitere Produkte aufgelistet.

  2. Installieren Sie die Migrationsprodukte, die Sie mit dem vorherigen Schritt abgerufen haben, mit dem Kommando zypper in -t product LIST_OF_PRODUCTS, beispielsweise

    zypper in -t product SUSE_SLES-SP2-migration
  3. Registrieren Sie die Produkte, die Sie mit dem vorherigen Schritt installiert haben, damit die zugehörigen Aktualisierungskanäle verfügbar werden:

    suse_register -d 2 -L /root/.suse_register.log
  4. Aktualisieren Sie die Repositorys und Services erneut:

    zypper ref -s
  5. Prüfen Sie die Liste der abrufbaren Repositorys mit zypper lr. Mindestens die folgenden Repositorys müssen aktiviert sein:

    • SLES11-SP1-Pool

    • SLES11-SP1-Updates

    • SLES11-SP2-Core

    • SLES11-SP2-Updates

    Je nach Umfang der Installation müssen weitere Repositorys für Add-On-Produkte oder Erweiterungen aktiviert werden.

    Falls eines dieser Repositorys nicht aktiviert ist (die SP2-Repositorys werden mit diesem Verfahren nicht standardmäßig aktiviert), aktivieren Sie es mit zypper modifyrepo --enable REPOSITORY ALIAS, beispielsweise:

    zypper modifyrepo --enable SLES11-SP2-Core SLES11-SP2-Updates

    Enthält die Konfiguration Drittanbieter-Repositorys, die nicht mit SP2 kompatibel sind, deaktivieren Sie die betreffenden Repositorys mit zypper modifyrepo --disable REPOSITORY ALIAS.

  6. Damit ist die Vorbereitung abgeschlossen, und Sie können die Distribution mit zypper dup --from REPO 1 --from REPO 2 ... aktualisieren. Führen Sie dabei in jedem Fall alle erforderlichen Repositorys mit --from auf, beispielsweise:

    zypper dup --from SLES11-SP2-Core --from SLES11-SP2-Updates

    Bestätigen Sie mit y. Die Aufrüstung wird gestartet.

  7. Nach der Aufrüstung der Distribution mit dem vorherigen Schritt ist die minimale Migration abgeschlossen (eine minimale Teilmenge der Pakete wurde auf den aktuellen SP2-Stand aktualisiert). Überspringen Sie diesen Schritt, wenn keine vollständige Migration ausgeführt werden soll.

    Für eine vollständige Migration (alle Pakete werden auf den aktuellen SP2-Stand aktualisiert) führen Sie das folgende Kommando aus:

    zypper update -t patch
  8. Damit ist die Aufrüstung auf SP2 abgeschlossen. Registrieren Sie nun das Produkt erneut:

    suse_register -d 2 -L /root/.suse_register.log
  9. Booten Sie abschließend das System neu.

  10. Das System wurde erfolgreich auf Service Pack 2 aktualisiert.

7.5.2 Aktualisierung durch Booten von einer Installationsquelle

Als Alternative zur Online-Migration (weitere Informationen finden Sie unter Abschnitt 7.5.1, „Online-Migration“) können Sie Ihr System auch von einer Installationsquelle booten, also von einer DVD oder einer Netzwerkinstallationsquelle. Die Aktualisierung beginnt wie eine normale Installation.

Die ISO-Images für Service Pack 2 sind bei http://download.novell.com/ erhältlich. Brennen Sie die Images auf eine DVD, oder bereiten Sie eine Netzwerkinstallationsquelle gemäß Abschnitt 14.2, „Einrichten des Servers, auf dem sich die Installationsquellen befinden“ vor.

7.5.2.1 Aktualisieren von einem lokalen DVD-Laufwerk

Vor Beginn einer neuen Installation eines SUSE Linux Enterprise-SP müssen Sie sicherstellen, dass alle Service Pack-Installationsmedien (DVDs) verfügbar sind.

Prozedur 7.1: Booten vom Service Pack-Medium
  1. Legen Sie das erste SUSE Linux Enterprise-SP-Medium ein und booten Sie Ihren Rechner. Ein ähnlicher Startbildschirm wie bei der ursprünglichen Installation von SUSE Linux Enterprise 11 wird angezeigt.

  2. Wählen Sie Installation und fahren Sie dann gemäß den YaST-Installationsanweisungen in Kapitel 6, Installation mit YaST fort.

7.5.2.2 Aktualisieren von einer Netzwerkinstallationsquelle

Vor der Aktualisierung eines SUSE Linux Enterprise-SP über eine Netzwerkinstallationsquelle müssen die folgenden Anforderungen erfüllt sein:

Detaillierte Informationen zum Starten der Aufrüstung von einem Remote-Server finden Sie unter Kapitel 14, Installation mit entferntem Zugriff.

7.5.2.2.1 Netzwerkinstallation – Booten von DVD

Gehen Sie zum Ausführen einer Netzwerkinstallation mit der SP-DVD als Bootdatenträger wie folgt vor:

  1. Legen Sie die SUSE Linux Enterprise-SP-DVD 1 ein und booten Sie Ihren Rechner. Ein ähnlicher Startbildschirm wie bei der ursprünglichen Installation von SUSE Linux Enterprise 11 wird angezeigt.

  2. Wählen Sie Installation, um den SP-Kernel zu booten, und drücken Sie dann die Taste F4, um den Typ der Netzwerkinstallationsquelle auszuwählen (FTP, HTTP, NFS oder SMB).

  3. Geben Sie die entsprechenden Pfadinformationen ein oder wählen Sie SLP als Installationsquelle.

  4. Wählen Sie den entsprechenden Installationsserver aus den angebotenen aus oder geben Sie den Typ der Installationsquelle und deren Standort bei der Aufforderung der Bootoptionen an, wie unter Abschnitt 6.1.2, „Installieren von einer Netzwerkquelle ohne SLP“ beschrieben. YaST wird gestartet.

    Schließen Sie die Installation ab, wie in Abschnitt 7.5.2.3, „Der Aktualisierungsvorgang“ beschrieben.

7.5.2.2.2 Netzwerkinstallation – PXE-Boot

Gehen Sie zum Ausführen einer Netzwerkinstallation eines SUSE Linux Enterprise-Service Packs über das Netzwerk wie folgt vor:

  1. Passen Sie den Setup Ihres DHCP-Servers an, um die für den PXE-Boot erforderlichen Adresseninformationen anzugeben, gemäß Abschnitt 14.3.5, „Vorbereiten des Zielsystems für PXE-Boot“.

  2. Richten Sie einen TFTP-Server ein, der das Boot-Image für den PXE-Boot beinhaltet.

    Verwenden Sie die erste CD oder DVD Ihres SUSE Linux Enterprise-Service Packs dafür oder folgen Sie den Anweisungen in Abschnitt 14.3.2, „Einrichten eines TFTP-Servers“.

  3. Bereiten Sie den PXE-Boot und Wake-on-LAN auf dem Zielcomputer vor.

  4. Starten Sie den Boot des Zielsystems und verwenden Sie VNC, um sich entfernt mit der auf diesem Computer ausgeführten Installationsroutine zu verbinden. Weitere Informationen finden Sie unter Abschnitt 14.5.1, „VNC-Installation“.

  5. Schließen Sie die Installation ab, wie in Abschnitt 7.5.2.3, „Der Aktualisierungsvorgang“ beschrieben.

7.5.2.3 Der Aktualisierungsvorgang

Nach dem Booten vom Installationsmedium oder vom Netzwerk starten Sie die Aktualisierung wie folgt:

  1. Wählen Sie im Bildschirm Willkommen die Sprache und die Belegung der Tastatur aus, und nehmen Sie die Lizenzvereinbarung an. Fahren Sie mit Weiter fort.

  2. Wenn Sie von einem physischen Medium gebootet haben, prüfen Sie die Integrität des Mediums mit der Medienprüfung. Überspringen Sie diesen Schritt nur dann, wenn Sie das Medium bereits zuvor geprüft hatten.

  3. Wählen Sie im Bildschirm Installationsmodus die Option Aktualisieren. Klicken Sie auf Weiter. Der Aktualisierungsvorgang wird gestartet.

7.5.3 Aktualisieren über das Subscription Management Tool (SMT)

Als Alternative zum Herunterladen der Aktualisierungen vom Novell-Aktualisierungsserver für jedes einzelne Client-System können Sie die Aktualisierungen mit dem Subscription Management Tool (SMT) für SUSE Linux Enterprise auf einen lokalen Server spiegeln.

Dieses Werkzeug fungiert als Novell Customer Center-Proxy für Client-Registrierungen und als Software-Aktualisierungs-Repository. In der Dokumentation zu SMT unter http://www.suse.com/doc/smt11/ finden Sie einen Überblick über die Funktionen sowie Anweisungen zur Implementierung.

7.5.4 Aktualisieren über SUSE Manager

SUSE Manager ist eine Serverlösung für die Bereitstellung von Aktualisierungen, Patches und Sicherheitsreparaturen für SUSE Linux Enterprise-Clients. Hier finden Sie eine Reihe von Werkzeugen und eine webgestützte Bedienoberfläche für Verwaltungsaufgaben.

In der Dokumentation zu SUSE Manager unter http://www.suse.com/doc/suse_manager/ finden Sie einen Überblick über die Funktionen sowie Anweisungen zum Einrichten des Servers und der Clients.

7.6 Aktualisieren von SLE 11 SP2 auf SLE 11 SP3

Die Online-Migration wird durch die folgenden Werkzeuge unterstützt:

  • YaST Wagon (grafische Bedienoberfläche)

  • zypper (Kommandozeile)

Wenn Sie das System mit der Online-Migration aktualisieren, so wird die Aktualisierung bei laufendem System ausgeführt. Sie müssen das System nur einmal nach Abschluss der Aktualisierung neu starten. Sie können die Aktualisierung auch nach wie vor mit den folgenden Alternativen vornehmen:

7.6.1 Anforderungen

Für eine Online-Aktualisierung gelten die nachstehenden Anforderungen. Beachten Sie auch Abschnitt 7.4, „Allgemeine Vorbereitungen für die Aktualisierung“.

Produktregistrierung

Um eine Verbindung mit den Aktualisierungskanälen herstellen zu können, muss Ihr Produkt registriert sein. Ist dies nicht der Fall, starten Sie die Registrierung entweder mit dem Modul Novell Customer Center-Konfiguration in YaST oder mit dem Kommandozeilenwerkzeug suse_register.

Durchführung eines Online-Updates

Überprüfen Sie, ob die aktuellen Patches für die zurzeit installierte Version installiert sind. Führen Sie vor der Online-Migration zunächst ein Online-Update aus. Wenn Sie eine grafische Bedienoberfläche nutzen, starten Sie das YaST-Online-Update oder das Aktualisierungs-Miniprogramm. Führen Sie in der Kommandozeile die folgenden Kommandos aus (das letzte Kommando muss zweimal ausgeführt werden):

zypper ref -s
zypper update -t patch
zypper update -t patch

Booten Sie das System bei Bedarf neu.

Weitere Informationen zu den Werkzeugen für die Online-Aktualisierung finden Sie unter Kapitel 1, YaST-Online-Aktualisierung oder Abschnitt 6.1.3, „Aktualisieren von Software mit zypper“.

Software von Drittanbietern

Wenn Ihr Setup Drittanbieter-Software oder Zusatzsoftware umfasst, sollten Sie dieses Verfahren auf einem anderen Rechner testen, um sicherzustellen, dass beim Update alle Abhängigkeiten erhalten bleiben.

Wichtig
Wichtig: Vollständige Ausführung der Online-Migration wichtig

Die Online-Migration muss stets von Anfang bis Ende ausgeführt werden. Wird eine laufende Online-Migration unterbrochen, so wird die Software des Systems unwiederbringlich beschädigt.

7.6.2 Online-Migration mit YaST Wagon

  1. Wenn alle Anforderungen erfüllt sind (siehe Abschnitt 7.5.1.1, „Anforderungen“), zeigt das Aktualisierungs-Miniprogramm in der Kontrollleiste eine Meldung an, dass eine Aufrüstung für die Distribution verfügbar ist. Klicken Sie darauf, um YaST Wagon zu starten. Alternativ führen Sie /usr/sbin/wagon als root in der Kommandozeile aus.

  2. Bestätigen Sie das Dialogfeld Willkommen mit Weiter.

  3. Wenn Wagon feststellt, dass die Anforerungen nicht erfüllt sind (erforderliche Wartungs-Aktualisierungen sind verfügbar, jedoch noch nicht installiert), wird automatisch eine Selbstaktualisierung gestartet, und Sie müssen das System unter Umständen neu booten. Befolgen Sie die Anweisungen auf dem Bildschirm.

  4. Wählen Sie im nachfolgenden Dialogfeld die Aktualisierungsmethode aus. Mit Customer Center verwenden Sie die Standardeinrichtung (empfohlen).

    Klicken Sie auf Benutzerdefinierte URL und wählen Sie die Software-Kanäle für die Online-Migration aus. Eine Liste der Kanäle wird angezeigt, in der Sie die Kanäle je nach Bedarf manuell aktivieren, deaktivieren, hinzufügen und löschen können. Fügen Sie die Aktualisierungsquelle(n) für SP3 hinzu. Dies sind wahlweise das SP3-Installationsmedium oder die Kanäle SP3-Pool und SP3-Updates. Durch Klicken auf OK gelangen Sie zurück zum Dialogfeld Aktualisierungsmodus.

    Zum Prüfen der Änderungen, die im Rahmen des Aktualisierungsvorgangs erfolgt sind, wählen Sie Automatische Repository-Änderungen überprüfen.

    Fahren Sie mit Weiter fort.

  5. Das System wird erneut registriert. Während des Vorgangs werden die Kanäle SP3-Pool und SP3-Updates dem System hinzugefügt (weitere Informationen siehe Abschnitt 7.2.3, „Kanalmodell“). Bestätigen Sie das Hinzufügen der Kanäle.

  6. Wenn Sie im Dialogfeld Aktualisierungsmodus die Option Automatische Repository-Änderungen überprüfen ausgewählt haben, wird die Liste der Repositorys angezeigt, und Sie können Kanäle manuell aktivieren, deaktivieren, hinzufügen oder löschen. Klicken Sie abschließend auf OK.

  7. Der Bildschirm Einstellungen für Distributionsaktualisierung wird geöffnet. Hier sehen Sie eine Zusammenfassung der Aktualisierungskonfiguration. Die folgenden Abschnitte stehen zur Verfügung:

    Add-on-Produkte

    Sie können Add-on-Produkte zu SUSE Linux Enterprise Server oder Drittanbieterprodukte hier hinzufügen.

    Optionen für das Update

    Liste der Aktionen, die im Rahmen der Aktualisierung ausgeführt werden. Sie können festlegen, ob zunächst alle Pakete heruntergeladen und dann im Ganzen installiert werden sollen (Standardeinstellung, empfohlen) oder ob sie einzeln nacheinander heruntergeladen und installiert werden sollen.

    Pakete

    Statistischer Überblick über die Aktualisierung.

    Sicherung

    Legen Sie die Optionen für die Sicherung fest.

    Klicken Sie zum Fortfahren auf Weiter und dann auf Start The Update (Aktualisierung starten).

    Wichtig
    Wichtig: Abbrechen der Online-Migration

    Auf diesem Bildschirm sowie auf allen vorhergehenden Bildschirmen können Sie die Online-Migration schadlos abbrechen, bevor Sie auf Start The Update (Aktualisierung starten) klicken. Mit Abbrechen können Sie den Aktualisierungsvorgang verlassen und das System in dem Zustand wiederherstellen, den es vor dem Starten von YaST Wagon aufwies. Befolgen Sie die Anweisungen auf dem Bildschirm und führen Sie die Registrierung erneut aus, bevor Sie Wagon beenden, damit die SP2-Kanäle vom System entfernt werden.

  8. Während des Aktualisierungsvorgangs werden die folgenden Schritte ausgeführt:

    1. Die Pakete werden aktualisiert.

    2. SuSEconfig wird ausgeführt.

    3. Das System wird neu gebootet (klicken Sie auf OK).

    4. Das soeben aktualisierte System wird erneut registriert.

  9. Das System wurde erfolgreich auf Service Pack 3 aktualisiert.

7.6.3 Online-Migration mit zypper

  1. Wenn alle Anforderungen erfüllt sind (siehe Abschnitt 7.5.1.1, „Anforderungen“), wurden die erforderlichen Produkte für die Online-Migration in /etc/products.d eingefügt. Mit dem folgenden Kommando erhalten Sie eine Liste dieser Produkte:

    zypper se -t product | grep -h -- "-migration" | cut -d'|' -f2

    Dieses Kommando sollte zumindest SUSE_SLES-SP3-migration zurückgeben. Je nach Umfang der Installation werden weitere Produkte aufgelistet.

  2. Installieren Sie die Migrationsprodukte, die Sie mit dem vorherigen Schritt abgerufen haben, mit dem Kommando zypper in -t product LIST_OF_PRODUCTS, beispielsweise

    zypper in -t product SUSE_SLES-SP3-migration
  3. Registrieren Sie die Produkte, die Sie mit dem vorherigen Schritt installiert haben, damit die zugehörigen Aktualisierungskanäle verfügbar werden:

    suse_register -d 2 -L /root/.suse_register.log
  4. Aktualisieren Sie die Repositorys und Services:

    zypper ref -s
  5. Prüfen Sie die Liste der abrufbaren Repositorys mit zypper lr.

    Falls eines dieser Repositorys nicht aktiviert ist (die SP3-Repositorys werden mit diesem Verfahren nicht standardmäßig aktiviert), aktivieren Sie es mit zypper modifyrepo --enable REPOSITORY ALIAS, beispielsweise:

    zypper modifyrepo --enable SLES11-SP3-Core SLES11-SP3-Updates

    Enthält die Konfiguration Drittanbieter-Repositorys, die nicht mit SP3 kompatibel sind, deaktivieren Sie die betreffenden Repositorys mit zypper modifyrepo --disable REPOSITORY ALIAS.

  6. Damit ist die Vorbereitung abgeschlossen, und Sie können die Distribution mit zypper dup --from REPO 1 --from REPO 2 ... aktualisieren. Führen Sie dabei in jedem Fall alle erforderlichen Repositorys mit --from auf, beispielsweise:

    zypper dup --from SLES11-SP3-Pool --from SLES11-SP3-Updates

    Bestätigen Sie mit y. Die Aufrüstung wird gestartet.

  7. Nach der Aufrüstung der Distribution mit dem vorherigen Schritt führen Sie das folgende Kommando aus:

    zypper update -t patch
  8. Damit ist die Aufrüstung auf SP3 abgeschlossen. Registrieren Sie nun das Produkt erneut:

    suse_register -d 2 -L /root/.suse_register.log
  9. Booten Sie abschließend das System neu.

  10. Das System wurde erfolgreich auf Service Pack 3 aktualisiert.

7.7 Aktualisieren von SLE 11 SP3 auf SLE 11 SP4

Es werden verschiedene Methoden zur Aktualisierung eines Systems mit SUSE Linux Enterprise Server 11 SP3 auf Service Pack 4 unterstützt. Sie können wahlweise die erforderlichen Patches mit den Online-Aktualisierungswerkzeugen installieren (Online-Migration) oder die Aktualisierung über das Service Pack-Installationsmedium durchführen. Darüber hinaus lassen sich die Aktualisierungen über Server vornehmen, auf denen die Abonnementverwaltung (SMT) oder SUSE Manager gehostet wird.

Die Online-Migration wird durch die folgenden Werkzeuge unterstützt:

  • YaST Wagon (grafische Bedienoberfläche)

  • zypper (Kommandozeile)

Alternativ können Sie das vollständige Service Pack-Medium (DVD-ISO-Image) herunterladen. Zum Starten der Aktualisierung booten Sie das System vom physischen Service Pack-Medium oder von einer Installationsquelle im Netzwerk.

7.7.1 Online-Migration

Die Aktualisierung des Systems mit der Online-Migration erfolgt aus dem laufenden System heraus. Sie müssen das System nur einmal nach Abschluss der Aktualisierung neu starten.

7.7.1.1 Anforderungen

Für eine Online-Aktualisierung gelten die nachstehenden Anforderungen. Beachten Sie auch Abschnitt 7.4, „Allgemeine Vorbereitungen für die Aktualisierung“.

Produktregistrierung

Um eine Verbindung mit den Aktualisierungskanälen herstellen zu können, muss Ihr Produkt registriert sein. Ist dies nicht der Fall, starten Sie die Registrierung entweder mit dem Modul Novell Customer Center-Konfiguration in YaST oder mit dem Kommandozeilenwerkzeug suse_register.

Durchführung eines Online-Updates

Überprüfen Sie, ob die aktuellen Patches für die zurzeit installierte Version installiert sind. Führen Sie vor der Online-Migration zunächst ein Online-Update aus. Wenn Sie eine grafische Bedienoberfläche nutzen, starten Sie das YaST-Online-Update oder das Aktualisierungs-Miniprogramm. Führen Sie in der Kommandozeile die folgenden Kommandos aus (das letzte Kommando muss zweimal ausgeführt werden):

zypper ref -s
zypper update -t patch
zypper update -t patch

Booten Sie das System bei Bedarf neu.

Siehe Abschnitt 1.0, YaST-Online-Aktualisierung (↑Administrationshandbuch), oder Abschnitt 6.1.3, Aktualisieren von Software mit Zypper (↑Administrationshandbuch). finden Sie weitere Informationen zu den Online-Update-Werkzeugen.

Software von Drittanbietern

Wenn Ihr Setup Drittanbieter-Software oder Zusatzsoftware umfasst, sollten Sie dieses Verfahren auf einem anderen Rechner testen, um sicherzustellen, dass beim Update alle Abhängigkeiten erhalten bleiben.

Wichtig
Wichtig: Vollständige Ausführung der Online-Migration wichtig

Die Online-Migration muss stets von Anfang bis Ende ausgeführt werden. Wird eine laufende Online-Migration unterbrochen, so wird die Software des Systems unwiederbringlich beschädigt.

7.7.1.2 Online-Migration mit YaST Wagon

Die erforderlichen Schritte für ein SLES 11 SP1-System finden Sie unter https://www.suse.com/support/kb/doc.php?id=7011872. Das nachfolgende Verfahren gilt für die Online-Migration von SP3 zu SP4.

  1. Wenn alle Anforderungen erfüllt sind (siehe Abschnitt 7.5.1.1, „Anforderungen“), zeigt das Aktualisierungs-Miniprogramm in der Kontrollleiste eine Meldung an, dass eine Aufrüstung für die Distribution verfügbar ist. Klicken Sie darauf, um YaST Wagon zu starten. Alternativ führen Sie /usr/sbin/wagon als root in der Kommandozeile aus.

  2. Bestätigen Sie das Dialogfeld Willkommen mit Weiter.

  3. Wenn Wagon feststellt, dass die Anforerungen nicht erfüllt sind (erforderliche Wartungs-Aktualisierungen sind verfügbar, jedoch noch nicht installiert), wird automatisch eine Selbstaktualisierung gestartet, und Sie müssen das System unter Umständen neu booten. Befolgen Sie die Anweisungen auf dem Bildschirm.

  4. Wählen Sie im nachfolgenden Dialogfeld die Aktualisierungsmethode aus. Mit Customer Center verwenden Sie die Standardeinrichtung (empfohlen).

    Klicken Sie auf Benutzerdefinierte URL und wählen Sie die Software-Kanäle für die Online-Migration aus. Eine Liste der Kanäle wird angezeigt, in der Sie die Kanäle je nach Bedarf manuell aktivieren, deaktivieren, hinzufügen und löschen können. Fügen Sie die Aktualisierungsquelle(n) für SP4 hinzu. Dies sind wahlweise das SP4-Installationsmedium oder die Kanäle SP4-Pool und SP4-Updates. Durch Klicken auf OK gelangen Sie zurück zum Dialogfeld Aktualisierungsmodus.

    Zum Prüfen der Änderungen, die im Rahmen des Aktualisierungsvorgangs erfolgt sind, wählen Sie Automatische Repository-Änderungen überprüfen.

    Fahren Sie mit Weiter fort.

  5. Das System wird erneut registriert. Während des Vorgangs werden die Kanäle SP4-Pool und SP4-Updates dem System hinzugefügt (weitere Informationen siehe Abschnitt 7.2.3, „Kanalmodell“). Bestätigen Sie das Hinzufügen der Kanäle.

  6. Wenn Sie im Dialogfeld Aktualisierungsmodus die Option Automatische Repository-Änderungen überprüfen ausgewählt haben, wird die Liste der Repositorys angezeigt, und Sie können Kanäle manuell aktivieren, deaktivieren, hinzufügen oder löschen. Klicken Sie abschließend auf OK.

  7. Wählen Sie den Migrationstyp aus:

    Full migration (Vollständige Migration)

    Aktualisiert alle Pakete auf den aktuellen SP4-Stand.

    Minimal Migration (Minimale Migration)

    Aktualisiert eine minimale Gruppe von Paketen auf den aktuellen SP4-Stand.

    Mit Erweitert wählen Sie die Repositorys für die Aufrüstung manuell aus. Bestätigen Sie Ihre Auswahl.

  8. Der Bildschirm Einstellungen für Distributionsaktualisierung wird geöffnet. Hier sehen Sie eine Zusammenfassung der Aktualisierungskonfiguration. Die folgenden Abschnitte stehen zur Verfügung:

    Add-on-Produkte

    Sie können Add-on-Produkte zu SUSE Linux Enterprise Server oder Drittanbieterprodukte hier hinzufügen.

    Optionen für das Update

    Liste der Aktionen, die im Rahmen der Aktualisierung ausgeführt werden. Sie können festlegen, ob zunächst alle Pakete heruntergeladen und dann im Ganzen installiert werden sollen (Standardeinstellung, empfohlen) oder ob sie einzeln nacheinander heruntergeladen und installiert werden sollen.

    Pakete

    Statistischer Überblick über die Aktualisierung.

    Sicherung

    Legen Sie die Optionen für die Sicherung fest.

    Klicken Sie zum Fortfahren auf Weiter und dann auf Start The Update (Aktualisierung starten).

    Wichtig
    Wichtig: Abbrechen der Online-Migration

    Auf diesem Bildschirm sowie auf allen vorhergehenden Bildschirmen können Sie die Online-Migration schadlos abbrechen, bevor Sie auf Start The Update (Aktualisierung starten) klicken. Mit Abbrechen können Sie den Aktualisierungsvorgang verlassen und das System in dem Zustand wiederherstellen, den es vor dem Starten von YaST Wagon aufwies. Befolgen Sie die Anweisungen auf dem Bildschirm und führen Sie die Registrierung erneut aus, bevor Sie Wagon beenden, damit die SP4-Kanäle vom System entfernt werden.

  9. Während des Aktualisierungsvorgangs werden die folgenden Schritte ausgeführt:

    1. Die Pakete werden aktualisiert.

    2. SuSEconfig wird ausgeführt.

    3. Das System wird neu gebootet (klicken Sie auf OK).

    4. Das soeben aktualisierte System wird erneut registriert.

  10. Das System wurde erfolgreich auf Service Pack 4 aktualisiert.

7.7.1.3 Online-Migration mit zypper

  1. Wenn alle Anforderungen erfüllt sind (siehe Abschnitt 7.5.1.1, „Anforderungen“), wurden die erforderlichen Produkte für die Online-Migration in /etc/products.d eingefügt. Mit dem folgenden Kommando erhalten Sie eine Liste dieser Produkte:

    zypper se -t product | grep -h -- "-migration" | cut -d'|' -f2

    Dieses Kommando sollte zumindest SUSE_SLES-SP4-migration zurückgeben. Je nach Umfang der Installation werden weitere Produkte aufgelistet.

  2. Installieren Sie die Migrationsprodukte, die Sie mit dem vorherigen Schritt abgerufen haben, mit dem Kommando zypper in -t product LIST_OF_PRODUCTS, beispielsweise

    zypper in -t product SUSE_SLES-SP4-migration
  3. Registrieren Sie die Produkte, die Sie mit dem vorherigen Schritt installiert haben, damit die zugehörigen Aktualisierungskanäle verfügbar werden:

    suse_register -d 2 -L /root/.suse_register.log
  4. Aktualisieren Sie die Repositorys und Services:

    zypper ref -s
  5. Prüfen Sie die Liste der abrufbaren Repositorys mit zypper lr. Mindestens die folgenden Repositorys müssen aktiviert sein:

    • SLES11-SP4-Pool

    • SLES11-SP4-Updates

    Je nach Umfang der Installation müssen weitere Repositorys für Add-on-Produkte oder Erweiterungen aktiviert werden.

    Falls eines dieser Repositorys nicht aktiviert ist (die SP4-Repositorys werden mit diesem Verfahren nicht standardmäßig aktiviert), aktivieren Sie es mit zypper modifyrepo --enable REPOSITORY ALIAS, beispielsweise:

    zypper modifyrepo --enable SLES11-SP4-Pool --enable SLES11-SP4-Updates

    Enthält die Konfiguration Drittanbieter-Repositorys, die nicht mit SP4 kompatibel sind, deaktivieren Sie die betreffenden Repositorys mit zypper modifyrepo --disable REPOSITORY ALIAS.

  6. Damit ist die Vorbereitung abgeschlossen, und Sie können die Distribution mit zypper dup --from REPO 1 --from REPO 2 ... aktualisieren. Führen Sie dabei in jedem Fall alle erforderlichen Repositorys mit --from auf, beispielsweise:

    zypper dup --from SLES11-SP4-Pool --from SLES11-SP4-Updates

    Bestätigen Sie mit y. Die Aufrüstung wird gestartet.

  7. Nach der Aufrüstung der Distribution mit dem vorherigen Schritt ist die minimale Migration abgeschlossen (eine minimale Teilmenge der Pakete wurde auf den aktuellen SP4-Stand aktualisiert). Überspringen Sie diesen Schritt, wenn keine vollständige Migration ausgeführt werden soll.

    Für eine vollständige Migration (alle Pakete werden auf den aktuellen SP4-Stand aktualisiert) führen Sie das folgende Kommando aus:

    zypper update -t patch
  8. Damit ist die Aufrüstung auf SP4 abgeschlossen. Registrieren Sie nun das Produkt erneut:

    suse_register -d 2 -L /root/.suse_register.log
  9. Booten Sie abschließend das System neu.

Das System wurde erfolgreich auf Service Pack 4 aktualisiert.

7.7.1.4 Aktualisierung durch Booten von einer Installationsquelle

Als Alternative zur Online-Migration können Sie Ihr System auch von einer Installationsquelle booten, also von einer DVD oder einer Netzwerkinstallationsquelle. Die Aktualisierung beginnt wie eine normale Installation.

Die ISO-Images für Service Pack 4 sind bei http://download.suse.com/ erhältlich. Brennen Sie die Images auf eine DVD, oder bereiten Sie eine Netzwerkinstallationsquelle gemäß Abschnitt 14.2, „Einrichten des Servers, auf dem sich die Installationsquellen befinden“ vor.

7.8 Rückportierungs-Quellcode

Bei SUSE kommt die Rückportierung umfassend zum Einsatz. Dieser Abschnitt erläutert, warum der Vergleich der Versionsnummern irreführend sein kann, wenn es darum geht, die Funktionen und die Probleme einer Software zu beurteilen.

7.8.1 Warum Rückportierung?

Upstream-Entwickler befassen sich hauptsächlich damit, die Software weiterzuentwickeln. In vielen Fällen beheben sie Fehler, während sie gleichzeitig neue Funktionen einbauen, die noch nicht eingehend getestet wurden und daher ihrerseits neue Fehler verursachen.

Distributionsentwickler müssen daher zwischen Folgendem unterscheiden:

  • Fehlerbehebungen mit begrenztem Risiko von Funktionsstörungen und

  • Änderungen, die die bestehenden Funktionen stören.

In den meisten Fällen beachten Distributionsentwickler nicht alle Upstream-Änderungen, sobald ein Paket in eine veröffentlichte Distribution eingebunden ist. Häufig bleiben sie bei der Upstream-Version, die sie ursprünglich veröffentlicht hatten, und sie erstellen auf Patches auf der Grundlage der Upstream-Änderungen, mit denen dann Fehler behoben werden sollen. Dies wird als Rückportierung bezeichnet.

Im Allgemeinen stellen Distributionsentwickler nur in zwei Fällen eine neuere Software-Version bereit:

  • wenn die Änderungen zwischen ihren Paketen und den Upstream-Versionen so groß geworden sind, dass eine Rückportierung nicht mehr praktikabel ist, oder

  • für Software, die schon an sich rasch veraltet, beispielsweise Anti-Malware-Software.

7.8.2 Argumente für die Rückportierung

Bei SUSE wird die Rückportierung umfassend genutzt, damit die verschiedenen Anforderungen an Unternehmens-Software in ein gesundes Gleichgewicht gebracht werden können. Beispiele für die wichtigsten Punkte:

  • Es sollen stabile Schnittstellen (APIs) erzielt werden, auf die die Software-Hersteller sich verlassen können, wenn sie Produkte für die gemeinsame Verwendung mit den Unternehmensprodukten von SUSE bauen.

  • Die Pakete, die in den Unternehmensprodukten von SUSE zum Einsatz kommen, sollen die höchstmögliche Qualität aufweisen und gründlich getestet werden, und das nicht nur in sich selbst, sondern auch als Bestandteil des gesamten Unternehmensprodukts.

  • Die Zertifizierungen der Unternehmensprodukte von SUSE durch andere Hersteller, z. B. Zertifizierungen für Oracle- oder SAP-Produkte, sollen aufrechterhalten werden.

  • Die Entwickler von SUSE sollen sich darauf konzentrieren können, die kommende Version des Produkts so gut wie möglich zu gestalten; sie sollen ihre Aufmerksamkeit nicht auf zahllose Versionen aufteilen müssen.

  • Es soll klar ersichtlich sein, was in einer bestimmten Unternehmensversion vorhanden ist, damit unser Kundendienst genaue und zeitnahe Informationen dazu bereitstellen kann.

7.8.3 Argumente gegen die Rückportierung

Es gilt die allgemeine Richtlinie, dass keine neuen Upstream-Versionen eines Pakets in unsere Unternehmensprodukte eingeführt werden. Diese Regel ist allerdings nicht ohne Ausnahmen. Bei einer eng umgrenzten Klasse von Paketen, insbesondere bei Antiviren-Software, wiegen die Sicherheitsaspekte schwerer als die konservative Vorgehensweise, die mit Blick auf die Qualitätssicherung aus einzuhalten wäre. Für Pakete in dieser Klasse werden gelegentlich neuere Versionen in eine veröffentliche Version einer Unternehmensproduktlinie eingeführt.

Gelegentlich wird auch bei anderen Arten von Paketen entschieden, eine neue Version einzuführen, statt eine Rückportierung vorzunehmen. Dies ist dann der Fall, wenn eine Rückportierung wirtschaftlich nicht praktikabel ist oder wenn äußerst relevante technische Argumente für die Einführung der neueren Version sprechen.

7.8.4 Auswirkungen der Rückportierungen auf die Interpretation der Versionsnummern

Aufgrund der verbreiteten Praxis der Rückportierungen ist es nicht möglich, aus einem einfachen Vergleich der Versionsnummern festzustellen, ob ein SUSE-Paket eine Korrektur für ein bestimmtes Problem enthält oder eine bestimmte Funktion in diesem Paket eingefügt wurde. Durch die Rückportierung gibt der Upstream-Teil der Versionsnummer eines SUSE-Pakets lediglich an, auf welcher Upstream-Version das SUSE-Paket basiert. Das Paket enthält unter Umständen Fehlerkorrekturen und Funktionen, die in der zugehörigen Upstream-Version fehlen, jedoch in das SUSE-Paket rückportiert wurden.

Informationen zu diesen Fehlerkorrekturen und Funktionen finden Sie an mehreren Stellen:

  • Changelog des Pakets:

    rpm -q --changelog name-of-installed-package
    rpm -qp --changelog packagefile.rpm

    Die Ausgabe dokumentiert den Änderungsverlauf des Pakets in Kurzform.

  • Das Changelog des Pakets enthält beispielsweise Einträge wie bnc#1234, die sich auf Fehler im Bugzilla-Statusüberwachungssystem von Novell beziehen oder mit anderen Fehlerüberwachungssystemen verknüpft sind. (Aus Gründen der Geheimhaltung sind nicht alle Informationen frei für alle Benutzer zugänglich.)

  • Ein Paket kann eine Datei /usr/share/doc/packagename/README.SUSE oder README.SuSE umfassen, in der Sie allgemeine Informationen zum betreffenden SUSE-Paket finden.

  • Das RPM-Quellpaket enthält die Patches, die während der regulären binären RPMs als separate Dateien angewendet werden können. Wenn Sie das Lesen des Quellcodes beherrschen, können Sie diese Dateien interpretieren. Weitere Informationen finden Sie im Buch Maximum RPM.

  • In den SUSE-Sicherheitsmitteilungen finden Sie Korrekturen zu Sicherheitsfehlern. Die Fehler werden häufig mit standardisierten Kennungen wie CAN-2005-2495 bezeichnet, die im Rahmen des CVE-Projekts (Common Vulnerabilities and Exposures, häufige Sicherheitslücken und Gefährdungen) vergeben werden.

Diese eingeschränkte Aussagefähigkeit der Versionsnummern durch die Rückportierung macht sich insbesondere bei Sicherheitssuchwerkzeugen negativ bemerkbar. Einige Werkzeuge für die Suche nach Sicherheitslücken (oder bestimmte Tests in diesen Werkzeugen) beruhen ausschließlich auf den Versionsinformationen. Bei diesen Werkzeugen/Tests besteht daher die Gefahr von falsch-positiven Ergebnissen (die Angabe, dass eine Sicherheitslücke in einer Software aufgefunden wurde, die in Wahrheit gar nicht besteht), wenn eine Rückportierung stattgefunden hat. Beim Auswerten der Berichte von Sicherheitssuchwerkzeugen muss daher in jedem Fall überprüft werden, ob ein Eintrag lediglich auf der Versionsnummer beruht oder aber auf einem tatsächlich ausgeführten Test auf eine Sicherheitslücke.

7.9 Atomic-Aktualisierung

Die Atomic-Aktualisierung basiert auf Tools, die zwei Kopien des Systems verwalten und nach einem Aktualisierungsfehler eine einfache Wiederherstellung des Systems ermöglichen. Für die bereitgestellten Tools ist ein spezielles Festplattenpartitions-Setup erforderlich. Jede Kopie des Systems befindet sich auf einer eigenen primären Partition. Falls eine Aktualisierung fehlschlägt, können Sie jederzeit zum vorherigen Zustand des Systems auf der anderen Partition zurückwechseln.

7.9.1 Einrichtung

Warnung
Warnung: Strenge Partitionierungsanforderungen

Die Implementierung stellt strenge Anforderungen an die Festplattenpartitionierung: Die erste Root-Partition lautet /dev/sda1; sie darf nicht mehr als die Hälfte der gesamten Festplatte belegen. Als zweite Root-Partition des Systems erstellt das Tool danach die Partition /dev/sda2. Weitere Partitionen, sofern erforderlich, werden von beiden Root-Partitionen gemeinsam verwendet. Deren Größe muss berücksichtigt werden, d. h., die Größe der ersten Root-Partition muss entsprechend reduziert werden. Hier eine Berechnungsformel zur Grobabschätzung:

Die Größe der Festplatte minus der Größe von sda1 minus der Größe von sda2 ist der freie Speicher für zusätzliche Partitionen.

  1. Installieren Sie das System mit /dev/sda1 als einzige Root-Partition, wobei diese Partition weniger als die Hälfte der Gesamtfestplattengröße einnehmen darf.

  2. Passen Sie das installierte System nach Bedarf an. Vergewissern Sie sich, dass das Paket multi-update-tools installiert ist.

  3. Führen Sie multi-update-setup --partition aus. Dadurch wird die zweite Root-Partition des Systems (/dev/sda2) mit gleicher Größe erstellt.

  4. Partitionieren Sie den Rest der Festplatte nach Bedarf und fahren Sie mit den erforderlichen Anpassungen fort(*).

  5. Führen Sie multi-update-setup --clone aus, um das System auf die andere Partition zu kopieren. Mit diesem Kommando ändern Sie auch den Root-Eintrag (/) auf dem Zielsystem in /etc/fstab.

  6. Nehmen Sie bei Bedarf weitere Anpassungen vor (*).

  7. Führen Sie multi-update-setup --bootloader aus, um das Bootloader-Setup zu starten. Durch dieses Kommando wird dem Bootloader-Menü ein Eintrag zum Booten des anderen Systems hinzugefügt.

    Warnung
    Warnung: GRUB Bootloader (obligatorisch)

    Die Installation des GRUB Bootloader ist obligatorisch. Die Tools sind nicht mit anderen Bootloadern kompatibel.

  8. Wenn an den mit (*) gekennzeichneten Stellen keine Anpassungen vorgenommen werden müssen, führen Sie multi-update-setup --complete aus. Hierdurch werden alle drei Schritte durchgeführt.

7.9.2 Aktualisierung des anderen Systems

Führen Sie multi-update aus. Dieses Kommando führt zypper in einer chroot-Umgebung aus und aktualisiert das jeweils andere System, unabhängig davon, welches System aktiv ist. Sein Bootmenü wird beim Booten als Standard angeboten.

7.9.3 Fehlersuche

Falls der Bootloader des aktualisierten Systems bei der Aktualisierung beschädigt wurde, müssen Sie das Active-Flag für die Root-Partition des anderen Systems setzen, um dieses System zu booten.

Lässt sich das aktualisierte System gar nicht booten, benötigen Sie Zugriff auf das Bootloader-Menü, um das andere System auswählen zu können.

Weitere Informationen zu GRUB finden Sie unter Kapitel 11, Der Bootloader GRUB.

7.9.4 Einschränkung

Die Root-Partition muss anhand des Partitionsnamens, der ID oder auf andere Weise eingehängt werden. Das Einhängen anhand der Partitions-UUID oder der Kennung wird nicht unterstützt.

7.9.5 Weiterführende Informationen

Weitere Informationen finden Sie in der Readme-Datei /usr/share/doc/packages/multi-update-tools/README des multi-update-tools-Pakets.

7.10 Migrations-Hooks für YaST Wagon

Mithilfe von Migrations-Hooks sind Sie in der Lage, ein benutzerdefiniertes externes Skript zu einem bestimmten Zeitpunkt im Migrationsvorgang auszuführen. Mit diesen Skripten können Sie bestimmte Probleme behandeln, die nicht mit den normalen RPM-Skripten bearbeitet werden können, oder auch zusätzliche Aktionen vornehmen, die während der Migration erforderlich sind (nicht jedoch während einer normalen Aktualisierung der Pakete).

Die Migrations-Hooks werden mit Root-Berechtigungen ausgeführt, sodass beliebige Wartungsaufgaben in den Skripten erledigt werden können (z. B. Starten/Beenden von Services, Datensicherung oder Datenmigration). Die Skripte dürfen nicht interaktiv sein; STDIN und STDOUT werden bei der Ausführung in YaST an Pipes umgeleitet. Die X-Sitzung darf nicht verwendet werden, da sie unter Umständen nicht zur Verfügung steht (beispielsweise bei der Ausführung im Textmodus). Denken Sie daran, die Ausführungsberechtigungen für die Hook-Skripte festzulegen.

Migrations-Hooks werden in der yast2-wagon-Paketversion 2.17.32.1 (als Aktualisierung für SLES11-SP2 bereitgestellt) oder 2.17.34 (in SLES11-SP3 enthalten) sowie in höheren Versionen unterstützt.

7.10.1 Position und Namenskonventionen für Hook-Skripte

Die Skripte werden im Verzeichnis /var/lib/YaST2/wagon/hooks/ gesucht. Der erwartete Skriptname besitzt das Format Schritt_Folge_Präfix_Name, wobei Folgendes gilt:

Schritt

ist ein vordefinierter Migrationsschrittname, der den aktuellen Migrationsschritt beschreibt.

Folge

ist eine Sequenznummer im Bereich von 00 bis 99, mit der sich die Reihenfolge festlegen lässt, in der die Skripte ausgeführt werden sollen. (Die führende Null ist für die richtige Sortierung wichtig und muss daher beibehalten werden!)

Präfix

muss eindeutig sein, damit keine Konflikte auftreten (Namensraum). Verwenden Sie den Paketnamen (sofern es Teil eines Pakets ist) oder den Herstellernamen, den Internet-Domänennamen oder andere Namen, die für die nötige Eindeutigkeit sorgen.

Name

kann eine beliebige Zeichenkette umfassen (nur zur Unterscheidung der Skripte). Geben Sie nach Möglichkeit einen aussagekräftigen Namen an.

Beispiel 7.2: Hook-Skript mit vollständigem Pfad
/var/lib/YaST2/wagon/hooks/before_package_migration_00_postgresql_backup

7.10.2 Beendungswert des Hook-Skripts

Das Skript muss den Beendungswert 0 zurückgeben. Bei einem Fehler (Beendungswert ungleich null) wird eine Fehlermeldung in Wagon angezeigt, und Sie können wahlweise das Skript neu starten, den Fehler ignorieren (und mit anderen Skripten fortfahren) oder die Hooks für den aktuellen Schritt und die aktuelle Phase komplett abbrechen.

7.10.3 Idempotente Skripte

Die Hook-Skripte können potenziell mehrmals ausgeführt werden: Durch das Zurück- und Vorwärtsgehen in den Wagon-Dialogfeldern wird Wagon unter Umständen neu gestartet, oder einige Schritte im Migrationsverfahren werden mehrmals abgearbeitet. Dieser Aspekt muss daher in den Skripten berücksichtigt werden. Beispielsweise kann in den Skripten zu Beginn überprüft werden, ob eine bestimmte Aktion ausgeführt werden muss oder ob diese Aktion bereits erledigt wurde, oder es kann eine einfache, temporäre Stempeldatei angelegt werden, oder die Mehrfachausführung muss anderweitig unterbunden werden.

7.10.4 Liste der unterstützten Hooks

Einige Hooks sind optional, da sie von den vorherigen Werten abhängen oder von Werten, die vom Benutzer ausgewählt werden. Einige Hooks werden mehrmals aufgerufen, beispielsweise die Registrierung, die vor und nach der Migration vorgenommen wird. Im Folgenden werden die unterstützten Hooks (Schrittnamen) in der Reihenfolge ihrer Ausführung aufgelistet:

before_init

Wird gleich zu Beginn gestartet. (Hinweis: Wird bei einem Neustart von Wagon erneut aufgerufen.)

before_welcome , after_welcome

Wird vor/nach dem Anzeigen des Willkommen-Dialogfelds gestartet.

before_registration_check , after_registration_check

Wagon prüft den Registrierungstatus. (Falls die Registrierung eines oder mehrere Produkte abgelaufen ist, kann die Migration fehlschlagen.) Ist alles in Ordnung, wird kein Dialogfeld geöffnet, und Wagon wird automatisch mit dem nächsten Schritt fortgesetzt.

before_custom_url , after_custom_url

Der Repository-Manager wird gestartet (optional, nur im in Patch CD-Modus).

before_self_update , after_self_update

Wird vor/nach der Selbstaktualisierung von Wagon aufgerufen (damit die jeweils aktuelle Version für die Migration verwendet wird).

before_installing_migration_products , after_installing_migration_products

Wird vor/nach dem Installieren der Migrationsprodukte aufgerufen.

before_selecting_migration_source , after_selecting_migration_source

Wagon fordert den Benutzer auf, die Migration über die Novell Customer Center-Repositorys oder anhand eines benutzerdefinierten Repositorys vorzunehmen. Der nächste Schritt ist abhängig von der Auswahl des Benutzers.

before_registration , after_registration

Führt die SUSE-Registrierung durch (wobei die Migrations-Repositorys hinzugefügt werden).

before_repo_selection , after_repo_selection

Für die manuelle Repository-Verwaltung.

before_set_migration_repo , after_set_migration_repo

Zum Auswählen der Migrations-Repositorys (vollständige/minimale Migration mit Novell Customer Center) oder der Aktualisierungs-Repositorys (Migration mit benutzerdefinierten Repositorys)

before_package_migration

Vor der Aktualisierung; nach diesem Schritt beginnt die eigentliche Migration, und es ist nicht möglich, automatisch zum vorherigen Status zurückzugehen. (Ein Abbruch in dieser Phase führt zu einem inkonsistenten (nur halb aktualisierten) System, und ein manuelles Rollback ist erforderlich.)

before_registration , after_registration

Startet die SUSE-Registrierung (zum Registrieren der aktualisierten Produkte)

before_congratulate , after_congratulate

Vor/nach der Anzeige des Glückwunsch-Dialogfelds in Wagon nach der erfolgreichen Migration

before_exit

Aufruf unmittelbar vor dem Beenden von Wagon (in jedem Fall, also unabhängig vom Migrationsergebnis, auch nach dem Abbrechen und beim Neustarten)

7.10.5 Abbruch-Hooks

Diese besonderen Abbruch-Hooks werden aufgerufen, wenn der Benutzer die Migration abbricht. Diese Hooks können in jedem Schritt des Migrationsverfahrens aufgerufen werden; die Reihenfolge der Ausführung kann daher nicht garantiert werden. Wenn die Skripte von den Ergebnissen anderer Hooks abhängig sind, muss jeweils der aktuelle Status geprüft werden.

before_abort

Benutzer hat den Abbruch der Migration bestätigt

before_abort_rollback , after_abort_rollback

Benutzer hat das Rollback nach einem Abbruch bestätigt (Rückkehr zu den bisherigen Produkten, die vor der Migration installiert waren) Diese Hooks werden nach before_abort aufgerufen; wenn der Benutzer das Rollback nicht bestätigt, werden sie übersprungen.

7.10.6 Neustart-Hooks

Diese Hooks werden aufgerufen, wenn Wagon sich selbst neu startet.

before_restart

Wagon wird beendet und anschließend neu gestartet

after_restart

Wagon wurde neu gestartet und führt den nächsten Schritt im Migrationsverfahren aus

7.10.7 Häufig verwendete Hooks

Es stehen zahlreiche Hooks zur Auswahl, doch viele sind nur in bestimmten Fällen sinnvoll. Im normalen Betrieb sollten Sie auf die folgenden Hooks zurückgreifen:

  • Sollen bestimmte Aktionen erledigt werden, bevor das System migriert wird (wenn also noch die bisherige Version ausgeführt wird), verwenden Sie den Hook before_package_migration.

    Zu diesem Zeitpunkt ist klar, dass die Migration vorbereitet ist und in Kürze ausgeführt wird; in den vorherigen Schritten bestand dagegen immer noch die Möglichkeit, die Migration abzubrechen.

  • Sollen bestimmte Aktionen erledigt werden, nachdem das System migriert wurde (auf dem System wird bereits die neue, migrierte Version ausgeführt, wobei bestimmte Funktionen noch nicht aktiv sind; der aktualisierte Kernel muss beispielsweise neu gebootet werden, aktualisierte Services müssen neu gestartet werden usw.), verwenden Sie den Hook before_congratulate oder after_congratulate.

    Hiermit lassen sich außerdem die temporären Ergebnisse des Hooks before_package_migration bereinigen. Zu diesem Zeitpunkt ist die Migration erfolgreich abgeschlossen.

  • Sollen die Änderungen zurückgenommen werden, nachdem die Migration abgebrochen wurde, verwenden Sie einen geeigneten Abbruch-Hook für die jeweilige Situation. Denken Sie daran, dass die Abbruch-Hooks jederzeit aufgerufen werden können, sodass eine Rücknahme unter Umständen nicht nötig ist (also wenn der Hook, mit dem die Änderungen erfolgen, noch nicht aufgerufen wurde). Bei den Abbruch-Hooks muss der aktuelle Status überprüft werden.

7.10.8 Veraltete Hooks

In älteren Versionen von Wagon wurden lediglich zwei Hook-Skripte unterstützt: /usr/lib/YaST2/bin/wagon_hook_init und /usr/lib/YaST2/bin/wagon_hook_finish. Allerdings konnte dabei immer nur ein Skript als Hook ausgeführt werden, und es war nicht möglich, die Hooks direkt in RPM-Pakete einzubinden.

Aus Gründen der Abwärtskompabilität werden die alten Hook-Skripte auch in den neueren Versionen von Wagon unterstützt. Statt dieser veralteten Hooks sollten Sie jedoch die neuen Hooks before_init und before_exit nutzen.

Diese Seite drucken