Avamar: Cómo realizar una restauración a nivel de archivos de Linux VMware sin usar el usuario raíz mediante sudo

Antecedentes en FLR de Avamar:   
La restauración a nivel de archivos de Avamar es una solución de recuperación sin agente que se puede utilizar para restaurar uno o más archivos invitados desde un respaldo de imagen de máquina virtual. El mecanismo que se utiliza para facilitar la restauración a nivel de archivos son las herramientas de VMware y vSphere API guest operation.functions. El respaldo de imagen de máquina virtual monta el disco virtual (.vmdk) en el proxy de Avamar durante la navegación. Después de seleccionar los archivos para la restauración, se copiarán el archivo de transferencia del proxy a la VM de destino.    

Requisitos obligatorios de FLR:    

1. La máquina virtual de destino debe estar encendida.
2. La máquina virtual de destino debe tener instaladas las herramientas de VMware y el servicio debe estar en ejecución durante las operaciones de restauración. 
3. El administrador de Avamar o la operación de respaldo/restauración/usuario de Avamar deben tener credenciales válidas en el invitado de destino (requisito del SDK de operaciones de invitado de VMware) y estas credenciales se deben ingresar al inicio de las operaciones de restauración a nivel de archivos.
4. El usuario invitado de destino debe tener privilegios para escribir la ubicación o la operación fallará. Para la máquina virtual de Windows, el usuario de la VM de restauración también debe tener privilegios para escribir sin elevación de UAC. Para las máquinas virtuales linux, la VM de restauración debe poder escribir sin sudo. 

Requisitos opcionales de FLR: Se requiere para un método de transferencias HTTPS más rápidas. 

1. Las máquinas virtuales de destino deben tener acceso TCP 443 a las máquinas virtuales proxy.
2. Para máquinas virtuales Linux, se debe instalar una aplicación wget moderna dentro de la máquina virtual antes de la operación de restauración.  

Si no se cumplen los requisitos operacionales, se observan las siguientes advertencias antes de enviar el trabajo:   

Si la máquina virtual de destino no puede realizar una conexión HTTPS al proxy:    



Dentro del proxy: /usr/local/avamarclient/bin/logs/VSphereWebService.log, consulte el código de salida wget non zero 

[VWS - DEBUG] 2020/02/24 15:56:20 TID=2403 MID=398040: sGuestExeFullFilename = /usr/bin/wget --no-check -certificate --bytes -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 --nvidia -t 1 -T 10 https://182proxy.burlington.lab:443/test

[VWS - FUNC] 24/02/2020 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 se realizó correctamente. Ret: 4

O

Linux sin wget:     



Dentro del 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 --hexadecimal -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/02/20 24 15:56:20 TID=2403 MID=398042: sExeFullPath = /usr/bin/wget
[VWS - DEBUG] 2020/02/24 15:56:20 TID=24 03 MID=398043: sParameters = --no-check-certificate --bp -t 1 -T 10 https://182proxy.burlington.lab:443/test
[VWS - ERROR] 2020/02/24 15:56:20 TID=140363826202979 MID=398068: Error startprograminguest: Falla de SOAP 1.1: "":ServerFaultCode [sin subcódigo] "No se encontró el
archivo /usr/bin/wget"
Detalle: <FileNotFoundFault xmlns="urn:vim25" xsi:type="FileNotFound"><file>/usr/bin/wget</file></FileNotFoundFault>

O bien,

[VWS: DEBUG] 2020/02/24 15:34:22 TID=2397 MID=395783: StartProgramInGuest se realizó correctamente. Ret: 1

Función opcional de FLR: Restaurar la lista de control de acceso ( ACL)

De manera predeterminada, esta función no está habilitada.   
Resultado:    
Sin la función ACL (valor predeterminado):    
Todos los archivos restaurados desde la función de restauración a nivel de archivos pertenecerán a las credenciales de invitado de vm ingresadas durante las operaciones de FLR y no se configurarán permisos de archivo anteriores.

Con la función ACL habilitada:    
Si el usuario desea que los archivos restaurados tengan la propiedad y los permisos del archivo de creación original configurados en el archivo restaurado, debe habilitar esta función opcional.



Resultado:    
Durante las operaciones de restauración, se crearán nuevos archivos como los usuarios de la VM de FLR, pero al final de una restauración, el flujo de trabajo de ACL se ejecutará y configurará la propiedad y el permiso de archivo de vuelta al estado original. 

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

[VWS - FUNC] 03/03/2020 03:42:29 TID=140664473914958 MID=254066: VirtualMachineWs::ExecuteRestoreAcl INTRO
[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 a /tmp/7fc01f28-c871-4835-948d-2d8a14bd1d8b.xml
[VWS - FUNC] 2020/03/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-2d8a14bd 1d8b.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 INTRO
[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 correcto
[VWS - DEBUG] 2020/03/03 03:42:47 TID=3662 MID=254441: StartProgramInGuest se realizó correctamente. Ret: 0
[VWS - FUNC] 03/03/2020 03:42:47 TID=140664473914958 MID=254519: VirtualMachineWs::ExecuteRestoreAcl LEAVE

En algunas distribuciones de Linux, como Ubuntu o Photon Os, los usuarios raíz del sistema operativo no están configurados ni configurados de manera predeterminada. En su lugar, los administradores de Linux dependen del comando sudo para ejecutar operaciones de elevación.  

Sin embargo, debido a las herramientas de VMware y VMware SDK, la mayoría de las operaciones (VM_LoginInGuest, CopyFileFromHostToGuest y ListFilesInGuest) no es posible para que las herramientas de VMware ejecuten el comando sudo. 

Cuando las operaciones de restauración se realizan con un usuario normal, la operación puede fallar debido a privilegios de invitado de destino insuficientes.

Para los ambientes en los que el usuario raíz de Linux está deshabilitado, no está configurado o debido a problemas de seguridad no se puede compartir, tenga en cuenta los siguientes pasos de resolución:     

Opción 1. Restaure a una ubicación alternativa como usuario no root. 
Ejemplo:    
Archivo de origen:  /root/test (carpeta/archivo restringido)
Archivo de destino:  /home/flruser/ (ubicación no restringida) Creaciones de
vm huéspedes:  Resultado de "flruser":

    
Durante la navegación de FLR, los discos virtuales se montan en el proxy de Avamar y se muestran en la interfaz del usuario. Esto incluye todas las carpetas y archivos, navegue por la carpeta /root y seleccione file1.txt, seleccione "restore everything to a different location" y navegue hasta /home/flruser/ como absolution Destination.



Resultado:   
el archivo root/test se restaurará en /home/flruser/test Nota: El archivo tendrá permiso para usuarios invitados de
FLR. 

Opción 2. Restaure a una ubicación alternativa con la opción Restore ACL mediante la función sudo. 
En Avamar 18.2, instale el hot fix del proxy 318791 (o posterior)
En Avamar 19.2, instale el hot fix de proxy 318791 (o posterior) Estos hot fixes agregan la

nueva función "enablesudouserrestore" que, de manera predeterminada, está deshabilitada.

Instrucciones para habilitar la función sudo:
en un proxy de Avamar:

1. En el proxy, instale el hot fix arriba
2. Edite /usr/local/avamarclient/bin/config.xml, agregue/edite la línea (<enablesudouserrestore>1</enablesudouserrestore>) en el archivo
3. Reinicie FLR mediante el comando: service vmwareflr restart

En todas las máquinas virtuales de Linux en las que se activará la función FLR:    

1. Cree un usuario de FLR dedicado:  ejemplo: flruser.  Para mayor seguridad, el shell se puede deshabilitar para esta cuenta
2. Copie el archivo binario /usr/local/avamarclient/bin/RestoreAcl del proxy de Avamar a la VM de destino mediante la ubicación fija /usr/bin/RestoreACL y establezca el permiso en 755 mediante chmod

3. Modifique /etc/sudoers para permitir que el usuario de FLR del paso 1 excute el archivo binario RestoreACL sin contraseña. 

Opción 3: Restaure a la ubicación original mediante el método sudo wget con ACL. 

Nota: 

• Esta opción solo está disponible cuando https de red opcional está disponible y cuando la selección de restauración tiene >5 Mb o 10 archivos seleccionados.
• El uso de la GUI de Avamar para navegar por las ubicaciones de VM de destino en vivo con una ubicación de carpetas restringidas puede fallar, pero escribir explícitamente en "Absolution Destination" seguirá funcionando. 

1. Realice los pasos de la opción 2 en el proxy para habilitar la restauración de ACL.
2. En el proxy de Avamar, edite /usr/local/avamarclient/bin/wget_linux_script.template 

3. Reinicie FLR mediante el comando: service vmwareflr restart
4. En cada máquina virtual de Linux en la que se utilizará la restauración de FLR a la ubicación original, modifique /etc/sudoers para permitir que el usuario de FLR del paso 1 ejecute wget binary sin contraseña.