Blog Marcina Bojko

Prezentacja tradycyjnie dostepna w formie slajdów:

👁 2012-04-25 21.09.44

Jak zapewne wiadomo tym, którzy przebrnęli przez poprzednie wpisy o DRBL, system ten dostarcza ciekawy mechanizm umożliwiający dostarczanie kilku pożytecznych narzędzi za pomoca  PXE bezpośrednio do komputera na którym je potrzebujemy. Iż jest to czasem błogosławieństwo chyba nie muszę opowiadać: brak dyskietki, dysku USB, CDROMU, uszkodzenie tychże i tak dalej i tak dalej.

Przykład? Konieczność wykonania akcji ratunkowej/maintenance na badanym systemie – ot klasyczny uszkodzony Windows/Linux do spacyfikowania. Zazwyczaj wykonujemy opcję startu z CD/DVD, czasem klucza USB (bez angażowania dysku twardego), a tu pokażę jak możemy to zrobić łatwiej i przyjemniej: via network. Dzisiaj zajmiemy się dostarczeniem jednego z ciekawszych systemów ratunkowych: System Rescue CD, dostępnego tu: http://www.sysresccd.org

Kilka aksjomatów:

– pokaz przeprowadzam na openSUSE 11.3 z zainstalowanym systemem i prekonfigurowanym DRBL’em w wersji 1.10.31_1

– interfejs dla podsieci DRBL to 172.16.0.1, podsieć 172.16.0.0/24

– obrazy systemów dostarczamy za pomocą http – można to zrealizować poprzez tftp, nfs, nbd – http pozostaje jednak najbardziej uniwersalny dla dodatkowych systemów podpinanych do DRBL’a, jak również stosunkowo najłatwiejszy w konfiguracji.

– zawartość serwera HTTP domyślnie znajduje się w /srv/www/htdocs

– zawartość DRBL/Tftpd domyślnie znajduje się w /tftpboot/nbi_img

– plik konfiguracyjny drbla znajduje się w /tftpboot/nbi_img/pxelinux.cfg/default

– wszystkie operacje wykonujemy jako root/sudo su

Zaczynamy od pobrania ostatniej wersji System Rescue CD – na potrzeby manuala jest to 2.3.1, ale oczywiście powinno działać z wersjami wcześniejszymi i późniejszymi, bez dokonywania zmian innych niż nazewnictwo plików i ich wersje:

# pobieramy i montujemy ISO jako filesystem
wget http://downloads.sourceforge.net/project/systemrescuecd/sysresccd-x86/2.3.1/systemrescuecd-x86-2.3.1.iso
mkdir -p /media/system
mount systemrescuecd-x86-2.3.1.iso /media/system -o loop

# zawartość pliku ISO jest dostępna w /media/system # kopiujemy z System Rescue CD jego kernel i initrd
cp /media/system/isolinux/rescuecd /tftpboot/nbi_img/rescuecd
cp /media/system/isolinux/rescue64 /tftpboot/nbi_img/rescue64
cp /media/system/isolinux/initram.igz /tftpboot/nbi_img/initram.igz.systemrescue

#Kopiujemy plik obrazu systemu do naszego domyślnego serwera http.
cp /media/system/sysrcd.dat /srv/www/htdocs/sysrcd.dat
cp /media/system/sysrcd.md5 /srv/www/htdocs/sysrcd.md5

# sprawdzamy czy mamy uruchomiony serwer http:
chkconfig -l apache2
apache2 0:off 1:off 2:off 3:on 4:off 5:on 6:off
 
# Uwaga, - krok opcjonalny jeżeli poprzedni krok zwrócił nam same 'off'
yast2 -i apache2
chkconfig --add apache2

# testujemy nasz serwer http
wget http://172.16.0.1/index.html

--2011-10-14 18:04:49-- http://172.16.0.1/index.html
Connecting to 172.16.0.1:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 44 [text/html]
Saving to: `index.html'

100%[=====================================================================================================================================>] 
44 --.-K/s in 0s 

2011-10-14 18:04:50 (2.19 MB/s) - `index.html' saved [44/44]
# Wygląda na to iż wszystko działa ;) # Robimy kopię ustawień DRBL'a
cp -p /tftpboot/nbi_img/pxelinux.cfg/default /tftpboot/nbi_img/pxelinux.cfg/default.old
# Swoim ulubionym edytorem (gedit/mcedit/vi/ed) dokonujemy edycji pliku: 
/tftpboot/nbi_img/pxelinux.cfg/default

mcedit /tftpboot/nbi_img/pxelinux.cfg/default
# Na końcu pliku dodajemy linie:

label System Rescue CD 2.3.1
# MENU DEFAULT
# MENU HIDE
 MENU LABEL System Rescue CD 2.3.1
# MENU PASSWD
 kernel rescuecd
 append initrd=initram.igz.systemrescue netboot=http://172.16.0.1/sysrcd.dat setkmap=pl 
 nomodeset dostartx
# TEXT HELP
# Boot System Rescue CD via network
# ENDTEXT

label System Rescue CD 2.3.1 64bit (required 400 MB or more)
# MENU DEFAULT
# MENU HIDE
 MENU LABEL System Rescue CD 2.3.1 64bit (required 400 MB or more)
# MENU PASSWD
 kernel rescue64
 append initrd=initram.igz.systemrescue netboot=http://172.16.0.1/sysrcd.dat docache 
 setkmap=pl nomodeset dostartx
# TEXT HELP
# Boot System Rescue CD 64bit via network
# ENDTEXT

I efekt:
👁 1

👁 2
W następnym odcinku: GParted, PartedMagic, i Hiren's Boot CD ;)

Przezwyciężając lenistwo:

Część I

Część II

Część III

Część IV

Część V

Część VI

Spotkanie odbyło się planowo – poniżej snapshot prezentacji.

Filmy mam nadzieję dam radę później 😉

Kontynuując współpracę z uczelniami – w dniu 4 listopada, na Wydziale Matematyczno-Przyrodniczym KUL, sala 604 będę miał przyjemność poprowadzić spotkanie dotyczące DRBL – kolejna, bogatsza o rok doświadczeń edycja spotkania z LUMD.

Spotkanie rozpoczyna się o 18:40

Skupimy się głównie na możliwościach deploymentu i migracji wielu jednostek jednocześnie, jak również na systemie pracy terminalowej dla małych klientów (biblioteki, uczelnie itp.)

Oficjalna strona Koła Naukowego Informatyków KUL: http://kni.kul.lublin.pl/Aktualnosci.aspx

Mam nadzieję, iż tym razem uda się zamieścić film z wykładu 🙂

Zapraszam 😉

Zapewne Ci z was, którzy aktywnie używają DRBL’a w swojej pracy mieli juz okazję wykorzystać pakiet DRBL-Winroll. Ci z Was, którzy realizowali już rollouty, masowe migracje czy deploymentu, wiedzą też o konieczności zmiany SID’a maszyn – często wykorzystując narzędzie Marka Russinovicha ‚NewSID‚

No właśnie – czy zmiana SID‚a jest konieczna? Dużo się bowiem zmieniło od czasu Windows 98 😉
Pod koniec roku 2009, Mark Russinovich, twórca (między innymi) świetnego narzędzia NewSid,  opublikował wpis na swoim blogu: http://blogs.technet.com/b/markrussinovich/archive/2009/11/03/3291024.aspx w którym dosyć autorytatywnie rozprawia się z mitem ‚konieczności zmiany SID‚a’ w klonowanych systemach.

Podsumowując artykuł – dla tych, którzy klonują stacje robocze oparte na systemach Windows, zabawa w zmianę SID przyda się tylko i wyłącznie gdy … stawiacie kontrolery domen Active Directory 😉 Pozostali mogą spać spokojnie, sytuacja gdy maszyny z tym samym SID’em zbuntują się i zaczną dzielić się tajnymi plikami jest praktycznie niemożliwa 😉

Dla tych którzy chcą jednak i te rzeczy w swojej sieci miec pod kontrolą pozostają minimum 3 rozwiązania.

1. Użyj Microsoftowego programu SysPREP.

Zaletą tego rozwiązania jest dosyć dokładne przygotowanie unikalnego systemu dla identycznych stacji roboczych, jak również szybkość i prostota działania.
Wadą jednak pozostaje konieczność ponownej ręcznej rejestracji/aktywacji systemu, z jego nużącym wpisywaniem klucza oraz przechodzenie przez etap ‚wykrywam/wykrywam/wykrywam/chyba instaluję’.

O ile w przypadku instalacji wersji OEM’owych – wydaje się to być jedynie słuszną drogą (jak również przygotowywanie wersji dla klienta końcowego do samodzielnej rejestracji), o tyle w przypadku korzystania z licencji typu MOLP/Select/VLK dokładanie roboty jest zupełnie niepotrzebne.

2. Użyj narzędzia NewSID
Chociaż narzędzie to zostało wycofane pod koniec 2009 roku z witryny SysInternals, wciąż jeszcze można je znaleźć na dzisiątkach stron z przydatnymi programami.
Zaletą tego pakietu jest doskonała zgodność z przeszłymi wersjami systemów oraz prostota działania.

Z racji wycofania wsparcia dla tego narzędzia, niewiadomym jest jak będzie się ono zachowywac po wydaniu kolejnych poprawek do systemów Vista/Windows 7, jak i przyszłych edycji Windowsowej familii. W niektórych przypadkach problemy sprawiać moga próby wykorzystania tego narzędzia w zautomatyzowanej formie – na przykład wygenerowaniu nowych nazw dla hosta opartych o przewidywalny schemat.

3. Uzyj narzędzia DRBL-Winroll
Zaletą narzędzia jest jego wszechstronność – nie tylko możemy zmienić SID (nazwę) stacji roboczej, ale również jego przyszłe ustawienia sieciowe, nazwę grupy roboczej i dostępność usługi sshd.

Wadą rozwiązanie jest: konieczność przygotowywania domyślnych konfigów na określonej grupy maszyn (np. kojarzenie IP/grupy roboczej z MAC okreslonych stacji roboczych) i automatyczna instalacja pakietu CygWin. W przypadku chęci kozrystania z setupów automatycznych z serwera DRBL niezbędne jest skonfigurowanie kluczy ssh.

Dla tych którzy szukają wciąż NewSID’a – link: TU

Wspominałem wcześniej o jednej z podstawowych funkcjonalności serwerów DRBL – mechaniźmie klonowania stacji roboczych z wykorzystaniem wspólnej pracy Clonezilli i PXE. W skrócie – serwer DRBL zapewnia nam możliwość startu źródłowej stacji roboczej za pomocą PXE, Clonezilla wraz z pakietami towarzyszącymi klonuje zawartość dysków stacji roboczych do plików. Pliki mogą być zapisywane (używając kilku wskazanych metod kompresji) za pomocą SMB/FTP/SSH/NFS lub na lokalnych dyskach. Wspierane filesystemy to min:

• ext2,
• ext3,
• reiserfs,
• xfs,
• Jfs
• FAT16/32,
• NTFS 3 i 5(streams),
• HFS+
• Praca blokowa (block-by-block, sector-by-sector)

Idea ta pozwala na wykonanie jednoczesnych operacji na dowolnej ilości stacji roboczych – co więcej, w zależności od ilości danych i szybkości sieci, samo odtwarzanie/zapisywanie trwa od kilkunastu sekund, do kilkunastu minut.
Wyobrażcie sobie następujące zastosowanie: organizacja, w której wystepuje kilka modeli stacji roboczych. Każda z nich może spełniać inną rolę – od stacji użytkownika wprowadzającego dane po stacje księgujące, graficzne, administracyjne, techniczne – wszystko zależy od zastosowanego profilu oprogramowania lub ustawień systemowych.
Przy każdej awarii lub standaryzacji czeka nas nie lada wyzwanie:

– instalacja OS (często aktywacja ponowna – a więc wyjaśnianie dlaczego właściwie aktywuje się ta kopię po raz kolejny)
– instalacja wszystkich możliwych poprawek, service packów, Support Packów danego producenta itp.
– instalacja niezbędnego oprogramowania
– konfiguracja pod użytkownika

Każdy pracownik działu IT doskonale zna ten schemat. Aby ułatwić sobie życie: wykorzystując DRBL, na jednej ze wskazanych maszyn tworzymy instalację wzorcową (np. OS+poprawki+w miarę stałe ustawienia), resztę doinstalowując za pomocą skryptu z wykorzystaniem wolumenów sieciowych.

Z małą ilością użytkowników (stacje profilowane pod konkretnych userów a nie role) możemy pójśc o krok dalej – przygotowujemy pełny obraz: OS+poprawki+aplikacje+ustawienia charakterystyczne. Czas kompresji i rozmiar pliku wynikowego zależą ściśle od ilościu materiału do kompresji oraz maszyny na jakiej to wykonujemy.

Na szczęście sama dekompresja jest błyskawiczna – mam przygotowane obrazy pod różnych klientów w różnych instytucjach – przeciętny czas odtworzenia stacji roboczej po awarii to około 6 minut (obraz), 2-3 minuty na restart maszyny i dalsza konfiguracja za pomocą skryptu sieciowego – kolejne 3 minuty.

Idąc dalej tym sposobem – o ile jest taka potrzeba, za pomocą mechanizmu WoL możemy zaplanować wykonywanie kopii wskazanych maszyn np. co weekend.

Jak widać w czasie poniżej 15 minut można mieć pełne Disaster Recovery 😉

Co z serwerami zapytacie?
Rewelacyjnie. Wiemy bowiem, iż bez pełnego DR, w środowiskach które nie pracują jako HA – przeważnie posiadając jedną/dwie nie zwirtualizowane maszyny spełniające swoją rolę – metoda ta sprawdza się bardzo dobrze.
Zarówno w środowisku serwerów HP/DELL/IBM oraz innych firm trzecich, przy znikomym nakładzie środków i pracy możemy spokojnie wykonywać kopie OS umieszczane na dyskach macierzowych (SmartArray w HP, ServeRaid w IBM i PERC-H w Dell’u).
Minimalistyczny DR w tego typu maszynach obejmuje:
– konfigurację RAID HW
– odtworzenie OS za pomocą DRBL
– odtworzenie danych dla aplikacji/systemu z backupu.

Dla przykładu: DR zaprojektowany przeze mnie dla 200 maszyn HP DL 380 G4/G5, z Windows 2003, trzema różnymi wolumenami logicznymi (recovery OS), zajmujący około 20GB, odtwarzał się w około 8-9 minut (sieć 1Gb). Synchronizacja partycji z danymi – kolejne 10 minut.

👁 hp9000

Historia zaczyna się jak wszystkie – był sobie serwer HP 9000. W radosnym roku 1995 został uruchomiony w jednej z państwowych instytucji obsługując cały oddział i zapewniając niezbędne aplikacje, pod kontrolą systemu HP-UX. Chociaż dookoła tejże maszyny jak grzyby po deszczu wyrastały nowe maszyny, nowe szafy, nowe zwirtualizowane środowiska, maszyna wciąż okazywała się potrzebna zapewniając odpowiednie konektory do pracujących baz danych.

W tymże roku 1995 został opracowany podstawowy scenariusz DR (Disaster Recovery) odtwarzania pełnego systemu z napędów taśmowych. Procedura przetrwała, same napędy jak i taśmy niekoniecznie 😉 W związku ze zbliżającym się widmem awarii zostałem poproszony o przygotowanie planu ratunkowego pozwalającego na pełne odtworzenie systemu wraz z bieżącymi runetime’ami.

Dłuższą chwilę zajęło wyszukiwanie informacji o maszynie w części ‚Discontinued’ na stronie HP. WIzja lokalna potwierdziła założenia – magistrala SCSI (FAST), złącza wewnętrzne w standardzie HS50, wraz z dyskiem na taśmie znajdują się CDROM SCSI oraz napęd taśmowy – jeden z pierwszych DDS’ów 😉

Szatański plan ewoluował w następujące formie

Wariant A

Odszukujemy dystrybucję Linuxa wydaną dla PA-RISC (koniecznie live) i zmuszamy IPL’a maszyny do startu z tejże. Mają uruchomionego Linuxa możemy dostarczyć odpowiednie narzędzie do wykonania snapshotu sektorów startowych, tablicy partycji oraz samego systemu. Przygotowujemy procedurę odzysku – operację odwrotną dla procedury zabezpieczenia danych, również opartą o dystrybucję Linux wydaną dla PA-RISC.

Wariant B

Wykorzystując sytuację iż cały system pracuje na pojedynczym dysku SCSI  2.1 GB w standardzie Fast-SCSI HS50 – patrz poniżej – odnajdujemy odpowiedni kontroler SCSI, uruchamiamy maszynę pod kontrolą systemu Linux, odnajdujemy informację o możliwościach odczytu tablicy partycji systemu HP-UX i za pomocą odpowiedniego narzędzia wykonujemy kopię wskazanego dysku do obrazu a następnie na dysk ‚awaryjny’. Dodam iż odszukanie kontrolera ze złączem Fast nie sprawiło większego problemu, natomiast dysku o pojemności większej niż 2.1 GB już tak 😉

👁 HS50

Wariant C

Idziemy na żywioł 😉

Wariant A odpadł bardzo szybko – brak odpowiedniej dystrybucji live

Wariant B wykrzaczył się w połowie – OpenSuse w wersji 11.0 i 11.1 nie były w stanie odnaleźć na wskazanym dysku żadnych partycji. Ponieważ – czysto teoretycznie – powinny to zrobić, musieliśmy założyć iż kontroler HP 9000 nieco inaczej odczytuję geometrię dysku, stąd niepowodzenie w odczycie tejże dla kontrolera Tekram i systemu Linux.

Ostatnią deską ratunku okazało się banalne skopiowanie zawartości dysku za pomocą dd – ten soft nigdy nie przestanie mnie zadziwiać oraz przerzucenie obrazu również za pomocą dd na dysk awaryjny. W tymże dysku (jako że kontroler HP9000 należał do nieco prehistorycznych) należało jeszcze upewnić się iż auto-spinning jest zapewniony a ID i LUN ustawione właściwie. Dodam że cała operacja odczytu dysku zakończyła się w ok. 15 minut, drugie tyle zajęło skopiowanie obrazu dd.

Dysk zapasowy włożony w czeluści serwera został prawidłowo rozpoznany i obsłużony przez IPL, system wystartował poprawnie, konektory się podniosły. Hurra dla Linuxa ? 😉

Jak działa to w praktyce ? Otóż bardzo fajnie. System jest wyposażony w odpowiedni skrypt który sam pobierze i zainstaluje mini-instalacje powyżej zebranych dystrybucji. Oznacza to – iż chcemy np. mieć możliwość instalacji Debiana (Etch i Lenny) zarówno w wersji 32 jak i 64 bitowej, uruchamiamy odpowiedni skrypt (net-install) z parametrem Debian i za chwilę możemy cieszyć się dodatkowymi opcjami dodanymi do menu PXE.

Dalsza część usprawniania instalacji to oczywiście parametry przekazywane do instalatora w trakcie jego uruchomienia. Możemy wybrać jedno z właściwych repozytoriów Debiana, przekazać parametry instalacji …. lub możemy skorzystać z w pełni zautomatyzowanych systemów instalujących (FAI dla Debiana, AutoYAST dla SuSE)

W czasie pracy najwięcej czasu poświęciłem projektowi AUTOYAST, który dostępny jest dla systemów SuSE (openSuSE, Novellowe SLED i SLES). Ten w pełni dojrzały projekt pozwala nam na totalną i pełną konfigurację instalowanego systemu przez zestaw dyrektyw i parametrów zapisywanych w składni XML. Mamy wpływ na każdy etap procesu instalacji – zaczynając od parametryzacji dysków, partycji, filesystemów, rozmiarów instalacji, wybranych pakietów, startujących usług, konfiguracji wszelakich usług, uruchamiania dodatkowych skryptów (zarówno w fazie PRE jak i POST instalacyjnej), na integracji z LDAP i wykorzystaniu informacji z tegoż systemu do parametryzacji wszelakich instalacji.

Ba, dzięki podziałowi na fazy PRE i POST możliwe są takie rzeczy jak przygotowywanie własnych modułów do obsługi sprzetu (np. nietypowych lub nieobsługiwanych standardowo kart sieciowych, dostarczenie ich w fazie PRE a następnie kontynuacja instalacji w fazie POST)

System posiada własny edytor, dla zaawansowanych zostaje wersja XML do edycji ręcznej. Narzędzie jest bardzo wygodnie – wynikiem procesu projektowania jest plik XML którego lokalizację przekazujemy za pomocą PXE i DRBL’a do instalatora. Przygotować możemy nieskończoną ilość takich profilowanych instalacji dołączając je kolejno do menu instalatora.

Przykładowa dyrektywa instalacji stosowanych przeze mnie:

label Instalacja
# MENU DEFAULT
# MENU HIDE
MENU LABEL Instalacja zaplecze v.2.xx
# MENU PASSWD
TEXT HELP
* Instalacja systemu operacyjnego SLED 10 SP1
ENDTEXT
kernel linux
append initrd=initrd.200902 ramdisk_size=128000 splash=silent showopts install=http://172.16.0.1:/sled server=172.16.0.1 serverdir=/sled autoyast=http://172.16.0.1/sled/autoyast-net-raid.xml language=pl_PL

Jak wygląda wydajność takiego rozwiązania? Systemy sprofilowane (SLED 10 SP1) na maszynach klasy Intel Celeron (1.8/2.0) z 1 GB RAM, z pełnym oprogramowaniem projektowym instalują się około 45 minut. Niesamowitym plusem takiego rozwiązania, przy zastosowaniu szybszych interfejsow Gigabitowych jest fakt, iż jednocześnie może trwać instalacja wielu maszyn. W testach przeprowadzanych przez nas do 5 maszyn jednocześnie spowolnienie instalacji było niewidoczne (sieć lokalna, interfejsy i switche gigabitowe).

Przy wzroście ilości maszyn do 10 na raz czas instalacji per wzrósł o ok.5 do 7 minut. Oznacza to, iż średniej klasy maszyna (desktop jako serwer) jest w stanie przeprowadzić około 80 instalacji dziennie w 8 godzinnym cyklu pracy. Zakładając możliwość dostawienie drugiego interfejsu – liczba wzrasta do 150 w cyklu 8 godzinnym.

Warto zaznaczyć iż instalacja jest totalnie bezobsługowa – można nawet nie wykorzystywać monitorów do obserwacji procesu. Prostym wpisem w autoyast całość instalacji kończymy shutdownem – oznacza to iż każda z maszyn które własnie go wykonały są gotowe do spakowania do pudełka lub wykorzystania w projekcie.

Rozwinięciem idei  instalacji bezdotykowej jest zastosowanie sieci serwerów DRBL jak na poniższej ilustracji:

👁 Slajd18

Poszczególne serwery rozproszone w innych lokalizacjach (inny budynek, inne miasto, inny kraj) pozwalają na wykonywanie dokladnie tych samych czynności w oddziałach, używając tych samych (lub odpowiednio zmodyfikowanych korzystając z LDAP/AD) parametrów.

Za całość procesu synchronizacji odpowiadać może subsystem RSYNC skonfigurowany tak aby weryfikować i naprawiać ewentualne błędy za pomocą weryfikacji sum kontrolnych MD5.

Najciekawiej wygląda zarządzanie zmianą w tego typu projekcie – z racji niewielkich rozmiarów zarówno samego autoyast.xml , jak i poszczególnych pakietów wchodzących w sklad instalacji, aktualizację założeń instalacji, aktualizację pakietów instalacyjnych można przeprowadzić dosłownie w kilka minut.

W praktyce przesłanie samych założeń instalacji trwa około 2 minut w przypadku 6 dodatkowych rozproszonych lokalizacji. Gdy w grę wchodzą pakiety dodatkowe wykorzystujemy przetwarzanie równoległe – wiele jednoczesnych procesów synchronizacji (wykorzystujących fakt iż łacze serwera centralnego jest wielokrotnie bardziej wydajne niż łącza poszczególnych serwerów oddziałowych.

Ponieważ jednocześnie, oprócz samych opisow instalacji przesyłać można obraz wykonane za pomocą systemu Clonezilla sam DRBL okazał się doskonałym uzupełnieniem codziennej pracy systemowo-projektowej.

Wyobraśmy sobie projekt w którym z częstotliwością np. miesięczną zmieniają się obrazy instalacyjne stacji roboczych i nośników. Dystrybucja tychże na nośnikach DVD/USB okazywała się koszmarem – zawsze zdarzało się iż wersja jak została zainstalowana różni sie od wersji obowiązujacej. Dokładając do tego czas rozproszenie i przygotowania nośników okazało się to sporym problemem.

Rozwiązanie przyszło w postacji maszyny DRBL – zawsze dostępnej z tym samym menu co ostatnio. Zawartość obrazów mogła zostać zaktualizowana, instalator mógł wykonywać zupełnie nowe czynności, jednakże z punktu widzenia instalującego NIC się nie zmieniało. Zawsze witał go ten sam, widziany ostatnio obrazek 😉

Ponieważ jak słusznie zauważył jeden z moich szanownych projektowych kolegów:  ‚ Wpisanie hasła ‚drbl’ do Googla już od 3 pozycji zaczyna wypluwać Twoje nazwisko‚ 🙂  warto by było, aby wykorzystując materiały które tak pięknie udało mi się zebrać, przekazać kilka dobrych słów w temacie tegoż produktu – którego zastosowanie mogę wyobrazić sobie prawie wszędzie. Samo ‚wygooglanie’ ma związek z wykładem jaki miałem przyjemność przekazywać dla studentów AGH w Krakowie, z racji inicjatywy LUMD, szerzej tutaj: https://marcinbojko.wordpress.com/2009/05/04/lumd-linux-u-mnie-dziala/

Spróbujmy. Sam akronim DRBL rozwija się w skrót Diskless Remote Boot Linux, co oznaczając możliwość uruchomienia dowolnej dystrybucji Linuxa, za pomocą sieci na bezdyskowych końcówkach (workstacjach) było jednym z pierwszych zastosowań tego systemu.

W praktyce ewoluował on do takiego stopnia (min. przez różne dziwne pomysły które udało nam się zastosować) iż stał się mechanizmem dostarczania dowolnych usług/aplikacji za pośrednictwem protokołów PXE. Wyjaśniając bardziej: pozwala nam za pomocą bootowania z wykorzystaniem interfejsów sieciowych uruchomić prawie że dowolną usługę lub aplikację system.

Przykłady? Przykłady poniżej.

Co w tym nowego zapytacie? Nowego – nic.  Ale jeżeli zbierze się w całość wszystkie systemu które do tej pory trzeba było instalować oddzielnie aby uzyskać podobny efekt (poświęcając temu spore ilości godzin) to własnie uzyskamy naszego DRBL’a.

Mechanizm działania jest prosty – dowolna workstacja, która posiada możliwość bootowania z karty sieciowej (w praktyce wszystkie produkowane po 2002/2003 roku) – za pomocą protokołu PXE otrzymuje od serwera DRBL możliwość uruchomienia menu startowego, z którego możemy uruchamiać dalsze dowolne podsystemy. Ponieważ system jest skonstruowany tak aby nie wykorzystywać przestrzeni dyskowej na workstacji klienckiej, jedynym ograniczeniem w uruchamianiu bardziej rozbudowanych subsystemów staje się pamięć RAM. Oczywiście sama ilość pamięci jest ściśle określana przez subsystem który chcemy uruchomić – dla zdalnego uruchomienia np. FREEDOS‚a wystarczy nawet 640kb 😉

Oznacza to iż dla uruchomienia prostego zestawu serwer-klient potrzebujemy sprzętu który spełnia naprawdę minimalne wymagania, co za tym idzie jest tani, łatwo dostępny i …. wspomniałem już tani ?

Zobaczcie sami jak pięknie może to wyglądać.

Sieć korzystająca z zasobów serwera DRBL może wyglądać na przykład tak:

👁 Image
👁 Slajd6

– za pomocą jednego serwera i 4 interfejsów sieciowych (jeden WAN) oferujemy 3 różne usługi.

Wiemy, w wielkim skrócie jak, teraz pytanie CO można dostarczyć w ten sposób. Proszę bardzo: standardowe przykłady:

👁 Slajd8

Instalacja wspieranych systemów:

• Instalacja wielu stacji roboczych jednocześnie (do 40 na interfejsach gigabitowych) bez wyraźnego spowolnienia działania.
• Wykorzystanie mechanizmu unicast i multicast
• Wykorzystanie mechanizmów PXE, TFTP, HTTP (lokalny i z repozytoriów), FTP, NFS
• Możliwość instalacji skryptowej (min. autoyast w SUSE), instalacja dodatkowych aplikacji i pakietów
• Możliwość wykonywania aktualizacji ze wskazanych repozytoriów lub cache’u lokalnego
• Wspiera mini-dystrybucje lub wersje net-install

Uruchamianie OS na maszynach klienckich za pomocą PXE

Klonowanie i utrzymanie dysków i wolumenów (Clonezilla)

Na dzisiaj tyle danych do przełknięcia 😉  O ile wskoczę na pozycję numer jeden w Google – będę kontynuował temat.

Kilka tygodni temu miałem okazję puścic w eter parę słów odnosnie oprogramowania open-source (którego jestem orędownikiem) na przykładzie systemu DRBL (Diskless Remote Boot Linux) – softu, do którego da się podpiąć wiele innych ‚modułów’, zamieniając to w jeden wielki przemysłowy kombajn.

Wykład odbył się 16.04.2009, na AGH w Krakowie z inicjatywy LUMD Koło Naukowe Informatyków „KERNEL” . Ponieważ nie wiem czy i kiedy będzie dostępny film z wykładu, zamieszczam na razie sama prezentację, którą w formie open-source mozna wykorzystywać dalej.

Prezentacje mozna pobrać stąd: Prezentacja

Sam system DRBL jest dostępny tutaj:http://drbl.sourceforge.net/