As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

Migrar um Linux WorkSpace para um sistema operacional diferente

Você pode migrar um Linux existente WorkSpace para um pacote de sistema operacional Linux diferente, preservando o diretório inicial, os arquivos e os dados do usuário. A migração substitui o volume raiz (sistema operacional) por um novo pacote, mantendo o volume do usuário (/home) intacto. Isso é diferente de uma reconstrução, que atualiza o volume raiz com o mesmo pacote de sistema operacional.

O WorkSpace recurso Migrate gerencia todo o processo automaticamente, incluindo a correção da propriedade do arquivo e a limpeza do ambiente de desktop quando necessário.

Caminhos de migração compatíveis

A tabela a seguir mostra os sistemas operacionais de origem e destino suportados para a WorkSpace migração do Linux.

O Amazon Linux 2 é uma fonte de migração válida, mas não é um destino de migração válido. O Amazon Linux 2 chegou ao fim da vida útil e novos WorkSpaces não podem ser criados com pacotes AL2.

Todos os caminhos de migração entre Ubuntu, RHEL e Rocky Linux são suportados em ambas as direções. Você pode atualizar (por exemplo, RHEL 8 → RHEL 9) ou fazer o downgrade (por exemplo, Ubuntu 24.04 → Ubuntu 22.04). Você também pode migrar entre famílias de distribuição (por exemplo, Rocky 9 → Ubuntu 24.04 ou RHEL 9 → Rocky 8). A única restrição é que você não pode migrar um WorkSpace para o mesmo pacote que ele já está usando.

As migrações do Amazon Linux 2 exigem correção automática de propriedade do ID de usuário e limpeza do ambiente de desktop. As migrações entre todas as outras distribuições (Ubuntu, RHEL, Rocky) não exigem correção de propriedade porque todas essas distribuições usam SSSD para integração com o Active Directory, que atribui IDs de usuário estáveis.

Pré-requisitos

Antes de migrar um Linux WorkSpace, verifique o seguinte:

Como migrar um WorkSpace

Usar o AWS Console de Gerenciamento

Usar o AWS CLI

Use o migrate-workspace comando para migrar um WorkSpace para um pacote diferente:

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

Para encontrar os IDs de pacotes de destino disponíveis:

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

Monitorando o status da migração

A migração normalmente leva de 20 a 30 minutos. Monitore o WorkSpace status:

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

As WorkSpace transições pelos seguintes estados: AVAILABLE → PENDING → AVAILABLE (em caso de sucesso) ou ERROR (em caso de falha). Se a migração falhar durante o provisionamento, o plano de controle restaurará automaticamente o original. WorkSpace

Post-migration verificação

Depois que a migração for concluída, verifique o seguinte:

Verifique o WorkSpace status

Confirme WorkSpace se está no AVAILABLE estado no AWS console ou por meio da CLI.

Verifique o login do usuário

Faça com que o usuário faça login no WorkSpace e confirme se a área de trabalho está carregando corretamente.

Verifique o registro de migração

Para migrações de AL2, revise o registro de migração para obter detalhes sobre o que foi alterado:

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

Esse registro mostra os IDs de usuário antigos e novos, o número de arquivos alterados em cada fase e os registros de data e hora.

Verifique o status da Fase 2

Para verificar se a migração em segundo plano foi concluída:

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

O que acontece durante a migração

Quando você inicia uma migração, as seguintes etapas ocorrem:

O diretório inicial do usuário é armazenado em um volume EBS separado que é preservado durante a migração. Todos os arquivos /home/username sobrevivem à transição, incluindo documentos, chaves SSH, configuração do shell e dados do aplicativo.

Migração do Amazon Linux 2

As migrações do Amazon Linux 2 envolvem etapas adicionais que são processadas automaticamente. Esta seção explica o que acontece e por quê.

Por que as migrações de AL2 são diferentes

O Amazon Linux 2 usa o Winbind para integração com o Active Directory, enquanto todas as distribuições Linux mais recentes (Ubuntu, RHEL, Rocky) usam SSSD. Esses dois sistemas atribuem IDs de usuário POSIX diferentes ao mesmo usuário do Active Directory:

Após a migração, todos os arquivos no diretório inicial do usuário pertencem ao antigo UID do Winbind. O usuário não pode acessar seus próprios arquivos até que a propriedade seja corrigida para corresponder ao novo UID SSSD.

Além disso, o Amazon Linux 2 usa o ambiente de desktop MATE (GNOME 2), enquanto as distribuições mais recentes usam o GNOME 3.x. Os arquivos de configuração do MATE estão em conflito com o GNOME 3.x e devem ser limpos para garantir que a área de trabalho funcione.

Two-phase correção de propriedade

Para evitar tempos limite de provisionamento, a correção de propriedade é dividida em duas fases.

Fase 1 (durante o provisionamento)

Corrige a propriedade de arquivos essenciais para desktop necessários para login imediato:

A fase 1 é concluída rapidamente, independentemente do tamanho total do diretório inicial, garantindo que o provisionamento nunca falhe devido aos grandes diretórios iniciais.

Fase 2 (em segundo plano, após a reinicialização)

Corrige a propriedade de todos os arquivos restantes:

Limpeza do ambiente de desktop

Durante a migração do AL2, os seguintes arquivos de configuração do desktop MATE são movidos para um diretório de backup dentro do log de migração (~/workspace-migration-log-YYYYMMDD/removed-configuration/):

Esses arquivos não são excluídos — eles são movidos para o diretório de backup e podem ser recuperados, se necessário. Após a limpeza, a área de trabalho carrega com a aparência padrão do GNOME 3.x.

Restauração do contexto SELinux

Quando o destino da migração é RHEL ou Rocky Linux, os contextos de segurança do SELinux são sempre restaurados em todo o diretório inicial do usuário (/home/username), independentemente do sistema operacional de origem. Isso se aplica a todos os caminhos de migração que têm como alvo uma SELinux-enabled distribuição, incluindo:

Em todos os casos, a restauração do contexto garante que os arquivos tenham os rótulos de segurança corretos para a política SELinux da distribuição de destino.

A restauração do contexto é executada em duas fases, correspondendo à correção de propriedade:

Correção automática do diretório inicial do RFC 2307

O Active Directory oferece suporte aos atributos RFC 2307 (também conhecidos como “Atributos Unix”), que permitem aos administradores especificar propriedades do usuário POSIX, incluindo o caminho do diretório inicial (). unixHomeDirectory O SSSD respeita esse atributo, enquanto o Winbind no AL2 o ignorou e sempre o usou. /home/username

Ao migrar do AL2 para uma SSSD-based distribuição, o objeto de usuário do AD pode ter sido unixHomeDirectory definido para um caminho diferente (por exemplo,/home/CORP/jsmith). Nesse caso, o SSSD resolve o diretório inicial do usuário para esse AD-specified caminho. Como os dados reais do usuário são /home/username da era AL2, o AD-specified caminho não existe no volume.

O sistema de migração detecta essa situação automaticamente:

Essa correção é permanente — a override_homedir configuração persiste em sssd.conf todas as reinicializações e futuras reinicializações do SSSD.

Ativando os caminhos do diretório inicial do RFC 2307 após a migração

Se a migração corrigiu automaticamente o caminho do diretório inicial do RFC 2307 e você quiser que o SSSD respeite o unixHomeDirectory atributo AD daqui para frente, você poderá reverter a substituição. Essa é uma alteração de configuração avançada que só deve ser realizada se você entender as implicações.

Para restaurar os caminhos do diretório inicial do RFC 2307:

Etapa 1: Determinar o caminho do diretório AD-specified inicial

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

Etapa 2: mover os dados do usuário para o AD-specified caminho

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

Etapa 3: remover a configuração override_homedir de /sssd.conf etc/sssd

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

Etapa 4: reiniciar o SSSD

sudo systemctl restart sssd

Etapa 5: Verificar se o diretório inicial foi resolvido corretamente

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

Notificações ao usuário

O sistema de migração usa dois mecanismos de notificação para manter o usuário informado:

Se o usuário não estiver conectado (por exemplo, uma parada automática WorkSpace que não tenha sido acessada), a Fase 2 será executada silenciosamente sem erros.

Migração entre distribuições modernas

As migrações entre as distribuições Ubuntu, RHEL e Rocky Linux não exigem correção de propriedade do ID do usuário. Todas essas distribuições usam SSSD para integração com o Active Directory, que atribui IDs de usuário estáveis derivadas do AD SID. Os arquivos do usuário mantêm a propriedade correta durante a migração.

Os caminhos de migração comuns nessa categoria incluem:

Para migrações para destinos RHEL ou Rocky Linux, a restauração do contexto do SELinux sempre é executada para garantir que os arquivos tenham os rótulos de segurança corretos para a política SELinux da distribuição de destino. Isso se aplica independentemente da distribuição da fonte. Para arquivos que já têm rótulos corretos, a restauração é autônoma.

O que os usuários mantêm e quais mudanças

O que é preservado

O que muda

Auto-stop e sempre ativo WorkSpaces

Auto-stop WorkSpaces

Para WorkSpaces configurar com parada automática (hibernação após o tempo limite de inatividade):

Always-on WorkSpaces

Para quem está sempre ligado WorkSpaces:

Limitações conhecidas

Solução de problemas

A migração falha durante o provisionamento

Se a migração falhar e ela WorkSpace retornar ao ERROR estado, o plano de controle tentará restaurar automaticamente o original WorkSpace. Verifique os registros de provisionamento:

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

Causas comuns:

O usuário não consegue fazer login após a migração

A área de trabalho parece quebrada ou tem o tema errado

Isso geralmente ocorre ao migrar do AL2 e alguns arquivos de configuração do MATE não foram limpos. Para redefinir a área de trabalho para os padrões:

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

# Log out and log back in

Os arquivos têm propriedade errada após a migração

Se os arquivos no diretório inicial estiverem inacessíveis após uma migração de AL2, a Fase 2 ainda poderá estar em execução:

# 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

Se a Fase 2 tiver sido concluída, mas alguns arquivos ainda tiverem propriedade incorreta, você poderá corrigi-los 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 {} +

Locais de arquivos de log