Kapitel 4. Aktualisieren von SUSE Linux Enterprise¶
Inhaltsverzeichnis
- 4.1. Terminologie
- 4.2. Wartungsmodell für SUSE Linux Enterprise 11
- 4.3. Unterstützte Aufrüstungspfade auf SLE SP4
- 4.4. Allgemeine Vorbereitungen für die Aktualisierung
- 4.5. Aktualisieren von SLE 11 SP1 auf SLE 11 SP2
- 4.6. Aktualisieren von SLE 11 SP2 auf SLE 11 SP3
- 4.7. Aktualisieren von SLE 11 SP3 auf SLE 11 SP4
- 4.8. Rückportierungs-Quellcode
- 4.9. Atomic-Aktualisierung
- 4.10. Migrations-Hooks für YaST Wagon
Zusammenfassung
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.
4.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.
4.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.
4.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:
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.
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.
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 4.1, „Weiterentwicklung der Wartungsbereitstellung (gilt auch für SLED)“ stellt einige der oben genannten Aspekte vor.
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 4.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.
4.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 4.1, „Sicherheitsupdates und Fehlerbehebungen“.
Tabelle 4.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 |
✓ |
✓ |
✓ |
✓ | |
4.2.3. Kanalmodell¶
Beim bisherigen Wartungsmodell waren SUSE Linux Enterprise Desktop 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 SLED11-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 4.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 4.2. Kanal-Layout für SUSE Linux Enterprise 11 SP1, SP2 und SP3¶
|
Typ |
SLES |
SLED | ||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Erforderliche Kanäle |
SP1
SP2
SP3
SP4
|
SP1
SP2
SP3
SP4
| ||||||||||||||||||||||||||
|
Optionale Kanäle |
SP1
SP2
SP3
SP4
|
SP1
SP2
SP3
SP4
| ||||||||||||||||||||||||||
|
Produktspezifisch (Beispiele) |
|
|
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- oderPool-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-Updatesaktualisiert. 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.
4.2.3.1. Ursprung der Pakete¶
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.
4.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 + 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
4.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 RepositorySLED11-Extrasverschoben. 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 EintragSLED11-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 4.5, „Aktualisieren von SLE 11 SP1 auf SLE 11 SP2“ und Abschnitt 4.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 4.5, „Aktualisieren von SLE 11 SP1 auf SLE 11 SP2“.
- Aufrüsten von SUSE Linux Enterprise 11 SP2
Weitere Informationen finden Sie unter Abschnitt 4.6, „Aktualisieren von SLE 11 SP2 auf SLE 11 SP3“.
- Aufrüsten von SUSE Linux Enterprise 11 SP3
Weitere Informationen finden Sie unter Abschnitt 4.7, „Aktualisieren von SLE 11 SP3 auf SLE 11 SP4“.
![[Important]](static/images/important.png) | 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. | |
4.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.
4.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 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.
4.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 4.1, „Über df -h angezeigte Liste“ ist /dev/sda3 die Root-Partition, die Sie sich notieren sollten (eingehängt als /).
Beispiel 4.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 39G 1.6G 37G 4% /windows/C
/dev/sda2 4.6G 2.6G 2.1G 57% /windows/DSoftware 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.
4.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.
4.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 Desktop finden Sie online unter http://www.suse.com/doc/sles11/#additional.
4.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:
(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.
4.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.
4.5.1.1. Anforderungen¶
Für eine Online-Aktualisierung gelten die nachstehenden Anforderungen. Beachten Sie auch Abschnitt 4.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 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 (↑Administrationshandbuch) oder Abschnitt „Aktualisieren von Software mit zypper“ (Kapitel 7, Verwalten von Software mit Kommandozeilen-Tools, ↑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.
| 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. | |
4.5.1.2. Online-Migration mit YaST ¶
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.
Wenn alle Anforderungen erfüllt sind (siehe Abschnitt 4.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 zu starten. Alternativ führen Sie /usr/sbin/wagon als
rootin der Kommandozeile aus.Bestätigen Sie das Dialogfeld mit .
Wenn 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.
Wählen Sie im nachfolgenden Dialogfeld die Aktualisierungsmethode aus. Mit verwenden Sie die Standardeinrichtung (empfohlen).
Klicken Sie auf 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-CoreundSP2-Updates. Durch Klicken auf gelangen Sie zurück zum Dialogfeld .Zum Prüfen der Änderungen, die im Rahmen des Aktualisierungsvorgangs erfolgt sind, wählen Sie .
Fahren Sie mit fort.
Das System wird erneut registriert. Während des Vorgangs werden die Kanäle
SP2-CoreundSP2-Updatesdem System hinzugefügt (weitere Informationen siehe Abschnitt 4.2.3, „Kanalmodell“). Bestätigen Sie das Hinzufügen der Kanäle.Wenn Sie im Dialogfeld die Option 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 .
Wählen Sie den Migrationstyp aus:
Aktualisiert alle Pakete auf den aktuellen SP2-Stand.
Aktualisiert eine minimale Gruppe von Paketen auf den aktuellen SP2-Stand.
Mit wählen Sie die Repositorys für die Aufrüstung manuell aus.
Bestätigen Sie Ihre Auswahl.
Der Bildschirm wird geöffnet. Hier sehen Sie eine Zusammenfassung der Aktualisierungskonfiguration. Die folgenden Abschnitte stehen zur Verfügung:
Sie können Add-on-Produkte zu SUSE Linux Enterprise Server oder Drittanbieterprodukte hier hinzufügen.
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.
Statistischer Überblick über die Aktualisierung.
- Sicherung
Legen Sie die Optionen für die Sicherung fest.
Klicken Sie zum Fortfahren auf und dann auf .
Abbrechen der Online-Migration Auf diesem Bildschirm sowie auf allen vorhergehenden Bildschirmen können Sie die Online-Migration schadlos abbrechen, bevor Sie auf klicken. Mit 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.
Während des Aktualisierungsvorgangs werden die folgenden Schritte ausgeführt:
Die Pakete werden aktualisiert.
SuSEconfig wird ausgeführt.
Das System wird neu gebootet (klicken Sie auf ).
Das soeben aktualisierte System wird erneut registriert.
Das System wurde erfolgreich auf Service Pack 2 aktualisiert.
4.5.1.3. Online-Migration mit zypper¶
Wenn alle Anforderungen erfüllt sind (siehe Abschnitt 4.5.1.1, „Anforderungen“), wurden die erforderlichen „Produkte“ für die Online-Migration in
/etc/products.deingefü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_SLED-SP2-migrationzurückgeben. Je nach Umfang der Installation werden weitere Produkte aufgelistet.Installieren Sie die Migrationsprodukte, die Sie mit dem vorherigen Schritt abgerufen haben, mit dem Kommando zypper in -t product
LIST_OF_PRODUCTS, beispielsweisezypper in -t product SUSE_SLED-SP2-migration
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
Aktualisieren Sie die Repositorys und Services erneut:
zypper ref -s
Prüfen Sie die Liste der abrufbaren Repositorys mit zypper lr. Mindestens die folgenden Repositorys müssen sein:
SLED11-SP1-PoolSLED11-SP1-UpdatesSLED11-SP2-CoreSLED11-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 --enableREPOSITORY ALIAS, beispielsweise:zypper modifyrepo --enable SLED11-SP2-Core SLED11-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.Damit ist die Vorbereitung abgeschlossen, und Sie können die Distribution mit zypper dup --from
REPO 1--fromREPO 2...aktualisieren. Führen Sie dabei in jedem Fall alle erforderlichen Repositorys mit--fromauf, beispielsweise:zypper dup --from SLED11-SP2-Core --from SLED11-SP2-Updates
Bestätigen Sie mit . Die Aufrüstung wird gestartet.
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
Damit ist die Aufrüstung auf SP2 abgeschlossen. Registrieren Sie nun das Produkt erneut:
suse_register -d 2 -L /root/.suse_register.log
Booten Sie abschließend das System neu.
Das System wurde erfolgreich auf Service Pack 2 aktualisiert.
4.5.2. Aktualisierung durch Booten von einer Installationsquelle¶
Als Alternative zur Online-Migration (weitere Informationen finden Sie unter Abschnitt 4.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 11.2, „Einrichten des Servers, auf dem sich die Installationsquellen befinden“ vor.
4.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 4.1. Booten vom Service Pack-Medium¶
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.
Wählen Sie und fahren Sie dann gemäß den YaST-Installationsanweisungen in Kapitel 3, Installation mit YaST fort.
4.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:
Eine Netzwerkinstallationsquelle ist gemäß Abschnitt 11.2, „Einrichten des Servers, auf dem sich die Installationsquellen befinden“ eingerichtet.
Eine funktionierende Netzwerkverbindung auf dem Installationsserver und dem Zielrechner, der einen Namensdienst, DHCP (optional, aber erforderlich für den PXE-Boot) und OpenSLP (optional) enthält, ist vorhanden.
Die SUSE Linux Enterprise-SP-DVD 1 zum Booten des Zielsystems oder ein Zielsystem für PXE-Boot gemäß Abschnitt 11.3.5, „Vorbereiten des Zielsystems für PXE-Boot“ ist vorhanden.
Detaillierte Informationen zum Starten der Aufrüstung von einem Remote-Server finden Sie unter Kapitel 11, Installation mit entferntem Zugriff.
4.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:
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.
Wählen Sie , 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).
Geben Sie die entsprechenden Pfadinformationen ein oder wählen Sie als Installationsquelle.
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 3.1.2, „Installieren von einer Netzwerkquelle ohne SLP“ beschrieben. YaST wird gestartet.
Schließen Sie die Installation ab, wie in Abschnitt 4.5.2.3, „Der Aktualisierungsvorgang“ beschrieben.
4.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:
Passen Sie den Setup Ihres DHCP-Servers an, um die für den PXE-Boot erforderlichen Adresseninformationen anzugeben, gemäß Abschnitt 11.3.5, „Vorbereiten des Zielsystems für PXE-Boot“.
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 11.3.2, „Einrichten eines TFTP-Servers“.
Bereiten Sie den PXE-Boot und Wake-on-LAN auf dem Zielcomputer vor.
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 11.5.1, „VNC-Installation“.
Schließen Sie die Installation ab, wie in Abschnitt 4.5.2.3, „Der Aktualisierungsvorgang“ beschrieben.
4.5.2.3. Der Aktualisierungsvorgang¶
Nach dem Booten vom Installationsmedium oder vom Netzwerk starten Sie die Aktualisierung wie folgt:
Wählen Sie im Bildschirm die und die Belegung der aus, und nehmen Sie die Lizenzvereinbarung an. Fahren Sie mit fort.
Wenn Sie von einem physischen Medium gebootet haben, prüfen Sie die Integrität des Mediums mit der . Überspringen Sie diesen Schritt nur dann, wenn Sie das Medium bereits zuvor geprüft hatten.
Wählen Sie im Bildschirm die Option . Klicken Sie auf . Der Aktualisierungsvorgang wird gestartet.
4.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.
4.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.
4.6. Aktualisieren von SLE 11 SP2 auf SLE 11 SP3¶
Die Online-Migration wird durch die folgenden Werkzeuge unterstützt:
(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:
4.6.1. Anforderungen¶
Für eine Online-Aktualisierung gelten die nachstehenden Anforderungen. Beachten Sie auch Abschnitt 4.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 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 (↑Administrationshandbuch) oder Abschnitt „Aktualisieren von Software mit zypper“ (Kapitel 7, Verwalten von Software mit Kommandozeilen-Tools, ↑Administrationshandbuch).
- 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.
| 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. | |
4.6.2. Online-Migration mit YaST ¶
Wenn alle Anforderungen erfüllt sind (siehe Abschnitt 4.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 zu starten. Alternativ führen Sie /usr/sbin/wagon als
rootin der Kommandozeile aus.Bestätigen Sie das Dialogfeld mit .
Wenn 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.
Wählen Sie im nachfolgenden Dialogfeld die Aktualisierungsmethode aus. Mit verwenden Sie die Standardeinrichtung (empfohlen).
Klicken Sie auf 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-PoolundSP3-Updates. Durch Klicken auf gelangen Sie zurück zum Dialogfeld .Zum Prüfen der Änderungen, die im Rahmen des Aktualisierungsvorgangs erfolgt sind, wählen Sie .
Fahren Sie mit fort.
Das System wird erneut registriert. Während des Vorgangs werden die Kanäle
SP3-PoolundSP3-Updatesdem System hinzugefügt (weitere Informationen siehe Abschnitt 4.2.3, „Kanalmodell“). Bestätigen Sie das Hinzufügen der Kanäle.Wenn Sie im Dialogfeld die Option 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 .
Der Bildschirm wird geöffnet. Hier sehen Sie eine Zusammenfassung der Aktualisierungskonfiguration. Die folgenden Abschnitte stehen zur Verfügung:
Sie können Add-on-Produkte zu SUSE Linux Enterprise Server oder Drittanbieterprodukte hier hinzufügen.
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.
Statistischer Überblick über die Aktualisierung.
- Sicherung
Legen Sie die Optionen für die Sicherung fest.
Klicken Sie zum Fortfahren auf und dann auf .
Abbrechen der Online-Migration Auf diesem Bildschirm sowie auf allen vorhergehenden Bildschirmen können Sie die Online-Migration schadlos abbrechen, bevor Sie auf klicken. Mit 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.
Während des Aktualisierungsvorgangs werden die folgenden Schritte ausgeführt:
Die Pakete werden aktualisiert.
SuSEconfig wird ausgeführt.
Das System wird neu gebootet (klicken Sie auf ).
Das soeben aktualisierte System wird erneut registriert.
Das System wurde erfolgreich auf Service Pack 3 aktualisiert.
4.6.3. Online-Migration mit zypper¶
Wenn alle Anforderungen erfüllt sind (siehe Abschnitt 4.5.1.1, „Anforderungen“), wurden die erforderlichen „Produkte“ für die Online-Migration in
/etc/products.deingefü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_SLED-SP3-migrationzurückgeben. Je nach Umfang der Installation werden weitere Produkte aufgelistet.Installieren Sie die Migrationsprodukte, die Sie mit dem vorherigen Schritt abgerufen haben, mit dem Kommando zypper in -t product
LIST_OF_PRODUCTS, beispielsweisezypper in -t product SUSE_SLED-SP3-migration
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
Aktualisieren Sie die Repositorys und Services:
zypper ref -s
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 --enableREPOSITORY ALIAS, beispielsweise:zypper modifyrepo --enable SLED11-SP3-Core SLED11-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.Damit ist die Vorbereitung abgeschlossen, und Sie können die Distribution mit zypper dup --from
REPO 1--fromREPO 2...aktualisieren. Führen Sie dabei in jedem Fall alle erforderlichen Repositorys mit--fromauf, beispielsweise:zypper dup --from SLED11-SP3-Pool --from SLED11-SP3-Updates
Bestätigen Sie mit . Die Aufrüstung wird gestartet.
Nach der Aufrüstung der Distribution mit dem vorherigen Schritt führen Sie das folgende Kommando aus:
zypper update -t patch
Damit ist die Aufrüstung auf SP3 abgeschlossen. Registrieren Sie nun das Produkt erneut:
suse_register -d 2 -L /root/.suse_register.log
Booten Sie abschließend das System neu.
Das System wurde erfolgreich auf Service Pack 3 aktualisiert.
4.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.
4.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.
4.7.1.1. Anforderungen¶
Für eine Online-Aktualisierung gelten die nachstehenden Anforderungen. Beachten Sie auch Abschnitt 4.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.
| 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. | |
4.7.1.2. Online-Migration mit YaST ¶
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.
Wenn alle Anforderungen erfüllt sind (siehe Abschnitt 4.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 zu starten. Alternativ führen Sie /usr/sbin/wagon als
rootin der Kommandozeile aus.Bestätigen Sie das Dialogfeld mit .
Wenn 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.
Wählen Sie im nachfolgenden Dialogfeld die Aktualisierungsmethode aus. Mit verwenden Sie die Standardeinrichtung (empfohlen).
Klicken Sie auf 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-PoolundSP4-Updates. Durch Klicken auf gelangen Sie zurück zum Dialogfeld .Zum Prüfen der Änderungen, die im Rahmen des Aktualisierungsvorgangs erfolgt sind, wählen Sie .
Fahren Sie mit fort.
Das System wird erneut registriert. Während des Vorgangs werden die Kanäle
SP4-PoolundSP4-Updatesdem System hinzugefügt (weitere Informationen siehe Abschnitt 4.2.3, „Kanalmodell“). Bestätigen Sie das Hinzufügen der Kanäle.Wenn Sie im Dialogfeld die Option 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 .
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 wählen Sie die Repositorys für die Aufrüstung manuell aus. Bestätigen Sie Ihre Auswahl.
Der Bildschirm wird geöffnet. Hier sehen Sie eine Zusammenfassung der Aktualisierungskonfiguration. Die folgenden Abschnitte stehen zur Verfügung:
Sie können Add-on-Produkte zu SUSE Linux Enterprise Server oder Drittanbieterprodukte hier hinzufügen.
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.
Statistischer Überblick über die Aktualisierung.
- Sicherung
Legen Sie die Optionen für die Sicherung fest.
Klicken Sie zum Fortfahren auf und dann auf .
Abbrechen der Online-Migration Auf diesem Bildschirm sowie auf allen vorhergehenden Bildschirmen können Sie die Online-Migration schadlos abbrechen, bevor Sie auf klicken. Mit 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.
Während des Aktualisierungsvorgangs werden die folgenden Schritte ausgeführt:
Die Pakete werden aktualisiert.
SuSEconfig wird ausgeführt.
Das System wird neu gebootet (klicken Sie auf ).
Das soeben aktualisierte System wird erneut registriert.
Das System wurde erfolgreich auf Service Pack 4 aktualisiert.
4.7.1.3. Online-Migration mit zypper¶
Wenn alle Anforderungen erfüllt sind (siehe Abschnitt 4.5.1.1, „Anforderungen“), wurden die erforderlichen „Produkte“ für die Online-Migration in
/etc/products.deingefü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_SLED-SP4-migrationzurückgeben. Je nach Umfang der Installation werden weitere Produkte aufgelistet.Installieren Sie die Migrationsprodukte, die Sie mit dem vorherigen Schritt abgerufen haben, mit dem Kommando zypper in -t product
LIST_OF_PRODUCTS, beispielsweisezypper in -t product SUSE_SLED-SP4-migration
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
Aktualisieren Sie die Repositorys und Services:
zypper ref -s
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 --enableREPOSITORY ALIAS, beispielsweise:zypper modifyrepo --enable SLED11-SP4-Pool --from SLED11-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.Damit ist die Vorbereitung abgeschlossen, und Sie können die Distribution mit zypper dup --from
REPO 1--fromREPO 2...aktualisieren. Führen Sie dabei in jedem Fall alle erforderlichen Repositorys mit--fromauf, beispielsweise:zypper dup --from SLED11-SP4-Pool --from SLED11-SP4-Updates
Bestätigen Sie mit . Die Aufrüstung wird gestartet.
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
Damit ist die Aufrüstung auf SP4 abgeschlossen. Registrieren Sie nun das Produkt erneut:
suse_register -d 2 -L /root/.suse_register.log
Booten Sie abschließend das System neu.
Das System wurde erfolgreich auf Service Pack 4 aktualisiert.
4.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 11.2, „Einrichten des Servers, auf dem sich die Installationsquellen befinden“ vor.
4.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.
4.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.
4.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.
4.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.
4.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.SUSEoderREADME.SuSEumfassen, 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-2495bezeichnet, 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.
4.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.
4.9.1. Einrichtung¶
![[Warning]](static/images/warning.png) | Strenge Partitionierungsanforderungen |
|---|---|
Die Implementierung stellt strenge Anforderungen an die Festplattenpartitionierung: Die erste Root-Partition lautet
Die Größe der Festplatte minus der Größe von | |
Installieren Sie das System mit
/dev/sda1als einzige Root-Partition, wobei diese Partition weniger als die Hälfte der Gesamtfestplattengröße einnehmen darf.Passen Sie das installierte System nach Bedarf an. Vergewissern Sie sich, dass das Paket
multi-update-toolsinstalliert ist.Führen Sie multi-update-setup --partition aus. Dadurch wird die zweite Root-Partition des Systems (
/dev/sda2) mit gleicher Größe erstellt.Partitionieren Sie den Rest der Festplatte nach Bedarf und fahren Sie mit den erforderlichen Anpassungen fort(*).
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.Nehmen Sie bei Bedarf weitere Anpassungen vor (*).
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.
GRUB Bootloader (obligatorisch) Die Installation des GRUB Bootloader ist obligatorisch. Die Tools sind nicht mit anderen Bootloadern kompatibel.
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.
4.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.
4.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 12, Der Bootloader GRUB (↑Administrationshandbuch).
4.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.
4.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.
4.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.
4.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:
Schrittist ein vordefinierter Migrationsschrittname, der den aktuellen Migrationsschritt beschreibt.
Folgeist 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äfixmuss 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.
Namekann eine beliebige Zeichenkette umfassen (nur zur Unterscheidung der Skripte). Geben Sie nach Möglichkeit einen aussagekräftigen Namen an.
Beispiel 4.2. Hook-Skript mit vollständigem Pfad
/var/lib/YaST2/wagon/hooks/before_package_migration_00_postgresql_backup
4.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.
4.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.
4.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)
4.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.
4.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
4.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.
4.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.