Avamar: Como realizar uma restauração em nível de arquivo da VMware do Linux sem que o usuário root utilize o sudo

Segundo plano na FLR do Avamar:
A restauração em nível de arquivo do Avamar é uma solução de recuperação sem agente que pode ser usada para restaurar um ou mais arquivos de convidado a partir de um backup de imagem de máquina virtual. Os mecanismos usados para facilitar a restauração em nível de arquivo são as ferramentas da VMware e as funções de operação de convidados da API do vSphere. O backup de imagem de máquina virtual monta o disco virtual (.vmdk) no proxy do Avamar durante a pesquisa. Depois que os arquivos forem selecionados para restauração, eles serão copiados e transferidos do proxy para a VM de destino.

Requisitos obrigatórios da FLR:

1. A máquina virtual de destino deve estar ligada.
2. A máquina virtual de destino deve ter as ferramentas da VMware instaladas e o serviço deve estar em execução durante as operações de restauração. 
3. O administrador ou o usuário de operações de backup/restauração do Avamar deve ter credenciais válidas no convidado de destino (requisito do SDK de operações de convidado da VMware). Essas credenciais precisam ser inseridas no início das operações de restauração em nível de arquivo.
4. O usuário convidado de destino deve ter privilégios para gravar o local ou a operação que falhar. Para a máquina virtual Windows, o usuário da VM de restauração também precisa ter privilégios para gravar sem elevação de UAC. Para máquinas virtuais Linux, a VM de restauração deve ser capaz de gravar sem sudo. 

Requisitos opcionais da FLR: Obrigatórios para o método de transferências HTTPS mais rápido. 

1. As máquinas virtuais de destino devem ter acesso TCP 443 às máquinas virtuais de proxy.
2. Para máquinas virtuais Linux, um aplicativo wget moderno deve ser instalado dentro da máquina virtual antes da operação de restauração.  

Se os requisitos operacionais não forem cumpridos, os seguintes avisos serão exibidos antes do envio do trabalho:

Se a VM de destino não puder estabelecer uma conexão HTTPS com o proxy:



No proxy: /usr/local/avamarclient/bin/logs/VSphereWebService.log, consulte o código de saída wget sem ser zero

[VWS - DEBUG] 2020/02/24 15:56:20 TID=2403 MID=398040: sGuestExeFullFilename = /usr/bin/wget --no-check-certificate --spider -t 1 -T 10 https://182proxy.burlington.lab:443/test
[VWS - DEBUG] 2020/02/24 15:56:20 TID=2403 MID=398041: sUnicodeExeDir = /usr/bin
[VWS - DEBUG] 2020/02/24 15:56:20 TID=2403 MID=398042: sExeFullPath = /usr/bin/wget
[VWS - DEBUG] 2020/02/24 15:56:20 TID=2403 MID=398043: sParameters = --no-check-certificate --spider -t 1 -T 10 https://182proxy.burlington.lab:443/test

[VWS - FUNC]  2020/02/24 15:56:2 TID=3662 MID=254389: VirtualMachineWs::CheckProcessStatus ENTER
[VWS - DEBUG] 2020/02/24 15:56:2 TID=3662 MID=254390: ullPid = 3053
[VWS - WARN]  2020/02/24 15:56:2 TID=140664473914958 MID=254428: CheckProcessStatus Succeeded
[VWS - DEBUG] 2020/02/24 15:56:2  TID=3662 MID=254441: StartProgramInGuest Succeeded. Ret: 4

Ou
  
Linux sem wget:



No proxy: /usr/local/avamarclient/bin/logs/VSphereWebService.log, consulte:

[VWS - DEBUG] 2020/02/24 15:56:20 TID=2403 MID=398040: sGuestExeFullFilename = /usr/bin/wget --no-check-certificate --spider -t 1 -T 10 https://182proxy.burlington.lab:443/test
[VWS - DEBUG] 2020/02/24 15:56:20 TID=2403 MID=398041: sUnicodeExeDir = /usr/bin
[VWS - DEBUG] 2020/02/24 15:56:20 TID=2403 MID=398042: sExeFullPath = /usr/bin/wget
[VWS - DEBUG] 2020/02/24 15:56:20 TID=2403 MID=398043: sParameters = --no-check-certificate --spider -t 1 -T 10 https://182proxy.burlington.lab:443/test
[VWS - ERROR] 2020/02/24 15:56:20 TID=140363826202979 MID=398068: StartProgramInGuest Error: SOAP 1.1 fault: "":ServerFaultCode [no subcode]
"File /usr/bin/wget was not found"
Detail: <FileNotFoundFault xmlns="urn:vim25" xsi:type="FileNotFound"><file>/usr/bin/wget</file></FileNotFoundFault>

Ou

[VWS - DEBUG] 2020/02/24 15:34:22 TID=2397 MID=395783: StartProgramInGuest Succeeded. Ret: 1

Recurso opcional da FLR: Restaurar Lista de Controle de Acesso (ACL) 

Por padrão, esse recurso não está ativado.
Resultado:
Sem o recurso ACL (padrão):
Todos os arquivos restaurados a partir do recurso de restauração em nível de arquivo serão de propriedade do usuário de credenciais de convidado da VM inserido durante as operações de FLR, e as permissões de arquivo anteriores não serão definidas.

Com o recurso ACL ativado:
Se o usuário quiser que os arquivos restaurados tenham a propriedade do arquivo de criação original e as permissões definidas no arquivo restaurado, ele precisará ativar esse recurso opcional.



Resultado:
Durante as operações de restauração, os novos arquivos serão criados como usuários da VM de FLR, mas no final de uma restauração, o fluxo de trabalho da ACL será executado e definirá a propriedade e a permissão de arquivo de volta ao estado original. 

No proxy: /usr/local/avamarclient/bin/logs/VSphereWebService.log, consulte:

[VWS - FUNC] 2020/03/03 03:42:29 TID=140664473914958 MID=254066: VirtualMachineWs::ExecuteRestoreAcl ENTER
[VWS - FUNC] 2020/03/03 03:42:29 TID=140664473914958 MID=254067: VirtualMachineWs::ExecuteRestoreAcl RestoreAcl Input file created
[VWS - FUNC] 2020/03/03 03:42:29 TID=140664473914958 MID=254068: VirtualMachineWs::ExecuteRestoreAcl Input File transfer /usr/local/avamarclient/bin/7fc01f28-c871-4835-948d-2d8a14bd1d8b.xml to /tmp/7fc01f28-c871-4835-948d-2d8a14bd1d8b.xml
[VWS - FUNC] 2020/03/03 03:42:32 TID=140664473914958 MID=254140: VirtualMachineWs::ExecuteRestoreAcl Exe File transfer /usr/local/avamarclient/bin/RestoreAcl to /tmp/7fc01f28-c871-4835-948d-2d8a14bd1d8b.exe
[VWS - DEBUG] 2020/03/03 03:42:40 TID=3662 MID=254349: sGuestExeFullFilename = /tmp/7fc01f28-c871-4835-948d-2d8a14bd1d8b.exe /tmp/7fc01f28-c871-4835-948d-2d8a14bd1d8b.xml 0001
[VWS - FUNC] 2020/03/03 03:42:42 TID=3662 MID=254389: VirtualMachineWs::CheckProcessStatus ENTER
[VWS - DEBUG] 2020/03/03 03:42:42 TID=3662 MID=254390: ullPid = 3053
[VWS - WARN] 2020/03/03 03:42:47 TID=140664473914958 MID=254428: CheckProcessStatus Succeeded
[VWS - DEBUG] 2020/03/03 03:42:47 TID=3662 MID=254441: StartProgramInGuest Succeeded. Ret: 0
[VWS - FUNC] 2020/03/03 03:42:47 TID=140664473914958 MID=254519: VirtualMachineWs::ExecuteRestoreAcl LEAVE

Em algumas distribuições do Linux, como Ubuntu ou Photon Os, os usuários root do SO não são configurados por padrão. Em vez disso, os administradores do Linux dependem do comando sudo para executar operações de elevação.  

No entanto, devido às ferramentas da VMware e ao VMware SDK, a maioria das operações (VM_LoginInGuest, CopyFileFromHostToGuest e ListFilesInGuest) não permite que as ferramentas da VMware executem o comando sudo. 

Quando as operações de restauração são realizadas com um usuário normal, elas poderão falhar devido a privilégios insuficientes de convidado de destino.

Nos ambientes em que o usuário root do Linux está desativado, não configurado ou não pode ser compartilhado devido a problemas de segurança, considere as seguintes etapas de resolução:

Opção 1. Restaurar em local alternativo como usuário não root. 
Exemplo:
Arquivo de origem:  /root/test (pasta/arquivo restrito)
Arquivo de destino:  /home/flruser/ (local não restrito) 
Criações do VM Guest:  "flruser"  

Resultado:
Durante a pesquisa da FLR, os discos virtuais são montados no proxy do Avamar e exibidos na interface do usuário. Isso inclui todas as pastas e arquivos. Procure a pasta /root, selecione file1.txt, marque a opção "Restore everything to a different location" e procure ou digite /home/flruser/ no campo Absolution Destination.



Resultado:
o arquivo root/test será restaurado em /home/flruser/test 
Observe que o arquivo terá permissão de usuários convidados FLR. 

Opção 2. Restaurar em local alternativo com a opção Restore ACL usando o recurso sudo. 
No Avamar 18.2, instale o hotfix 318791 (ou posterior) do proxy
No Avamar 19.2, instale o hotfix 318791 (ou posterior) do proxy 

Esses hotfixes adicionam o novo recurso "enablesudouserrestore" que é desativado por padrão.

Instruções para ativar o recurso sudo:
Em um proxy do Avamar:

1. No proxy, instale o hotfix acima
2. Edite /usr/local/avamarclient/bin/config.xml, adicione/edite a linha (<enablesudouserrestore>1</enablesudouserrestore>) no arquivo
3. Reinicie a FLR por meio do comando: service vmwareflr restart

Em cada máquina virtual Linux onde o recurso FLR estiver ativo:

1. Crie um usuário FLR dedicado:  flruser de exemplo.  Para maior segurança, o shell pode ser desativado para esta conta
2. Copie o binário /usr/local/avamarclient/bin/RestoreAcl do proxy do Avamar e cole na VM de destino, usando o local corrigido /usr/bin/RestoreACL, e defina a permissão para o 755 usar chmod

3. Modifique /etc/sudoers para permitir que o usuário FLR da Etapa 1 execute o binário RestoreACL sem senha. 

Opção 3: Restaurar no local original usando o método sudo wget com ACL. 

Nota: 

• Essa alternativa ficará acessível somente quando a rede opcional HTTPS estiver disponível e quando a seleção de restauração tiver >5 Mb ou 10 arquivos selecionados.
• O uso da GUI do Avamar para procurar as localizações de VM de destino em tempo real com local de pastas restrito pode falhar, mas a opção de digitar diretamente no campo "Absolution Destination" continuará funcionando. 

1. Execute as etapas da Opção 2 no proxy para ativar a restauração de ACL.
2. No proxy do Avamar, edite edit /usr/local/avamarclient/bin/wget_linux_script.template 

3. Reinicie a FLR por meio do comando: service vmwareflr restart
4. Em cada máquina virtual Linux onde a restauração FLR no local original for usada, modifique /etc/sudoers para permitir que o usuário FLR da Etapa 1 execute o binário wget sem senha.