Clonezilla Server Edition (SE)

 

Wprowadzenie

Każdy, kto administruje co najmniej kilkoma stacjami roboczymi, wie, ile czasu zajmuje powtarzanie tych samych zadań dla każdej z nich. Jeżeli jest ich kilkadziesiąt lub kilkaset okazuje się, że zarządzanie nimi bez jakiegokolwiek „wspomagania” jest praktycznie niemożliwe. Podobny problem pojawia się podczas różnego rodzaju warsztatów i szkoleń, gdy przed nową edycją konieczne jest szybkie przywrócenie wszystkich stacji do „konfiguracji domyślnej”. Istnieją różne metody rozwiązania tego problemu.

Najpopularniejsze z nich to:

1. używanie tzw. „cienkich klientów”, czyli terminali, które stanowią tylko interfejs do zdalnie dostępnych zasobów,
2. uruchamiania sieciowych obrazów systemu na zwykłych stacjach roboczych,
3. klonowanie hostów, czyli instalacja jednego wzorcowego systemu, a następnie jego „dystrybucja” na pozostałe hosty.

Pierwsze podejście wymaga scentralizowanej infrastruktury dedykowanej do tego zadania. Podobnie wygląda to w drugim przypadku: tu wykorzystywany jest centralny serwer. W obu tych rozwiązaniach centralny serwer stanowi najważniejszy element systemu i bez niego całość nie będzie działać. Z tego powodu nie można więc pozwolić sobie na jego awarię, co oczywiście wiąże się z odpowiednimi kosztami.

Powyższych problemów można uniknąć przy trzecim podejściu, którym szerzej zajmę się w tym artykule. Zagadnienie tworzenia i odtwarzania obrazów dysku/partycji zostało już tu opisane na przykładzie Clonezilli Live. Czas więc przybliżyć Clonezillę w wersji SE pozwalającą na grupowe klonowanie hostów.

Najważniejsze różnice między wersjami Clonezilli Live i SE to:

• możliwość równoczesnej obsługi wielu hostów,
• uruchamianie systemu na zdalnych hostach przez sieć,
• wydajne odtwarzanie przy pomocy multicastu.

Dzięki swym właściwościom Clonezilla SE znajduje zastosowanie w masowym wdrażaniu systemów. W praktyce pozwala to na równoległe odtwarzanie systemu na dużej liczbie stacji PC, w takim samym czasie, jaki zajmuje odtworzenie go na jednej. Dzięki temu wdrażanie dużej liczby systemów (np. 1k+) nie stanowi poważnego problemu, o ile zastosuje się transmisję multicast.

W klasycznym podejściu klonowanie wielu stacji odbywało się przy użyciu transmisji unicast (jeden do jednego) pomiędzy serwerem a każdym hostem. W związku z tym odtwarzając N hostów, te same dane były N-krotnie wysyłane przez sieć do każdego z odbiorców osobno. O ile w przypadku małej ilości danych nie stanowi to problemu, to w przypadku transmisji na poziomie gigabajtów, ma to już duże znaczenie. Rozwiązanie tego problemu stanowi transmisja multicast, czyli tzw. „transmisja grupowa”. Polega ona na wysyłaniu danych przez jednego nadawcę do wielu odbiorców w określonej grupie. Uwaga! Nie należy jej mylić z transmisją broadcast, podczas której dane są wysyłane do wszystkich.

W multicaście tworzone jest specjalne drzewo, tak aby przez łącza, którymi dane są przesyłane do wielu klientów, wysyłać je tylko raz, rozdzielając transmisję jak najdalej od źródła. Pozwala to na znaczące oszczędności obciążenia sieci, ponieważ te same dane nie są wysyłane wielokrotnie tymi samymi łączami.

Clonezilla SE jest w praktyce jednym z komponentów systemu DRBL (Diskless Remote Boot in Linux), którego instalacja i konfiguracja zostanie przedstawiona w tym artykule. DRBL dostępny jest w dwóch wersjach:

• instalowanej jako serwer, co pozwala na wygenerowanie i zapisanie własnej konfiguracji,
• live, czyli gotowej dystrybucji do jednorazowego uruchomienia, z domyślną konfiguracją.

 

Opis scenariusza

Najczęstsze podejście do zagadnienia masowego wdrażania wielu identycznych hostów polega na instalacji i pełnej konfiguracji jednego z nich jako wzorca. Następnie tworzony jest obraz wzorcowego systemu, który potem przenoszony jest na pozostałe hosty. Największe znaczenie dla czasochłonności całego procesu ma czas dystrybucji kopii na klonowane hosty. Wszelkie metody pozwalające na jego zrównoleglenie są bardzo pożądane. Dzięki zastosowaniu transmisji multicast, otrzymuje się w przybliżeniu N-krotne przyspieszenie: maksymalna wartość N to ok. 100 (wartość taką podają developerzy). Jeżeli proces ma objąć większą liczbę hostów, należy podzielić je na grupy po ok. 100 i każdą grupę odtwarzać osobno. Można użyć kilku interfejsów na serwerze lub klonować poszczególne grupy sekwencyjnie. Mimo tej drobnej niedogodności, uważam, że stukrotne przyspieszenie procesu kopiowania jest bardzo dobrym wynikiem.

Chciałbym zwrócić szczególną uwagę na fakt, że rozwiązanie opisywanego problemu wykorzystuje tylko niektóre z bardzo wielu możliwości DRBL. Pozostałe z nich to m.in.:

• zdalna instalacja systemu operacyjnego,
• tworzenia obrazu systemu i uruchamianie go przez sieć,
• zdalne zarządzanie stacjami roboczymi,
• zbiorcze uruchamianie zadań administracyjnych, np. testu pamięci.

Użycie wszystkich opcji DRBL wymaga tylko włączenia obsługiwanych stacji. Pozostałe działania można wykonywać zdalnie, z serwera.

Dostępne są trzy tryby pracy DRBL:

1. Full DRBL – stacje klienckie korzystają z przygotowanego wcześniej i uruchamianego przez sieć obrazu systemu i mają swoje własne katalogi /etc i /var dostępne z serwera przez NFS. Dla każdego hosta wymaga to oczywiście zapewnienia odpowiedniej przestrzeni dyskowej na serwerze dla wspomnianych katalogów.
2. DRBL SSI (Single system image) – stacje korzystają z obrazu systemu uruchamianego przez sieć i każda z nich ma swoje katalogi /etc i /var umieszczone w tmpfs (tymczasowym systemie plików). W tym przypadku każdy klient musi mieć min 256 MB RAM. UWAGA! Należy także pamiętać o tym, że z powodu użycia tmpfs, dane zawarte w katalogach /etc i /var, zostaną utracone po ponownym uruchomieniu systemu.
3. Bez bezdyskowej obsługi stacji.

W ramach opcji DRBL SSI dostępne są następujące tryby pracy:

1. Full Clonezilla – każdy klient ma swoje katalogi /etc i /var dostępne po NFS.
2. Clonezilla box – katalogi /etc i /var każdego klienta znajdują się w tmpfs i są tracone po restarcie komputera.
3. Nie używanie Clonezilli.
4. Clonezilla Live.

Niestety, zarówno na stronie DRBL, jak i w różnych innych materiałach, opisy wymienionych trybów nie są do końca zgodne z tym, co dzieje się w procesie konfiguracji. Nie do końca jasne są również różnice pomiędzy poszczególnymi trybami. Powyższy podział przytoczyłem w oparciu o informacje pozyskane bezpośrednio w procesie konfiguracji. Mimo że tryb DRBL SSI ma wykorzystywać ulotne katalogi /etc i /var w tmpfs, to Clonezilla w tym trybie pozwala na skonfigurowanie katalogów /etc i /var dostępnych po NFS. Nieścisłość ta i brak konsekwencji deweloperów systemu DLBL wprowadza zamieszanie, które powodować może problemy z konfiguracją. Niestety, nie miałem możliwości sprawdzenia, czy jest to tylko błąd w opisach, czy też rzeczywisty problem.

W poniższym scenariuszu wybieram DRBL SSI i Clonezilla Live, ponieważ zamierzam tylko przenieść dane na odpowiednią liczbę stacji roboczych bez późniejszego uruchamiania systemu przez sieć.

Konfiguracja hosta stanowiącego serwer jest następująca:

• nazwa: CL-SE,
• interfejs eth0 – dostęp do Internetu,
• interfejs eht1 – sieć LAN do której podłączone są tylko klonowane stacje,
• interfejs eth2 – dodatkowy, nieużywany w tym wypadku interfejs, który jest dostępny w hoście stanowiącym serwer,
• dystrybucja: Debian GNU/Linux testing (wheezy),
• kernell: 3.2.0-4-486,
• pakiet drbl zainstalowany z repozytoriów dla Debiana w wersji 1.12.15-1.

Host ten ma aktualną instalację systemu Debian testing (grudzień 2012).

Należy zwrócić uwagę na fakt, że zastosowanie hubów całkowicie uniemożliwia użycie multicastu, ponieważ ramki ethernetowe są kopiowane na wszystkie porty huba z wyjątkiem portu źródłowego. Skutkiem tego jest nadmiarowe obciążenie sieci, którego chcę tu uniknąć. Można to zrobić, używając multicastu. W celu wykorzystania zalet transmisji multicast niezbędne jest zbudowanie topologii sieciowej w oparciu o switche.

 

Instalacja DRBL

Ze względu na to, że klonowanie hostów jest zazwyczaj operacją powtarzaną cyklicznie, instalacja DRBL jest wygodniejsza od wersji live. Wymagania sprzętowe dla DRBL są dostępne tutaj i warto się z nimi zapoznać przed rozpoczęciem procesu instalacji.

Sam proces jest dość prosty. W pierwszej kolejności należy dodać repozytorium pakietów odpowiednie dla swojego systemu, a następnie zainstalować pakiet DRBL, będący w rzeczywistości instalatorem DRBL. Dalszy proces instalacji może przebiegać według jednego z trzech scenariuszy:

1. Jeśli dana dystrybucja obsługuje system pakietowy oraz mamy dobre łącze internetowe, można uruchomić DRBL w trybie interaktywnym, który zadając pytania, doinstaluje i skonfiguruje wymagane pakiety.
2. Kiedy system pracuje w trybie offline lub nie obsługuje systemu pakietowego, istnieje możliwość ręcznej instalacji pakietów.
3. Na koniec wersja „dla niecierpliwych”: tryb, który instaluje i konfiguruje wszystko automatycznie. Należy jednak pamiętać, że domyślne wartości nie zawsze muszą być tymi, które będą pasowały do konkretnego przypadku użycia. Potencjalnie problemy mogą wynikać z faktu, że:

• DHCP używa dynamicznej alokacji adresów IP do hostów – efekt: dany host nie zawsze dostanie ten sam adres,
• każdy interfejs, poza głównym eth0, zapewnia obsługę tylko dla 12 klientów.

Ze względu na wspomniane ograniczenia, decyduję się na automatyczną instalację DRBL z pakietów, jednak z konfiguracją ręczną.

1. Aktualizuję system:

root@CL-SE:~# aptitude update && aptitude upgrade

2. Instaluję klucz podpisujący repozytorium DRBL:

root@CL-SE:~# wget -q http://drbl.org/GPG-KEY-DRBL -O- | apt-key add -

3. Muszę dodać repozytorium DRBL do mojego systemu paczek. W zależności od używanego systemu paczek, należy użyć odpowiednich repozytoriów niezbędnych do instalacji DRBL. Ich lista dostępna jest pod tym adresem.

Zatem, dodaję następujący wpis do /etc/apt/sources.lit:

deb http://drbl.sourceforge.net/drbl-core drbl stable
root@CL-SE:~# cat /etc/apt/sources.list
# DRBL repository
deb http://drbl.sourceforge.net/drbl-core drbl stable
# standard debian repository
deb http://ftp.pl.debian.org/debian/ wheezy main non-free contrib 
deb-src http://ftp.pl.debian.org/debian/ wheezy main non-free contrib
# debian security repository  
deb http://security.debian.org/ wheezy/updates main contrib non-free 
deb-src http://security.debian.org/ wheezy/updates main contrib non-free

Zwracam uwagę na fakt, że dostępne są także repozytoria testing i unstable. Należy wpisać wówczas testing/unstable, zamiast stable, tak jak w powyższym pliku.

4. Aktualizuję bazę pakietów:

root@CL-SE:~# aptitude update

5. Instaluję DRBL:

root@CL-SE:~# aptitude install drbl

6. Uruchamiam instalator DRBL:

root@CL-SE:~# /opt/drbl/sbin/drblsrv -i

(Wersja dla „niecierpliwych” uruchamiana jest poleceniem /opt/drbl/sbin/drbl4imp).

7. Pierwszy komunikat pyta mnie, czy chcę zainstalować obrazy instalacji sieciowej dla różnych systemów z rodziny Linux. Wybrałem opcję „yes”.

8. Kolejne pytanie dotyczy tego, czy chcę używać wyjścia szeregowej konsoli na klientach. Wybieram odpowiedź domyślną „no”.

9. Teraz należy dokonać wyboru architektury dla jądra uruchamianego przez DRBL na klientach. Domyślną opcją jest i586 i ją wybieram. i386 może się przydać dla bardzo starych stacji roboczych. Podczas pierwszej instalacji DRBL wybrałem opcję „Use the same architecture as this DRBL server”, ponieważ serwer i stacje klienckie miały dokładnie taką samą konfigurację sprzętową. Jednak DRBL nie był w stanie uruchomić jądra na klientach, zgłaszając niepoprawną architekturę, dlatego najbezpieczniejszym rozwiązaniem jest i586.

10. Po aktualizacji listy pakietów pojawia się pytanie, czy chcę zaktualizować swój system. Ponieważ zrobiłem to bezpośrednio przed instalacją DRBL, wybieram odpowiedź „no”.

11. Otrzymuję komunikat o instalacji dodatkowych pakietów wymaganych przez DRBL przy pomocy systemu paczek.

12. W dalszej części doinstalowywane są wymagane składniki różnych systemów z rodziny Linux. Na poniższym zrzucie widać Debiana, Fedorę, Mandrake i OpenSuse.

13. Na poniższym zrzucie widać pobieranie obrazów do instalacji sieciowej, w tym przypadku Ubuntu. Chwilę później otrzymuję pytanie o wybór jądra, które będzie uruchamiane na stacjach klienckich. Domyślną opcją jest wybór jądra dostarczanego z DRBL. Pamiętając o wcześniejszych problemach z architekturą jądra, wybieram opcję domyślną.

14. Na poniższym zrzucie widać postęp instalacji kernela dla klientów.

15. Ostatni ekran pokazuje komunikaty o poprawnym wygenerowaniu obrazów dla uruchamiania klientów przez sieć. Instalacja DRBL została szczęśliwie zakończona.

Konfiguracja DRBL

Nie zdecydowałem się wersję „dla niecierpliwych”, więc po zainstalowaniu DRBL, muszę go skonfigurować. Ze względu na wiele możliwych opcji konfiguracji, trybów działania i dostępnych scenariuszy użycia DRBL i Clonezilli, w procesie konfiguracji pojawi się wiele pytań o te elementy. Chociaż, całkowicie nie dotyczą mojego scenariusza, muszę udzielić na nie odpowiedzi.

UWAGA! Podczas konfiguracji serwera DRBL wszystkie obsługiwane przez niego stacje klienckie (przeznaczone do klonowania) powinny być wyłączone.

1. Uruchamiam proces konfiguracji DRBL w trybie interaktywnym:

root@CL-SE:~# /opt/drbl/sbin/drblpush -i

2. Pierwsze pytanie dotyczy domeny, której będę używał w mojej sieci. Ponieważ nie mam domeny, wpisałem tutaj „example.com”.

3. Teraz trzeba podać nazwę domeny NIS potrzebnej do obsługi konfiguracji sieci LAN. Należy tu wpisać nazwę, zgodną z resztą infrastruktury sieciowej. Ponieważ w moim przypadku jest to wydzielone środowisko, nazwa ta nie ma znaczenia i wpisałem zgodne z domeną: example.

4. Następnie należy podać prefiks nazwy hosta dla systemów Linux w klientach. W moim przypadku wpisałem CL-TestClient, jednak i to nie ma tu żadnego znaczenia, ponieważ będę klonował jedną ze stacji na pozostałe. Opcja ta jest przydatna w przypadku, gdy DRBL przechowuje konfigurację wszystkich hostów na serwerze i udostępnia ją po NFS do obrazów uruchomionych przez sieć (dotyczy to innych trybów pracy DRBL).

5. Zostaje pokazana konfiguracja sieci na serwerze. DRBL próbuje znaleźć publiczny adres IP, który będzie określał interfejs używany do dostępu do Internetu, jednak w moim przypadku, wszystkie adresy IP są prywatne. Muszę podać, który interfejs ma zostać użyty do komunikacji z siecią. To eth0.

6. Kolejna opcja pozwala na zapisanie adresów MAC klientów i przypisanie im stałych adresów IP. Zamiast wpisywać je ręcznie i ryzykować pomyłkę, DRBL zadba o wygenerowanie całej konfiguracji DHCP. Adresy MAC są zbierane ze wszystkich hostów, które zostaną włączone po rozpoczęciu tego procesu, i będę miały wybraną opcję uruchamiania przez sieć. Adresy IP będą przypisywane poszczególnym MAC w kolejności włączania. Bardzo ważne jest, aby nadal wszystkie stacje były wyłączone. Wybieram opcję „yes”.

7. DRBL rozpoczął nasłuchiwanie na portach eth1 i eth2 (które wcześniej zostały wybrane do obsługi sieci). Naciskając klawisz 1, można podglądać listę zebranych adresów.

8. Uruchamiam testowo jeden z hostów. Otrzymałem na jego ekranie komunikat z poniższego zrzutu. Może on sugerować brak komunikacji hosta z serwerem DRBL. Oznacza jednak, że nie nastąpiło uruchomienie żadnego systemu.

9. Przechodzę do serwera DRBL i naciskam klawisz 1, wywołując listę z zapamiętanym adresem MAC uruchomionego przed chwilą hosta. Czyli wszystko poszło dobrze i mogę rozpocząć uruchamianie pozostałych hostów.

10. Po uruchomieniu dwóch pozostałych hostów otrzymałem następującą listę adresów MAC i mogę wybrać opcję „2”, aby zakończyć ten proces.

11. Otrzymuję komunikat z informacją o miejscu, w którym zostały zapisane zebrane adresy MAC z podziałem na interfejsy. Kolejne pytanie dotyczy decyzji, czy za każdym razem chcę przydzielić ten sam adres IP do poszczególnych hostów. Wybieram opcję „yes”.

12. DRBL pyta o lokalizację pliku z adresami MAC do skonfigurowania DHCP, jednocześnie podpowiadając nazwę wygenerowanego przed chwilą pliku. Wystarczy więc potwierdzić ją klawiszem „Enter”.

13. Teraz należy wybrać początkowy adres IP używany przez klientów w ramach sieci z interfejsu eth1. Należy podać wartość tylko ostatniego oktetu adresu IP. Podałem tutaj 100, aby adresy były przydzielane kolejno, zaczynając od 192.168.0.100.

14. Kolejny ekran prezentuje wygenerowany zakres adresów IP uwzględniający liczbę zebranych adresów MAC. Wszystko się zgadza, więc go akceptuję.

15. Poniższy zrzut ekranu pokazuje powtórzenie konfiguracji sieci, tym razem dla interfejsu eth2. W mojej konfiguracji ten interfejs nie obsługuje żadnych klientów, służy tylko do zarządzania. Natomiast konfiguracja DRBL nie daje bezpośredniej możliwości wyłączenia go z całego procesu. DRBL pozwala tylko wybrać, jaki zakres adresów IP ma być skonfigurowany dla DHCP dla eth2. Co ciekawe, przy próbie ustawienia liczby hostów wynoszącej 0, otrzymywałem zakres adresacji IP dla DHCP: 192.168.56.200-192.168.56.199, co świadczy o jakimś błędzie w oprogramowaniu. Uznałem, że serwer DHCP może nie zaakceptować tak skonfigurowanego zakresu i nie działać poprawnie, dlatego nie zaakceptowałem tej konfiguracji i wykonałem proces konfiguracji interfejsu eth2 jeszcze raz.

16. Tutaj widoczny jest wynik konfiguracji dla 2 hostów, tak aby nie było dziwnego zakresu adresów IP dla DHCP. Akceptuję tę konfigurację.

17. Otrzymuję schemat konfiguracji sieciowej do sprawdzenia. Ponieważ wszystko jest ok, ją też zatwierdzam.

18. Kolejny ekran dotyczy wyboru trybu pracy DRBL do bezdyskowej obsługi klientów. Dostępne są następujące tryby, opisane wcześniej szczegółowo:

• Full,
• SSI (single system image),
• brak obsługi stacji bezdyskowych.

Wybieram domyślną opcję SSI najbardziej odpowiadającą moim potrzebom.

19. Poniższy ekran umożliwia wybór trybu pracy DRBL SSI (dokładny opis we wstępie), dostępne są:

• Full Clonezilla,
• Clonezilla box mode,
• nie stosowanie Clonezilli,
• Clonezilla Live.

Wybieram opcję „Clonezilla live”, która najbardziej odpowiada moim potrzebom.

20. Teraz muszę wybrać konkretną wersję Clonezilli, którą chcę używać. Zostaję przy opcji domyślnej, czyli „alternate stable (Ubuntu-based)”.

21. Teraz muszę podać ścieżkę do katalogu, w którym będą przechowywane utworzone później obrazy hostów. Wybieram opcję domyślą ze ścieżką /home/partimg, czyli po prostu naciskam „Enter”.

22. Kolejna opcja pozwala mi zadecydować, czy w przypadku gdy klient ma partycję swap, to Clonezilla może jej użyć w celu zwiększenia dostępnej pamięci? Wybieram „yes”.

23. Poniższy ekran pozwala wybrać maksymalny rozmiar użytej przestrzeni z partycji swap. Pozostawiam domyślną wartość 128 MB. Opcja ta nie ma specjalnie większego znaczenia, ponieważ system uruchamiany na stacjach przez DRBL ma za zadanie wgrać tylko obraz dysku, co nie wymaga wielu zasobów.

24. Teraz decyduję, czy stacje klienckie mają się uruchamiać w trybie graficznym czy tekstowym. Zostawiam domyślną opcję, czyli tryb graficzny.

25. Wybieram normalne logowanie do trybu graficznego. Opcjonalnie jest jeszcze dostępne logowanie automatyczne i logowanie po określonym czasie.

26. Odpowiadam na pytanie, czy na stacjach chcę użyć takiego samego hasła roota jak w serwerze. Wybieram „no”, ponieważ te dane i tak nie będą propagowane z serwera do klientów.

27. Kolejne pytanie dotyczy ustawienia hasła do uruchamiania systemu przez sieć, w celu zwiększenia bezpieczeństwa. Ze względu na fakt, że jest to tylko testowa konfiguracja, ta opcja nie jest mi w tej chwili potrzebna.

28. Muszę teraz wybrać, czy klient ma pytać się o tryb, w którym się uruchomi. Wybieram „yes”.

29. Następnie określam czas, po jakim na kliencie ma zostać wybrana domyślna opcja uruchamiania systemu. Akceptuję proponowaną wartość 7s.

30. W tym momencie mogę wybrać, czy uruchomić tryb graficzny w menu PXE podczas startowania klientów. Dodatkowo mam tu podaną komendę, przy pomocy której mogę w przyszłości wybrać tryb tekstowy (jeśli będą problemy z trybem graficznym). Wybieram domyślne „yes”.

31. Kolejny wybór dotyczy przynależności użytkowników systemowych do poszczególnych grup. Tę opcję konfiguracyjną używamy, gdy konfiguracja jest przechowywana przez DRBL na serwerze. Nie jest to mój przypadek. Wybieram opcję domyślną.

32. Teraz mogę tak skonfigurować klientów, aby mieli po 2 adresy IP na interfejsie: publiczny do komunikacji z Internetem oraz prywatny do współpracy z serwerem DRBL. Taka konfiguracja nie jest mi w tym scenariuszu potrzebna, dlatego wybieram domyślną opcję „no”.

33. Następne pytanie dotyczy umożliwienia stacjom klienckim działania jak terminale. Należy pamiętać, że wymaga to użycia zasobów serwera. Wybieram „no”, gdyż ta opcja nie dotyczy mojego scenariusza.

34. DRBL pyta, czy chcę, aby serwer służył jako NAT dla klientów mających dostęp do Internetu. W mojej konfiguracji stacje klienckie nie mają publicznego adresu IP, zatem wybieram „yes”.

35. Poniższy ekran informuje o szczegółach konfiguracji usługi NFS i przypomina o konieczności ponownego uruchomienia tej konfiguracji, jeśli zmieniona zostanie konfiguracja wsparcia dla NFS w jądrze systemu.

36. Teraz otrzymuję ekran z informacją o miejscu, w którym zostaną zapisane aktualne ustawienia iptables. DRBL dokona ich modyfikacji, tak aby odpowiadały wprowadzonym przed chwilą parametrom. Akceptując, wybierając opcję „yes”.

37. Na tym zrzucie widać postęp procesu konfiguracji środowiska.

38. Dotarłem do końca konfiguracji. Wszystkie usługi są już uruchomione. Na końcu otrzymanego komunikatu widoczna jest informacja o miejscu, w którym znajduje się aktualny plik konfiguracyjny DRBL i o poleceniu, którym można go ponownie skonfigurować z wykorzystaniem tego pliku.

Tworzenie obrazu

Po zakończeniu instalacji DRBL mogę przejść do tworzenia obrazu, który potem zostanie sklonowany na pozostałe hosty. Sam proces tworzenia wzorca można podzielić na 2 etapy:

1. Konfiguracja serwera DRBL, która uruchomi odpowiedni system na wzorcowym hoście.
2. Uruchomienie hosta wzorcowego i obsługa procesu tworzenia obrazu uruchomionego bezpośrednio na nim.

Przed przystąpieniem do tworzenia obrazu wgrywam swój klucz ssh do systemu, który będzie klonowany, tak aby po zakończeniu całego procesu odtwarzania, móc się swobodnie logować na wszystkich stacjach.

root@CL-SE:~# ssh-copy-id root@192.168.0.100

W tym momencie należy wyłączyć wszystkie stacje robocze i pozostawić tylko działający serwer. UWAGA! W czasie tego procesu hosty, na które będę kopiował system z wzorca, powinny pozostać wyłączone.

1. Akcje wykonywane na serwerze DRBL:

1. Uruchamiam DRBL:

root@CL-SE:~# /opt/drbl/sbin/dcs

2. Wybieram tryb pracy DRBL: „All – Select all clients”. Klonowanie będzie odbywało się z odwołaniem się tylko do pojedynczego hosta, a pozostałe będę wyłączone, dlatego mogę zaznaczyć tutaj opcję „all”.

3. Uruchamiam Clonezillę „clonezilla-start”. Pozostałe opcje stanowią zestaw różnych możliwości dostarczanych przez DRBL, tj. uruchomienie zdalnych hostów w trybie tekstowym, graficznym, uruchomienie im testu pamięci, uruchomienie instalacji sieciowej, restart, uruchomienie lokalnego systemu czy po prostu Wake-on-LAN. Wiele z tych opcji jest bardzo przydatnych w przypadku zarządzania większymi sieciami stacji klienckich.

4. Wybieram tryb „Beginner mode”, który w pełni wystarczy dla mojego scenariusza.

5. Zaznaczam tryb działania „save-disk”, ponieważ chcę dokonać sklonowania całego dysku hosta wzorcowego. Stosowanie tej opcji jest zalecane szczególnie wtedy, gdy na klonowanym hoście zainstalowano kilka systemów operacyjnych (np. w przypadku laboratoriów studenckich na uczelni). Pozostałe opcje pozwalają na tworzenie obrazu/odtwarzanie pojedynczych partycji, a ostatnia opcja – na dokonanie wyboru bezpośrednio na hoście docelowym. Jednak w tym przypadku nie ma możliwości wykorzystania wydajnego odtwarzania przy pomocy multicastu. Dostępne jest tylko odtwarzanie w trybie unicast.

6. Pojawia się pytanie o to, czy konfiguracja tworzonego obrazu zostanie wprowadzona na serwerze czy na wzorcowym hoście. Wybieram opcję „Later_in_client”, aby wprowadzić wszystkie dane w kliencie. Jest to wygodniejsze, ponieważ nie trzeba mieć tych informacji przygotowanych już teraz. Praca przebiega najszybciej, jeśli wybieram podpowiedzi z menu Clonezilli na klonowanym hoście.

7. Poniższe menu pozwala wybrać opcję sprawdzania i naprawy źródłowego systemu plików. Domyślnie Clonezilla zaznacza brak sprawdzania i tak wybieram.

8. Otrzymuję możliwość wyboru, czy chcę sprawdzić utworzony obraz. Decyduję o sprawdzeniu, ponieważ pozwala to uchronić się przed późniejszymi problemami.

9. Określam, co ma zrobić klonowany host po zakończeniu procesu tworzenia obrazu. Wybieram opcję restartu, aby mieć pewność, że system działa poprawnie.

10. Decyduję o maksymalnym rozmiarze pliku obrazu dysku. Jeśli obraz będzie większy niż podana wartość, zostanie podzielony na kilka plików. Jest to pomocne przy przenoszeniu/przechowywaniu obrazu na nośnikach o ograniczonej pojemności (np. płyty DVD). Wartość należy podać w MB. W przypadku gdy nie chcemy dzielić plików, należy wpisać odpowiednio dużą wartość. Tu zgodnie z podpowiedzią wpisałem 10^6, co daje 1TB.

11. Otrzymuję komunikat od DRBL, że uruchamiam Clonezillę z opcją „range” w dhcpd.conf. Opcja ta dotyczy mojego portu eth2, który nie jest używany do odtwarzania. Mogę zatem spokojnie zignorować ten komunikat i wciskam „Enter”.

12. Po naciśnięciu „Enter”, widzę, że Clonezilla:

1. konfiguruje lokalne środowisko do pracy,
2. informuje, że można już uruchamiać hosty przeznaczone do odtwarzania (z opcją uruchamiania przez sieć),
3. podaje polecenie, które może być użyte w przyszłości do powtórzenia całego procesu bez potrzeby przechodzenia przez całe menu programu.

2. Akcje wykonywane na wzorcowym hoscie

Włączam host wzorcowy z opcją uruchamiania przez sieć.

1. Otrzymuję ekran bootloadera wygenerowanego przez DRBL z różnymi opcjami, np. uruchomienie testu pamięci, uruchomienie lokalnego systemu, systemu Debian przez sieć, czy uruchomienia Clonezilli. Wybieram ostatnią opcję. Jej opis odzwierciedla wybraną przed chwilą na serwerze konfigurację do tworzenia kopii.

2. Na poniższym zrzucie ekranu widać uruchamiający się system, który m.in. podmontowuje przez NFS dysk serwera, aby zapisać na nim obraz dysku.

3. Otrzymuję menu z prośbą o podane nazwy dla tworzonego obrazu, wypełnione od razu podpowiedzią. Akceptuję wartość domyślną.

4. Kolejne menu pozwala na wybranie dysku, którego obraz chcę utworzyć. Zarówno stacja wzorcowa, jak i docelowe, mają tylko jeden dysk twardy, oznaczony sda, który tutaj zaznaczam.

5. Otrzymuję menu obrazujące postęp procesu tworzenia obrazu.

6. Po zakończeniu procesu tworzenia obrazu klient został zrestartowany, a na serwerze DRBL otrzymałem komunikat o poprawnym utworzeniu obrazu. Widoczny jest obraz w katalogu /home/partimage, który po skompresowaniu ma rozmiar 420MB. Dla porównania: wzorcowy dysk miał 1.7GB zajętej przestrzeni.

Oczywiście w przypadku konieczności wykonania obrazów dysku wielu hostów (np. przy zabezpieczaniu backupów), można to zrobić według takiego samego scenariusza. Wystarczy tylko uruchomić wszystkie hosty, dla których mają być utworzone obrazy.

 

Odtwarzanie

Po zakończeniu procesu tworzenia obrazu, mogę przejść do kopiowania danych na dyski docelowych hostów. W tej chwili powinienem wyłączyć hosta, który stanowił wzorzec, ponieważ nie będzie mi już potrzebny. Nie należy go uruchamiać w czasie procesu odtwarzania na pozostałych stacjach, aby nie uruchomić tego samego procesu także na tym hoście.

Proces klonowania pozostałych stacji można podzielić na 3 etapy:

1. Konfiguracja serwera DRBL, która uruchomi odpowiedni system na docelowych hostach.
2. Uruchomienie hostów, na które zostanie wgrany obraz.
3. Modyfikacja konfiguracji sklonowanych hostów w celu uniknięcia konfliktów w sieci lokalnej.

UWAGA! Na początku należy wyłączyć wszystkie stacje robocze i pozostawić tylko działający serwer.

1. Akcje wykonywane na serwerze DRBL

1. Uruchamiam DRBL:

root@CL-SE:~# /opt/drbl/sbin/dcs

2. W pierwszej kolejności otrzymuję pytanie o wybór klientów, na które będę wgrywał obraz. Tak jak poprzednio, wybieram: „All – Select all clients”, czyli włączę tylko te hosty, które mają zostać sklonowane.

3. Na następnym ekranie muszę wybrać tryb pracy. Zaznaczam opcję uruchomienia Clonezilli „clonezilla-start”.

4. Wybieram tryb pracy Clonezilli: „Beginner mode”, który w pełni wystarczy dla mojego scenariusza.

5. Zaznaczam opcję „restore-disk”, ponieważ tworzony był obraz dysku. Analogicznie odtwarzam cały dysk.

6. Wybieram opcję restartu hosta po zakończeniu procesu odtwarzania. Pozostałe opcje pozwalają na wyłączenie hosta lub dokonanie wyboru bezpośrednio na zdalnym hoście. UWAGA! Należy pamiętać, że ta ostatnia opcja wymaga indywidualnego podejścia do każdego komputera, co może być czasochłonne.

7. Wybieram obraz do odtworzenia, w tym przypadku dostępny jest tylko jeden.

8. Wybieram dysk docelowy. Tutaj będzie to sda, ponieważ klonowane hosty mają tylko jeden dysk twardy.

9. Wybieram odtwarzanie przy użyciu multicastu. Dostępne jest jeszcze odtwarzanie w oparciu o unicast, czyli osobna transmisja do każdego hosta, co niestety obciąża znacząco sieć. Natomiast opcja broadcast, czyli transmisja do wszystkich, może być zastosowana tylko pod warunkiem posiadania odizolowanej sieci, gdyż w przeciwnym wypadku istnieje niebezpieczeństwo zakłócenia działania innych hostów, które nie uczestniczą w procesie klonowania.

10. Wybieram opcję „clients-to-wait”, która oznacza, że proces klonowania rozpocznie się wtedy, gdy podana za chwilę liczba klientów zostanie podłączona. Alternatywnie można też wybrać maksymalny okres oczekiwana, w którym stacje klienckie biorące udział w klonowaniu muszą się zgłosić. Możliwe jest też połączenie obu trybów.

11. Wpisuję wartość 2, ponieważ potrzebuję odtworzyć tylko 2 hosty.

12. Otrzymuję komunikat, w którym DRBL:

1. informuje że, udało się znaleźć port sieciowy obsługujący multicast, w tym przypadku eth1,
2. informuje, że port eth1 jest poprawnie skonfigurowany i aktywny,
3. przypomina o konieczności podłączenia wszystkich hostów przy pomocy switchy do sieci podłączonej do portu eth1, gdyż w przeciwnym wypadku odtwarzanie nie zostanie rozpoczęte, ponieważ hosty nie będą widoczne w ramach transmisji multicast,upewniam się, że wszystko zostało poprawnie skonfigurowane i wciskam „Enter”.

13. Po naciśnięciu „Enter” widzę, że Clonezilla:

1. konfiguruje lokalne środowisko do pracy,
2. informuje, że można już uruchamiać hosty przeznaczone do odtwarzania (z opcją uruchamiania przez sieć),
3. podaje polecenie, które może być użyte w przyszłości do powtórzenia całego procesu bez potrzeby ponownego ustawiania wszystkich parametrów w menu.

2. Akcje wykonywane na odtwarzanych hostach

Dla każdego klienta biorącego udział w odtwarzaniu powtarzam następujące kroki:

1. Zaczynam od uruchomienia hosta z opcją uruchamiania przez sieć.

2. Otrzymuję ekran bootloadera wygenerowanego przez DRBL z różnymi opcjami. Wybieram ostatnią z nich, której opis odzwierciedla wybraną przed chwilą na serwerze konfigurację odtwarzania.

3. Na poniższym zrzucie ekranu widać uruchamiający się system.

4. Ponieważ odtwarzanie odbywa się na całkowicie czyste dyski, Clonezilla zaczyna od odtworzenia tablicy partycji.

5. Po uruchomieniu wszystkich wymaganych komponentów systemu pojawia się poniższy ekran z informacją, że proces odtwarzania nie został rozpoczęty. Wynika to z faktu, że podczas konfiguracji serwera wybrałem opcję odtwarzania określonej liczby klientów (w tym przypadku dwóch). W związku z tym poniższy ekran jest sygnałem oczekiwania na podłączenie się wszystkich wymaganych hostów. Multicast pozwala na zmniejszenie obciążenia sieci, ale wymaga równoczesnego rozpoczęcia wysyłania danych do wszystkich klientów.

6. Po uruchomieniu i podłączeniu się ostatniego hosta przeznaczonego do odtwarzania, na wszystkich odtwarzanych hostach pojawi się poniższy ekran z postępem całego procesu.

7. W czasie oczekiwania na odtworzenie, postanowiłem przyjrzeć się komunikacji sieciowej. Uruchomiłem tcpdump’a (sniffer sieciowy) na porcie eth1, którego używa Clonezilla. Na poniższym zrzucie wyraźnie widać całą komunikację od serwera do klientów. Używany jest multicastowy adres 232.168.0.1, który wg RFC 3171 należy do sieci 232.0.0.0/8 określonej jako „Source Specific Multicast Block”.

8. Po ok. 3 minutach na każdym odtwarzanym hoście otrzymuję komunikat o poprawnym zakończeniu procesu odtwarzania.

9. W następnej kolejności wykonywane jest odtwarzanie MBR.

10. Clonezilla wykryła, że partycja sda1 znajdująca się na liście do odtwarzania jest partycją startową gruba i dokonuje jego reinstalacji.

11. Otrzymuję komunikat, że cały proces zakończył się powodzeniem. Clonezilla uruchomiona na kliencie wysyła komunikat do serwera i restartuje klienta.

Na serwerze otrzymuję komunikat o poprawnym zakończeniu procesu odtwarzania dla każdego klienta.

3. Konfiguracja stacji z GNU/Linux

Po odtworzeniu wszystkich stacji do rozwiązania pozostały jeszcze następujące problemy:

1. wszystkie sklonowane hosty mają dokładnie taką samą nazwę hosta,
2. wszystkie sklonowane hosty mają dokładnie te same certyfikaty serwera ssh,
3. w zależności od usług zainstalowanych na każdym kliencie może także istnieć potrzeba ich personalizacji.

Rozwiązanie pierwszych dwóch problemów dla wszystkich hostów jest stosunkowo proste i wymaga użycia krótkiego skryptu napisanego w bashu, który wykona logowanie na każdego klienta i wprowadzi wymagane zmiany.

IP_CLASS='192.168.0';
for i in `seq 100 102`; do
ssh ${IP_CLASS}.$i "rm /etc/ssh/ssh_host_*_key*; ssh-keygen -f /etc/ssh/ssh_host_rsa_key -N -t rsa; ssh-keygen -f /etc/ssh/ssh_host_dsa_key -N -t dsa; ssh-keygen -f /etc/ssh/ssh_host_ecdsa_key -N '' -t ecdsa; echo CL-Client-$i > /etc/hostname; hostname CL-Client-$i";
ssh-keygen -R ${IP_CLASS}.$i;
done

Ponieważ wgrałem swój klucz ssh na hosta wzorcowego, znajduje się on teraz na wszystkich sklonowanych hostach. Dzięki temu mam możliwość wykonywania zdalnych operacji na wszystkich klientach bez konieczności wpisywania hasła. Iterując pętlą po wszystkich hostach, mogę szybko dokonywać niezbędnych modyfikacji.

Powyższy skrypt wykonuje następujące działania:

• Generowane są nowe klucze serwera sshd: rsa, dsa, ecdsa (przy pomocy polecenia ssh-keygen -f /etc/ssh/plik_klucza -N ” -t typ_klucza).
• Ustawiana jest nowa nazwa hosta z numerem takim samym jak koniec adresu IP.
• Po wygenerowaniu nowego klucza serwera ssh na zdalnym hoscie jego odcisk nie będzie się zgadzał z tym zapisanym lokalnie. Dlatego konieczne jest skasowanie lokalnego odcisku przy pomocy polecenia ssh-keygen -R HOST.

Przy pomocy prostej pętli sprawdzam możliwość logowania się na wszystkich klientach i ich nazwy.

Cały proces klonowania został zakończony.

4. Konfiguracja stacji z MS Windows

Wszystkie stacje zostały odtworzone. Teraz należy jeszcze zająć się poniższymi kwestiami:

1. wszystkie sklonowane hosty mają wpisany ten sam numer licencji,
2. wszystkie sklonowane hosty mają dokładnie taką samą nazwę hosta,
3. może być potrzebna konfiguracja związana z odpowiednią grupą roboczą i domeną AD.

Rozwiązanie pierwszego problemu jest zadaniem bardziej skomplikowanym i nie jest bezpośrednio związane z tematyką niniejszego artykułu, w związku z tym nie będę się nim zajmował.

Przy rozwiązywaniu dwóch pozostałych problemów można posłużyć się narzędziem DRBL-Winroll. Jest niewielki program, który instaluje się na każdej stacji (czyli wystarczy go zainstalować i odpowiednio skonfigurować na stacji wzorcowej). Dzięki niemu możliwe jest ustawienie szablonów nazwy hosta (np. prefiks-końcówka_adresu_IP), grupy roboczej i domeny. Dodatkowo możliwe jest też skonfigurowanie na wszystkich stacjach serwera sshd, który umożliwi automatyczną akceptację komend wysyłanych z serwera DRBL. Po odtworzeniu obrazów każdy host podczas uruchamiania systemu sam ustawi odpowiednie wartości wspomnianych parametrów konfiguracyjnych.

 

Podsumowanie

Chciałbym zaznaczyć, że celem niniejszego artykułu nie było utworzenie zoptymalizowanego systemu do zarządzania stacjami roboczymi, lecz opis narzędzia wykorzystywanego w konkretnym przypadku.

Wybór rozwiązania zależy za każdym razem od postawionych założeń i posiadanej infrastruktury. Przykładowo, w przypadku użycia dużej liczby usług, które wymagają personalizacji, może się okazać, że klonowanie jest niewygodne i należy zastosować tryb DRBL Full/Full Clonezilla, w którym konfiguracja z /etc/ jest przechowywana na serwerze DRBL.

 

Bibliografia:

• DRBL
• DRBL-Winroll
• Clonezilla

 – Adam Smutnicki