Bezdyskowa stacja robocza na bazie Gentoo

1.  Wprowadzenie

O przewodniku

Przewodnik pomaga skonfigurować bezdyskową stację roboczą opartą o dystrybucję Gentoo Linux. W zamierzeniach ma być tak przyjazny dla początkującego użytkownika Linuksa, jak tylko możliwe. W końcu każdy z nas kiedyś był początkujący :) Zaawansowani użytkownicy mogliby z łatwością powiązać różnorodne przewodniki o bezdyskowych stacjach oraz konfiguracji sieci i zrobić to samodzielnie. Mamy jednak nadzieję, że niniejszy dokument ułatwi instalację wszystkim zainteresowanym użytkownikom, zarówno początkującym jak i zaawansowanym.

Czym jest bezdyskowa stacja?

Bezdyskowa stacja to przeważnie PC bez typowych urządzeń uruchomieniowych takich jak twarde dyski, stacje dyskietek lub napędy CD. Bezdyskowe stacje uruchamiają się z sieci i dlatego potrzebują serwera, który dostarcza przestrzeni na składowanie danych, analogicznie do twardego dysku. Od tego momentu taki serwer będziemy określali mianem master, natomiast bezdyskową stację nazywali slave. Bezdyskowy komputer musi posiadać kartę sieciową, która wspiera uruchamianie z PXE lub Etherboot; pod adresem Etherboot.org znajduje się lista wspieranych urządzeń. Większość nowych kart sieciowych wspiera PXE, podobnie karty zintegrowane z płytami głównymi.

Zanim zaczniemy

Zakładamy, że na komputerze master jest zainstalowane Gentoo oraz jest tam wystarczającą ilość wolnego miejsca na składowanie systemu plików dla maszyn slave. Musimy upewnić się że posiadamy jeden interfejs sieciowy, z połączeniem do internetu, który jest oddzielony od połączenia z siecią lokalną.

2.  Konfiguracja maszyn: master i slave

O kernelach

Kernel to program, który pośredniczy między sprzętem a innymi programami, które mamy na naszym komputerze. W skrócie: kernel stanowi centrum nowoczesnego systemu operacyjnego. Kiedy uruchamiamy komputer, BIOS wykonuje instrukcje znajdujące się w zarezerwowanym obszarze twardego dysku. Te instrukcje są przeważnie boot loaderem, który ładuje kernel. Po tym jak kernel zostanie załadowany, wszystkie procesy są przez niego obsługiwane.

Więcej informacji o kernelach i ich konfiguracji można znaleźć w przewodniku po kernelu.

Konfiguracja kernela na komputerze master

Kernel na maszynie master może być tak duży i dostosowany do potrzeb jak tylko to potrzebne. Jednakże trzeba zaznaczyć kilka niezbędnych opcji. Przejdźmy do menu konfiguracyjnego kernela wpisując:

# cd /usr/src/linux
# make menuconfig

Naszym oczom powinno się ukazać szaroniebieskie menu stanowiące alternatywę dla ręcznej edycji pliku /usr/src/linux/.config. Jeśli kernel działa prawidłowo, to można zachować bieżący plik konfiguracyjny. Wystarczy wyjść z menu i napisać:

# cp .config .config_working

Wejdźmy do następujących elementów menu i upewnijmy się, że wymienione niżej opcje są zaznaczone do wkompilowania (lecz NIE jako moduły). Poniższa lista wzorowana jest na kernelu w wersji 2.6.10. W innej wersji tekst oraz kolejność mogą się różnic. Należy zaznaczyć przynajmniej opcje pokazane poniżej.

Code maturity level options  --->
  [*] Prompt for development and/or incomplete code/drivers

Device Drivers --->
  Networking options --->
    <*> Packet socket
    <*> Unix domain sockets
    [*] TCP/IP networking
    [*]   IP: multicasting
    [ ] Network packet filtering (replaces ipchains)

File systems --->
  Network File Systems  --->
    <*> NFS server support
    [*]   Provide NFSv3 server support


Jeśli zamierzamy korzystać z internetu poprzez maszynę master i/lub posiadamy
firewall, to w kernelu powinno być włączone wsparcie dla iptables.

  [*] Network packet filtering (replaces ipchains)
  IP: Netfilter Configuration  --->
    <*> Connection tracking (required for masq/NAT)
    <*> IP tables support (required for filtering/masq/NAT)

Możliwość filtrowania pakietów możemy zapewnić poprzez dodanie modułów. Zalecamy przeczytanie rozdziału o firewallach, z przewodnika Gentoo Security i o tym jak je prawidłowo skonfigurować.

Po skonfigurowaniu kernela na komputerze master, należy go zbudować:

# make && make modules_install
(Przed kopiowaniem należ upewnić się że /boot jest zamontowany)
# cp arch/i386/boot/bzImage /boot/bzImage-master

Następnie dodajemy wpis dla nowego kernela w pliku lilo.conf lub grub.conf, w zależności od tego jaki boot loader posiadamy. Ustawiamy nowy kernel jako standardowy. Po tym jak bzImage został skopiowany do katalogu startowego, wszystko co pozostaje zrobić to ponownie uruchomić maszynę, tak by nowe ustawienia zostały załadowane.

O kernelu dla maszyny slave

Zaleca się skompilowanie kernela dla maszyny slave bez jakichkolwiek modułów, gdyż ładowanie i ich zdalna konfiguracja jest trudnym i zbędnym procesem. Co więcej, kernel dla maszyny slave powinien być tak mały i spójny jak to tylko możliwe, by mógł być efektywnie ładowany z sieci. Skompilujemy kernel dla maszyny slave w tej samej lokalizacji, w której kernel dla maszyny master był konfigurowany.

Dobrym pomysłem jest utworzenie kopii zapasowej pliku konfiguracyjnego kernela dla maszyny master. Dzięki temu unikniemy zamieszania i straty czasu. Kopię wykonujemy wpisując:

# cp /usr/src/linux/.config /usr/src/linux/.config_master

Chcemy skonfigurować kernel dla maszyny slave, w ten sam sposób, w który konfigurowaliśmy kernel dla maszyny master. Mamy możliwość rozpoczęcia prac ze 'świeżym' plikiem konfiguracyjnym, wystarczy, że przywrócimy /usr/src/linux/.config wpisując:

# cd /usr/src/linux
# cp .config_master .config

Teraz przechodzimy do menu konfiguracyjnego przez wpisanie:

# cd /usr/src/linux
# make menuconfig

Upewnijmy się że zaznaczone są następujące opcje jako mające być wbudowane w kernel, lecz NIE jako moduły:

Code maturity level options  --->
  [*] Prompt for development and/or incomplete code/drivers

Device Drivers --->
  [*] Networking support
  Networking options --->
    <*> Packet socket
    <*> Unix domain sockets
    [*] TCP/IP networking
    [*]   IP: multicasting
    [*]   IP: kernel level autoconfiguration
    [*]     IP: DHCP support (NEW)

File systems --->
  Network File Systems  --->
    <*> file system support
    [*]   Provide NFSv3 client support
    [*]   Root file system on NFS

Teraz nadszedł czas by skompilować kernel dla maszyny slave. W tym miejscu należy wykazać się ostrożnością i nie zepsuć modułów (jeśli jakieś są), które zostały zbudowane dla maszyny master.

# cd /usr/src/linux
# make

Na komputerze master tworzymy katalog, który będzie zawierał niezbędne pliki systemowe oraz dane stacji bezdyskowych. W przewodniku używamy katalogu /diskless, ale można wybrać dowolną lokalizację. Skopiujmy obraz kernela, dla maszyny slave, do katalogu /diskless:

# mkdir /diskless
# cp /usr/src/linux/arch/i386/boot/bzImage /diskless

Konfiguracja wstępnego systemu plików dla maszyny slave

Systemy plików dla maszyn master i slave mogą być często modyfikowane. Obecnie interesuje nas tylko stworzenie wstępnego systemu plików, złożonego z plików konfiguracyjnych i punktów montowań. Na początek musimy utworzyć katalog, dla pierwszej maszyny slave, w obrębie /diskless. Każdy komputer slave musi mieć własny system plików, gdyż współdzielenie pewnych plików systemowych, może spowodować problemy z uprawnieniami i prowadzić do ciężkich awarii. Chociaż katalogom można nadawać dowolne nazwy, to jednak zalecamy używać adresów IP maszyn slave, gdyż adresy te są unikalne i nie wprowadzają zamieszania. Załóżmy, że statyczny adres IP naszej pierwszej maszyny slave to np. 192.168.1.21:

# mkdir /diskless/192.168.1.21

Różne pliki konfiguracyjne, z katalogu /etc, muszą zostać zmienione by prawidłowo działać na komputerze slave. Z maszyny master kopiujemy katalog /etc do katalogu głównego maszyny slave, wpisując:

# cp -r /etc /diskless/192.168.1.21/etc

System plików nadal nie jest gotowy, gdyż potrzebne są różne katalogi i punkty montowania. By je utworzyć wpisujemy:

# mkdir /diskless/192.168.1.21/home
# mkdir /diskless/192.168.1.21/dev
# mkdir /diskless/192.168.1.21/proc
# mkdir /diskless/192.168.1.21/tmp
# mkdir /diskless/192.168.1.21/mnt
# chmod a+w /diskless/192.168.1.21/tmp
# mkdir /diskless/192.168.1.21/mnt/.initd
# mkdir /diskless/192.168.1.21/root
# mkdir /diskless/192.168.1.21/sys
# mkdir /diskless/192.168.1.21/var
# mkdir /diskless/192.168.1.21/var/empty
# mkdir /diskless/192.168.1.21/var/lock
# mkdir /diskless/192.168.1.21/var/log
# mkdir /diskless/192.168.1.21/var/run
# mkdir /diskless/192.168.1.21/var/spool
# mkdir /diskless/192.168.1.21/usr
# mkdir /diskless/192.168.1.21/opt

Większość katalogów "szkieletowych" powinna wyglądać znajomo; Katalogi typu /dev czy /proc zostają wypełnione podczas startu maszyny slave, inne będą podmontowane później. Należy także zmienić plik /diskless/192.168.1.21/etc/conf.d/hostname, by odzwierciedlić nazwę maszyny slave. Binaria, biblioteki i inne pliki zostaną dodane w dalszej części tego przewodnika, tuż przed próbą uruchomienia maszyny slave.

Mimo tego, że /dev jest wypełniany przez udev, należy utworzyć wpis console. Jeśli tego nie zrobimy, to będzie pojawiał się błąd "unable to open initial console".

# mknod /diskless/192.168.1.21/dev/console c 5 1

3.  Konfiguracja serwera DHCP

O serwerze DHCP

DHCP jest skrótem dla Dynamic Host Configuration Protocol. Serwer DHCP jest pierwszą maszyną, z którą komputer slave komunikuje się podczas uruchamiania z PXE. Podstawowym zadaniem serwera DHCP jest przydzielenie adresu IP. Serwer DHCP jest w stanie przypisać adres IP na podstawie adresów MAC kart sieciowych klientów. Jak tylko komputer slave uzyska adres IP, serwer DHCP przekazuje jej informację skąd wziąć bazowy system plików oraz kernel.

Zanim zaczniemy

Zanim zaczniemy należy sprawdzić czy wymagane komponenty działają poprawnie. Na początek sprawdzamy połączenie sieciowe:

# ifconfig eth0 multicast
# ifconfig -a

Trzeba upewnić się że interfejs eth0 funkcjonuje prawidłowo. Powinno to wyglądać mniej więcej tak:

eth0      Link encap:Ethernet  HWaddr 00:E0:83:16:2F:D6
          inet addr:192.168.1.1  Bcast:192.168.1.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:26460491 errors:0 dropped:0 overruns:2 frame:0
          TX packets:32903198 errors:0 dropped:0 overruns:0 carrier:1
          collisions:0 txqueuelen:100
          RX bytes:2483502568 (2368.4 Mb)  TX bytes:1411984950 (1346.5 Mb)
          Interrupt:18 Base address:0x1800

Musi być napisane MULTICAST. Jeśli tak nie jest, to trzeba przebudować kernel tak by zawierał wsparcie dla multicast.

Instalacja serwera DHCP

Jeśli w naszej sieci nie ma jeszcze serwera DHCP, to go instalujemy:

# emerge dhcp

Jeśli w sieci już jest zainstalowany serwer DHCP pozostaje wyedytować plik konfiguracyjny, by uruchamianie z PXE funkcjonowało prawidłowo.

Konfigurowanie serwera DHCP

Jest tylko jeden plik konfiguracyjny, który należy wyedytować przed uruchomieniem serwera DHCP: /etc/dhcp/dhcpd.conf. Kopiujemy i edytujemy dostarczony plik przykładowy:

# cp /etc/dhcp/dhcpd.conf.sample /etc/dhcp/dhcpd.conf
# nano -w /etc/dhcp/dhcpd.conf

Ogólny układ pliku to sformatowana struktura, która wygląda tak:

# ogólne opcje
ddns-update-style none;
shared-network LOCAL-NET {
# współdzielone opcje sieciowe
subnet 192.168.1.0 netmask 255.255.255.0 {
    # opcje dla podsieci
    host slave{
        # opcje charakterystyczne dla hosta
    }
    group {
        # opcje charakterystyczne dla grupy
    }
}
}

Blok shared-network jest opcjonalny i powinien być używany dla tych IP, które chcemy przypisać, a które należą do tej samej topologii sieci. W pliku musi zostać zadeklarowana przynajmniej jedna sekcja subnet. Niewymagany blok group pozwala zebrać opcje charakterystyczne dla grupy wpisów. Dobry przykład pliku dhcpd.conf wygląda tak:

#
# Przykładowy plik dhcpd.conf dla klientów bezdyskowych
#

# Wyłączanie dynamicznych DNS
ddns-update-style none;

# Zakładamy jedną domyślną bramkę wyjściową dla IP
option routers 192.168.1.1;

# Zapewniamy informację o DNS dla klientów
option domain-name-servers 192.168.1.1;
option domain-name "mydomain.com";

# Wyszczególniamy, który serwer TFTP ma zostać użyty
next-server 192.168.1.1;

# Deklarujemy opcje bufora zapewniającego dla klientów PXE:
# Code 1: adres Multicast IP startowego serwera plików
# Code 2: port UDP, na którym klient powinien sprawdzać odpowiedzi MTFTP
# Code 3: port UDP, którego używa serwer MTFTP do nasłuchiwania zapytań
# Code 4: liczba sekund, przez które klient musi monitorować aktywność, zanim
#         spróbuje rozpocząć nowy transfer MTFTP
# Code 5: Liczba sekund przez które klient musi nasłuchiwać, zanim ponownie
#         uruchomi transferMTFTP

option space PXE;
option PXE.mtftp-ip               code 1 = ip-address;
option PXE.mtftp-cport            code 2 = unsigned integer 16;
option PXE.mtftp-sport            code 3 = unsigned integer 16;
option PXE.mtftp-tmout            code 4 = unsigned integer 8;
option PXE.mtftp-delay            code 5 = unsigned integer 8;
option PXE.discovery-control      code 6 = unsigned integer 8;
option PXE.discovery-mcast-addr   code 7 = ip-address;

# Należy zdeklarować podsieć, gdzie będą się znajdowały nasze bezdyskowe węzły
subnet 192.168.1.0 netmask 255.255.255.0 {


  class "pxeclients" {
    match if substring (option vendor-class-identifier, 0, 9) = "PXEClient";
    vendor-option-space PXE;

    # Przynajmniej jedna z opcji PXE, charakterystycznych dla dostawcy, musi
    # być ustawiona, by boot ROMy klienta wiedziały, że jesteśmy serwerem
    # zdolnym obsłużyć PXE. Ustawiamy adres MCAST IP na 0.0.0.0, aby boot ROMy
    # wiedziały, że nie jesteśmy w stanie dostarczyć multicat TFTP (adres
    # 0.0.0.0 oznacza brak adresu).

    option PXE.mtftp-ip 0.0.0.0;

    # Nazwa pliku, który boot ROMy powinny ściągnąć.
    filename "pxelinux.0";
  }

  # Należy zapewnić klientom etherboot odpowiednie informacje
  class "etherboot" {
        match if substring(option vendor-class-identifier, 0, 9) = "Etherboot";
        filename "vmlinuz_arch";
  }

  # Dodajemy jedną deklarację hosta dla każdego bezdyskowego hosta
  host slave21 {
       # Używamy adresu MAC karty sieciowej w komputerze slave
       hardware ethernet                00:40:63:C2:CA:C9;
       # Nadajemy komputerowi slave statyczny adres IP
       fixed-address                    192.168.1.21;
  }
}

Maszyna z adresem IP po wpisie next-server, będzie odpytana o wskazany plik filename. Wartość ta powinna odpowiadać adresowi IP serwera tftp, przeważnie jest taka sama jak adres IP maszyny master. Nazwa filename jest podana względem katalogu /diskless (jest to spowodowane opcjami serwera tftp i zostanie omówione w dalszej części). Wewnątrz bloku host, opcja hardware ethernet określa adres MAC, fixed-address przypisuje stały adres IP do konkretnego adresu MAC. Strona manuala dhcpd.conf może okazać się bardzo pomocna, ponieważ zawiera opisy opcji nie znajdujących się w tym HOWTO. Można ją przeczytać wpisując:

# man dhcpd.conf

Uruchamianie serwera DHCP

Przed uruchomieniem skryptu startowego dhcp, edytujemy plik /etc/conf.d/dhcp, tak by wyglądał mniej więcej tak:

IFACE="eth0"
# dodatkowe opcje

Zmienna IFACE określa interfejs sieciowy na którym dostępny jest serwer DHCP. W tym przypadku jest to eth0. Dodawanie kolejnych argumentów do zmiennej IFACE może być użyteczne w przypadku złożonych sieci, gdy mamy wiele kart sieciowych. Serwer dhcp uruchamiamy wpisując:

# /etc/init.d/dhcp start

W celu dodania serwera dhcp do skryptów startowych należy wpisać:

# rc-update add dhcp default

Kłopoty z serwerem DHCP

Chcąc zobaczyć czy stacja startuje poprawnie, można obejrzeć plik /var/log/messages. Jeśli stacja uruchomi się poprawie, to plik messages powinien na końcu zawierać linie wyglądające tak:

DHCPDISCOVER from 00:00:00:00:00:00 via eth0
DHCPOFFER on 192.168.1.21 to 00:00:00:00:00:00 via eth0
DHCPREQUEST for 192.168.1.21 from 00:00:00:00:00:00 via eth0
DHCPACK on 192.168.1.21 to 00:00:00:00:00:00 via eth0

Jeśli otrzymujemy następujący komunikat, oznacza to, że prawdopodobnie z plikiem konfiguracyjnym jest coś nie tak, ale serwer DHCP działa prawidłowo.

no free leases on subnet LOCAL-NET

Każdorazowa zmiana konfiguracji wymaga ponownego uruchomienia serwera DHCP. Serwer uruchamiamy komendą:

# /etc/init.d/dhcpd restart

4.  Konfiguracja serwera TFTP oraz PXE Linux Bootloadera i/lub Etherboot

O serwerze TFTP

TFTP jest skrótem od Trivial File Transfer Protocol. Zadaniem serwera TFTP jest dostarczanie, maszynom slave, bazowego sytemu plików oraz kernela. Wszystkie kernele i bazowe systemy plików będą składowane na serwerze TFTP, więc prawdopodobnie to dobry pomysł, by maszynę master uczynić serwerem TFTP.

Instalacja serwera TFTP

Wysoce zalecany serwer tftp jest dostępny w portage jako pakiet tft-hpa. Tak się składa, że serwer tftp jest napisany przez autora SYSLINUX i działa bardzo dobrze z pxelinux. Instalujemy wpisując:

# emerge tftp-hpa

Konfiguracja serwera TFTP

Edytujemy plik /etc/conf.d/in.tftpd. Należy w nim określić katalog domowy serwera tftp poprzez zmienną INTFTPD_PATH, a wszelkie opcje przekazywane w linii poleceń, umieścić w zmiennej INTFTPD_OPTS. Powinno to wyglądać mniej więcej tak:

INTFTPD_PATH="/diskless"
INTFTPD_OPTS="-l -v -s ${INTFTPD_PATH}"

Opcja -l oznacza, że serwer nasłuchuje w trybie STAND ALONE, więc nie trzeba uruchamiać intetd. Opcja -v powoduje zwiększenie poziomu logowania/raportowania błędów. Opcja -s /diskless określa katalog główny serwera tftp.

Uruchamianie serwera TFTP

Serwer uruchamiamy przez wpisanie:

# /etc/init.d/in.tftpd start

Serwer tftp powinien zostać uruchomiony z opcjami, które zostały określone w pliku /etc/conf.d/in.tftpd. Serwer może być uruchamiany podczas startu systemu, wystarczy wpisać:

# rc-update add in.tftpd default

O PXELINUX

Tę sekcję możemy pominąć, jeśli używamy tylko Etherboot. PXELINUX jest sieciowym odpowiednikiem LILO lub GRUBa i jest obsługiwany przez TFTP. Właściwie jest to niewielki zbiór instrukcji, które informują klienta, gdzie należy szukać kernela i bazowego systemu plików oraz pozwalają na przekazywanie różnych opcji do kernela.

Zanim zaczniemy

Będzie nam potrzebny plik pxelinux.0, który znajduje się w pakiecie SYSLINUX autorstwa H. Peter Anvina. Pakiet można zainstalować wpisując:

# emerge syslinux

Ustawianie PXELINUX

Przed uruchomieniem serwera tftp trzeba ustawić pxelinux. Na początku kopiujemy binarkę pxelinux do katalogu /diskless:

# cp /usr/share/syslinux/pxelinux.0 /diskless
# mkdir /diskless/pxelinux.cfg
# touch /diskless/pxelinux.cfg/default

Spowoduje to utworzenie standardowego pliku konfiguracyjnego bootloadera. Binarka pxelinux.0 będzie szukać w katalogu pxelinux.cfg, pliku którego nazwa jest adresem IP klienta. Adresem zapisanym szesnastkowo. Jeśli nie znajdzie takiego pliku, usunie skrajnie prawą cyfrę z nazwy pliku i spróbuje ponownie, aż skończą się cyfry. Wersje syslinux'a 2.05 i późniejsze, najpierw szukają pliku o nazwie będącej postacią adresu MAC. Jeśli nie ma takiego pliku, to wykonywana jest - opisana wcześniej - procedura wyszukująca. Jeśli żaden plik nie został znaleziony, to używany jest plik default.

(Początkowe 01 oznacza Ethernet, kolejne bajty odpowiadają adresowi MAC
maszyny slave)
01-00-40-63-c2-ca-c9

(Przypisane adresy IP w formie szesnastkowej)
C0A80115
C0A8011
C0A801
C0A80
C0A8
C0A
C0
C

default

Zacznijmy od pliku default:

DEFAULT /bzImage
APPEND ip=dhcp root=/dev/nfs nfsroot=192.168.1.1:/diskless/192.168.1.21

Znacznik DEFAULT wskazuje pxelinux'owi obraz bzImage, wcześniej przygotowanego kernela. Znacznik APPEND dodaje opcje startowee dla jądra. Z uwagi na to, że skompilowaliśmy kernel dla maszyny slave z NFS_ROOT_SUPPORT, to będziemy musieli określić tutaj katalog nfsroot. Pierwsze z adresów IP to IP maszyny master, zaś drugie IP to nazwa katalogu, który został stworzony w /diskless z myślą o składowaniu bazowego systemu plików maszyn slave.

O Etherboot

Etherboot uruchamia sieciowe obrazy startowe z serwera TFTP. Podobnie jak PXE, Etherboot jest równoważny z LILO lub GRUBem. Narzędzie mknbi umożliwia tworzenie różnych obrazów z różnymi opcjami.

Zanim zaczniemy

Potrzebujemy programu mknbi (narzędzie do tworzenia bootowalnych obrazów kernela stosowanych przy uruchamianiu z sieci), by tworzyć obrazy Etherboot. To narzędzie stworzy skonfigurowany obraz kernela na podstawie oryginalnego kernela. Obraz będzie zawierał opcje, takie jak wymieniono w dalszej części.

# emerge mknbi

Tworzenie Etherboot

W tym rozdziale stworzymy prosty obraz etherboot. Jako, że serwer dhcp wskazuje klientom ścieżkę do katalogu głównego w opcji "option root-path" pliku dhcpd.conf, to nie musimy jej tutaj załączać. Więcej informacji można znaleźć w podręczniku dla mknbi.

# man mknbi

Tworzenie obrazu startowego. Zostanie utworzony bootowalny obraz ELF będący w stanie przekazać do kernela parametry dhcp i ścieżkę do katalogu głównego. Ponadto kernel zostanie zmuszony do znalezienia serwera dhcp w sieci.

# mkelf-linux -ip=dhcp /diskless/bzImage > /diskless/vmlinuz 

Problemy z procesem uruchamiania z sieci

Jest kilka sposobów na testowanie procesu uruchamiania z sieci. Podstawowy to wykorzystanie narzędzia o nazwie tcpdump. Jeśli chcemy zainstalować tcpdump'a wpisujemy po prostu:

# emerge tcpdump

Teraz możemy analizować ruch sieciowy i upewnić się, że komunikacja klient/serwer funkcjonuje prawidłowo. Jeśli coś nie działa, to należy wykluczyć kilka przyczyn. Na początek sprawdzamy czy klient/serwer są fizycznie połączone, a kable sieciowe nie są uszkodzone. Jeśli klient/serwer nie otrzymują zapytań na określonym porcie sprawdźmy czy nie jest to winą firewalla. Ruch sieciowy między dwoma komputerami można zacząć analizować wpisując:

# tcpdump host client_ip i server_ip

Można także wykorzystać tcpdump do słuchania na określonym porcie, takim jak port tftp, wpisując:

# tcpdump port 69

Częsty błąd jaki może się pojawić to: "PXE-E32: TFTP open time-out". Jest to prawdopodobnie spowodowane kwestiami konfiguracji firewalla. Jeśli korzystamy z TCPwrappers, to warto sprawdzić pliki /etc/hosts.allow oraz etc/hosts.deny i upewnić się, że są skonfigurowane poprawnie. Klient powinien mieć możliwość podłączenia się do serwera.

5.  Konfiguracja serwera NFS

O serwerze NFS

NFS to skrót od Network File System. Serwer NFS jest używany do udostępniania katalogów dla maszyn slave. Ta część może zostać później zmodyfikowana, ale póki co, chcemy by komputer slave był uruchamiany bez dysku.

O portmapperze

Różnorodne usługi klient/serwer nie nasłuchują na określonym porcie, lecz polegają na RPC (Remote Procedure Calls - zdalnych wywołaniach procedur). Kiedy usługa jest uruchamiana, zaczyna nasłuchiwać na losowym porcie, a następnie rejestruje ten port w Portmapperze. NFS polega na RPC i dlatego, zanim zostanie uruchomiony, wymaga działającego Portmappera.

Zanim zaczniemy

Serwer NFS potrzebuje wsparcia na poziomie kernela, więc jeśli tego brakuje, to należy przebudować kernel na komputerze master. Na wszelki wypadek warto sprawdzić konfigurację wpisując:

# grep NFS /usr/src/linux/.config_master

Jeśli kernel został prawidłowo skonfigurowany, to powinno pojawić się coś w stylu:

CONFIG_PACKET=y
# CONFIG_PACKET_MMAP is not set
# CONFIG_NETFILTER is not set
CONFIG_NFS_FS=y
CONFIG_NFS_V3=y
# CONFIG_NFS_V4 is not set
# CONFIG_NFS_DIRECTIO is not set
CONFIG_NFSD=y
CONFIG_NFSD_V3=y
# CONFIG_NFSD_V4 is not set
# CONFIG_NFSD_TCP is not set

Instalacja serwera NFS

Pakiet z NFS można uzyskać poprzez portage pisząc:

# emerge nfs-utils

Pakiet zostanie zainstalowany wraz z narzędziem do mapowania portów (portmapper), serwerem i klientem nfs. Automatycznie zostaną obsłużone zależności startowe.

Konfiguracja serwera NFS

Istnieją trzy główne pliki konfiguracyjne, które należy wyedytować:

/etc/exports
/diskless/192.168.1.21/etc/fstab
/etc/conf.d/nfs

Plik /etc/exports określa jak, do kogo i co eksportować poprzez NFS. Plik fstab na komputerze slave zostanie zmodyfikowany tak, by było możliwe zamontowanie systemu plików NFS, wyeksportowanego przez maszynę master.

Typowy plik /etc/exports dla maszyny master powinien wyglądać mniej więcej tak:

# dla każdej maszyny slave należy dodać jedną linię podobną do tej
/diskless/192.168.1.21   192.168.1.21(sync,rw,no_root_squash,no_all_squash)
# wspólne dla wszystkich maszyn slave
/opt   192.168.1.0/24(sync,ro,no_root_squash,no_all_squash)
/usr   192.168.1.0/24(sync,ro,no_root_squash,no_all_squash)
/home  192.168.1.0/24(sync,rw,no_root_squash,no_all_squash)
# jeśli chcesz mieć współdzielony log
/var/log   192.168.1.21(sync,rw,no_root_squash,no_all_squash)

Pierwsze pole określa katalog, który ma być wyeksportowany. Kolejne z pól wskazuje do kogo eksportować i w jaki sposób. To pole można podzielić na dwie części: kto może montować wskazany katalog oraz co montujący klient może zrobić w systemie plików: ro tylko odczytywać, rw odczytywać/zapisywać; no_root_squash i no_all_squash są ważne dla stacji bezdyskowych, które zapisują na dysku, by żądania I/O nie zostały przerwane przez system operacyjny. Plik fstab, /diskless/192.168.1.21, dla maszyny slave powinien wyglądać tak:

# te wpisy są istotne
master:/diskless/192.168.1.21   /         nfs     sync,hard,intr,rw,nolock,rsize=8192,wsize=8192    0 0
master:/opt                     /opt      nfs     sync,hard,intr,ro,nolock,rsize=8192,wsize=8192    0 0
master:/usr                     /usr      nfs     sync,hard,intr,ro,nolock,rsize=8192,wsize=8192    0 0
master:/home                    /home     nfs     sync,hard,intr,rw,nolock,rsize=8192,wsize=8192    0 0
none                            /proc     proc    defaults                                     0 0
# użyteczne, ale zbyteczne
master:/var/log                 /var/log  nfs     hard,intr,rw                                 0 0

W tym przykładzie, master jest nazwą maszyny master, ale równie dobrze może to być adres IP maszyny master. Pierwsze pole określa katalog, który ma być podmontowany, a drugie wskazuje, gdzie ma być zamontowany. Trzecie pole opisuje system plików i powinno zawierać NFS dla każdego katalogu zamontowanego przez NFS. Czwarte pole dotyczy różnych opcji, które będą wykorzystywane w procesie montowania (więcej informacji w podręczniku mount(1), man mount ). Niektórzy mają problemy z punktami montowania z opcją soft, więc zrobiliśmy wszystko z opcją hard. Warto zerknąć na różne opcje w /etc/fstab, by klaster był bardziej wydajny.

Ostatni plik jaki należy wyedytować, to /etc/conf.d/nfs. Określa kilka opcji uwzględnianych przy uruchamianiu nfs i wygląda tak:

# Plik konfiguracyjny dla /etc/init.d/nfs

# Liczba serwerów, które standardowo mają być uruchomione
RPCNFSDCOUNT=8

# Opcje do przekazania do rpc.mountd
RPCMOUNTDOPTS=""

Zmiennej RPCNFSDCOUNT należy przypisać ilość bezdyskowych stacji w sieci.

Uruchamianie serwera NFS

Serwer nfs powinien zostać uruchomiony za pomocą skryptu znajdującego się w /etc/init.d, należy wpisać:

# /etc/init.d/nfs start

Jeśli chcemy, by skrypt był wykonywany podczas uruchamiania systemu, to wpisujemy:

# rc-update add nfs default

6.  Ukończenie prac nad systemem plików dla maszyny slave

Kopiowanie brakujących plików

Teraz zajmiemy się synchronizacją systemu plików pomiędzy komputerami slave i master. Dostarczymy wymagane binaria, jednocześnie zachowując pliki charakterystyczne dla maszyny slave.

# rsync -avz /bin /diskless/192.168.1.21
# rsync -avz /sbin /diskless/192.168.1.21
# rsync -avz /lib /diskless/192.168.1.21

Konfigurowanie sieci w instalacji bezdyskowej

Aby zapobiec zatrzymaniu połączenia z naszym serwerem NFS przez skrypt startowy sieci, musimy dodać opcję do /etc/conf.d/net na naszym kliencie bezdyskowym.

(Dodajemy ten wpis do już istniejących opcji naszego klienta bezdyskowego)
config_eth0=( "noop" )

Skrypty startowe

Potrzebne jest tyle skryptów startowych w katalogu /diskless/192.168.1.21/etc/runlevels, co usług na bezdyskowej stacji roboczej. Wszystko zależy od przeznaczenia maszyny slave.

/diskless/192.168.1.21/etc/runlevels/:
total 16
drwxr-xr-x    2 root     root         4096 2003-11-09 15:27 boot
drwxr-xr-x    2 root     root         4096 2003-10-01 21:10 default
drwxr-xr-x    2 root     root         4096 2003-03-13 19:05 nonetwork
drwxr-xr-x    2 root     root         4096 2003-02-23 12:26 single

/diskless/192.168.1.21/etc/runlevels/boot:
total 0
lrwxrwxrwx    1 root     root           20 2003-10-18 17:28 bootmisc -> /etc/init.d/bootmisc
lrwxrwxrwx    1 root     root           19 2003-10-18 17:28 checkfs -> /etc/init.d/checkfs
lrwxrwxrwx    1 root     root           17 2003-10-18 17:28 clock -> /etc/init.d/clock
lrwxrwxrwx    1 root     root           22 2003-10-18 17:28 domainname -> /etc/init.d/domainname
lrwxrwxrwx    1 root     root           20 2003-10-18 17:28 hostname -> /etc/init.d/hostname
lrwxrwxrwx    1 root     root           22 2003-10-18 17:28 localmount -> /etc/init.d/localmount
lrwxrwxrwx    1 root     root           18 2003-10-18 17:28 net.lo -> /etc/init.d/net.lo
lrwxrwxrwx    1 root     root           20 2003-10-18 17:28 netmount -> /etc/init.d/netmount
lrwxrwxrwx    1 root     root           21 2003-10-18 17:28 rmnologin -> /etc/init.d/rmnologin
lrwxrwxrwx    1 root     root           19 2003-10-18 17:28 urandom -> /etc/init.d/urandom

/diskless/192.168.1.21/etc/runlevels/default:
total 0
lrwxrwxrwx    1 root     root           23 2003-10-18 17:28 consolefont ->  /etc/init.d/consolefont
lrwxrwxrwx    1 root     root           19 2003-10-18 17:28 distccd -> /etc/init.d/distccd
lrwxrwxrwx    1 root     root           19 2003-10-18 17:28 keymaps -> /etc/init.d/keymaps
lrwxrwxrwx    1 root     root           17 2003-10-18 17:28 local -> /etc/init.d/local
lrwxrwxrwx    1 root     root           16 2003-10-18 17:28 sshd -> /etc/init.d/sshd
lrwxrwxrwx    1 root     root           21 2003-10-18 17:28 syslog-ng -> /etc/init.d/syslog-ng
lrwxrwxrwx    1 root     root           17 2003-10-18 17:28 vixie-cron -> /etc/init.d/vixie-cron

/diskless/192.168.1.21/etc/runlevels/nonetwork:
total 0
lrwxrwxrwx    1 root     root           17 2003-10-18 17:28 local -> /etc/init.d/local

/diskless/192.168.1.21/etc/runlevels/single:
total 0

Nadszedł czas, by zacisnąć kciuki i uruchomić maszynę slave. Działa? Możemy sobie pogratulować, jesteśmy dumnymi posiadaczami bezdyskowych stacji roboczych :)

Materiał udostępniany na podstawie licencji Creative Commons - Attribution / Share Alike.