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 enquanto preserva 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 trabalho quando necessário.

Caminhos de migração compatíveis

A tabela a seguir mostra os sistemas operacionais de origem e de destino compatíveis com a WorkSpace migração para 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 um novo WorkSpaces não pode ser criado 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 a correção automática da propriedade da ID do usuário e a 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 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 passam 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 restaura automaticamente o original. WorkSpace

Post-migration verificação

Após a conclusão da migração, verifique o seguinte:

Verifique o WorkSpace status

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

Verificar o login do usuário

Faça com que o usuário faça login no WorkSpace e confirme se o desktop está sendo carregado 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 sobreviverão à transição, incluindo documentos, chaves SSH, configuração do shell e dados do aplicativo.

Migrando do Amazon Linux 2

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

Por que as migrações do 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 entram em conflito com o GNOME 3.x e devem ser limpos para garantir um desktop funcional.

Two-phase correção de propriedade

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

Fase 1 (durante o provisionamento)

Corrige a propriedade de arquivos essenciais para o desktop necessários para o 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 de 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 visam 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 ocorre em duas fases, correspondendo à correção de propriedade:

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

O Active Directory oferece suporte aos atributos RFC 2307 (também conhecidos como “Atributos Unix”), que permitem aos administradores especificar as 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 sssd.conf nas reinicializações e futuras reinicializações do SSSD.

Habilitando 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ê pode reverter a substituição. Essa é uma alteração de configuração avançada que só deve ser executada 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: reinicie o SSSD

sudo systemctl restart sssd

Etapa 5: Verificar se o diretório inicial está 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 foi 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 da 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 de 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 não é operacional.

O que os usuários mantêm e o que muda

O que é preservado

O que muda

Auto-stop e sempre ligado WorkSpaces

Auto-stop WorkSpaces

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

Always-on WorkSpaces

Para estar sempre ativo 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 pode fazer login após a migração

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

Isso normalmente 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 ficarem inacessíveis após a migração do 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