Avamar: come eseguire un restore a livello di file VMware in Linux senza utilizzare l'utente root con sudo

Informazioni su Avamar FLR:
FLR (File Level Restore) di Avamar è una soluzione di ripristino senza agent che può essere utilizzata per eseguire il restore di uno o più file del guest dal backup dell'immagine di una macchina virtuale. Il meccanismo utilizzato per facilitare il restore a livello di file è dato dagli strumenti VMware e dalle funzioni delle operazioni guest dell'API vSphere. Il backup dell'immagine della macchina virtuale esegue il mounting del disco virtuale (.vmdk) sul proxy Avamar durante la ricerca. Dopo aver selezionato i file per il restore, essi verranno copiati per il trasferimento dal proxy alla VM di destinazione.

Requisiti obbligatori per FLR:

1. La macchina virtuale di destinazione deve essere accesa.
2. La macchina virtuale di destinazione deve disporre degli strumenti VMware installati e il servizio deve essere in esecuzione durante le operazioni di restore. 
3. L'amministratore Avamar o l'utente dell'operazione di backup/restore Avamar deve disporre di credenziali valide per il guest di destinazione (requisito dell'SDK per le operazioni guest VMware) e queste credenziali devono essere inserite all'inizio delle operazioni di restore a livello di file.
4. L'utente del guest di destinazione deve disporre di privilegi di scrittura per la posizione o l'operazione non riuscirà. Per la macchine virtuali Windows, l'utente della VM di restore deve disporre di privilegi di scrittura senza elevazione di Controllo dell'account utente; per le macchine virtuali Linux, la VM di restore deve essere in grado di eseguire scritture senza sudo. 

Requisiti opzionali per FLR: necessari per il metodo di trasferimento HTTPS più rapido. 

1. Le macchine virtuali di destinazione devono disporre di accesso TCP 443 alle macchine virtuali proxy.
2. Per le macchine virtuali Linux, è necessario che sia installata un'applicazione wget moderna all'interno della macchina virtuale prima dell'operazione di restore.  

Se i requisiti operativi non sono soddisfatti, prima dell'invio del lavoro vengono visualizzati i seguenti avvisi:

Se la VM di destinazione non riesce a effettuare una connessione HTTPS al proxy:



All'interno del proxy /usr/local/avamarclient/bin/logs/VSphereWebService.log, viene riportato un codice di uscita wget diverso da 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

Oppure

Linux senza wget:



All'interno del proxy /usr/local/avamarclient/bin/logs/VSphereWebService.log, viene riportato:

[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>

Oppure

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

Funzione opzionale per FLR: Restore Access Control List (ACL)

Per impostazione predefinita, questa funzione non è abilitata.
Risultato:
Senza funzione ACL (impostazione predefinita):
Tutti i file ripristinati dalla funzione File Level Restore saranno di proprietà dell'utente con credenziali guest per la VM specificato durante le operazioni FLR e le autorizzazioni file precedenti non verranno impostate.

Con funzione ACL abilitata:
Se l'utente desidera che per i file sottoposti a restore siano impostate la stessa proprietà e le stesse autorizzazioni della creazione originale, deve abilitare questa funzione opzionale.



Risultato:
Durante le operazioni di restore, verranno creati nuovi file come utenti di VM FLR, ma al termine del restore, il flusso di lavoro ACL verrà eseguito e imposterà la proprietà e le autorizzazioni dei file sullo stato originale. 

All'interno del proxy /usr/local/avamarclient/bin/logs/VSphereWebService.log, viene riportato:

[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

In alcune distribuzioni Linux come Ubuntu o Photon OS, per impostazione predefinita gli utenti root del sistema operativo non sono impostati o configurati. Gli amministratori Linux si basano quindi sul comando sudo per eseguire le operazioni di elevazione dei privilegi.  

Tuttavia, a causa degli strumenti VMware e dell'SDK VMware, nella maggior parte delle operazioni (VM_LoginInGuest, CopyFileFromHostToGuest e ListFilesInGuest) non è possibile per gli strumenti VMware eseguire il comando sudo. 

Quando si esegue il restore con un utente normale, l'operazione potrebbe non riuscire a causa di privilegi insufficienti del guest di destinazione.

Per gli ambienti in cui l'utente root Linux è disabilitato, non configurato o non può essere condiviso per motivi di sicurezza, considerare i seguenti passaggi come risoluzione:

Opzione 1: eseguire il restore in una posizione alternativa come utente non root. 
Esempio:
File di origine:  /root/test (cartella/file con restrizioni)
File di destinazione:  /home/flruser/(posizione senza restrizioni)
Creazione del guest della VM:  "flruser"

Risultato:
Durante la ricerca in FLR, viene eseguito il mounting dei dischi virtuali sul proxy Avamar ed essi vengono visualizzati nell'interfaccia utente, inclusi tutti i file e le cartelle. Sfogliare la cartella /root e selezionare file1.txt, scegliere "Restore everything to a different location", quindi selezionare tramite il pulsante Browse o digitare /home/flruser/ in Absolute Destination.



Risultato:
Il file root/test verrà ripristinato in /home/flruser/test.
Notare che il file disporrà dell'autorizzazione degli utenti guest di FLR. 

Opzione 2: eseguire il restore in una posizione alternativa con l'opzione Restore ACL utilizzando la funzione sudo. 
In Avamar 18.2, installare l'hotfix 318791 (o versione successiva) per il proxy.
In Avamar 19.2, installare l'hotfix 318791 (o versione successiva) per il proxy.

Questi hotfix aggiungono una nuova funzione "enablesudouserrestore", disabilitata per impostazione predefinita.

Istruzioni per abilitare la funzione sudo:
Su un proxy Avamar:

1. Installare l'hotfix indicato sopra sul proxy.
2. Modificare /usr/local/avamarclient/bin/config.xml, aggiungere/modificare la riga (<enablesudouserrestore>1</enablesudouserrestore>) nel file.
3. Riavviare FLR con il comando service vmwareflr restart.

Su tutte le macchine virtuali Linux in cui sarà attiva la funzione FLR:

1. Creare un utente FLR dedicato,  ad esempio flruser.  Per maggiore sicurezza, la shell può essere disabilitata per questo account.
2. Copiare il binario /usr/local/avamarclient/bin/RestoreAcl dal proxy Avamar alla VM di destinazione utilizzando la posizione fissa /usr/bin/RestoreACL e impostare l'autorizzazione su 755 mediante chmod.

3. Modificare /etc/sudoers per consentire all'utente FLR del passaggio 1 di eseguire il binario RestoreACL senza password. 

Opzione 3: eseguire il restore nella posizione originale utilizzando il metodo sudo wget con ACL. 

Nota: 

• Questa opzione è disponibile solo se è disponibile il protocollo HTTPS di rete opzionale e quando per il restore sono selezionati più di 5 MB o 10 file.
• L'utilizzo della GUI Avamar per selezionare le posizioni delle macchine virtuali di destinazione attive in caso di posizione con cartelle con restrizioni potrebbe avere esito negativo, ma sarà comunque possibile digitare esplicitamente la posizione in "Absolute Destination". 

1. Eseguire le operazioni descritte in Opzione 2 sul proxy per abilitare il restore ACL.
2. Sul proxy Avamar, modificare /usr/local/avamarclient/bin/wget_linux_script.template. 

3. Riavviare FLR con il comando service vmwareflr restart.
4. In ogni macchina virtuale Linux su cui verrà utilizzato il restore FLR nella posizione originale, modificare /etc/sudoers per consentire all'utente FLR del passaggio 1 di eseguire il binario wget senza password.