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 Basisverzeichnis, die Dateien und Daten des Benutzers beibehalten. Bei der Migration wird das Root-Volume (Betriebssystem) durch ein neues Bundle ersetzt, wobei das Benutzer-Volume (/home) intakt bleibt. Dies unterscheidet sich von einer Neuerstellung, bei der das Root-Volume mit demselben Betriebssystempaket aktualisiert wird.

Die WorkSpace Migrate-Funktion wickelt den gesamten Prozess 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.

Quell-Betriebssystem	Ubuntu 22.04	Ubuntu 22.04 Grafik	Ubuntu 24.04	RHEL 8	RHEL 9	Felsig 8	Felsig 9
Amazon Linux 2 (PCoIP)	✓	✓	✓	✓	✓	✓	✓
Amazon Linux 2 (WSP)	✓	✓	✓	✓	✓	✓	✓
Ubuntu 22.04	—	✓	✓	✓	✓	✓	✓
Ubuntu 22.04 Grafik	✓	—	✓	✓	✓	✓	✓
Ubuntu 24.04	✓	✓	—	✓	✓	✓	✓
RHEL 8	✓	✓	✓	—	✓	✓	✓
RHEL 9	✓	✓	✓	✓	—	✓	✓
Felsig 8	✓	✓	✓	✓	✓	—	✓
Felsig 9	✓	✓	✓	✓	✓	✓	—

Amazon Linux 2 ist eine gültige Migrationsquelle, aber kein gültiges Migrationsziel. Amazon Linux 2 hat das Ende seiner Lebensdauer erreicht und neue WorkSpaces können nicht mit AL2-Bundles 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 (z. B. Ubuntu 24.04 → Ubuntu 22.04) durchführen. 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 ein Paket nicht auf dasselbe Paket migrieren können WorkSpace , das es bereits verwendet.

Migrationen von Amazon Linux 2 erfordern eine automatische Korrektur der Benutzer-ID-Inhaberschaft und eine Bereinigung der Desktop-Umgebung. Migrationen zwischen allen anderen Distributionen (Ubuntu, RHEL, Rocky) erfordern keine Besitzkorrektur, da diese Distributionen alle SSSD für die Active Directory-Integration verwenden, wodurch stabile Benutzer-IDs zugewiesen werden.

Voraussetzungen

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

• WorkSpace state — Der WorkSpace muss sich im AVAILABLE Bundesstaat befinden. Sie können keine Daten migrieren, WorkSpace die gestartet oder beendet werden oder sich in einem Fehlerstatus befinden.

• Keine Active Directory-Gesamtvertrauensstellung — Für WorkSpace das Verzeichnis dürfen keine Forest Trust-Beziehungen konfiguriert sein. SSSD, das von allen modernen Linux-Distributionen für die Active Directory-Integration verwendet wird, unterstützt Forest Trust nicht. Wenn Forest Trust konfiguriert ist, schlägt die Migration während der Bereitstellung fehl.

• Ausreichender EBS-Speicher — Sie WorkSpace müssen über ausreichend EBS-Speicher für den Migrationsvorgang verfügen.

Wie migriert man ein WorkSpace

Verwendung der AWS Management Console

1. Öffnen Sie die WorkSpaces Amazon-Konsole unter https://console.aws.amazon.com/workspaces/.

2. Wählen Sie im Navigationsbereich WorkSpaces aus.

3. Wählen Sie die aus WorkSpace , die Sie migrieren möchten.

4. Wählen Sie „Aktionen“ und anschließend „Migrieren WorkSpace“.

5. Wählen Sie das Zielbetriebssystempaket aus.

6. Wählen Sie Migrate (Migrieren).

Verwendung der AWS CLI

Verwenden Sie den migrate-workspace Befehl, um ein Paket 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 Ziel-Bundle-IDs:

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

Den Migrationsstatus überwachen

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 Fehlschlag). Wenn die Migration während der Bereitstellung fehlschlägt, stellt die Kontrollebene automatisch das Original WorkSpace wieder her.

Post-migration Überprüfung

Überprüfen Sie nach Abschluss der Migration Folgendes:

Überprüfen Sie WorkSpace den Status

Vergewissern Sie WorkSpace sich in der AWS Konsole oder über die CLI, dass der AVAILABLE Status aktiviert ist.

Überprüfen Sie die Benutzeranmeldung

Bitten Sie den Benutzer, sich bei 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

So überprüfen Sie, 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 initiieren, werden die folgenden Schritte ausgeführt:

1. Das Benutzervolume (/home) ist vom vorhandenen Volume getrennt WorkSpace.

2. Das Bestehende WorkSpace wird entsorgt.

3. Aus dem Zielbetriebssystempaket WorkSpace wird ein neues erstellt.

4. Das Benutzervolume wird wieder an das neue WorkSpace AT /home angehängt.

5. Das neue WorkSpace System wird bereitgestellt: Das Netzwerk wird konfiguriert, die Instanz tritt Active Directory bei und das Home-Verzeichnis des Benutzers wird eingerichtet.

6. Bei der Migration von Amazon Linux 2 wird der Dateibesitz korrigiert und die ältere Desktop-Konfiguration wird bereinigt (sieheMigration von Amazon Linux 2).

7. Das System wird WorkSpace neu gestartet und steht dem Benutzer zur Verfügung, um sich anzumelden.

Das Basisverzeichnis des Benutzers wird auf einem separaten EBS-Volume gespeichert, das während der gesamten Migration beibehalten wird. 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 abgewickelt 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:

• Winbind (AL2): Weist Benutzer-IDs mithilfe eines unvorhersehbaren algorithmischen Schemas zu (z. B. UID 1000).

• SSSD (moderne Distributionen): Weist stabile Benutzer-IDs zu, die von der Active Directory-SID abgeleitet sind (z. B. UID 1285401133).

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

Darüber hinaus 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 sicherzustellen, dass der Desktop funktioniert.

Two-phase Korrektur der Eigentumsrechte

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

Phase 1 (während der Bereitstellung)

Behebt den Besitz kritischer Desktop-Dateien, die für die sofortige Anmeldung erforderlich sind:

• Das Home-Verzeichnis selbst

• SSH-Schlüssel () ~/.ssh/

• Desktop-Konfiguration () ~/.config/

• Shell-Profile (.bashrc,.bash_profile,.profile)

• Alle Dateien oder Verzeichnisse der obersten Ebene ohne weltweite Leseberechtigung

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

Phase 2 (Hintergrund, nach dem Neustart)

Behebt die Eigentumsrechte an allen verbleibenden Dateien:

• Läuft beim Systemstart als Systemd-Dienst (ws-migrate-phase2.service)

• Wiederholt die Benutzerauflösung für bis zu 10 Minuten, falls SSSD beim Systemstart noch nicht bereit ist — wenn das Auflösungszeitlimit überschritten wird, bleibt der Dienst aktiviert und versucht es beim nächsten Systemstart erneut

• Verwendet I/O Priorität im Leerlauf und niedrigste CPU-Priorität — beeinträchtigt die Benutzererfahrung nicht

• Der Benutzer kann sich anmelden und normal arbeiten, während Phase 2 läuft

• Eigentümerkorrekturen für große Verzeichnisse (mehr als 10 Mio. Dateien) werden weiterhin im Hintergrund abgeschlossen

• Self-removes die Systemd-Servicedatei nach erfolgreichem Abschluss

Bereinigung der Desktop-Umgebung

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

• ~/.config/dconf/user— MATE-specific dconf-Datenbank

• ~/.gconf/— Legacy-GConf-Verzeichnis

• ~/.config/mate-session/— Konfiguration der MATE-Sitzung

• ~/.config/mate-panel/— Konfiguration des MATE-Panels

• ~/.local/share/mate-panel/— Anwendungsdaten des MATE-Panels

• ~/.config/pluma/— Einstellungen des MATE-Texteditors

• ~/.config/caja/— Konfiguration des MATE-Dateimanagers

• ~/.config/marco/— Einstellungen des MATE-Fenstermanagers

• ~/.config/gtk-2.0/, ~/.config/gtk-3.0/ — GTK-Themenkonfigurationen

• ~/.local/share/recently-used.xbel— Liste der zuletzt verwendeten Dateien

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 dem standardmäßigen Erscheinungsbild von GNOME 3.x geladen.

Wiederherstellung des SELinux-Kontextes

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

• Migrationen von Nicht-SELinux-Quellen (Ubuntu, AL2), bei denen Dateien keine SELinux-Labels vollständig haben.

• Migrationen zwischen SELinux-enabled Distributionen (zum Beispiel RHEL 8 → RHEL 9, Rocky 8 → Rocky 9 oder RHEL 9 → Rocky 9). SELinux-Richtlinienversionen und Dateikontextdefinitionen können sich zwischen Hauptversionen ändern.

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

Die Kontextwiederherstellung erfolgt entsprechend der Eigentümerkorrektur in zwei Phasen:

• Phase 1: Stellt während der Bereitstellung Kontexte auf kritischen Pfaden (~/.ssh/,~/.config/) wieder her.

• Phase 2: Stellt nach dem Neustart Kontexte im gesamten Home-Verzeichnis im Hintergrund wieder her.

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 ignoriert 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, existiert der AD-specified Pfad auf dem Volume nicht.

Das Migrationssystem erkennt diese Situation automatisch:

1. Nach der Bereitstellung löst SSSD das Home-Verzeichnis des Benutzers in den Pfad auf. AD-specified

2. Das Migrationssystem prüft, ob dieser Pfad auf dem Benutzervolume vorhanden ist.

3. Wenn der AD-specified Pfad nicht existiert, er aber /home/username existiert, erkennt das System dies als nicht übereinstimmende Pfadabweichung nach RFC 2307.

4. Das System meldet sich override_homedir=/home/%u direkt an /etc/sssd/sssd.conf (in allen Domänenabschnitten) und startet SSSD neu.

5. Nach dem Neustart von SSSD wird das Home-Verzeichnis des Benutzers zu dem Verzeichnis aufgelöst/home/username, in dem sich die Daten tatsächlich befinden.

6. Die Migration erfolgt normal anhand der vorhandenen Daten.

Diese Korrektur ist dauerhaft — die override_homedir Einstellung bleibt auch bei sssd.conf Neustarts und future SSSD-Neustarts bestehen.

Aktivierung der RFC 2307-Home-Verzeichnispfade nach der Migration

Wenn die Migration den RFC 2307-Home-Verzeichnispfad automatisch korrigiert hat 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 sich der Auswirkungen bewusst sind.

Warnung

Nach dem Entfernen der Überschreibung verwendet SSSD den AD-specified Home-Verzeichnispfad. Sie müssen die Benutzerdaten in diesen Pfad verschieben, bevor Sie den Override entfernen können. Andernfalls erhält der Benutzer ein leeres Home-Verzeichnis.

So stellen Sie die Pfade für das Stammverzeichnis nach RFC 2307 wieder her:

Schritt 1: Ermitteln Sie den Pfad zum AD-specified Home-Verzeichnis

# 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 Benutzerdaten in den AD-specified Pfad

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

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

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

Schritt 4: SSSD neu starten

sudo systemctl restart sssd

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

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

Wichtig

Nach dem Entfernen der Überschreibung werden future WorkSpace Neuerstellungen und Migrationen den Pfad verwenden. AD-specified Stellen Sie vor der nächsten Neuerstellung oder Migration sicher, dass sich die Daten am richtigen Speicherort befinden.

Benutzerbenachrichtigungen

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

1. Systemd-Dienstbenachrichtigungen der Phase 2 — Wenn der Benutzer nach dem Start oder Abschluss von Phase 2 mit dem Desktop verbunden ist, werden ihm Benachrichtigungen direkt vom Dienst angezeigt:

   • Zu Beginn der Phase 2: „Abschluss der Dateimigration im Hintergrund. Sie können normal weiterarbeiten. Auf einige Dateien kann möglicherweise erst zugegriffen werden, wenn die Migration abgeschlossen ist.“

   • Nach Abschluss von Phase 2: „Die Dateimigration wurde erfolgreich abgeschlossen. Alle Dateien sollten jetzt die richtigen Eigentümer haben. Einzelheiten finden Sie unter ~/workspace-migration-log-*.“

2. XDG-Autostart-Anmeldebenachrichtigung — Ein Autostart-Eintrag () wird bei der ersten Anmeldung nach der Migration ausgeführt. ~/.config/autostart/ws-migration-notify.desktop /usr/lib/skylight/check-migration-status Dies gilt für den Fall, dass der Benutzer eine Verbindung herstellt, während Phase 2 noch läuft oder nachdem sie bereits abgeschlossen ist:

   • Falls Phase 2 noch läuft: „Die Dateimigration läuft im Hintergrund. Sie können normal weiterarbeiten. Auf einige Dateien kann möglicherweise erst zugegriffen werden, wenn die Migration abgeschlossen ist.“

   • Wenn Phase 2 abgeschlossen ist: „Die Dateimigration wurde erfolgreich abgeschlossen. Alle Dateien sollten jetzt die richtigen Eigentümer haben. Einzelheiten finden Sie unter ~/workspace-migration-log-*.“

   Der Autostart-Eintrag wird entfernt, nachdem die Abschlussbenachrichtigung angezeigt wurde, sodass er bei nachfolgenden Anmeldungen nicht ausgeführt wird.

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

Migration zwischen modernen Distributionen

Bei Migrationen zwischen Ubuntu-, RHEL- und Rocky Linux-Distributionen ist keine Korrektur des Besitzes der Benutzer-ID erforderlich. Alle diese Distributionen verwenden SSSD für die Active Directory-Integration, wodurch stabile Benutzer-IDs zugewiesen werden, die von der AD-SID abgeleitet werden. Die Dateien des Benutzers behalten während der gesamten Migration die korrekte Eigentümerschaft.

Zu den gängigen Migrationspfaden in dieser Kategorie gehören:

• Cross-family: Ubuntu 22.04 ↔ RHEL 8/9, Ubuntu 22.04 ↔ Rocky 8/9, RHEL ↔ Rocky

• Versionsupgrades: Ubuntu 22.04 → Ubuntu 24.04, RHEL 8 → RHEL 9, Rocky 8 → Rocky 9

• Grafikpakete: Beliebige Quelle → Ubuntu 22.04 Graphics. Ubuntu Graphics WorkSpaces kann auch zu jedem anderen Ziel migrieren, das nicht von Graphics stammt.

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. Bei Dateien, die bereits korrekte Labels haben, ist die Wiederherstellung ein No-Op.

Was Benutzer behalten und was ändert sich

Was bleibt erhalten

• Alle Dateien im Home-Verzeichnis (Dokumente, Downloads, Desktop usw.)

• SSH-Schlüssel und Konfiguration () ~/.ssh/

• Shell-Konfiguration (.bashrc,.profile,.bash_profile)

• Browser-Lesezeichen und Profile (Firefox, Chrome)

• Application-specific Daten und Konfiguration (außer MATE-Desktop-Komponenten bei AL2-Migrationen)

Was ändert sich

• Die Desktop-Umgebung wird auf das standardmäßige Erscheinungsbild von GNOME 3.x auf der Zieldistribution zurückgesetzt.

• Ältere MATE-Desktop-Einstellungen werden entfernt und gesichert (nur AL2-Migrationen).

• Desktop-Symbole und Bedienfeldanpassungen werden auf die Standardeinstellungen zurückgesetzt.

• Die auf dem Root-Volume installierten Anwendungen werden durch die Standardanwendungen des Zielpakets ersetzt. Die vom Benutzer in seinem Home-Verzeichnis installierten Anwendungen bleiben erhalten.

Auto-stop und immer aktiv WorkSpaces

Auto-stop WorkSpaces

Bei WorkSpaces Konfiguration mit Auto-Stop (Ruhezustand nach Timeout im Leerlauf):

1. Die Migration ist abgeschlossen und der Neustart. WorkSpace

2. Der Phase-2-Hintergrunddienst wird beim Booten gestartet. Wenn SSSD noch nicht bereit ist, versucht der Dienst bis zu 10 Minuten lang erneut, die Benutzerauflösung zu beheben, bevor er fortfährt.

3. Wenn der Benutzer innerhalb des Leerlaufzeitlimits (normalerweise 1 Stunde) keine Verbindung herstellt, wird Phase 2 automatisch im Hintergrund ausgeführt.

4. Bei typischen Workloads (weniger als 100.000 Dateien) wird Phase 2 innerhalb des Leerlauf-Timeouts abgeschlossen.

5. Der wird nach Abschluss von Phase 2 in den WorkSpace Ruhezustand versetzt.

6. Wenn der Benutzer das nächste Mal eine Verbindung herstellt, ist die Migration bereits abgeschlossen und es werden keine Benachrichtigungen angezeigt.

Always-on WorkSpaces

Für Always-on WorkSpaces:

1. Die Migration ist abgeschlossen und der WorkSpace Neustart.

2. Der Phase-2-Hintergrunddienst wird beim Booten gestartet und bis zum Abschluss ausgeführt.

3. Der Benutzer kann jederzeit eine Verbindung herstellen und normal arbeiten — Phase 2 wird mit Priorität im Leerlauf ausgeführt und beeinträchtigt die Leistung nicht.

Bekannte Beschränkungen

• Active Directory Forest Trust: SSSD unterstützt keine Forest Trust-Beziehungen. WorkSpaces in Verzeichnissen, in denen Forest Trust konfiguriert ist, kann nicht migriert werden.

• Amazon Linux 2 als Ziel: AL2 hat das Ende seiner Lebensdauer erreicht und ist kein gültiges Migrationsziel. Sie können nur von AL2 migrieren, nicht von AL2.

• Kein Rollback: Abgeschlossene Migrationen können nicht auf das vorherige Betriebssystem zurückgesetzt werden. Wenn Sie zum vorherigen Betriebssystem zurückkehren müssen, müssen Sie eine neue Migration initiieren (mit Ausnahme von AL2, das kein gültiges Ziel ist).

• MATE-Desktop-Anpassungen: Bei der Migration von AL2 werden die MATE-Desktop-Einstellungen entfernt. Sie werden auf dem GNOME 3.x-Desktop gesichert~/workspace-migration-log-YYYYMMDD/removed-configuration/, können aber nicht automatisch auf den GNOME 3.x-Desktop angewendet werden.

• Große Home-Verzeichnisse: Bei Home-Verzeichnissen mit Millionen von Dateien kann die Korrektur der Besitzverhältnisse im Hintergrund in Phase 2 mehrere Stunden dauern. Der Benutzer kann während dieser Zeit normal arbeiten, aber einige Dateien haben möglicherweise bis zum Abschluss von Phase 2 eine falsche Eigentümerschaft.

• Dateifreigabe: Wenn der Benutzer die Dateifreigabe (z. B. Samba-Shares) in seinem Home-Verzeichnis eingerichtet hat, kann sich der Eigentümerwechsel während der AL2-Migration auf die Freigabeberechtigungen auswirken. Die Konfigurationen für die gemeinsame Nutzung von Dateien müssen nach der Migration möglicherweise erneut eingerichtet werden.

• RFC 2307-Override: Wenn die Migration eine Nichtübereinstimmung des RFC 2307-Home-Verzeichnispfads automatisch korrigiert hat, wird das unixHomeDirectory AD-Attribut über in überschrieben. override_homedir sssd.conf Prüfen Sie, Aktivierung der RFC 2307-Home-Verzeichnispfade nach der Migration ob SSSD den Pfad berücksichtigen soll. AD-specified

Fehlerbehebung

Die Migration schlägt während der Bereitstellung fehl

Wenn die Migration fehlschlägt und der ERROR Status WorkSpace wieder hergestellt wird, 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:

• Forest Trust konfiguriert: SSSD kann keiner Domäne mit Forest Trust beitreten. Entfernen Sie Forest Trust vor der Migration.

• AD-Konnektivitätsprobleme: Sie WorkSpace können den Domänencontroller nicht erreichen. Überprüfen Sie die VPC-Netzwerk- und Sicherheitsgruppenregeln.

• Fehler bei der DNS-Auflösung: Die AD-Domäne WorkSpace kann nicht aufgelöst werden. Überprüfen Sie die DNS-Konfiguration.

Der Benutzer kann sich nach der Migration nicht anmelden

• Stellen Sie sicher, WorkSpace dass der in AVAILABLE Ordnung ist.

• Vergewissern Sie sich, dass der Domänenbeitritt erfolgreich abgeschlossen wurde: sudo cat /var/lib/skylight/domain-join-status sollte enthaltentrue.

• Stellen Sie sicher, dass der Benutzer aufgelöst werden kann: id username sollte die UID und die Gruppen des Benutzers zurückgeben.

• SSSD-Status überprüfen: sudo sssctl domain-status domain sollte angezeigt werden. Online status: Online

Der Desktop scheint kaputt zu sein oder hat ein falsches Design

Dies tritt normalerweise auf, wenn eine Migration von AL2 durchgeführt wurde 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 einen falschen Besitzer

Wenn nach einer AL2-Migration nicht auf Dateien im Home-Verzeichnis 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 falsche Eigentümer 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

Protokoll	Speicherort	Inhalt
Protokoll des Domänenbeitritts	/var/log/skylight/domain-join.log	Vollständiger Bereitstellungs-Workflow einschließlich Migrationsphase 1
Zusammenfassung der Migration	~/workspace-migration-log-YYYYMMDD/user-id-migration.txt	Old/new UIDs, Dateianzahl, Zeitstempel für Phase 1 und Phase 2
Backed-up MATE-Konfigurationen	~/workspace-migration-log-YYYYMMDD/removed-configuration/	MATE-Desktop-Dateien wurden während der AL2-Migration entfernt
Dateiliste der Phase 1	~/workspace-migration-log-YYYYMMDD/phase1-processed-files.txt	In Phase 1 verarbeitete Dateien (werden von Phase 2 verwendet, um Duplikate zu überspringen)