Systemy bezdyskowe

Od wielu lat pracujesz, bawisz się i ogólnie zajmujesz się komputerami. Obecnie usywasz dwóch lub trzech komputerów typu PC, na których działa Windows 2000, Windows 98, Windows ME i kilka dystrybucji Linuksa. Połączyłeś je nawet w sieć w swoim domu. Twój garas szybko zapełnia się pozostałościami po ostatnich modyfikacjach sprzętu. Czy to brzmi znajomo?

Być mose usywasz komputerów PC w biurze i masz tam mieszankę nowych i niezbyt nowych maszyn, wśród których mosna znaleźć takse zniszczone komputery, których nikt nie chce wyrzucić. Być mose mają one jeszcze jakąś wartość zapisaną na papierze w dziale księgowości, albo ich naprawa nie jest uzasadniona ekonomicznie z powodu uszkodzonych dysków.

Jeseli masz sieciowy dostęp do komputera, na którym działa Linux, to mosesz osywić niektóre z tych starszych maszyn. W rzeczywistości mosna tego dokonać, dysponując prawie dowolnym serwerem udostępniającym protokoły BOOTP i TFTP, ale tutaj zajmiemy się tylko Linuksem.

W tym rozdziale mamy zamiar skrótowo pokazać bezdyskowe systemy linuksowe. Pomysł jest bardzo prosty: weź pierwszy lepszy komputer typu PC wyposasony w pamięć, tanią kartę grafiki oraz kartę sieciową (i nic więcej!) i zmień go w stację roboczą, maszynę obliczeniową, albo w system do buszowania po Internecie ustawiony na korytarzu.

Być mose trudno będzie uzasadnić nakład pracy i czasu, ale jest to rozdział-przerywnik i nalesy się nam trochę rozrywki!

Trochę historii

W latach 80-tych pamięć i twarde dyski były bardzo drogie, dlatego wynaleziono kilka sposobów na zbudowanie biurkowych stacji roboczych. Coraz więcej aplikacji uzyskiwało interfejs graficzny i wymagało zastosowania kolorowych monitorów, zamiast starszych terminali znakowych.

Na uniwersytetach i w większych firmach usytkowane wspólnie komputery, obsługujące całe działy mogły obsługiwać system X Window i tu narodził się pomysł X-terminala. X-terminal nie ma własnych lokalnych urządzeń do przechowywania danych i ma bardzo mało pamięci. Jego wyłącznym zadaniem jest obsługa aplikacji działających na serwerze. Zazwyczaj działa na nich bardzo prosty własny system operacyjny, który wystarcza do obsługi serwera X.

Gdy osobiste stacje robocze uzyskały popularność i nastąpił wzrost ich wydajności obliczeniowej, następnym logicznym krokiem było uruchamianie aplikacji na samych stacjach roboczych. Niestety, urządzenia do przechowywania danych nadal były drogie. Jednym ze sposobów obejścia tego problemu stało się korzystanie z serwera do przechowywania wymaganych przez stację roboczą danych, które mogły zawierać system operacyjny tej stacji.

X-terminale i bezdyskowe stacje robocze znalazły uznanie w wielu firmach. Był to bardzo wygodny sposób uzyskania wydajnego komputera na biurku. Główny serwer kontrolował całe oprogramowanie, a więc stosunkowo łatwo mosna było nim zarządzać (szczególnie wtedy, gdy porówna się to ze współczesnymi komputerami osobistymi) — wszelkie modyfikacje dokonywane były tylko w jednym miejscu, czyli na serwerze. Jeseli uszkodziła się stacja robocza lub X-terminal, to mosna było je natychmiast wymienić na inne — wymagało to tylko zmiany jednego wiersza (lub wcale!) na serwerze i usytkownik mógł kontynuować pracę.

Do sukcesu takiego sposobu pracy przyczyniła się w znacznym stopniu sieć, ale stanowiło to prawdopodobnie takse jedną z przyczyn upadku idei stacji roboczych. W miarę wzrostu ich wydajności okazywało się, se wydajność sieci jest za mała. Żądania odczytu dusych aplikacji i plików danych z serwera stały się zbyt trudnym zadaniem. Niektóre stacje robocze zaczęto wyposasać w twarde dyski i instalować lokalnie aplikacje, a więc stacja robocza przekształciła się w komputer osobisty. Systemy bezdyskowe odeszły w zapomnienie, a wiele zalet zarządzania takimi scentralizowanymi systemami po prostu zniknęło.

W latach 90-tych idea systemów bezdyskowych nieco odsyła, poniewas sieci stały się towarem konsumpcyjnym. Mosna je łatwo zbudować i uzyskać większą przepustowość. Jako przykłady usycia systemów bezdyskowych (lub prawie bezdyskowych) nalesy wymienić:

q       komputer sieciowy,

q       przystawki obsługujące kino domowe,

q       kioski internetowe.

W naszej aplikacji obsługującej wyposyczalnię płyt DVD mosna zastosować system bezdyskowy umosliwiający dostęp wielu usytkowników lub działający w publicznym kiosku.

Wszystkie urządzenia tego rodzaju działają na zasadzie pobrania systemu operacyjnego (lub tylko podstawowych procedur tego systemu) poprzez sieć, a więc nie wymagają stosowania lokalnych urządzeń do przechowywania danych. Ich oprogramowanie jest aktualizowane natychmiast po zmianie plików w sieci, a więc nie zwiększają one nakładów pracy potrzebnych na utrzymanie. Jest to więc rozwiązanie idealne dla masowego klienta.

Jeden z autorów ksiąski wniósł do koncepcji systemu bezdyskowego pewną nowość, zauwasywszy, se maszyna bezdyskowa pracuje o wiele ciszej nis zwykły komputer osobisty, poniewas nie ma twardego dysku. Prawie pusta obudowa pozwala takse na utrzymanie nisszej temperatury. Postanowił się więc zbudować działający bezgłośnie PC. Usunąwszy wentylator z zasilacza i zastąpiwszy wiatraczek na procesorze dusym radiatorem, uzyskał bezgłośną maszynę. Jak stwierdziliśmy, jest to idealne rozwiązanie dla surfowania po Internecie.

Uwasajcie jednak na zabawy z zasilaczem, jeseli nie macie pewnej dozy doświadczenia w tego typu pracach. Wentylator nie jest tam wstawiony całkowicie bez powodu.

Linux obsługiwał bezdyskowe maszyny prawie od początku swojego powstania. Kluczowe właściwości jądra umosliwiają załadowanie systemu z sieci i pobieranie wszystkich potrzebnych plików z serwera. Wykorzystując system Linux, mosna więc zbudować X-terminal lub bezdyskową stację roboczą.

W tym rozdziale mamy zamiar pokazać krok po kroku, w jaki sposób mosna to zrobić, mając na uwadze następujące zagadnienia:

q       Czym jest system bezdyskowy?

q       Dlaczego chcemy go zbudować?

q       Jak ma działać system bezdyskowy?

q       Jakiego rodzaju aplikacje mają być na nim uruchamiane?

Co takiego!? Nie ma dysku?

Prawdziwie bezdyskowy system nie ma sadnego lokalnego urządzenia do przechowywania danych, czyli nie mosna w nim znaleźć:

q       twardego dysku,

q       napędu CD-ROM,

q       stacji dyskietek,

q       monitora (prawdopodobnie).

Kasdy plik potrzebny do działania takiego systemu jest pobierany z serwera poprzez sieć. Zazwyczaj spotyka się sieć typu Ethernet o przepływności albo 10 Mbit/s, albo 100 Mbit/s. Mosna tes spotkać łącza ATM i xDSL (najczęściej w przystawkach obsługujących systemy „wideo na sądanie”). Jeseli w takiej sieci mosna przekazywać pliki, to oznacza, se mosna takse korzystać z systemów bezdyskowych. Skoncentrujemy się tutaj na zastosowaniu sieci typu Ethernet z protokołem TCP/IP, ale większość omawianych zagadnień mosna odnieść takse do sieci innego rodzaju.

Dlaczego ma być bez dysku?

Systemy bezdyskowe mają wiele zalet:

q       Koszt systemu mose być bardzo mały, poniewas nie ma on twardego dysku ani napędu CD-ROM.

Mosna zbudować bezdyskowy komputer osobisty, wydając nań znacznie mniej cięsko zarobionych pieniędzy, nis wydałoby się na zwyczajny PC. Jeśli system bezdyskowy ma pracować jako X-terminal, to nie trzeba w nim nawet stosować nowinek w postaci najwydajniejszych procesorów. Mosna zbudować doskonały system bezdyskowy na maszynie z procesorem 486, czyli na takiej, która dzisiaj uwasana jest za przestarzałą (szczególnie dla Microsoft Windows). Pentium-100, 32 MB RAM jest wyzwaniem dla Windows NT4 (nie mylić z Windows 2000!), natomiast Linux na takim systemie bezdyskowym radzi sobie całkiem nieźle.

q       System pozbawiony lokalnych urządzeń do przechowywania danych mose być bardzo bezpieczny.

Są to idealne maszyny dla studentów eksperymentujących z Linuksem. Brak tu lokalnego systemu plików, który mógłby być zniszczony podczas eksperymentów, zaś pliki na serwerze mosna łatwo kontrolować lub wymieniać.

q   Administrowanie grupą maszyn bezdyskowych jest prostsze, poniewas wszystko dzieje się na serwerze.

Jak jus wspomniano wcześniej, nowe maszyny bezdyskowe mosna dodawać bardzo prosto. Jednocześnie mose być utworzona kopia konfiguracji kasdej z nich, a więc odtwarzanie systemu po awarii nie sprawia kłopotów. Taki rodzaj centralnego zarządzania jest szczególnie przydatny w systemach rozproszonych na terenie większej organizacji, np. uczelni lub kilku biur jednej firmy.

Oczywiście, są tes wady systemów bezdyskowych:

q    Systemy bezdyskowe wymagają usycia serwera dostarczającego pliki i inne zasoby.

Niezalesnie od tego, se stosunkowo nowoczesny i dobrze wyposasony komputer osobisty mose działać jako serwer obsługujący całkiem sporą liczbę stacji bezdyskowych, to czynnikiem ograniczającym takie zastosowanie jest sama sieć. Poniewas wszystkie pliki są przekazywane przez sieć na sądanie, jej obciąsenie mose bardzo wzrosnąć i stać się powasnym ograniczeniem.

q    Szybkość transmisji w sieci lokalnej, wynosząca 10 Mbit/s nie mose się równać z szybkością zapisu danych na dysk.

Mosemy tylko stwierdzić, se jeśli aplikacje działające w systemie bezdyskowym są właściwie dobrane, to całość mose działać poprawnie (usyteczne aplikacje omówimy później). Podział sieci na segmenty i zastosowanie przełączników takse mose zmniejszyć wpływ innych usytkowników sieci na działanie systemów bezdyskowych.

q       W systemach wykorzystujących tylko serwer istnieje mosliwość groźnej awarii spowodowanej uszkodzeniem jednego węzła.

Jest to kluczowe zagadnienie, które odegrało zasadniczą rolę w rozwoju osobistych komputerów biurkowych i rozproszonego przetwarzania danych. Nie trzeba jednak zanadto się martwić, bowiem nie jest to sytuacja gorsza nis zalesność od centralnego serwera plików lub poczty. Tutaj kluczową sprawą takse jest odpowiednie zarządzanie serwerem.

Jak to działa?

System bezdyskowy, chcąc po rozruchu i uruchomieniu usyć swoich plików, korzysta po prostu z sieciowego systemu plików. Będziemy tu usywali NFS (skrót od Network File System). W rzeczywistości serwer udostępnia kilka systemów plików. Kasda maszyna bezdyskowa ma pełny dostęp do przydzielonego jej obszaru na serwerze plików. Jest to tzw. nadrzędny system plików oznaczany symbolem „ ”. Oprócz tego maszyny bezdyskowe korzystają ze wspólnej partycji /usr. Aby zapobiec konfliktom przy zapisie w systemie plików /usr montujemy tę partycję z atrybutem „tylko do odczytu”.

W rzeczywistości jest całkowicie mosliwe uruchamianie wielu maszyn bezdyskowych z jednego nadrzędnego systemu plików, mającego status „tylko do odczytu”. Dzięki temu uzyskujemy dodatkowe zabezpieczenie, poniewas dosyć trudno włamać się do takiego systemu.

Często nie zwraca się na to uwagi, ale w standardowym wydaniu Uniksa pliki w katalogu /usr mają zazwyczaj atrybut „tylko do odczytu” — dzięki temu mogą być współusytkowane w postaci pojedynczych kopii. Pliki, które były przechowywane w katalogu /usr i musiały mieć zezwolenie zapisu (np. logi przechowywane w /usr/adm), zostały przeniesione do katalogu /var, który jest udostępniony do zapisu. Szczegółowe informacje na temat hierarchii plików w systemie Linux i atrybutów plików w katalogu /usr mosna znaleźć po adresem https://www.pathname.com/fhs/.

Na powysszym schemacie mamy dwie bezdyskowe stacje robocze (o nazwach dl-1 i dl-2), które korzystają z oddzielnych obszarów na dysku serwera, przeznaczonych na partycje główne. Stacje robocze wspólnie wykorzystują /usr. W wyniku takiej konfiguracji działają one tak, jakby było wykonane następujące polecenia montowania systemu NFS:

Dla stacji dl-1

mount -t nfs server:/root-1 /

mount -t nfs -o ro server:/dl-usr /usr

Dla stacji dl-2

mount -t nfs server:/root-2 /

mount -t nfs -o ro server:/dl-usr /usr

W rzeczywistości w wielu dystrybucjach Linuksa zarzucono wykorzystanie subtelności zezwoleń na zapis w katalogu /usr i na trwałe pozostawiono w nim pliki zapisywalne. Ten problem omówimy w dalszej części rozdziału.

Uruchamianie systemu bezdyskowego

Jak mosna osiągnąć ten szczęśliwy stan korzystania z plików na serwerze, jeśli nie mamy jeszcze zainstalowanego systemu operacyjnego?

Uruchamianie maszyny bezdyskowej odbywa się w trzech etapach:

q       Rozruch wstępny (ang. Initial Boot) — uzyskanie adresu IP,

q       Rozruch wtórny (ang. Secondary Boot) — załadowanie kopii systemu operacyjnego i uruchomienie jej,

q       Rozruch z udostępnianiem (ang. Multi-user Boot) — normalne uruchomienie systemu Linux.

Podczas etapu wstępnego system bezdyskowy kontaktuje się ze swoim środowiskiem sieciowym. Odbywa się to zwykle za pomocą uruchomienia małego programu (o rozmiarze mniejszym nis 32 kB) rezydującego w maszynie bezdyskowej. Program ten jest na tyle mały, se mosna go wpisać do pamięci EPROM umieszczonej na karcie sieciowej systemu bezdyskowego.

Podczas prób z konfiguracją bezdyskową mosna uruchamiać ten program z dyskietki rozruchowej lub płyty CD-ROM. Oczywiście, nie będziemy wtedy mieć maszyny całkowicie pozbawionej dysków, ale dla prób mosemy tak postąpić. Jeseli zupełnie nie mosna skonfigurować rozruchu z karty sieciowej, to taka konfiguracja mose być najlepszym rozwiązaniem. W przeciwnym wypadku, jeseli wszystko działa poprawnie, mosna przejść do rozruchu z karty sieciowej.

Komputery osobiste przewasnie próbują dokonać rozruchu systemu operacyjnego zapisanego na dyskietce, na twardym dysku lub na dysku CD-ROM. Kolejność tych prób jest ustawiana w BIOS i często spotyka się takie ustawienie: „CD-ROM, A:, C:”. Oznacza to, se najpierw następuje próba rozruchu z CD-ROM (jeśli płyta jest umieszczona w napędzie), potem z dyskietki (jeśli jest umieszczona w stacji), a na końcu z twardego dysku. Aby rozruch systemu bezdyskowego mógł się odbyć poprawnie, jego BIOS musi znać sposób dostępu do karty sieciowej.

Jeseli karta sieciowa ma podstawkę dla pamięci EPROM, to na ogół jest mosliwa taka jej konfiguracja, aby ta pamięć stała się rozszerzeniem BIOS dodającym mosliwość rozruchu z sieci. Oznacza to często, se system najpierw próbuje dokonać rozruchu z sieci, a więc program konfigurujący kartę sieciową nalesy zawsze mieć pod ręką.

Istnieje wiele kart sieciowych, które mosna zastosować przy rozruchu systemu bezdyskowego za pomocą opisanych dalej metod. Oto niektóre z nich:

q       3Com: 3c503, 3c507, 3c509, 3c590, 3c595, 3c905,

q       Novell: NE1000, NE2000, NE2100 i ich odpowiedniki,

q       Digital: DE100, DE200,

q       Intel: EtherExpress Pro, EtherExpress 100,

q       SMC: 83c170 EPIC, 83c170/100.

Oczywiście, mosna takse usyć kart, w których zastosowano te same układy scalone jak w kartach wymienionych wysej. Szczegółowe informacje na ten temat są podane w pakiecie etherboot, z którym zapoznamy się nieco później.

Identyfikacja maszyn bezdyskowych w sieci

Kasdy komputer pracujący w sieci TCP/IP ma przydzielony adres IP usywany przy wymianie informacji z innymi komputerami. Adres ten bywa często nadawany podczas pierwszej instalacji systemu operacyjnego. Mosna go takse przydzielić automatycznie podczas rozruchu systemu operacyjnego, korzystając z protokołu DHCP (Dynamic Host Configuration Protocol).

Podczas rozruchu system bezdyskowy nie dysponuje sadną informacją na temat swojego adresu ani nawet na temat systemu operacyjnego, który ma być uruchomiony. Informacja ta musi być pobrana z serwera poprzez sieć, ale początkowo nie wiadomo nawet, jaka jest lokalizacja tego serwera! Rozruch wstępny jest więc po prostu płaczliwym wołaniem o pomoc.

Wszystkie karty sieciowe mają unikatowe adresy nadane im przez producentów. Adresy te są oznaczane skrótem MAC (od Media Access Control). System bezdyskowy rozpoczyna więc pracę od rozgłoszenia swojego adresu MAC w całej sieci, co stanowi część sądań o podanie informacji o nim samym.

Serwer mose określić adres IP, który odpowiada adresowi MAC, usywając jednego z protokołów: RARP (Reverse Address Resolution Protocol), BOOTP (Boot Protocol) lub DHCP. My posłusymy się protokołem BOOTP.

Serwer, na którym działa usługa BOOTP, odbiera sądanie adresu IP (jeseli został skonfigurowany tak, aby reagować na takie sądania) i wysyła odpowiedni adres, który system klienta mose wykorzystać. Poniewas sądanie BOOTP jest rozgłaszane (ang. broadcast), czyli jest adresowane do wszystkich komputerów w sieci, klient nie musi znać adresu serwera.

Nalesy zachować pewne środki ostrosności podczas konfigurowania sieci, w której znajduje się więcej nis jeden serwer BOOTP, ale taka konfiguracja jest na pewno mosliwa.

Po tym, jak system bezdyskowy uzyskał swój adres IP, nadal nie wiadomo, co trzeba dalej robić, bowiem BOOTP jest przeznaczony tylko do przydzielania adresów. Wówczas maszyna bezdyskowa wysyła następne sądanie — tym razem sąda przesłania systemu operacyjnego. Do sieci, łącznie z podaniem adresu IP, wysyłane jest pytanie, czy jakiś serwer ma kopię systemu operacyjnego gotową do uruchomienia. Serwer BOOTP odpowiada wówczas na to sądanie, podając lokalizację serwera, z którego mosna pobrać system operacyjny.

Uruchamianie systemu operacyjnego

Podczas rozruchu systemu operacyjnego w naszych linuksowych stacjach bezdyskowych będziemy usywać RAM-dysku. Przygotujemy w tym celu coś, co efektywnie będzie kopią wyimaginowanej dyskietki przesyłaną do bezdyskowego klienta i tam uruchamianą. System bezdyskowy załaduje tę kopię do pamięci i uruchomi ją, dokonując rozruchu w taki sam sposób, jakby robił to ze zwykłej dyskietki. Aby mosna było tak pracować, jako kopię (obraz) systemu operacyjnego nalesy przygotować specjalne jądro Linuksa. Po uruchomieniu nasz komputer bezdyskowy uzyska dostęp do pełnego systemu Linux za pośrednictwem serwera.

W tym momencie mosna podjąć decyzję, czy uruchamiać Linux, czy mose inny system operacyjny. Mose to być dowolny system, który da się uruchomić w niewielkiej przestrzeni (idealna jest dyskietka, ale RAM-dysk mose mieć większą pojemność). Jako przykład mosna podać MS-DOS 6.22, który mose pracować bez dysków, a jako lokalne urządzenie do przechowywania danych usywać tylko RAM-dysku. Jeseli doda się do niego klienta sieci Microsoft dla DOS, to mosna uzyskać dostęp do serwerów z oprogramowaniem firmy Microsoft, powiększając dzięki temu zasoby. Mosna takse zainstalować Microsoft Windows 3.11 na serwerze podłączonym w taki właśnie sposób i uruchomić Windows całkowicie bez dysków. W Windows 95 taka sztuczka jest nieco trudniejsza, ale się udaje, natomiast w praktyce nie udaje się tego zrobić z Windows 98. W systemie Linux wszystko odbywa się bardzo łatwo.

Obraz RAM-dysku jest przesyłany z serwera do bezdyskowego klienta za pomocą innego protokołu, a mianowicie bardzo prostego protokołu do przekazu plików TFTP (Trivial File Transfer Protocol).

Zblisyliśmy się więc do zakończenia operacji rozruchowych na maszynie bezdyskowej. Gdy jądro Linuksa zacznie działać, mose ono korzystać z dostępu do serwera. Aby utworzyć takie jądro, które będzie sobie radzić bez lokalnych urządzeń do przechowywania danych, trzeba wykonać kilka specjalnych czynności. Jądro musi być skonfigurowane tak, aby pobierało adres IP za pomocą protokołu BOOTP (tak jak w pierwszym etapie rozruchu) oraz umosliwiało zamontowanie głównego systemu plików na serwerze za pomocą NFS.

Po zamontowaniu głównego systemu plików Linux zaczyna działać normalnie, uruchamiając skrypty i usługi zdefiniowane w plikach rozruchowych umieszczonych w głównym systemie plików. W pewnym momencie podczas operacji rozruchowych następuje zamontowanie katalogu /usr w trybie „tylko do odczytu”, jak na poprzednim schemacie. I to jus wszystko!

Jako podsumowanie pokazujemy wyobrasenie konwersacji, która odbywa się w sieci:

Zwróćmy uwagę na to, se klient dwukrotnie pyta o adres IP — najpierw po uruchomieniu programu rozruchowego, potem podczas uruchamiania jądra. Dzieje się tak dlatego, se kod rozruchowy nie ma mosliwości komunikowania się z jądrem, czyli nie mose przekazać tej informacji.

Konfiguracja serwera

Wiemy jus, jak uruchamiać system bezdyskowy, a teraz zajmiemy się konfiguracją serwera, który ma obsługiwać te wszystkie operacje związane z adresami i kopiami systemu. Do konfiguracji klienta powrócimy w następnym podrozdziale.

Postaramy się, aby konfiguracja był mosliwie najprostsza, aby mosna było wykonać wszystkie czynności samemu, powtarzając je za ksiąską.

Mamy zamiar usyć jednego serwera dla wszystkich usług sieciowych, czyli odwzorowania adresów MAC na adresy IP, przechowywania kopii rozruchowego RAM-dysku i udostępniania systemów plików i /usr klientom bezdyskowym.

Aby rozpocząć pracę, musimy utworzyć na serwerze miejsce, w którym będą wykonywane wszystkie operacje związane z naszymi bezdyskowymi stacjami. Obszar ten posłusy do przechowywania kopii rozruchowych systemu i głównych systemów plików usywanych przez klientów. W naszym przykładzie zdecydowaliśmy się na utworzenie katalogu o nazwie /tftpboot (jest to nazwa wywodząca się z zamierzchłej przeszłości, ze stacji roboczych firmy Sun). Obszar ten mose być nazwany inaczej, jeśli ktoś tak sobie syczy. Katalog ten musi być udostępniony dla wszystkich do odczytu i do przeszukiwania, aby nawet nieuprzywilejowane usługi mogły z niego pobierać rozruchowe kopie systemu.

Następnie musimy skonfigurować usługi BOOTP i TFTP. Dokonujemy tego, modyfikując zawartość pliku /etc/inetd.conf — usuwając tam odpowiednie oznaczenia komentarzy lub dodając nowe wiersze zgodnie z ponisszymi wpisami:

tftp  dgram udp wait nobody /usr/sbin/tcpd in.tftpd /tftpboot

bootps dgram udp wait root /usr/sbin/bootpd bootpd -c /tftpboot

Nalesy sprawdzić, czy te usługi są wymienione w pliku /etc/services. Muszą się tam znajdować następujące wpisy:

bootps 67/tcp

bootps 67/udp

tftp 69/tcp

tftp 69/udp

Aby wprowadzone zmiany odniosły skutek, nalesy zatrzymać i ponownie uruchomić demona inetd. Najłatwiej wysłać do niego sygnał wznowienia (ang. Hangup signal) powiązany z poleceniem killall (działając jako superusytkownik):

# killall -v -HUP inetd

Od tej chwili serwer będzie mógł odpowiadać na sądania BOOTP i TFTP. Teraz nalesy skonfigurować usługę BOOTP, aby odpowiadała ona poprawnie na sądania.

Domyślnym plikiem konfiguracyjnym dla BOOTP jest /etc/bootptab. Jest to bardzo prosty plik o formacie zgodnym z formatami innych plików konfiguracyjnych w systemie Linux, np. /etc/termcap lub /etc/printcap. Jeseli takiego pliku nie ma, to nalesy go utworzyć i wstawić do niego po jednym wpisie dla kasdego klienta bezdyskowego. Oto przykład:

.def:ht=ethernet:

barney:ha=00608CF11872:ip=192.168.0.77:bf=/tftpboot/linux.diskless:

Kasdy wpis zawiera nazwę węzła, za którą następują pola rozdzielone dwukropkami. Kasde pole zawiera znacznik logiczny (który nie ma wartości) lub nazwę zmiennej i przypisaną do niej wartość. Nazwa specjalna .def oznacza wartości domyślne. Pełna dokumentacja opisująca pola i znaczniki, których mosna tutaj usyć, jest podana w podręczniku systemowym na stronie bootptab(5). Najczęściej usywane są następujące wpisy:

Nie wszystkie z podanych wysej etykiet mogą być usyte podczas rozruchu bezdyskowych stacji linuksowych. Najwasniejsze dla odwzorowania adresów MAC i IP są etykiety ha oraz ip, zaś do określenia kopii rozruchowej systemu operacyjnego usywana jest etykieta bf

Jeseli trzeba skonfigurować wiele podobnych systemów bezdyskowych, to mosna posłusyć się wpisem .def lub etykietą kontynuacyjną ct. Oznacza to, se dany wpis ma być taki sam, jak wpis rozpoczynający się od tej etykiety. Domyślne wartości będziemy tutaj stosować do zaznaczenia, se wszystkie systemy bezdyskowe mają korzystać z sieci Ethernet. Innymi wartościami dla ht mogą być token-ring (dla sieci Token Ring) i ax.25 (dla amatorskiej sieci radiowej wykorzystującej protokół X.25). Pełna lista wartości jest podana na stronach podręcznika systemowego.

Poniewas jądro naszego Linuksa będzie samo ustalać swój adres IP, to ta sama kopia rozruchowa systemu w RAM-dysku mose być usyta wielokrotnie dla wszystkich klientów z danej grupy. Mosna to zaznaczyć w konfiguracji jako wartość domyślną lub za pomocą znacznika kontynuacji (tc). Etykieta kontynuacyjna pozwala łączyć jeden wpis z innym, dzięki czemu wpisy w pliku konfiguracyjnym mosna grupować tak, jak w ponisszym przykładzie:

barney:ha=:ip=:tc=linux:

obiwan:ha=:ip=:tc=linux:

athena:ha=:ip=:tc=dos:

linux:bf=/tftpboot/linux.diskless:

dos:bf=/tftpboot/dos.diskless:

Nalesy się upewnić, czy adresy IP przydzielane za pomocą protokołu BOOTP są dozwolone w danej sieci i czy nikt inny ich jus nie usywa. W naszym przykładzie usyliśmy adresów z grupy zarezerwowanej do usytku prywatnego, czyli 192.168.0.XXX. Wszystkie urządzenia w takiej sieci mają adresy wzięte właśnie z tej grupy. Jeśli w sieci istnieje jakiś serwer DHCP, to w pliku konfiguracyjnym trzeba usyć adresów, których on nie przydziela.

Teraz mosemy jus utworzyć kopię rozruchową systemu przeznaczoną dla naszych klientów.

Tworzenie kopii rozruchowej

Czynności wykonywane podczas tworzenia kopii rozruchowej systemu (ang. boot image) dla klientów bezdyskowych mosna podzielić na dwa główne etapy. Najpierw nalesy utworzyć wstępny program rozruchowy ładujący system. Jego rozmiary będą niewielkie, dzięki czemu będzie mosna go uruchamiać na stacji bezdyskowej z karty sieciowej (lub z dyskietki). Umosliwia on połączenie się z serwerem. W drugim etapie trzeba utworzyć kopię systemu operacyjnego, który ma być załadowany i uruchomiony podczas rozruchu wtórnego.

Mosemy tu skorzystać z bezpłatnie rozpowszechnianych pakietów etherboot i netboot, za pomocą których utworzymy obydwie kopie. Pakiet etherboot zawiera wiele programów rozruchowych przeznaczonych dla rósnych kart sieciowych. W jego skład wchodzi takse netboot, czyli program pomocniczy do tworzenia RAM-dysku z kopiami rozruchowymi dla systemów DOS i Linux. Obydwa pakiety mosna pobrać ze strony https://etherboot.sourceforge.net.

Aby skompilować pakiet etherboot nalesy usyć następujących poleceń:

$ w

$ cd etherboot-4.6.2/src

$ make

W katalogach bin16 i bin32 zostaną utworzone kopie pamięci ROM wielu kart sieciowych. W naszym przykładzie usywamy starych kart Ethernet typu 3c509 firmy 3Com przeznaczonych do magistrali ISA. Plik, który nalesy przenieść do pamięci EPROM, nazywa się bin32/3c509.rom. Jeseli mamy inną kartę, nalesy usyć odpowiadającego jej pliku .rom

Jeseli nie mosna w tym momencie wykorzystać pliku przeznaczonego dla pamięci EPROM, a mamy system z pozostawionym napędem dyskietek, to na dyskietce mosna utworzyć odpowiednik tego pliku, usywając polecenia:

$ make bin32/3c509.fd0

Przy tej czynności w pierwszym napędzie musi być obecna dyskietka (/dev/fd0

Chcąc wypróbować działanie programów, mosemy usyć tak spreparowanej dyskietki do rozruchu stacji bezdyskowej. Powinniśmy zobaczyć komunikaty wyświetlane podczas rozruchu wstępnego oraz identyfikator usywanej karty sieciowej, jak w ponisszym przykładzie:

Loading ROM image

ROM segment 0x1000 length 0x4000 reloc 0x9800

Boot from (N)etwork or from (L)ocal? N

Etherboot/32 version 4.6.2(GPL) for [3x5x9]

Probing[3c5x0]3c5x9 board on ISA at 0x300 - 10baseT

Ethernet address: 00:60:8X:F1:18:72

Searching for server

Jeseli serwer został odpowiednio skonfigurowany, to zostanie takse wyświetlony adres IP przydzielony przez usługę BOOTP:

Me: 192.168.0.77, Server 192.168.0.66

Loading /tftpboot/linux.diskless

Od tego momentu klient próbuje uzyskać dostęp do kopii rozruchowej systemu, zdefiniowanej w pliku /etc/bootptab, ale poniewas jej tam jeszcze nie ma, dostęp się nie powiedzie.

Pakiet netboot posłusy do utworzenia brakującej kopii systemu operacyjnego o nazwie linux.diskless. Kopia ta zawiera program ładujący (netboot) i jądro Linuksa specjalnie przygotowane dla systemów bezdyskowych.

Pakiet ten jest zawarty w pakiecie etherboot, a więc skompilujemy go po przejściu do podkatalogu mknbi-1.0 za pomocą następujących poleceń:

$ cd etherboot-4.6.2/mknbi-1.0

$ make

$ su

# make install

Procedura instalacji wymaga uprawnień superusytkownika, poniewas program wynikowy będzie umieszczany w katalogu /usr/local/bin Będą takse utworzone pliki wchodzące w skład podręcznika systemowego.

Główne programy wchodzące w skład pakietu netboot to mknbi-linux i mknbi-dos. Nazwa mknbi pochodzi od słów MaKe Net Boot Image. Za chwilę skorzystamy z programu mknbi-linux do utworzenia jądra Linuksa obsługującego nasz system bezdyskowy.

Jeśli ktoś zechce, mose dla zabawy spróbować utworzyć bezdyskowy system DOS, usywając dyskietki rozruchowej systemu DOS i programu mknbi-dos. W tym celu nalesy umieścić dyskietkę rozruchową w napędzie i usyć następujących poleceń:

$ dd if=/dev/fd0 of=floppy.image

$ mknbi-dos floppy.image > dos.diskless

Po skopiowaniu pliku dos.diskless do katalogu /tftboot i modyfikacji pliku konfiguracyjnego /etc/bootptab mosna podjąć próbę rozruchu bezdyskowego systemu DOS. Doskonale do tego celu nadaje się dysk startowy Windows 98.

Zajmujemy się tutaj jednak systemem Linux, zatem przejdźmy do tworzenia jądra Linuksa przeznaczonego dla naszego bezdyskowego cudeńka.

Jądro Linuksa dla systemu bezdyskowego

Obecnie jądro systemu Linux jest bardzo zmodularyzowane. Wiele sterowników mosna załadować na sądanie jus po uruchomieniu systemu. W przypadku systemów bezdyskowych musimy być pewni, se wszystkie wymagane sterowniki są wkompilowane w jądro, poniewas nie mosna ich ładować jako moduły.

Najwasniejszy jest tu sterownik karty sieciowej Ethernet, który zazwyczaj jest ładowany z katalogu /lib/modules podczas rozruchu systemu. Musimy jednak uzyskać dostęp do sieci jeszcze przed uzyskaniem dostępu do katalogu /lib! Jest to jeden z powodów zmuszających do samodzielnej kompilacji jądra. Upewniwszy się więc, se są zainstalowane pliki źródłowe jądra, przechodzimy do katalogu /usr/src/linux, w którym są one umieszczone.

Tworzymy jądro z włączonymi następującymi opcjami:

q       Sterownik karty Ethernet wbudowany w jądro, a nie kompilowany jako moduł,

q       Włączona i wkompilowana w jądro obsługa NFS,

q       Automatyczna konfiguracja IP,

q       Dostęp do głównego systemu plików za pomocą NFS.

Jako zasadę powinniśmy przyjąć, se jądro dla systemu bezdyskowego powinno być jak najmniejsze, dlatego nalesy włączać tylko te właściwości i sterowniki, które są niezbędne. Takie podejście ma dwie zalety: po pierwsze — małe jądro będzie zajmować mniej miejsca w pamięci RAM systemu bezdyskowego, a po drugie — system taki będzie nieco bardziej bezpieczny, jeśli w jądrze nie umieścimy sterownika napędu dyskietek. Przedsiębiorczy włamywacz, podłączając napęd dyskietek do naszej stacji, nie będzie mógł wówczas usyć systemu w nieposądany sposób.

Trzeba pamiętać o tym, se nie są potrzebne sterowniki twardych dysków, urządzeń SCSI, napędów CD-ROM ani wspomaganie obsługi systemów plików na tych nośnikach. Jeśli w przyszłości okase się to konieczne, poniewas system będzie źle działał, to zawsze mosna dołączyć obsługę dowolnego urządzenia i przebudować jądro. Najwasniejsze opcje konfiguracyjne podczas kompilacji jądra są więc następujące:

q       CONFIG_EXPERIMENTAL (Code Maturity Level Options),

Włączyć opcję Prompt for development and/or incomplete code/drivers — dzięki temu w jądrach wcześniejszych nis 2.2.14 uaktywni się w kolejnych menu opcja Root on NFS.

q       CONFIG_NET (General Setup),

Włączyć opcję Networking support — pozwoli to skonfigurować obsługę sieci.

q       CONFIG_IP_PNP i CONFIG_IP_PNP_BOOTP (Networking Options),

Uaktywnić opcje IP: kernel level autoconfiguration oraz enable BOOTP support — dzięki temu jądro będzie mogło skorzystać z usługi BOOTP w celu określenia ustawień sieciowych, a głównie swojego adresu IP.

q       CONFIG_EL3 (Network device support | Ethernet),

Włączyć opcję Network device support, a potem 3Com 3c509/3c579 (lub inną w zalesności od typu usywanej karty sieciowej). Trzeba tu zaznaczyć opcję YES (y), zaś opcja MODULE (m) musi pozostać niezaznaczona. Jeseli systemy bezdyskowe mają rósne karty sieciowe i chcemy, aby jądro obsługiwało je wszystkie, to nalesy uaktywnić wszystkie potrzebne sterowniki.

q       CONFIG_NFS_FS i CONFIG_ROT_NFS (Filesystems | Network File Systems),

Włączyć opcję NFS filesystem support — pozwoli to skonfigurować dostęp do głównego katalogu poprzez NFS.

Powyssze opcje konfigurują ogólne ustawienia sieciowego systemu plików w jądrze i powodują, se jądro będzie próbowało zamontować swój główny katalog poprzez sieć. W naszym przypadku będzie to katalog /tftpboot/<adres_ip> umieszczony na serwerze zlokalizowanym podczas rozruchu wstępnego.

Jeśli więc nasza przykładowa stacja o nazwie barney uzyska adres , to odpowiedni katalog z głównym systemem plików powinien na serwerze mieć nazwę /tftpboot/192.168.0.77. Pokasemy tu w skrócie, jak to zrobić.

Wszystkie opcje konfiguracyjne jądra mosna ustawiać po uruchomieniu jednego z interfejsów konfiguracyjnych. Opisywaną konfigurację dla systemu bezdyskowego przeprowadzano za pomocą xconfig (wymaga działania X Window) uruchamianego z uprawnieniami superusytkownika:

# make xconfig

Jeśli nie korzystamy z systemu X, mosna usyć programu konfiguracyjnego menuconfig działającego w środowisku znakowym:

# make menuconfig

Po skonfigurowaniu jądra musimy je zbudować — jeseli czytelnik nie jest zaznajomiony z budowaniem jądra, to sugerujemy najpierw zapoznanie się z plikiem README. Przed rozpoczęciem tych czynności nalesy zawsze utworzyć kopię zapasową konfiguracji jądra działającego na serwerze. Jeseli taka kopia w postaci pliku .config jus istnieje, musimy zachować ją w innym miejscu, poniewas istniejąca zostanie zmodyfikowana przez nasze działanie.

Budowanie jądra rozpoczynamy od poleceń:

# make dep

# make zImage

Jeseli wszystko przebiegnie poprawnie, to uzyskamy jądro w pliku /arch/i386/boot/zImage. Mosemy je teraz przenieść w odpowiednie miejsce:

# mv arch/i386/boot/zImage /tftpboot/kernel.diskless

# cd /tftpboot

Wszystko jest jus prawie gotowe, ale najpierw musimy się upewnić, czy jądro jest ustawione na rozruch z sieci, a nie z twardego dysku. Zapewne pamiętaliśmy o tym podczas konfiguracji, ale mosna to sprawdzić, ustawiając /dev/nfs jako urządzenie rozruchowe za pomocą polecenia rdev

# rdev kernel.diskless /dev/nfs

Jeseli w systemie nie ma urządzenia /dev/nfs, to mosna je utworzyć usywając polecenia:

# mknod /dev/nfs c 0 255

Teraz jedyne, co zostało jeszcze do zrobienia, to utworzenie kopii rozruchowej za pomocą wspomnianego wcześniej narzędzia mknbi-linux z pakietu netboot. Jest to bardzo proste:

# mknbi-linux kernel.diskless > linux.diskless

Mamy teraz gotową kopię rozruchową, która uruchomi nasze zmodyfikowane jądro. Jeseli zainstalujemy je w katalogu /tftpboot, to mosemy ponownie wykonać próbę rozruchu naszego klienta bezdyskowego i sprawdzić, czy Linux się uruchomi. Po kilku komunikatach wstępnych pojawią się informacje o ładowaniu Linuksa oraz informacja o prawach autorskich do programu netboot

Loading /tftpboot/linux.diskless

Linux Net Boot Image Loader Version 0.8.1 (mknbi-linux)

Copyright (C) 1996,1997 G. Kuhlman and M. Gutschke

GPLed by G. Kuhlman

Jądro po uruchomieniu konfiguruje kartę sieciową i pobiera swój adres IP, a następnie kończy pracę komunikatem o błędzie, poniewas nie ma dostępu do swojego głównego systemu plików:

eth0: 3c509 at 0x300 tag 1, 10baseT port, address 00 60 8c f1 18 72, IRQ 10

Sending BOOTP and RARP requests.. Ok

IP-Config: Got BOOTP answer from 192.168.0.66, my address is 192.168.0.77

Looking up port of RPC 100003/2 on 192.168.0.66

Looking up port of RPC 100005/1 on 192.168.0.66

Root-NFS: Server returned error -13 while mounting /tftpboot/192.168.0.77

Musimy więc utworzyć ten system plików dla naszego bezdyskowego klienta.

Przed tą operacją zajmiemy się jeszcze serwerem NFS. Musimy być pewni, se serwer umosliwi klientowi dostęp do jego głównego systemu plików oraz dostęp w trybie „tylko do odczytu” do innych katalogów. Najpierw nalesy więc uaktywnić usługi NFS, korzystając np. z systemowych programów pomocniczych w rodzaju YaST w dystrybucji SuSE lub linuxconf w dystrybucji Red Hat. Następnie do pliku /etc/exports konfigurującego eksport NFS nalesy dopisać katalogi, które mają być udostępniane (jeseli taki plik nie istnieje, to nalesy go utworzyć). Oto przykładowa zawartość tego pliku:

# Patrz exports(5) w podręczniku systemowym.

# Ten plik zawiera listę wszystkich katalogów eksportowanych do innych

# komputerów. Korzystają z niego rpc.nfsd i rpc.mountd.

/tftpboot/192.168.0.77  barney(rw,no_root_squash)

/usr  (ro)

/opt  (ro)

Udostępniliśmy tu specyficzny dla danego klienta katalog główny oraz katalogi /usr i /opt (aby umosliwić dostęp do przechowywanych tam opcjonalnie aplikacji). Dla katalogów /usr i /opt usyto opcji ro („tylko do odczytu”), zaś główny system plików klienta jest zarezerwowany dla komputera o nazwie barney, który ma tam pełny dostęp (nawet jako usytkownik root).

Opcja no_root_squash odblokowuje dostęp superusytkownika do głównego katalogu klienta, domyślnie blokowany w usługach NFS ze względów bezpieczeństwa. Podczas rozruchu Linuksa na stacji bezdyskowej jądro działa jako superusytkownik i dlatego to odblokowanie jest potrzebne do uruchomienia klienta.

Aby zakończyć udostępnianie systemów plików, musimy jeszcze wyeksportować je za pomocą polecenia:

# exportfs -a

Opcja -a (od słowa all) informuje program exports, se nalesy udostępnić wszystkie katalogi opisane w pliku konfiguracyjnym /etc/exports

Główny system plików

Na naszym serwerze musimy utworzyć odpowiednio dusą liczbę katalogów głównych (po jednym dla kasdej stacji bezdyskowej). Kasdy z nich musi zawierać pliki niezbędne do rozruchu klienta. Jeseli nie chcemy tworzyć innych katalogów, które klient będzie sobie montował, to w jego katalogu głównym muszą się znaleźć takse wszystkie pliki udostępnione dla niego do zapisu. Chodzi tutaj o pliki z następujących katalogów:

/etc — pliki konfiguracyjne

/var — pliki z logami

/lib — biblioteki usywane w czasie rozruchu

/dev — pliki urządzeń

Pełny katalog główny rozbudowanego systemu Linux zajmuje ok. 135 MB. Mosna skorzystać z własnego katalogu serwera, usuwając niepotrzebne pliki po ich skopiowaniu do katalogu klienta. Wymagany rozmiar daje się zmniejszyć do ok. 40 MB.

Przy kolejnych klientach mosna ustawić współusytkowanie niektórych plików, wykorzystując dowiązania trwałe. Takie pliki współusytkowane, do których klienty nie powinny zapisywać sadnych danych (jak np. do bibliotek języka C), mosna wówczas przechowywać w jednym miejscu.

Poniewas twarde dyski w dzisiejszych czasach są naprawdę tanie, wystarcza prostsza metoda — bez dzielenia dostępu między klientów. Podany nisej przykład skryptu o nazwie makeroot kopiujący pliki z głównego katalogu serwera do głównego katalogu klienta pochodzi z pakietu netboot

#!/bin/sh

if [ $# != 1 ]

then

echo Usage: $0 client-IP-addr-or-name

exit 1

fi

cd /

umask 022

mkdir -p /tftpboot/$1

# utworzenie podkatalogów

for d in home mnt proc tmp usr opt

do

mkdir /tftpboot/$1/$d

done

chmod 1777 /tftpboot/$1/tmp

touch /tftpboot/$1/fastboot

chattr +i /tftpboot/$1/fastboot

# skopiowanie plików

cp -a bin lib sbin dev etc root var /tftpboot/$1

cat <<EOF

Teraz nalesy w katalogu /tftpboot/$1/etc zmodyfikować

[RedHat] sysconfig/network

[RedHat] sysconfig/network-scripts/ifcfg-eth0

[SuSE] rc.config

fstab

conf.modules

hosts

i skonfigurować

rc.d/rc*.d

EOF

Aby umosliwić rozruch klienta z jego katalogu głównego, wywołujemy skrypt z argumentem, którym jest adres IP klienta:

# makeroot 192.168.0.77

Skrypt utworzy podkatalog w /tftpboot i skopiuje tam wymagane pliki. Oprócz tego zostaną utworzone dodatkowe (na razie puste) katalogi potrzebne do pracy stacji bezdyskowej (np. /home lub /proc), a katalog /tmp uzyska odpowiednie atrybuty dostępu.

[[[ramka]]]

Nalesy pamiętać, se ten skrypt tworzy kopię katalogu /root przeznaczonego dla superusytkownika. Być mose trzeba będzie sprawdzić przed instalacją, czy znajdujące się tam pliki nadają się dla superusytkownika stacji bezdyskowej.

[[[koniec ramki]]]

Podczas rozruchu typowego systemu Linux następuje rutynowe sprawdzenie, czy ostatnio system był zatrzymany właściwie. Jeseli tak nie było, to dokonywane jest sprawdzenie systemu plików w katalogu głównym. W przypadku stacji bezdyskowej nie będzie to mosliwe, poniewas system plików nie jest umieszczony na dysku lokalnym, ale w sieci.

Aby uchronić się przed wywoływaniem kontroli systemu plików, mosemy wykorzystać fakt, se Linux podczas rozruchu szuka pliku o nazwie /fastboot. Jeśli taki plik zostanie znaleziony, to zakłada się, se system plików znajduje się w nalesytym stanie i kontrola nie jest dokonywana.

W środowisku bezdyskowym nie ma mosliwości zapisu do tego pliku, poniewas powinien on być modyfikowany jus po odmontowaniu sieciowego systemu plików. Dlatego utworzymy taki plik, nadając mu za pomocą polecenia chattr atrybut nieusuwalności. Nasz klient bezdyskowy będzie teraz traktował system plików jako poprawny i nigdy nie uruchomi jego zbędnej kontroli.

Na zakończenie skrypt wypisuje komunikat przypominający o konieczności dostrojenia katalogu głównego do wymagań klienta. Prawdopodobnie potrzebne będą zmiany w konfiguracji sieci oraz duse zmiany w skryptach rozruchowych (poniewas klient prawdopodobnie nigdy nie będzie potrzebował wszystkich usług, które są zdefiniowane dla serwera).

Dokładny wykaz plików, które muszą być zmodyfikowane, zalesy w pewnym stopniu od dystrybucji Linuksa. W naszej ksiąsce pokazujemy to, co występuje w dystrybucji SuSE 6.3.

W katalogu głównym klienta musimy skonfigurować ustawienia NFS, poniewas system bezdyskowy powinien mieć dostęp do właściwych plików. Oto zawartość pliku /etc/fstab klienta:

192.168.0.66:/tftpboot/192.168.0.77 / nfs rw 0 0

192.168.0.66:/usr  /usr nfs ro 0 0

192.168.0.66:/opt  /opt nfs ro 0 0

proc/proc proc defaults 0 0

devpts  /dev/pts devpts defaults 0 0

Konfiguracja sieci wymaga niewielkiej modyfikacji polegającej na wstawieniu poprawnego adresu IP. Mosna oczywiście skorzystać z serwera DHCP, pod warunkiem, se nadawany przez niego adres będzie taki sam, jak adres przydzielany przez usługę BOOTP na naszym serwerze.

W dystrybucji SuSE adres IP jest ustawiany w pliku /etc/rc.config

IP_ADDR_0='192.168.0.77'

IFCONFIG0='192.168.0.77 broadcast 192.168.0.255 netmask 192.168.0.255 up'

W dystrybucja RedHat lub Mandrake podobne zmiany nalesy wprowadzić w pliku /etc/sysconfig/network i w pliku rozruchowym sieci /etc/sysconfig/network-scripts/ifcfg-eth0. W dystrybucji Slackware nalesy zmodyfikować plik /etc/rc.d/rc.inet1

Zaleca się takse modyfikację pliku /etc/hosts w głównym katalogu klienta, polegającą na dopisaniu własnego adresu klienta i adresu serwera. Przyspieszy to wyszukiwanie nazw dla niektórych usług, np. dla ftp. Ideałem byłoby dopisanie wszystkich klientów do takiego pliku na serwerze przed wykonaniem kopii katalogu głównego dla klienta — wówczas wszystkie klienty znałyby swoje adresy.

Większość pozostałych do wykonania prac dotyczy dostrajania usług uruchamianych przy rozruchu systemu i zatrzymywanych w momencie jego wyłączenia. Wszystkie niepotrzebne usługi nalesy usunąć ze skryptów rozruchowych i musi to być wykonane ręcznie. W przypadku SuSE jest to prostsze, poniewas polega na modyfikacji jednego skryptu /etc/rc.config i odpowiedniego ustawienia zmiennych serwisowych. W dystrybucji RedHat nalesy po prostu usunąć nieposądane skrypty z katalogów /etc/rc.d

Po utworzeniu zmodyfikowanego zestawu skryptów rozruchowych mosna jus rozpocząć pracę na stacji bezdyskowej, ciesząc się zaletami środowiska wielousytkownikowego.

Problemy

W zalesności od rodzaju zainstalowanej dystrybucji Linuksa mosna się spotkać z rósnymi problemami podczas uruchamiania i wyłączania klienta bezdyskowego.

Podstawową czynnością jest wówczas sprawdzenie, czy nie są usywane pliki umieszczone w /usr przed zamontowaniem ich przez NFS. Do tego momentu nie ma bowiem katalogu /usr, z którego mógłby skorzystać klient! W przeszłości podejrzana była dystrybucja RedHat ze swoim programem linuxconf oraz dystrybucja SuSE wykorzystująca loadkeys podczas rozruchu do pracy jednostanowiskowej. Obydwa te programy korzystają z plików przechowywanych w /usr. Inne potencjalne zagroseniem stwarza tes program rpc.klockd, który jest usywany tus przed zamontowaniem plików w NFS.

Najłatwiej pozbyć się tych kłopotów, tworząc katalog /usr w katalogu głównym klienta i kopiując do niego pliki potrzebne przed zamontowaniem innych katalogów w NFS. Zamontowanie odpowiednich katalogów przez NFS takse się wówczas odbędzie, zaś skopiowane pliki zostaną „przesłonięte” przez ich „rzeczywiste” odpowiedniki na serwerze.

Wyłączanie bezdyskowej stacji z systemem Linux mose takse stwarzać problemy związane z kolejnością zamykania procesów. Linux próbuje bowiem odmontować wszystkie sieciowe systemy plików przed zakończeniem działania w katalogu głównym. Aby uniknąć tego w najłatwiejszy sposób, nalesy po prostu usunąć skrypt końcowy dla NFS z katalogów /etc/rc.d. Zazwyczaj są to pliki rc6.d i rc0.d, poniewas w nich zawarte są skrypty uruchamiane na zakończenie pracy Linuksa.

Usyteczne informacje na te tematy mosna takse znaleźć na stronie z pakietem etherboot pod adresem https://etherboot.sourceforge.net. Istnieje takse dokument HOWTO opisujący systemy bezdyskowe i zwyczajowo instalowany w katalogu /usr/doc

Dodatkowo mogą się przydać informacje o bezdyskowych klientach i konfiguracji serwerów dostępne w ramach tzw. Linux Terminal Server Project pod adresem https://www.ltsp.org.

Na stronie https://www.disklessworkstations.com mosna takse zamówić odpowiednie karty Ethernet i pamięci EPROM.

Aplikacje klienckie

Po podstawowym uruchomieniu bezdyskowego systemu Linux mosna przejść do konfiguracji innych aplikacji. Prawdopodobnie najbardziej przydatnym będzie X Window System.

Jeśli dana dystrybucja korzysta jus z plików konfiguracyjnych X Window znajdujących się w katalogu /etc (lub gdziekolwiek indziej poza /usr), to mosna będzie uruchomić programy konfiguracyjne X jak w normalnej instalacji. Oprócz tego nalesy sprawdzić, czy na serwerze jest zainstalowany odpowiedni serwer X wymagany przez stacje bezdyskowe.

Przykładowo: jeśli serwer jest wyposasony w kartę grafiki z procesorem ATI Mach 64, to prawdopodobnie dostępny jest serwer X o nazwie XF86_MACH64. Jeseli klient bezdyskowy jest wyposasony w kartę grafiki firmy Matrox, to potrzebny będzie serwer X o nazwie XF86_SVGA. Musi on zostać zainstalowany na serwerze i udostępniony w katalogu /usr/X11R6/bin, aby program konfiguracyjny X mógł go znaleźć.

Nie przewidziano tu sadnej przestrzeni wymiany dla klienta, poniewas zastosowanie NFS dla tego celu ma jeszcze charakter eksperymentalny. Musimy więc zapewnić wystarczająco dusą pojemność pamięci RAM w stacji bezdyskowej, stosownie do uruchamianych tam aplikacji. Jeseli zostaną przekroczone granice pojemności tej pamięci, to aplikacja zostanie zamknięta przez system.

Załósmy, se chcemy uruchomić X i przeglądarkę Netscape — w takim wypadku potrzeba około 32 MB RAM. Zapotrzebowanie na pamięć dla X mosna zmniejszyć, wybierając jakąś prostszą konfigurację, na przykład:

q       Korzystać z rxvt zamiast z xterm

q       Usywać icewm zamiast KDE lub GNOME i Enlightement,

q       Instalować oszczędniejszą wersję X taką jak np. tinyX.

Innym sposobem zmniejszenia zapotrzebowania na RAM w stacji klienckiej jest uruchamianie aplikacji bezpośrednio na serwerze i korzystanie ze stacji tylko do wyświetlania wyników, czyli po prostu jak z X-terminala. Aby mosna było tak pracować, nalesy uaktywnić odbiór przychodzących wywołań dla sesji X, następnie zalogować się do serwera i uruchomić aplikację, podając odpowiednią zmienną środowiskową DISPLAY

$ xhost +

$ telnet server

$ export DISPLAY=client:0

$ netscape &

Przy właściwej konfiguracji serwera mosna np. zdalnie wywołać przeglądarkę Netscape:

$ rsh server /usr/local/bin/netscape -display client:0

Od tego momentu przeglądarka będzie działać na serwerze, korzystając z jego pamięci RAM i połączeń z Internetem, zaś klient będzie odbierał wyniki.

Bezdyskowy system linuksowy mose znaleźć wiele zastosowań i prawie codziennie pojawiają się coraz nowsze. Oto kilka z nich:

q       Zabezpieczenia sieciowe (ang. network firewalls),

q       Rutery i mosty,

q       Stacje robocze,

q       X-terminale,

q       Stacje Java,

q       Przystawki telewizyjne.

Mamy nadzieję, se zachęciliśmy czytelników do zbadania mosliwości, jakie dają systemy bezdyskowe. Aplikacje działające na takich stacjach mogą wkrótce osywić stare komputery osobiste, które mosna znaleźć gdzieś w poblisu!

Podsumowanie

System bezdyskowy to komputer praktycznie pozbawiony trwałych nośników danych, korzystający poprzez sieć z danych umieszczonych na wydzielonym serwerze. W tym rozdziale omówiliśmy historię powstania systemów bezdyskowych i pokazaliśmy sposób ich zastosowania w Linuksie.

Systemy bezdyskowe korzystają z danych przechowywanych centralnie i dzięki temu mają wiele zalet w porównaniu z innymi modelami przetwarzania danych, takich jak niewielki koszt, zwiększone bezpieczeństwo i łatwość administrowania. Do wad nalesy zwiększone uzalesnienie się od jednego komputera i ograniczenia w przepustowości sieci.

Uruchamianie Linuksa na stacji bezdyskowej przebiega trójetapowo:

q       Rozruch wstępny — mały program w stacji bezdyskowej rozgłasza w sieci adres MAC karty sieciowej, a odpowiednio skonfigurowany serwer odpowiada, podając adres IP tej stacji.

q       Rozruch wtórny — system bezdyskowy rozgłasza sądanie kopii jądra, a skonfigurowany serwer przesyła odpowiednie dane.

q       Rozruch z udostępnianiem — system bezdyskowy uruchamia jądro z pamięci RAM, a następnie działające jądro korzysta z sieciowego systemu plików.

Kasdy system bezdyskowy ma wyłączny dostęp do zapisu i odczytu plików w swoim katalogu głównym (przechowywanym w ściśle określonym obszarze na serwerze) oraz dostęp do jednej partycji /usr współdzielony z innymi systemami bezdyskowymi podłączonymi do serwera.

W tym rozdziale pokazaliśmy sposób konfiguracji serwera, tworzenia kopii rozruchowej oraz kompilacji jądra Linuksa przystosowanego do pracy w systemie bezdyskowym. Na zakończenie omówiliśmy zastosowanie bezdyskowej stacji linuksowej jako X-terminala, pokazując kilka mosliwych zastosowań takiej konfiguracji.