Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Migrieren Sie ein Linux WorkSpace auf ein anderes Betriebssystem

Sie können ein vorhandenes Linux WorkSpace auf ein anderes Linux-Betriebssystempaket migrieren und dabei das Home-Verzeichnis, die Dateien und Daten des Benutzers beibehalten. Bei der Migration wird das Root-Volume (Betriebssystem) durch ein neues Paket ersetzt, während das Benutzer-Volume (/home) intakt bleibt. Dies unterscheidet sich von einem Rebuild, bei dem das Root-Volume mit demselben Betriebssystempaket aktualisiert wird.

Die WorkSpace Migrationsfunktion wickelt den gesamten Vorgang automatisch ab, einschließlich der Korrektur des Dateibesitzes und der Bereinigung der Desktop-Umgebung, falls erforderlich.

Unterstützte Migrationspfade

Die folgende Tabelle zeigt die unterstützten Quell- und Zielbetriebssysteme für die WorkSpace Linux-Migration.

Amazon Linux 2 ist eine gültige Migrationsquelle, aber kein gültiges Migrationsziel. Amazon Linux 2 hat das Ende seiner Lebensdauer erreicht und mit WorkSpaces AL2-Paketen können keine neuen erstellt werden.

Alle Migrationspfade zwischen Ubuntu, RHEL und Rocky Linux werden in beide Richtungen unterstützt. Sie können ein Upgrade (z. B. RHEL 8 → RHEL 9) oder ein Downgrade durchführen (z. B. Ubuntu 24.04 → Ubuntu 22.04). Sie können auch zwischen Distributionsfamilien migrieren (z. B. Rocky 9 → Ubuntu 24.04 oder RHEL 9 → Rocky 8). Die einzige Einschränkung besteht darin, dass Sie eine nicht auf dasselbe Paket migrieren können WorkSpace , das sie bereits verwendet.

Migrationen von Amazon Linux 2 erfordern eine automatische Korrektur der Benutzer-ID und eine Bereinigung der Desktop-Umgebung. Bei Migrationen zwischen allen anderen Distributionen (Ubuntu, RHEL, Rocky) ist keine Eigentümerkorrektur erforderlich, da diese Distributionen alle SSSD für die Active Directory-Integration verwenden, das stabile Benutzer-IDs zuweist.

Voraussetzungen

Bevor Sie ein Linux migrieren, überprüfen Sie Folgendes: WorkSpace

Wie migriert man eine WorkSpace

Verwendung der AWS Management Console

Verwendung der AWS CLI

Verwenden Sie den migrate-workspace Befehl, um a WorkSpace zu einem anderen Paket zu migrieren:

aws workspaces migrate-workspace \
    --source-workspace-id ws-1234567890abcdef0 \
    --bundle-id wsb-jttwgmx20 \
    --region us-east-1

So finden Sie verfügbare Zielpaket-IDs:

aws workspaces describe-workspace-bundles \
    --query 'Bundles[?contains(Name, `Ubuntu`) || contains(Name, `Rocky`) || contains(Name, `RHEL`)].{Name:Name,BundleId:BundleId}' \
    --output table

Überwachung des Migrationsstatus

Die Migration dauert in der Regel 20—30 Minuten. Überwachen Sie den Status WorkSpace:

aws workspaces describe-workspaces \
    --workspace-ids ws-1234567890abcdef0 \
    --query 'Workspaces[0].State' \
    --output text

Die WorkSpace Übergänge durchlaufen die folgenden Zustände: AVAILABLE → PENDING → AVAILABLE (bei Erfolg) oder ERROR (bei Misserfolg). Schlägt die Migration während der Bereitstellung fehl, stellt die Steuerungsebene automatisch das Original WorkSpace wieder her.

Post-migration Überprüfung

Überprüfen Sie nach Abschluss der Migration Folgendes:

Überprüfen Sie WorkSpace den Status

Bestätigen Sie in der AWS Konsole oder über die CLI, ob der AVAILABLE Status aktiviert WorkSpace ist.

Überprüfen Sie die Benutzeranmeldung

Bitten Sie den Benutzer, sich bei dem anzumelden WorkSpace und zu bestätigen, dass der Desktop korrekt geladen wird.

Überprüfen Sie das Migrationsprotokoll

Bei AL2-Migrationen finden Sie im Migrationsprotokoll Einzelheiten zu den Änderungen:

cat ~/workspace-migration-log-*/user-id-migration.txt

Dieses Protokoll zeigt die alten und neuen Benutzer-IDs, die Anzahl der in jeder Phase geänderten Dateien und Zeitstempel.

Überprüfen Sie den Status von Phase 2

Gehen Sie wie folgt vor, um zu überprüfen, ob die Hintergrundmigration abgeschlossen ist:

# Check if the Phase 2 service is still running
systemctl is-active ws-migrate-phase2.service 2>/dev/null

# "inactive" or "not found" means Phase 2 has completed
# "activating" means Phase 2 is still running (Type=simple service)

Was passiert bei der Migration?

Wenn Sie eine Migration einleiten, werden die folgenden Schritte ausgeführt:

Das Home-Verzeichnis des Benutzers wird auf einem separaten EBS-Volume gespeichert, das während der Migration erhalten bleibt. Alle darin enthaltenen Dateien /home/username überleben den Übergang, einschließlich Dokumente, SSH-Schlüssel, Shell-Konfiguration und Anwendungsdaten.

Migration von Amazon Linux 2

Migrationen von Amazon Linux 2 beinhalten zusätzliche Schritte, die automatisch durchgeführt werden. In diesem Abschnitt wird erklärt, was passiert und warum.

Warum sind AL2-Migrationen anders

Amazon Linux 2 verwendet Winbind für die Active Directory-Integration, während alle neueren Linux-Distributionen (Ubuntu, RHEL, Rocky) SSSD verwenden. Diese beiden Systeme weisen demselben Active Directory-Benutzer unterschiedliche POSIX-Benutzer-IDs zu:

Nach der Migration gehören alle Dateien im Home-Verzeichnis des Benutzers der alten Winbind-UID. Der Benutzer kann erst dann auf seine eigenen Dateien zugreifen, wenn der Besitz an die neue SSSD-UID angepasst wurde.

Zusätzlich verwendet Amazon Linux 2 die MATE-Desktop-Umgebung (GNOME 2), während neuere Distributionen GNOME 3.x verwenden. MATE-Konfigurationsdateien stehen in Konflikt mit GNOME 3.x und müssen bereinigt werden, um einen funktionierenden Desktop zu gewährleisten.

Two-phase Korrektur der Eigentumsverhältnisse

Um Zeitüberschreitungen bei der Bereitstellung zu vermeiden, wird die Eigentümerkorrektur in zwei Phasen aufgeteilt.

Phase 1 (während der Bereitstellung)

Korrigiert die Inhaberschaft an wichtigen Desktop-Dateien, die für die sofortige Anmeldung erforderlich sind:

Phase 1 ist unabhängig von der Gesamtgröße des Basisverzeichnisses schnell abgeschlossen, sodass sichergestellt wird, dass die Bereitstellung niemals aufgrund großer Basisverzeichnisse fehlschlägt.

Phase 2 (Hintergrund, nach dem Neustart)

Korrigiert den Besitz aller verbleibenden Dateien:

Säuberung der Desktop-Umgebung

Während der Migration von AL2 werden die folgenden MATE-Desktop-Konfigurationsdateien in ein Backup-Verzeichnis innerhalb des Migrationsprotokolls (~/workspace-migration-log-YYYYMMDD/removed-configuration/) verschoben:

Diese Dateien werden nicht gelöscht — sie werden in das Backup-Verzeichnis verschoben und können bei Bedarf wiederhergestellt werden. Nach der Bereinigung wird der Desktop mit der Standarddarstellung von GNOME 3.x geladen.

Wiederherstellung des SELinux-Kontextes

Wenn das Migrationsziel RHEL oder Rocky Linux ist, werden die SELinux-Sicherheitskontexte unabhängig vom Quellbetriebssystem immer im gesamten Benutzerstartverzeichnis (/home/username) wiederhergestellt. Dies gilt für alle Migrationspfade, die auf eine SELinux-enabled Distribution abzielen, einschließlich:

In allen Fällen stellt die Kontextwiederherstellung sicher, dass die Dateien die richtigen Sicherheitsbeschriftungen für die SELinux-Richtlinie der Zieldistribution haben.

Die Wiederherstellung des Kontextes erfolgt in zwei Phasen, die der Eigentümerkorrektur entsprechen:

Automatische Korrektur des RFC 2307-Home-Verzeichnisses

Active Directory unterstützt RFC 2307-Attribute (auch bekannt als „Unix-Attribute“), die es Administratoren ermöglichen, POSIX-Benutzereigenschaften einschließlich des Home-Verzeichnispfads () anzugeben. unixHomeDirectory SSSD respektiert dieses Attribut, während Winbind auf AL2 es ignorierte und immer verwendet hat. /home/username

Bei der Migration von AL2 zu einer SSSD-based Distribution wurde das AD-Benutzerobjekt möglicherweise auf einen anderen Pfad unixHomeDirectory gesetzt (z. B.). /home/CORP/jsmith In diesem Fall löst SSSD das Home-Verzeichnis des Benutzers in diesen Pfad auf. AD-specified Da die tatsächlichen Daten des Benutzers /home/username aus der AL2-Ära stammen, ist der AD-specified Pfad auf dem Volume nicht vorhanden.

Das Migrationssystem erkennt diese Situation automatisch:

Diese Korrektur ist dauerhaft — die override_homedir Einstellung bleibt auch bei sssd.conf Neustarts und zukünftigen SSSD-Neustarts erhalten.

Aktivierung der RFC 2307-Home-Verzeichnispfade nach der Migration

Wenn bei der Migration der RFC 2307-Home-Verzeichnispfad automatisch korrigiert wurde und Sie möchten, dass SSSD das unixHomeDirectory AD-Attribut in Zukunft respektiert, können Sie die Überschreibung rückgängig machen. Dies ist eine erweiterte Konfigurationsänderung, die nur durchgeführt werden sollte, wenn Sie die Auswirkungen verstehen.

So stellen Sie die Pfade des RFC 2307-Home-Verzeichnisses wieder her:

Schritt 1: Ermitteln Sie den AD-specified Home-Verzeichnispfad

# Query the AD unixHomeDirectory attribute
ldapsearch -H ldap://your-dc.example.com -b "dc=example,dc=com" \
    "(sAMAccountName=jsmith)" unixHomeDirectory

Schritt 2: Verschieben Sie die Daten des Benutzers in den AD-specified Pfad

sudo mkdir -p /home/CORP
sudo mv /home/jsmith /home/CORP/jsmith

Schritt 3: Entferne die Einstellung override_homedir aus /sssd.conf etc/sssd

sudo sed -i '/^override_homedir/d' /etc/sssd/sssd.conf

Schritt 4: Starten Sie SSSD neu

sudo systemctl restart sssd

Schritt 5: Stellen Sie sicher, dass das Home-Verzeichnis korrekt aufgelöst wird

getent passwd jsmith
# Should show /home/CORP/jsmith as the home directory

Benutzerbenachrichtigungen

Das Migrationssystem verwendet zwei Benachrichtigungsmechanismen, um den Benutzer auf dem Laufenden zu halten:

Wenn der Benutzer nicht verbunden ist (z. B. ein Autostopp WorkSpace , auf den nicht zugegriffen wurde), wird Phase 2 im Hintergrund und ohne Fehler ausgeführt.

Migration zwischen modernen Distributionen

Bei Migrationen zwischen Ubuntu-, RHEL- und Rocky Linux-Distributionen ist keine Korrektur der Benutzer-ID-Inhaberschaft erforderlich. Alle diese Distributionen verwenden SSSD für die Active Directory-Integration, bei der stabile Benutzer-IDs zugewiesen werden, die von der AD-SID abgeleitet werden. Die Benutzerdateien behalten während der gesamten Migration den korrekten Besitz.

Zu den häufigsten Migrationspfaden in dieser Kategorie gehören:

Bei Migrationen zu RHEL- oder Rocky Linux-Zielen wird die SELinux-Kontextwiederherstellung immer ausgeführt, um sicherzustellen, dass die Dateien die richtigen Sicherheitsbeschriftungen für die SELinux-Richtlinie der Zieldistribution haben. Dies gilt unabhängig von der Quelldistribution. Für Dateien, die bereits korrekte Bezeichnungen haben, ist die Wiederherstellung ein Kinderspiel.

Was Benutzer behalten und was ändert sich

Was bleibt erhalten

Was ändert sich

Auto-stop und immer aktiv WorkSpaces

Auto-stop WorkSpaces

Für WorkSpaces Konfigurationen mit automatischem Stopp (Ruhezustand nach Timeout im Leerlauf):

Always-on WorkSpaces

Für Always-On WorkSpaces:

Bekannte Beschränkungen

Fehlerbehebung

Die Migration schlägt während der Bereitstellung fehl

Schlägt die Migration fehl und WorkSpace kehrt in den ERROR Zustand zurück, versucht die Steuerungsebene automatisch, das Original WorkSpace wiederherzustellen. Überprüfen Sie die Bereitstellungsprotokolle:

# Connect to the WorkSpace (if accessible) and check the domain-join log
sudo cat /var/log/skylight/domain-join.log

Häufige Ursachen:

Der Benutzer kann sich nach der Migration nicht anmelden

Der Desktop scheint kaputt zu sein oder hat ein falsches Design

Dies tritt normalerweise auf, wenn Sie von AL2 migrieren und einige MATE-Konfigurationsdateien nicht bereinigt wurden. So setzen Sie den Desktop auf die Standardeinstellungen zurück:

# Remove remaining desktop configuration
rm -rf ~/.config/dconf/user
rm -rf ~/.gconf

# Log out and log back in

Dateien haben nach der Migration den falschen Besitzer

Wenn nach einer AL2-Migration auf Dateien im Home-Verzeichnis nicht zugegriffen werden kann, läuft Phase 2 möglicherweise noch:

# Check Phase 2 status
systemctl is-active ws-migrate-phase2.service 2>/dev/null

# Check the migration log for progress
cat ~/workspace-migration-log-*/user-id-migration.txt

Wenn Phase 2 abgeschlossen ist, aber einige Dateien immer noch den falschen Besitzer haben, können Sie sie manuell korrigieren:

# Find files with the old UID and change ownership
sudo find /home/username -uid old-uid -exec chown username {} +
sudo find /home/username -gid old-gid -exec chgrp username {} +

Speicherorte der Protokolldateien