Linux - SSH bez hasła - klucze RSA

Jeśli Twoja dzienna aktywność wymaga logowania na konta w wielu systemach Linux przez SSH, będziesz szczęśliwy wiedząc (jeśli już nie wiesz :) ), że jest sposób by umożliwić bezpieczny, uwierzytelniony zdalny dostęp, transfer plików, zdalne wykonywanie skryptów bez konieczności pamiętania i wpisywania haseł. SSH umożliwia wykorzystanie mechanizmu kluczy RSA do bezpiecznego logowania się do systemu.


1. generowanie kluczy RSA

Pierwszym krokiem jest wygenerowanie pary kluczy RSA na lokalnym systemie. Klucze użytkownika są przechowywane w katalogu $HOME/.ssh/ Do wygenerowania pary kluczy należy wykonać komendę:

# ssh-keygen -t rsa

Generating public/private rsa key pair. 
Enter file in which to save the key (/root/.ssh/id_rsa):

(Jest to bezpieczne, naciśnij enter tutaj jako / root / .ssh jest domyślnym i zalecanym katalogu do przechowywania RSA plik).

Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 

(Hasło tutaj wpiszesz muszą być wprowadzane za każdym razem użyć klucza RSA, ale na szczęście można ustawić bez hasła, naciskając klawisz Enter. Jednak plusem jest to, że trzeba tylko pamiętać jedno hasło dla wszystkich systemów, które uzyskują dostęp przez uwierzytelnianie kluczem RSA. Można zmienić passhrase później za pomocą "ssh-keygen-p").

Your identification has been saved in /root/.ssh/id_rsa. 
Your public key has been saved in /root/.ssh/id_rsa.pub. 

Twoje klucze zostały zapisane w odpowiednim katalogu. Upewnijmy się tylko że nikt inny ich nie odczyta.


# chmod 700 .ssh
# chmod 600 .ssh/id_rsa

# chmod 600 .ssh/id_rsa.pub


2. instalowanie klucza publicznego w zdalnym systemie

Teraz należy zainstalować klucz publiczny w systemie zdalnym. W tym celu należy skopiować plik

$HOME/.ssh/id_rsa.pub

Najlepiej zrobić to za pomoca komendy:

# scp .ssh/id_rsa.pub root@<IP_ADDRESS>:~/

Komenda ta skopjuje klucz publiczny do katalogu domowego użytkownika. Następnie logujemy się za pomocą SSH na system zdalny używając tego samego loginu co poprzednio - po raz ostatni podajemy hasło :) Autoryzowane klucze znajdują się w pliku 

$HOME/.ssh/authorized_keys

Musimy teraz przenieść nasz klucz publiczny do tego pliku.

# cat id_rsa.pub >> .ssh/authorized_keys

Uwaga na dwa ">>", użycie ich spowoduje dołączenie nowego klucza do pliku. W przypadku użycia tylko jednego znaku ">" plik zostanie nadpisany i stracimy zapisane tam inne klucze!!!

Następnie należy upewnić się, że tylko użytkownim ma dostęp do katalogu i pliku z kluczami

# chmod 700 .ssh
# chmod 600 .ssh/authorized_keys


3. sprawdzenie autoryzacji RSA

Po wszystkim sprawdzamy czy autoryzacja RSA działa. Wylogowujemy się z systemu zdalnego i wpisujemy:

# ssh root@<IP_ADDRESS>

Powinniśmy zobaczyć konsolę zdalnego systemu bez pytania się o hasło. Jeśli została podana passphrasse to ją podajemy jako hasło.

UWAGA:
Logowanie za pomocą kluczy jest tak długo bezpieczne jak długo bezpieczny jest nasz klucz prywatny. Nie udostępniaj go nikomu. Tylko za jego pomocą możliwe będzie zalogowanie się na zdalny system. Jego utrata bądź uszkodzenie spowoduje brak dostępu do systemu.

XenServer - interfejsy VLAN

Kilka dni temu robiłem małą instalację XenServera na lekko zmodyfikowanym serwerze HP Proliant DL120 G7. Normalnie nie nadaje się on do wirtualizacji, gdyż zastosowany przez HP kontroler macierzy RAID nie jest obsługiwany przez XenServer. Serwer jest standardowo wyposażony w dwa interfejsy ethernet, z czego interfejs pierwszy jest współdzielony z konsolą iLo3. Ponieważ potrzebowałem rozdzielić ruch zarządzający od ruchu produkcyjnego do pracy musiałem zaprząc protokół 802.1q czyli uruchomić obsługę VLANów. Założenie było następujące:

port Ethernet 1
- VLAN10 dla konsoli iLo3 - tworzony z poziomu konsoli, nie będzie opisywane,
- VLAN12 dla zarządzania XenServerem

port Ethernet 2
- VLAN25 dla maszyny wirtualnej 1
- VLAN26 dla maszyny wirtualnej 2

W czasie instalacji serwera nie przypisujemy żadnego adresu IP do interfejsów sieciowych, jeśli to zrobimy, trzeba będzie "odkręcać" bo adresy są podczas instalacji przypisywane do VLAN1 i ramki nie są tagowane. Po instalacji uruchamiamy command-line i wykonujemy:

1. tworzenie nowych interfejsów

# xe network-create name-label=<NAME_OF_NEW_INTERFACE>

np.

# xe network-create name-label=xenbr0.12

Tworzymy tyle interfejsów, ile jest potrzebne. Ja zrobiłem 3: xenbr0.12, xenbr1.25, xenbr1.26

2. wyświetlenie zainstalowanych kart sieciowych (PIF) oraz interfejsów sieciowych 

# xe pif-list

uuid ( RO)                  : 3f1ac1b6-800b-a7e3-1f3b-c142974199cb
                device ( RO): eth1
    currently-attached ( RO): true
                  VLAN ( RO): -1
          network-uuid ( RO): 18c82b20-d97b-2c88-fe25-07039342a1d9


uuid ( RO)                  : e5c0dee5-ec02-0aef-ac0c-4d5d1c88e948
                device ( RO): eth0
    currently-attached ( RO): true
                  VLAN ( RO): -1
          network-uuid ( RO): be31f919-9c54-c21e-43ec-df4b23bf02f6

# xe network-list

uuid ( RO)                : 70d0220b-0454-ec68-d232-12ea90e60fad

          name-label ( RW): xenbr1.26

    name-description ( RW): web server

              bridge ( RO): xapi2

uuid ( RO)                : 99a560ba-599a-f617-aa3e-1563fffa2b73

          name-label ( RW): xenbr1.25

    name-description ( RW): mail server

              bridge ( RO): xapi0

uuid ( RO)                : ed3346b4-a650-013c-afb2-a617234468cd

          name-label ( RW): xenbr0.19

    name-description ( RW): management

              bridge ( RO): xapi1

3. utworzenie interfejsów sieciowych 802.1q

# xe vlan-create network_uuid=<UUID_OF_INTERFACE> pif_list=<UUID_OF_PIF> vlan=<VLAN_NUMBER>

np.

# xe vlan-create network_uuid=be31f919-9c54-c21e-43ec-df4b23bf02f6 pif_list=ed3346b4-a650-013c-afb2-a617234468cd vlan=19

I tak dla każdego z interfejsów. Teraz pozostaje już nadać adres IP, można zrobić to z xsconsole, pojawią się tam nowe interfejsy. A do pełni szczęścia :) pozostaje skonfigurować switch LAN.

Cacti - wykresy stanu portów w switchach

Cacti jest przepotężnym narzędziem do zbierania i graficznej prezentacji najprzeróżniejszych parametrów sieci. W podstawowej instalacji są to wykresy obciążenia procesora, interfejsów sieciowych, zajętości pamięci itp. Cacti może być rozbudowane o wiele przeróżnych wykresów jak monitorowanie środowiska, zasilania, stanu serwerów (HTTP, DNS) i wiele innych. 

Niedawno spotkałem się z potrzebą monitorowania zajętości portów na switcha. Najprostszym sposobem było zaprzęgnięcie działającego już w sieci Cacti do dodatkowej pracy. W tym celu znalazłem na forum Cacti skrypt, który w zamierzeniu autora miał odczytywać potrzebne parametry - ilość wszystkich portów ethernet i portów, które działają w danym momencie. Przerobiłem go do swoich celów i dodałem nową funkcjonalność - odczyt portów w stanie Admin Up. Dodatkowo przystosowałem skrypt do działania z innymi switchami, nie tylko Cisco, ale również HP Procurve i 3COM.

Poniższe skrypty należy skopiować do katalogu /usr/share/cacti/site/scripts

check_ports_cisco.php

check_ports_hp.php

check_ports_3com.php

Cisco - większość switchy, sprawdzone na C3560, C2960, C3750 i C6505

HP - Procurve 2510G, 2524 (będzie działać ze wszystkimi switchami które numerują interfejsy cyframi), 1810G-8 i 4000M (modularny)
3COM - SuperStack II 3300, SuperStack III 4400 i 4500, Baseline 2226 Plus

Następnie, po zalogowaniu się do Cacti z prawami administratora musimy skonfigurować kilka zależnych od siebie elementów:

1. Data Input Methods

Input Fields - przy ich pomocy przekazujemy parametry do skryptu

Output Fields - przy ich pomocy odbieramy ze skryptu dane, ich nazwy muszą być identyczne z tymi które są w skrypcie

Jeżeli chcemy, by parametry do skrypty były przekazywane automatycznie na podstawie informacji zdefiniowanych w karcie urządzenia (Device), takich jak. IP adres, SNMP community, czy SNMP version, należy przy definiowaniu Input Field w polu Special Type Code wpisać jedno z podanych słów kluczowych, np. hostname dla adresu IP lub nazwy kanonicznej urządzenia.

2. Data Templates

W Data Templates definiujemy w jaki sposób RRDTools ma obsługiwać napływające ze skryptu dane. Ważne jest zdefiniowanie odpowiedniej ilości pól w szablonie, należy pamiętać o zapisywaniu szablonu po każdorazowym utworzeniu i edycji nowego pola.

3. Graph Templates  

 Tu definiujemy jak ma wyglądać wykres.

4. Device i Create Graph

Na koniec na karcie urządzenia dodajemy z listy rozwijanej nowy szablon i po wybraniu linka Create Graph For This Host dodajemy nowy wykres.

5. A tak wygląda efekt końcowy

Pole niebieskie to całkowita ilość interfejsów. Pole zielone to interfejsy w stanie Admin UP a czerwona linia to aktualnie aktywne interfejsy - w stanie Oper Up.

Pliki z gotowymi szablonami do switchy Cisco i HP 

generowane za pomocą Cacti 0.8.8a 

Rancid - narzędzie do monitorowania zmian i backupu konfiguracji - część 1

W codziennej pracy z sieciami prędzej czy później natkniemy się na problem archiwizacji konfiguracji urządzeń sieciowych - routerów, switchy, firewalli itp. Na rynku jest dostępne wiele różnych płatnych narzędzi takich jak Kiwi CatTools czy kombajn Cisco LMS . Co jednak w sytuacji, gdy np. budżet IT niedużej firmy nie pozwala na zakup komercyjnego rozwiązania? Przy małej ilości urządzeń można sobie pozwolić na ręczne backupy konfiguracji urządzeń, ale gdy ilość urządzeń rośnie nakład czasu potrzebny do wykonania backupów rośnie. Oczywiście można się posiłkować skryptami automatyzującymi pracę, lecz może być to dość karkołomne dla mniej doświadczonych adminów.

Rozwiązaniem tego problemu może być RANCID (Really Awesome New Cisco confIg Differ) - znakomite narzędzie przeznaczone do automatycznego backupu konfiguracji urządzeń sieciowych. Oprócz tego RANCID potrafi zachowywać różne wersje konfiguracji i porównywać je za pomocą CVS (Concurrent Version System). Wbrew nazwie RANCID potrafi backupować urządzenia różnych producentów takich jak:  Juniper, HP, Foundry itd. Do działania nie są potrzebne dodatkowe protokoły jak SNMP. Rancid loguje się do urządzenia i kopjuje konfigurację. Sam RANCID jest narzędziem działającym w trybie tekstowym, można go jednak doposażyć w graficzną nakładkę CVS-WEB.

 instalacja RANCIDa

Opis instalacji dotyczy systemu Linux Debian 6.0
Do prawidłowego działania RANCIDa potrzebne są następujące programy:
- Apache2
- CVS
- RANCID :)
- CVS-WEB  

Do instalacji pakietów możemy użyć albo graficznego managera pakietów, albo tekstowego apt-get. W obu przypadkach, przy prawidłowo zainstalowanym Debianie, instalacja pakietu RANCID automatycznie zainstaluje potrzebne powiązane pakiety (Apache2, CVS). Na koniec będzie potrzebne doinstalowanie pakietu CVS-WEB.

Zatem zaczynamy:

1. Najpierw instalujemy RANCIDa

    #apt-get install rancid

W trakcie instalacji zostanie utworzone konto użytkownika i jego katalog domowy.

2. Teraz edytujemy plik konfiguracyjny rancid.conf znajdujący się w katalogu /etc/rancid . Należy dodać przynajmniej jedną grupę. 

   LIST_OF_GROUPS="urzadzenia"

Przy większych sieciach, może być pomocne skonfigurowanie kilku grup. Nazwy grup muszą być rozdzielone znakiem spacji. 

   LIST_OF_GROUPS="ruter switch firewall"  

 3. Następnie należy skonfigurować plik o nazwie .cloginrc zawierający hasła potrzebne do zalogowania się na urządzenia. Edytujemy plik zachowując odpowiednią składnię w zależności od urządzenia, w przykładzie składnia dla urządzeń Cisco

add password 1.1.1.1 {USER_PASSWORD} {ENABLE_PASSWORD}
add autoenable 1.1.1.1 1

Jeśli urządzenie używa protokołu SSH zamiast telnet (np. Cisco PIX/ASA) do konfiguracji  dodajemy: 

add method 1.1.1.1 ssh

Znak "#" standartowo oznacza komentarz, zatem jeśli chcemy z jakiegoś powodu wyłączyć dane urządzenie z backupów to wystarczy że postawimy "#" na początku odpowiedniej linii.

Należy być bardzo ostrożnym z uprawnieniami pliku .cloginrc gdyż przechowuje on hasła w postaci tekstowej niezaszyfrowanej. Jedyną możliwością ochrony pliku jest ograniczenie praw dostępu do pliku wyłacznie dla właściciela. Zatem ustawiamy

  chmod 600 /home/rancid/.cloginrc
  chown -R rancid:rancid /home/rancid 

4. Kolej teraz na stworzenie architektury CVS. W tym celu należy zalogować się na konto użytkownika rancid 

  su rancid
  rancid@linux:~ /home/rancid/rancid/bin/rancid-cvs

Po tym w katalogu rancida powinna zostac utworzona struktura CVS on nazwie grupy jaką podaliśmy w pliku konfiguracyjnym.

5. Teraz dodajemy urządzenia do grupy /home/rancid/rancid/{nazwa_grupy}/router.db
Składnia pliku jest prosta: "ip_address":"typ_urządzenia":"status"  np.:

   1.1.1.1:cisco:up

 Następnie testujemy, czy rancid ma dostęp do skonfigurowanego urządzenia.

   rancid@linux:~ /home/rancid/rancid/bin/clogin 1.1.1.1

1.1.1.1
spawn telnet 1.1.1.1
Trying 1.1.1.1...
Connected to 1.1.1.1.
Escape character is '^]'.

User Access Verification

Username:
Password:
Router#

6. I uruchamiamy RANCIDa

  rancid@linux:~ /home/rancid/rancid/bin/rancid-run

Logi RANCID są dostępne w katalogu /var/log/rancid. 

7. By RANCID sprawdzał konfiguracje bez naszego udziału trzeba do crona dodać

   crontab -e -u rancid

   # uruchom rancid-run każdego dnia o 01:00 
   0 1 * * * /home/rancid/rancid/bin/rancid-run

Poza tym możemy pokusić się o automatyczne usuwanie logów. Rancid zapisuje osobne logi dla każdej grupy po każdorazowym zakończeniu pracy. Przy dużej ilości urządzeń i grup oraz szczególnie częstym uruchamianiu skryptu logów będzie bardzo dużo i ich ilość będzie przyrastała w zastraszającym tempie. Pokusiłem się o automatyczne usuwanie starych logów. By to zrobić do crona należy dodać linię.

  crontab -e -u rancid 

  # czyść logi co miesiąc o 00:15 

  15 00 1 * * find /var/lib/rancid/logs/ -type f -mtime +30 -exec rm {} \;

 instalacja CVS-WEB

RANCID pracuje, ale jak odczytać wyniki jego pracy? Można zrobić to przez interfejs tekstowy CVSa, ale jest to dość trudne. Z pomocą przychodzi nam bardzo przejrzysty i łatwy w użyciu CVS-WEB.
Zatem:

1. Instalujemy pakiet

  apt-get install cvsweb

2. W pliku /etc/cvsweb/cvsweb.conf należy odnaleźć sekcję @CVSrepositories i dodać katalog gdzie znajduje się główne repozytorium.

@CVSrepositories = (
#'local' => ['Local Repository', '/var/lib/cvs'],
'moje_urzadzenia' => ['urządzenia', '/var/lib/rancid/CVS'],
#'freeebsd' => ['FreeBSD', '/var/ncvs'],
#'openbsd' => ['OpenBSD', '/var/ncvs'],
#'netbsd' => ['NetBSD', '/var/ncvs'],
#'ruby' => ['Ruby', '/var/anoncvs/ruby'],
);

Następnie tworzymy link symboliczny do katalogu, gdzie znajdują się ikony i pliki css

  ln -s /usr/share/cvsweb /var/www/cvsweb

3. Teraz możemy przetestować CVS-WEB wpisując w przeglądarce:

  http://127.0.0.1/cgi-bin/cvsweb

XenServer - backup konfiguracji i oprogramowania serwera

Oprócz opisanego w poprzednim poście backupu maszyn wirtualnych, konsola XenServera umożliwia wykonanie kopii zapasowej samego serwera oraz jego konfiguracji. W tym celu należy wykonać komendę:

# xe host-backup host=<HOSTNAME> file-name=<PATH and FILENAME.xbk>

np.

# xe host-backup host=xen1 file-name=/mnt/nfs/xen1bckp.xbk

UWAGA: Aby odtworzyć serwer z kopii zapasowej należy wystartować system z dysku instalacyjnego XenServer. W przeciwieństwie do kopii zapasowych maszyn wirtualnych, odtworzenie kopii zapasowej serwera jest możliwe jedynie na oryginalnej maszynie.

Cisco - Jak EEM rozwiązał problem z tunelami IPSEC

Jakiś czas temu natknąłem się na problem z tunelami IPSEC. Wszystkie rutery które są w sieci są podłączone do Internetu łączami kablowymi UPC. Niestety mimo, że adresy IP są stałe, to UPC co 24 godziny "odświeża" połączenie, co powoduje zerwanie szyfrowanych tuneli IPSEC. Nie byłby to żaden problem, bo normalnie ponowne zestawienie tunelu jest praktycznie niezauważalne dla zwykłego użytkownika. Tymczasem zdarza się że pomimo ponownego zestawienia łącza internetowego, tunel IPSEC nie nawiązuje poprawnie komunikacji i nie ma łączność pomiędzy oddziałem a centralą. Jest to o tyle uciążliwe, że trzeba zalogować się na zdalny ruter i zrestartować interfejs Tunnel. Tu z pomocą przychodzi mało znane narzędzie Cisco - Embedded Event Manager EEM. EEM dostarcza narzędzie do wykrywania i reagowania na różne zdarzenia występujące w sieci lub na urządzeniu. Do jego oprogramowania służy dość prosty język skryptowy. W opisywanym wyżej przypadku sprawdzana jest ilość peerów EIGRP i jeżeli jest ona mniejsza od 1, skrypt restartuje interfejs Tunnel. Do sprawdzenia użyte zostało SNMP i OID zwracający potrzebną wartość. Całość działa bardzo skutecznie i czy to po chwilowych, czy też po dłuższych przerwach, komunikacja IPSEC jest przywracana bez udziału użytkownika czy administratora.

!

event manager applet Tunnel_restart
  event snmp oid 1.3.6.1.4.1.9.9.449.1.5.1.1.3.0.100.8 get-type exact entry-op lt entry-val 1 exit-op ge exit-val 1 exit-time 20 poll-interval 60
  action 101 syslog priority notifications msg "Restart Tunnel100 interface due to IP-SEC problem"
  action 102 cli command "enable"
  action 103 cli command "conf t"
  action 104 cli command "inter Tu100"
  action 105 cli command "shutdown"
  action 106 cli command "no shutdown"
  action 107 cli command "end"
!

XenServer - prosty backup maszyny wirtualnej

Istnieje co najmniej kilka metod wykonywania kopii zapasowych maszyn w Citrix XenServer. Większość z nich to dość drogie rozwiązania komercyjne jak PHD Virtual Backup . Oczywiście oferują one wiele użytecznych funkcji, ale czy jest to niezbędne, gdy mamy do backupu kilka maszyn wirtualnych, które na dodatek pracują na darmowej wersji XenServera? Nie, XenServer ma wbudowane narzędzie do wykonania i przywracania kopii zapasowej maszyny. Nie jest ono może intuicyjne i wymaga nieco wiedzy od użytkownika, ale jest w pełni funkcjonalne i sprawnie wykonuje żądane czynności. Zatem, jak to zrobić?

 przygotowanie do backupu

Do wykonania kopii zapasowej musimy przygotować miejsce. Najlepiej by był to jakiś dysk sieciowy, który potrafi udostępniać swoje zasoby jako dysk NFS. Oczywiście musi być on udostępniony z prawami do zapisu. Z konsoli XenServera należy utworzyć miejsce, gdzie podmontujemy dysk sieciowy:

 ~# mkdir /mnt/nfs

a następnie montujemy zasób sieciowy

~# mount -t nfs <IP_ADDR_>:<PATH> /mnt/nfs

<IP_ADDR> - adres IP dysku sieciowego 
<PATH>     - ścieżka do katalogu na dysku sieciowym, gdzie będzie wykonywana kopia zapasowa

UWAGA: nie jest to ścieżka zasobu SMB tylko NFS więc o ile jest to możliwe, należy sprawdzić na dysku, jaka jest prawidłowa ścieżka. Np. na moim Icy Box IB-NAS4220-B ścieżka NFS do zasobu public to /mnt/ide1/public

  wykonanie backupu 

Gdy mamy już przygotowane miejsce, możemy przystąpić do wykonywania kopii zapasowej. Najpierw należy wyświetlić listę maszyn wirtualnych:

 # xe vm-list
  

uuid ( RO)           : 2eff6db7-cf0d-24c2-8009-6c45c4435e0f

     name-label ( RW): machine1
    power-state ( RO): running


uuid ( RO)           : 2e4a8a77-e75a-47e7-5eb6-1aa9b5cf6b54
     name-label ( RW): machine2
    power-state ( RO): running

Jeśli zostały zainstalowane poprawnie XenTools na maszynach wirtualnych to wykonujemy kopię zapasową maszyny

 # xe vm-export vm=<UUID> filename=<PATH and FILENAME.xva>

np.

# xe vm-export vm=2eff6db7-cf0d-24c2-8009-6c45c4435e0f filename=/mnt/nfs/machine1_backup.xva

I możemy się cieszyć wykonana kopią maszyny. Nieco problemów stworzy maszyna, która z różnych powodów nie ma zainstalowanych XenTools. Taką maszynę musimy zatrzymać przed wykonaniem kopii zapasowej i uruchomić po zakończeniu operacji

 # xe vm-shutdown vm=<UUID>

 # xe vm-start vm=<UUID>

Kopię zapasową wykonujemy w identyczny sposób jak poprzednio. 

TU jest prosty skrypt, który realizuje backup wybranych maszyn. Nazwy maszyn trzeba wpisać w zmienną $HOSTS.

  przywracanie kopii zapasowej

Przywrócenie kopii zapasowej wykonujemy w podobny sposób jak backup. Najpierw należy sie upewnić czy jest prawidłowo podmontowany zasób z kopią zapasową. Następnie należy wyświetlić listę dostępnych Storage Repository i ich UUID

# xe sr-list

uuid ( RO)                : fffb9b4d-16e5-20b0-8154-962781d362c2
          name-label ( RW): Local storage
    name-description ( RW):
                host ( RO): xen1
                type ( RO): lvm
        content-type ( RO): user


uuid ( RO)                : d5175b5c-d042-aa49-ec90-1fcc6d2fc7a2
          name-label ( RW): Local Storage 2
    name-description ( RW):
                host ( RO): xen1
                type ( RO): lvm
        content-type ( RO): user 

Przywrócenie kopii wykonujemy za pomocą komendy

# xe vm-import sr-uuid=<UUID> filename=<PATH and FILENAME.xva>

np.

# xe vm-import sr-uuid=fffb9b4d-16e5-20b0-8154-962781d362c2 filename=/mnt/nfs/machine1_backup.xva