In den Versionshinweisen finden Sie zusätzliche Informationen zu den Änderungen, die seit der vorigen Version von SUSE Linux Enterprise vorgenommen wurden. Überpüfen sie anhand dieser Hinweise, ob Ihre Hardware oder Einrichtung überarbeitet werden muss, welche Ihrer bevorzugten Softwarepakete maßgeblich geändert wurden und welche Vorkehrungen Sie zusätzlich zu den allgemeinen Empfehlungen in diesem Abschnitt treffen sollten. In den Versionshinweisen finden Sie auch Informationen und Probleme, die erst nach der Fertigstellung des Handbuchs bekannt wurden.

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

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.

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 beispielsweise /dev/sda3 die Root-Partition, die Sie sich notieren sollten (eingehängt als /).

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/D

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.

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.

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

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.

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.4.4.1 Anforderungen #

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

Produktregistrierung

Um eine Verbindung mit den Aktualisierungs-Repositorys herstellen zu können, muss Ihr Produkt registriert sein. Ist dies nicht der Fall, starten Sie die Registrierung entweder mit dem Modul SUSE 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, 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.

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.

4.4.4.2 Online-Migration mit YaST Wagon #

Anmerkung

Die Online-Migration mit YaST Wagon ist nur verfügbar für Versionen vor SUSE Linux Enterprise Server 12.

1. Wenn alle Anforderungen erfüllt sind (siehe Abschnitt 4.4.4.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-Repositorys für die Online-Migration aus. Eine Liste der Repositorys wird angezeigt, in der Sie die Repositorys 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 Repositorys SP2-Core und SP2-Updates. Durch Klicken auf OK gelangen Sie zurück zum Dialogfeld Aktualisierungsmodus.

   Zum Prüfen der Änderungen an der Repository-Einrichtung, 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 Repositorys SP2-Core und SP2-Updates dem System hinzugefügt (weitere Informationen finden Sie unter Abschnitt 4.7.2, „Repository-Modell“). Bestätigen Sie das Hinzufügen der Repositorys.

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: 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-Repositorys vom System entfernt werden.

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

   1. Die Pakete werden aktualisiert.

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

   3. Das soeben aktualisierte System wird erneut registriert.

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

Als Alternative zur Online-Migration (weitere Informationen finden Sie unter Abschnitt 4.4.4, „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.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.

Als Alternative zum Herunterladen der Aktualisierungen vom SUSE-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 SUSE-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.

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.

Sie können Ihr System durch Booten von einer Installationsquelle aufrüsten. Diese kann entweder eine lokale DVD oder eine Netzwerkinstallationsquelle sein, so als ob Sie eine Neuinstallations durchführen. Sie wählen dann einfach im Boot-Bildschirm "Aufrüsten" statt "Installieren" aus, um das System aufzurüsten.

Gehen Sie folgendermaßen vor, um eine automatische Migration auszuführen:

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.

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 2 finden Sie unter Kapitel 13, Der Bootloader GRUB 2, Administrationshandbuch.

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.

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

Der Bereich für erweiterte Supportstufen beginnt in Jahr 10 und endet in Jahr 13. Sie umfassen fortlaufende L3-Diagnose auf technischer Ebene und rückwirkende Behebung kritischer Fehler. Diese Supportstufen führen proaktiv Updates für einfache lokale Root-Exploits in Kernel sowie für andere Root-Exploits durch, die direkt ohne Benutzerinteraktion ausgeführt werden können. Darüber hinaus werden vorhandene Workloads, Softwarestapel und Hardware mit einer limitierten Paketausschlussliste unterstützt. Einen Überblick finden Sie in Tabelle 4.1, „Sicherheitsupdates und Fehlerbehebungen“.

Das Repository-Layout entspricht den Produktlebenszyklen. Tabelle 4.2, „Repository-Layout für SUSE Linux Enterprise 11 SP2 und SP3 sowie für SUSE Linux Enterprise 12“ enthält eine Liste aller Repositorys von SUSE Linux Enterprise 11 SP2 bis SUSE Linux Enterprise 12.

zypper repos -u

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

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

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:

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:

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

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

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 auf der Versionsnummer beruht oder auf einem tatsächlich ausgeführten Test auf eine Sicherheitslücke.

Informationen zu rückportierten Fehlerkorrekturen und Funktionen finden Sie an mehreren Stellen:

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:

/var/lib/YaST2/wagon/hooks/before_package_migration_00_postgresql_backup

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.

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.

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:

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.

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

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:

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.