Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Migrar un Linux WorkSpace a un sistema operativo diferente

Puede migrar un Linux existente WorkSpace a un paquete de sistema operativo Linux diferente y, al mismo tiempo, conservar el directorio principal, los archivos y los datos del usuario. La migración reemplaza el volumen raíz (sistema operativo) por un nuevo paquete y, al mismo tiempo, mantiene intacto el volumen de usuario (/home). Esto es diferente de una reconstrucción, que actualiza el volumen raíz con el mismo paquete de sistema operativo.

La WorkSpace función de migración gestiona todo el proceso automáticamente, incluida la corrección de la propiedad de los archivos y la limpieza del entorno de escritorio cuando es necesario.

Rutas de migración compatibles

En la siguiente tabla se muestran los sistemas operativos de origen y destino compatibles para la WorkSpace migración a Linux.

Amazon Linux 2 es una fuente de migración válida, pero no es un destino de migración válido. Amazon Linux 2 ha llegado al final de su ciclo de vida útil y WorkSpaces no se pueden crear nuevos paquetes con AL2.

Todas las rutas de migración entre Ubuntu, RHEL y Rocky Linux son compatibles en ambas direcciones. Puede actualizar (por ejemplo, RHEL 8 → RHEL 9) o degradar (por ejemplo, Ubuntu 24.04 → Ubuntu 22.04). También puedes migrar entre familias de distribución (por ejemplo, Rocky 9 → Ubuntu 24.04 o RHEL 9 → Rocky 8). La única restricción es que no puedes migrar un paquete WorkSpace al mismo que ya está usando.

Las migraciones desde Amazon Linux 2 requieren la corrección automática de la propiedad de los ID de usuario y la limpieza del entorno de escritorio. Las migraciones entre todas las demás distribuciones (Ubuntu, RHEL, Rocky) no requieren corregir la propiedad, ya que todas estas distribuciones utilizan SSSD para la integración con Active Directory, que asigna identificadores de usuario estables.

Requisitos previos

Antes de migrar un Linux, compruebe lo siguiente: WorkSpace

Cómo migrar un WorkSpace

Uso de AWS Consola de administración

Uso de AWS CLI

Utilice el migrate-workspace comando para WorkSpace migrar un paquete a otro:

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

Para encontrar los ID de paquete de destino disponibles:

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

Supervisión del estado de la migración

La migración suele tardar entre 20 y 30 minutos. Supervise el estado WorkSpace:

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

Las WorkSpace transiciones pasan por los siguientes estados: AVAILABLE → PENDING → AVAILABLE (en caso de éxito) o ERROR (en caso de error). Si la migración falla durante el aprovisionamiento, el plano de control restaura automáticamente el original WorkSpace.

Post-migration verificación

Una vez finalizada la migración, compruebe lo siguiente:

Compruebe el WorkSpace estado

Confirme WorkSpace que está en AVAILABLE estado en la AWS consola o mediante la CLI.

Verifique el inicio de sesión del usuario

Haga que el usuario inicie sesión WorkSpace y confirme que el escritorio se carga correctamente.

Compruebe el registro de migración

Para las migraciones de AL2, consulte el registro de migración para obtener más información sobre los cambios:

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

Este registro muestra los ID de usuario antiguos y nuevos, la cantidad de archivos modificados en cada fase y las marcas de tiempo.

Compruebe el estado de la fase 2

Para comprobar si la migración en segundo plano se ha completado:

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

Qué ocurre durante la migración

Al iniciar una migración, se realizan los siguientes pasos:

El directorio principal del usuario se almacena en un volumen de EBS independiente que se conserva durante la migración. Todos los archivos que contiene /home/username sobreviven a la transición, incluidos los documentos, las claves SSH, la configuración del shell y los datos de la aplicación.

Migración desde Amazon Linux 2

Las migraciones desde Amazon Linux 2 implican pasos adicionales que se gestionan automáticamente. En esta sección se explica qué ocurre y por qué.

Por qué las migraciones de AL2 son diferentes

Amazon Linux 2 utiliza Winbind para la integración con Active Directory, mientras que todas las distribuciones de Linux más recientes (Ubuntu, RHEL, Rocky) utilizan SSSD. Estos dos sistemas asignan diferentes ID de usuario POSIX al mismo usuario de Active Directory:

Tras la migración, todos los archivos del directorio principal del usuario pertenecen al antiguo UID de Winbind. El usuario no puede acceder a sus propios archivos hasta que se corrija la propiedad para que coincidan con el nuevo UID del SSSD.

Además, Amazon Linux 2 utiliza el entorno de escritorio MATE (GNOME 2), mientras que las distribuciones más recientes utilizan GNOME 3.x. Los archivos de configuración de MATE entran en conflicto con GNOME 3.x y deben limpiarse para garantizar que el escritorio funcione correctamente.

Two-phase corrección de propiedad

Para evitar tiempos de espera en el aprovisionamiento, la corrección de la propiedad se divide en dos fases.

Fase 1 (durante el aprovisionamiento)

Corrige la propiedad de los archivos críticos del escritorio necesarios para el inicio de sesión inmediato:

La fase 1 se completa rápidamente, independientemente del tamaño total del directorio principal, lo que garantiza que el aprovisionamiento nunca falle debido al gran tamaño de los directorios principales.

Fase 2 (en segundo plano, después del reinicio)

Corrige la propiedad de todos los archivos restantes:

Limpieza del entorno de escritorio

Durante la migración desde AL2, los siguientes archivos de configuración de escritorio MATE se mueven a un directorio de respaldo dentro del registro de migración ()~/workspace-migration-log-YYYYMMDD/removed-configuration/:

Estos archivos no se eliminan: se mueven al directorio de respaldo y se pueden recuperar si es necesario. Tras la limpieza, el escritorio se carga con el aspecto predeterminado de GNOME 3.x.

Restauración del contexto de SELinux

Cuando el objetivo de la migración es RHEL o Rocky Linux, los contextos de seguridad de SELinux siempre se restauran en todo el directorio principal del usuario (/home/username), independientemente del sistema operativo de origen. Esto se aplica a todas las rutas de migración que se dirigen a una SELinux-enabled distribución, incluidas las siguientes:

En todos los casos, la restauración del contexto garantiza que los archivos tengan las etiquetas de seguridad correctas para la política de SELinux de la distribución de destino.

La restauración del contexto se ejecuta en dos fases, coincidiendo con la corrección de propiedad:

Corrección automática del directorio principal según la RFC 2307

Active Directory admite los atributos RFC 2307 (también conocidos como «atributos de Unix»), que permiten a los administradores especificar las propiedades de los usuarios POSIX, incluida la ruta del directorio principal (). unixHomeDirectory SSSD respeta este atributo, mientras que Winbind en AL2 lo ignoró y siempre lo usó. /home/username

Al migrar de AL2 a una SSSD-based distribución, es posible que el objeto de usuario de AD se haya unixHomeDirectory establecido en una ruta diferente (por ejemplo,). /home/CORP/jsmith En ese caso, SSSD convierte el directorio principal del usuario en esa ruta. AD-specified Como los datos reales del usuario /home/username provienen de la era AL2, la AD-specified ruta no existe en el volumen.

El sistema de migración detecta esta situación automáticamente:

Esta corrección es permanente: la override_homedir configuración se mantiene en sssd.conf todos los reinicios y futuros reinicios del SSSD.

Habilitar las rutas del directorio principal de la RFC 2307 después de la migración

Si la migración corrigió automáticamente la ruta del directorio principal según la RFC 2307 y quieres que SSSD respete el unixHomeDirectory atributo AD de ahora en adelante, puedes anular la anulación. Se trata de un cambio de configuración avanzado que solo debe realizarse si entiendes las implicaciones.

Para restaurar las rutas del directorio principal de la RFC 2307:

Paso 1: Determine la ruta del directorio AD-specified principal

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

Paso 2: Mueva los datos del usuario a la AD-specified ruta

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

Paso 3: Elimine la configuración override_homedir de//sssd.conf etc/sssd

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

Paso 4: Reiniciar SSSD

sudo systemctl restart sssd

Paso 5: Verifique que el directorio principal se resuelva correctamente

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

Notificaciones de usuario

El sistema de migración utiliza dos mecanismos de notificación para mantener informado al usuario:

Si el usuario no está conectado (por ejemplo, una parada automática a la WorkSpace que no se ha accedido), la fase 2 se ejecuta de forma silenciosa y sin errores.

Migración entre distribuciones modernas

Las migraciones entre distribuciones de Ubuntu, RHEL y Rocky Linux no requieren corregir la propiedad del ID de usuario. Todas estas distribuciones utilizan SSSD para la integración con Active Directory, que asigna identificadores de usuario estables derivados del SID de AD. Los archivos del usuario conservan la propiedad correcta durante la migración.

Las rutas de migración más comunes en esta categoría incluyen:

En las migraciones a destinos de RHEL o Rocky Linux, la restauración del contexto de SELinux siempre se ejecuta para garantizar que los archivos tengan las etiquetas de seguridad correctas para la política de SELinux de la distribución de destino. Esto se aplica independientemente de la distribución de origen. En el caso de los archivos que ya tienen las etiquetas correctas, la restauración no es posible.

Qué conservan los usuarios y qué cambios

¿Qué se conserva

¿Qué cambia

Auto-stop y siempre activas WorkSpaces

Auto-stop WorkSpaces

Para WorkSpaces configurarlos con parada automática (hibernación después de un tiempo de espera de inactividad):

Always-on WorkSpaces

Para estar siempre activo: WorkSpaces

Limitaciones conocidas

Resolución de problemas

La migración falla durante el aprovisionamiento

Si la migración falla y WorkSpace vuelve al ERROR estado, el plano de control intenta restaurar automáticamente el original WorkSpace. Compruebe los registros de aprovisionamiento:

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

Causas habituales:

El usuario no puede iniciar sesión después de la migración

El escritorio parece estar roto o tiene un tema incorrecto

Esto suele ocurrir cuando se migra desde AL2 y algunos archivos de configuración de MATE no se limpian. Para restablecer el escritorio a los valores predeterminados:

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

# Log out and log back in

Tras la migración, la propiedad de los archivos es incorrecta

Si no se puede acceder a los archivos del directorio principal después de una migración a AL2, es posible que la fase 2 siga ejecutándose:

# 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 fase 2 ha finalizado, pero algunos archivos siguen teniendo un propietario incorrecto, puede corregirlos manualmente:

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

Ubicaciones de archivo de registro