Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Migrer un Linux WorkSpace vers un autre système d'exploitation

Vous pouvez migrer un système Linux existant WorkSpace vers un autre ensemble de systèmes d'exploitation Linux tout en préservant le répertoire personnel, les fichiers et les données de l'utilisateur. La migration remplace le volume racine (système d'exploitation) par un nouveau bundle tout en conservant le volume utilisateur (/home) intact. Ceci est différent d'une reconstruction, qui actualise le volume racine avec le même bundle de système d'exploitation.

La WorkSpace fonction Migrate gère automatiquement l'ensemble du processus, y compris la correction de la propriété des fichiers et le nettoyage de l'environnement de bureau si nécessaire.

Voies de migration prises en charge

Le tableau suivant indique les systèmes d'exploitation source et cible pris en charge pour la WorkSpace migration vers Linux.

Amazon Linux 2 est une source de migration valide mais n'est pas une cible de migration valide. Amazon Linux 2 est en fin de vie et il n'est WorkSpaces pas possible d'en créer de nouveaux avec les offres AL2.

Tous les chemins de migration entre Ubuntu, RHEL et Rocky Linux sont pris en charge dans les deux sens. Vous pouvez effectuer une mise à niveau (par exemple, RHEL 8 → RHEL 9) ou une rétrogradation (par exemple, Ubuntu 24.04 → Ubuntu 22.04). Vous pouvez également migrer d'une famille de distribution à l'autre (par exemple, Rocky 9 → Ubuntu 24.04 ou RHEL 9 → Rocky 8). La seule restriction est que vous ne pouvez pas migrer WorkSpace vers le même bundle qu'il utilise déjà.

Les migrations depuis Amazon Linux 2 nécessitent une correction automatique de la propriété de l'identifiant utilisateur et un nettoyage de l'environnement de bureau. Les migrations entre toutes les autres distributions (Ubuntu, RHEL, Rocky) ne nécessitent pas de correction de propriété car ces distributions utilisent toutes le SSSD pour l'intégration d'Active Directory, qui attribue des ID utilisateur stables.

Conditions préalables

Avant de migrer un système Linux WorkSpace, vérifiez les points suivants :

Comment migrer un WorkSpace

Utilisation de AWS Console de gestion

Utilisation de AWS CLI

Utilisez la migrate-workspace commande pour migrer un WorkSpace vers un autre bundle :

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

Pour trouver les ID de bundle cible disponibles, procédez comme suit :

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

Surveillance de l'état de migration

La migration prend généralement de 20 à 30 minutes. Surveillez l' WorkSpaceétat :

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

Les WorkSpace transitions passent par les états suivants : AVAILABLE → PENDING → AVAILABLE (en cas de succès) ou ERROR (en cas d'échec). Si la migration échoue pendant le provisionnement, le plan de contrôle restaure automatiquement l'original WorkSpace.

Post-migration vérification

Une fois la migration terminée, vérifiez les points suivants :

Vérifier WorkSpace l'état

Vérifiez que l'AVAILABLEétat WorkSpace est activé dans la AWS console ou via l'interface de ligne de commande.

Vérifier la connexion de l'utilisateur

Demandez à l'utilisateur de se connecter au WorkSpace et de confirmer que le bureau se charge correctement.

Consultez le journal de migration

Pour les migrations AL2, consultez le journal des migrations pour plus de détails sur les modifications apportées :

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

Ce journal indique l'ancien et le nouveau nom d'utilisateur, le nombre de fichiers modifiés à chaque phase et les horodatages.

Vérifiez l'état de la phase 2

Pour vérifier si la migration en arrière-plan est terminée :

# 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)

Déroulement de la migration

Lorsque vous lancez une migration, les étapes suivantes se produisent :

Le répertoire personnel de l'utilisateur est stocké sur un volume EBS distinct qui est conservé tout au long de la migration. Tous les fichiers présents /home/username survivent à la transition, y compris les documents, les clés SSH, la configuration du shell et les données d'application.

Migration depuis Amazon Linux 2

Les migrations depuis Amazon Linux 2 impliquent des étapes supplémentaires qui sont gérées automatiquement. Cette section explique ce qui se passe et pourquoi.

Pourquoi les migrations AL2 sont différentes

Amazon Linux 2 utilise Winbind pour l'intégration d'Active Directory, tandis que toutes les nouvelles distributions Linux (Ubuntu, RHEL, Rocky) utilisent SSSD. Ces deux systèmes attribuent des ID utilisateur POSIX différents au même utilisateur Active Directory :

Après la migration, tous les fichiers du répertoire personnel de l'utilisateur sont détenus par l'ancien UID Winbind. L'utilisateur ne peut pas accéder à ses propres fichiers tant que la propriété n'est pas corrigée pour correspondre au nouvel UID SSSD.

En outre, Amazon Linux 2 utilise l'environnement de bureau MATE (GNOME 2), tandis que les nouvelles distributions utilisent GNOME 3.x. Les fichiers de configuration MATE entrent en conflit avec GNOME 3.x et doivent être nettoyés pour garantir un bureau fonctionnel.

Two-phase correction de propriété

Pour éviter les délais de provisionnement, la correction de propriété est divisée en deux phases.

Phase 1 (pendant le provisionnement)

Corrige la propriété des fichiers critiques pour le bureau nécessaires à une connexion immédiate :

La phase 1 se termine rapidement, quelle que soit la taille totale du répertoire personnel, afin de garantir que le provisionnement n'échoue jamais en raison de la taille des répertoires personnels.

Phase 2 (arrière-plan, après redémarrage)

Corrige la propriété de tous les fichiers restants :

Nettoyage de l'environnement de bureau

Lors de la migration depuis AL2, les fichiers de configuration de bureau MATE suivants sont déplacés vers un répertoire de sauvegarde dans le journal de migration (~/workspace-migration-log-YYYYMMDD/removed-configuration/) :

Ces fichiers ne sont pas supprimés. Ils sont déplacés vers le répertoire de sauvegarde et peuvent être restaurés si nécessaire. Après le nettoyage, le bureau se charge avec l'apparence par défaut de GNOME 3.x.

Restauration du contexte SELinux

Lorsque la cible de migration est RHEL ou Rocky Linux, les contextes de sécurité SELinux sont toujours restaurés sur l'intégralité du répertoire d'accueil de l'utilisateur (/home/username), quel que soit le système d'exploitation source. Cela s'applique à tous les chemins de migration qui ciblent une SELinux-enabled distribution, notamment :

Dans tous les cas, la restauration du contexte garantit que les fichiers possèdent les étiquettes de sécurité appropriées pour la politique SELinux de la distribution cible.

La restauration du contexte s'effectue en deux phases, correspondant à la correction de propriété :

Correction automatique du répertoire personnel RFC 2307

Active Directory prend en charge les attributs RFC 2307 (également appelés « attributs Unix »), qui permettent aux administrateurs de spécifier les propriétés utilisateur POSIX, y compris le chemin du répertoire personnel (). unixHomeDirectory SSSD respecte cet attribut, tandis que Winbind sur AL2 l'ignorait et l'utilisait toujours. /home/username

Lors de la migration d'AL2 vers une SSSD-based distribution, l'objet utilisateur AD a peut-être unixHomeDirectory défini un chemin différent (par exemple,/home/CORP/jsmith). Dans ce cas, SSSD résout le répertoire personnel de l'utilisateur sur ce AD-specified chemin. Étant donné que les données réelles de l'utilisateur /home/username datent de l'ère AL2, le AD-specified chemin n'existe pas sur le volume.

Le système de migration détecte automatiquement cette situation :

Cette correction est permanente : le override_homedir paramètre persiste lors des redémarrages et sssd.conf des prochains redémarrages du SSSD.

Activation des chemins du répertoire personnel RFC 2307 après la migration

Si la migration a corrigé automatiquement le chemin du répertoire de base de la RFC 2307 et que vous souhaitez que SSSD respecte l'unixHomeDirectoryattribut AD à l'avenir, vous pouvez annuler le remplacement. Il s'agit d'une modification de configuration avancée qui ne doit être effectuée que si vous en comprenez les implications.

Pour restaurer les chemins du répertoire personnel de la RFC 2307, procédez comme suit :

Étape 1 : Déterminer le chemin du AD-specified répertoire de base

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

Étape 2 : déplacer les données de l'utilisateur vers le AD-specified chemin

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

Étape 3 : Supprimez le paramètre override_homedir de//sssd.conf etc/sssd

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

Étape 4 : Redémarrer SSSD

sudo systemctl restart sssd

Étape 5 : Vérifiez que le répertoire de base est correctement résolu

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

Notifications utilisateur

Le système de migration utilise deux mécanismes de notification pour tenir l'utilisateur informé :

Si l'utilisateur n'est pas connecté (par exemple, un arrêt automatique WorkSpace auquel il n'a pas été accédé), la phase 2 s'exécute silencieusement sans erreur.

Migration entre les distributions modernes

Les migrations entre les distributions Ubuntu, RHEL et Rocky Linux ne nécessitent pas de correction de la propriété de l'identifiant utilisateur. Toutes ces distributions utilisent SSSD pour l'intégration d'Active Directory, qui attribue des ID utilisateur stables dérivés de l'AD SID. Les fichiers de l'utilisateur conservent leur propriété correcte tout au long de la migration.

Les voies de migration courantes de cette catégorie incluent :

Pour les migrations vers des cibles RHEL ou Rocky Linux, la restauration du contexte SELinux s'exécute toujours pour garantir que les fichiers possèdent les étiquettes de sécurité appropriées à la politique SELinux de la distribution cible. Cela s'applique quelle que soit la distribution de la source. Pour les fichiers dont les libellés sont déjà corrects, la restauration est impossible.

Ce que les utilisateurs conservent et quels changements

Ce qui est préservé

Quels sont les changements

Auto-stop et toujours actif WorkSpaces

Auto-stop WorkSpaces

Pour les WorkSpaces configurations avec arrêt automatique (mise en veille prolongée après un délai d'inactivité) :

Always-on WorkSpaces

Pour une utilisation permanente WorkSpaces :

Limitations connues

Résolution des problèmes

La migration échoue lors du provisionnement

Si la migration échoue et que le WorkSpace retour à ERROR l'état initial est rétabli, le plan de contrôle tente automatiquement de restaurer l'original WorkSpace. Consultez les journaux de provisionnement :

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

Causes courantes :

L'utilisateur ne peut pas se connecter après la migration

Le bureau semble cassé ou n'a pas le bon thème

Cela se produit généralement lors de la migration depuis AL2 et que certains fichiers de configuration MATE n'ont pas été nettoyés. Pour rétablir les paramètres par défaut du bureau :

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

# Log out and log back in

Le propriétaire des fichiers n'est pas le bon après la migration

Si les fichiers du répertoire personnel sont inaccessibles après une migration vers AL2, la phase 2 est peut-être toujours en cours d'exécution :

# 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

Si la phase 2 est terminée mais que la propriété de certains fichiers n'est toujours pas correcte, vous pouvez les corriger manuellement :

# 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 {} +

Emplacement des fichiers journaux