Partilhar via


Usar o ALAR (Reparo Automático) do Linux do Azure para corrigir uma VM do Linux

Aplica-se a: ✔️ VMs do Linux

Na próxima vez que você precisar executar um reparo em sua VM (máquina virtual) Linux do Azure, poderá automatizar o trabalho colocando os scripts ALAR (Reparo Automático do Linux no Azure) para trabalhar para você. Você não precisa mais executar o trabalho manualmente. Esses scripts simplificam o processo de recuperação e permitem que até mesmo usuários inexperientes recuperem sua VM Linux facilmente.

O ALAR utiliza a extensão de reparo de VM descrita em Reparar uma VM Linux usando os comandos de reparo da Máquina Virtual do Azure.

O ALAR abrange os seguintes cenários de reparo:

  • Cenários sem inicialização
    • Malformado /etc/fstab
      • erro de sintaxe
      • disco ausente
    • Initrd danificado ou linha de initrd ausente no /boot/grub/grub.cfg
    • O último kernel instalado não é inicializável
    • Instalação ou configuração do GRUB/EFI danificada
    • Desligamentos forçados de espaço em disco/auditado
  • Problemas de configuração
    • O console serial e o número de série do GRUB estão configurados incorretamente ou estão ausentes
    • Configuração incorreta do Sudo

Como usar o ALAR

Os scripts ALAR usam a extensão az vm repair, o comando run e sua opção --run-id. O valor da --run-id opção para a recuperação automatizada é linux-alar2. Para corrigir uma VM do Linux usando um script ALAR, siga estas etapas:

Observação

A função Colaborador de VM não fornece permissões suficientes para executar essas operações com script, pois elas exigem permissões para ler, gravar e excluir recursos no grupo de recursos que inclui a VM de destino. Portanto, funções como Colaborador ou Proprietário no nível do grupo de recursos são necessárias.

  1. Crie uma VM de resgate:

    az vm repair create --verbose --resource-group <RG-NAME> --name <VM-NAME>
    
    • Atualmente, há três parâmetros que solicitam valores se eles não forem fornecidos na linha de comando. Adicione esses parâmetros e valores ao comando para uma execução não interativa
      • --repair-username <RESCUE-USERNAME>
      • --repair-password <RESCUE-PASS>
      • --associate-public-ip
    • Consulte a documentação do az vm repair para obter mais opções que podem ser usadas para controlar a criação da VM de reparo.
  2. Execute o linux-alar2 script, juntamente com parâmetros para uma ou mais ações do ALAR na VM de resgate:

    az vm repair run --verbose --resource-group <RG-NAME> --name <VM-NAME> --run-id linux-alar2 --parameters <action1,action2,...> --run-on-repair
    

    Consulte o seguinte para obter nomes de ação válidos.

  3. Alterne a cópia do disco do sistema operacional de volta para a VM original e exclua os recursos temporários:

    az vm repair restore --verbose --resource-group <RG-NAME> --name <VM-NAME> 
    

    Observação

    Os discos originais e novos não são excluídos durante a restore fase.

Em todos os comandos de exemplo, estes são os parâmetros mostrados:

  • RG-NAME: o nome do grupo de recursos que contém a VM quebrada.
  • VM-NAME: O nome da VM quebrada.
  • RESCUE-USERNAME: o usuário criado na VM de reparo para logon. É o equivalente ao usuário criado em uma nova VM no portal do Azure.
  • RESCUE-PASS: A senha para RESCUE-USERNAME, entre aspas simples. Por exemplo: 'password!234'.
  • action1,action2, etc.: uma ou mais das ações definidas disponíveis para aplicar à VM quebrada. Consulte o seguinte para obter uma lista completa de ações e no ALAR GitHub ReadMe. Você pode passar uma ou mais ações que são executadas em sequência. Para várias operações, delinee-as usando vírgulas sem espaços, como fstab,sudo.

Quanto às ações da ALAR

fstab

Essa ação remove todas as linhas no arquivo /etc/fstab que não são necessárias para inicializar um sistema. Primeiro, uma cópia do arquivo original é feita para referência. Quando o sistema operacional é iniciado, o administrador pode editar o fstab para corrigir quaisquer erros que não permitiram uma reinicialização do sistema antes.

Para obter mais informações sobre problemas com um arquivo /etc/fstab malformado, consulte Solucionar problemas de inicialização da VM do Linux devido a erros no fstab.

efifixo

Essa ação pode ser usada para reinstalar o software necessário para inicializar a partir de uma VM GEN2. O arquivo grub.cfg também é regenerado.

grubfix

Essa ação pode ser usada para reinstalar o GRUB e regenerar o arquivo grub.cfg .

initrd (disco RAM inicial usado no processo de inicialização do Linux)

Essa ação pode ser usada para corrigir um initrd ou initramfs corrompido ou criado incorretamente.

Para que o initrd ou initramfs seja criado corretamente, adicione os módulos hv_vmbus, hv_netvsce hv_storvsc à imagem.

Problemas de inicialização relacionados ao Initrd podem aparecer como os seguintes sintomas registrados.

VFS não está sincronizando Nenhum 'init' funcional encontrado

Em ambos os casos, as informações a seguir são registradas antes que as entradas de erro sejam registradas.

Falha ao desempacotar

kernel

Essa ação altera o kernel padrão substituindo o kernel padrão/quebrado por uma versão instalada anteriormente.

Para obter mais informações sobre mensagens que podem estar registradas no console serial para eventos de inicialização relacionados ao kernel, consulte Como recuperar uma máquina virtual linux do Azure de problemas de inicialização relacionados ao kernel.

serialconsole

Essa ação corrige uma configuração de console serial incorreta ou malformada para o kernel Linux ou GRUB. Recomendamos que você execute essa ação nos seguintes casos:

  • Nenhum menu GRUB é exibido na inicialização da VM.
  • Nenhuma informação relacionada ao sistema operacional é gravada no console serial.

sudo

A sudo ação redefine as permissões no arquivo /etc/sudoers e todos os arquivos em /etc/sudoers.d para os modos 0440 necessários e verifique outras práticas recomendadas. Uma verificação básica é executada para detectar e relatar entradas de usuário duplicadas e mover somente o arquivo /etc/sudoers.d/waagent se for encontrado em conflito com outros arquivos.

auditado

Se a VM for desligada imediatamente após a inicialização devido à configuração do daemon de auditoria, use esta ação. Essa ação modifica a configuração do daemon de auditoria (no arquivo /etc/audit/auditd.conf) alterando o valor de HALT configurado para qualquer parâmetro action para SYSLOG, sem forçar o sistema a desligar. Em um ambiente LVM (Logical Volume Manager), se o volume lógico que contém os logs de auditoria estiver cheio e houver espaço disponível no grupo de volumes, o volume lógico poderá ser estendido por 10% do tamanho atual. No entanto, se você não estiver usando um ambiente LVM ou não houver espaço disponível, somente o auditd arquivo de configuração será alterado.

Importante

Essa ação altera a postura de segurança da VM alterando a configuração de daemon de auditoria para que o problema de desligamento da VM possa ser resolvido. Depois que a VM estiver em execução e acessível, você precisará avaliar a configuração e potencialmente revertê-la para o estado original. Para essa finalidade, um backup do arquivo auditd.conf é criado em /etc/audit pela ação ALAR.

Limitação

Não há suporte para VMs clássicas.

Próximas etapas

Se você tiver um bug ou quiser solicitar um aprimoramento para a ferramenta ALAR, poste um comentário no GitHub.

Você também pode encontrar as informações mais recentes sobre a ferramenta ALAR no GitHub.

Entre em contato conosco para obter ajuda

Se você tiver dúvidas, poderá fazer o suporte à comunidade do Azure. Você também pode enviar comentários sobre o produto para a comunidade de comentários do Azure.

Aviso de isenção de responsabilidade para contatos de terceiros

A Microsoft fornece informações de contato de terceiros para ajudá-lo a encontrar informações adicionais sobre esse tópico. Essas informações de contato podem ser alteradas sem aviso prévio. A Microsoft não garante a precisão das informações de contato de terceiros.