Uruchamianie systemów przez sieć

1.  Wprowadzenie

Ten dokument pokazuje jak umożliwić sieciowy start komputera opartego na Sun Microsystems SPARC lub UltraSPARC. Podczas pisania przyjęto założenie, że czytelnik dysponuje komputerem z zainstalowanym Gentoo Linux, który może zostać wykorzystany jako serwer netboot.

Zarówno serwer jak i klient netboot będą musiały znajdować się w tej samej podsieci, ponieważ protokół ARP z reguły nie jest rozprowadzany pomiędzy różnymi segmentami sieci.

Ogólnie, proces uruchamiania z sieci przebiega tak:

1. Klient wysyła zapytanie odwrotnego ARP (ang. reverse ARP, RARP), aby uzyskać swój adres IP
2. Serwer odpowiada wysyłając klientowi jego adres IP
3. Za pośrednictwem protokołu tftp próbuje ściągnąć obraz startowy z serwera RARP
4. Po ściągnięciu obrazu klient używa go do startu systemu

Jak widać potrzebne będą serwery odwrotnego ARP oraz tftp.

2.  Instalacja i konfiguracja oprogramowania

Demon odwrotnego ARP

Dostępne są w tej chwili dwie implementacja serwera RARP: net-misc/iputils (instalowane razem z podstawowym profilem systemu) oraz net-misc/rarpd.

Konfiguracja podstawowych składników rarpd: /etc/ethers

Niezależnie od wybranego rarpd należy zmodyfikować plik /etc/ethers. Plik ten informuje demona o tym, którym komputerom ma odpowiadać na zapytania oraz jaki ma im przyznawać adres.

Każdy wiersz /etc/ethersskłada się z adresu MAC karty sieciowej, z której zdalna maszyna będzie próbowała się uruchomić oraz nazwa komputera. Pola są oddzielane białymi znakami, natomiast rekordy powinny znajdować się w oddzielnych wierszach. Następujący przykład przeznaczony jest dla hosta nazywającego się sparc-netboot.gentoo.org:

08:00:20:77:1f:3e       sparc-netboot.gentoo.org

Daemon rarpd sprawdza zawartość pliku /etc/ethers za każdym razem, gdy otrzyma zapytanie, więc po modyfikacji nie jest potrzebny restart.

Rozwiązywanie nazw: /etc/hosts

Ponieważ każdy wpis w /etc/ethersjest nazwą hosta, serwer netboot musi być w stanie ją rozwiązać na odpowiadający jej adres IP. Jest to możliwe na dwa sposoby, za pośrednictwem /etc/hosts lub serwera nazw z którego serwer netboot korzysta.

Nowy wpis /etc/hosts będzie bardzo podobny do tego, który już prawdopodobnie znalazł się tam podczas instalacji Gentoo na serwerze. Na przykład, załóżmy, że hostowi sparc-netboot.gentoo.org odpowiada adres IP 10.0.1.15. Tak więc odpowiedni wpis /etc/hostswyglądałby tak:

10.0.1.15  sparc-netboot.gentoo.org

Jeśli preferowane jest wykorzystanie serwera nazw, to administrator DNS będzie musiał dodać rekord dla nazwy hosta, w naszym przypadku sparc-netboot.gentoo.org, wskazujący na odpowiedni adres IP. W tym celu należy się skonsultować z administratorem DNS i/lub dokumentacją serwera DNS.

Konfiguracja net-misc/iputils rarpd

Niestety nie istnieje skrypt init.d dla rarpd w wersji z net-misc/iputils, więc wpis taki trzeba będzie dodać do /etc/conf.d/local.start. Przykładowy wpis może wyglądać tak:

/usr/sbin/rarpd -v -e eth0

Objaśnienie powyższych opcji:

• -v Szczegółowe wyjście
• -e Nie sprawdzaj obecności obrazu bootowania, odpowiedz jeśli za pomocą bazy /etc/ethers oraz DNS da się przypisać danemu adresowi MAC adres IP.
• eth0 interfejs, na którym rarpd ma nasłuchiwać.

Więcej informacji znajduje się na stronie man rarpd, w sekcji ósmej.

Konifguracja net-misc/rarpd

Najpierw należy zainstalować rarpd:

# emerge net-misc/rarpd

Następnie należy ustawić właściwe opcje w /etc/conf.d/rarpd. Na przykład, dla konfiguracji podobnej jak poprzednio dla rarpd w wersji net-misc/iputils, powinno się ustawić opcje jak następuje:

RARPD_OPTS="-v -i eth0"

Wytłumaczenie powyższych opcji:

• -v Szczegółowe wyjście. Pokazuj zapytania, na które daemon odpowiada.
• -i Nasłuchuj na wymienionym interfejsie. Domyślnie rarpd nasłuchuje na domyślnym interfejsie dla lokalnego rodzaju systemu - o ile jest on dostępny.

Więcej opcji jest opisanych w stronie mana dla rarpd oraz w rarpd --help.

Demon tftpd

Dostępne są trzy wersje daemona tftp, net-misc/atftp, net-misc/netkit-tftp oraz net-misc/tftp-hpa. Potrzebny jest tylko jeden z nich.

Konfiguracja elementów wspólnych dla tftp

Każdy demon tftp potrzebuje katalogu, w którym umieszczone będą pliki przez niego udostępniane. W tym podręczniku użyjemy w tym celu /tftpboot. Katalog ten będzie traktowany jak katalog główny (/) podczas obsługi otrzymanych zapytań. Dodatkowo, skonfigurujemy system tak, aby deamon tftp działał z uprawnieniami użytkownika i grupy nobody.

Jeżeli wybrany katalog nie istnieje, to niezbędne stworzenie go poleceniem mkdir. Na przykład, dla tftpboot, właściwym poleceniem jest:

# /bin/mkdir /tftpboot

Następnie potrzebna będzie zmiana właściciela i grupy /tftpbootna nobody:

# chown nobody:nobody /tftpboot

Daemon atftp

Najpierw instalujemy pakiet net-misc/atftp:

# emerge net-misc/atftp

Po instalacji net-misc/atftp niezbędna jest jego konfiguracja. Jeżeli usługa tftpd jest potrzebna zaraz po starcie systemu, to potrzebne będzie dodanie wpisu do /etc/conf.d/local.start, ponieważ atftp nie ma własnych skryptów dla init.d, inetd ani xinetd. Jeżeli potrzebne jest wykorzystanie inetd albo xinetd, to należy zwrócić się do właściwych stron man.

Poniżej znajduje się przykładowy wpis atftpd w /etc/conf.d/local.start:

/usr/sbin/in.tftpd -v --daemon /tftpboot

Wyjaśnienie powyższych opcji:

• -v Zwiększenie lub ustawienie poziomu logowania. Bez argumentów podnosi poziom o jeden w stosunku do poziomu domyślnego. Domyślnym poziomem jest LOG_NOTICE, dla objaśnienia należy skonsultować się ze stroną syslog(3). Dostępne wartości mieszczą się pomiędzy 0 (LOG_EMERG) do 7 (LOG_DEBUG).
• --daemon Działaj jako daemon. Nie należy wykorzystywać tej opcji jeżeli atftpd jest uruchamiany przez inetd.

Więcej opcji jest opisanych w stronie mana atftpd w sekcji 8.

Daemon netkit-tftp

Najpierw instalujemy pakiet net-misc-tftp jak następuje:

# emerge net-misc/netkit-tftp

Następnie instalujemy sys-apps/xinetd - o ile nie jest już zainstalowany. Kiedy oba pakiety są już dostępne można skonfigurować netkit-tftp. Program ten musi być wykonywany z poziomu xinetd, jednak nie są z nim dostarczane żadne skrypty przykładowe, więc zapewniamy jeden poniżej:

service tftp
{
    protocol        = udp
    port            = 69
    socket_type     = dgram
    wait            = yes
    user            = nobody
    group           = nobody
    server          = /usr/sbin/in.tftpd
    server_args     = /tftpboot
    only_from       = 10.0.1.0
    disable         = no
}

Wyjaśnienie tych spośród powyższych opcji, które można zmienić: user to użytkownik z którego uprawnieniami wykonany zostanie in.tftpd, group to grupa z której uprawnieniami wykonany zostanie in.tftpd, server_args to katalog główny dla daemona tftp, a only_from to adresy, z których xinetd dopuszcza połączenia.

Dodatkowe informacje dostępne są na stronie manuala xinetd.conf, w sekcji 5.

Jeżeli xinetd działa, można mu wysłać sygnał HUP aby ponownie odczytał swoje pliki konfiguracyjne.

# /bin/killall -HUP xinetd

Jeżyli xinetd nie działa, należy go uruchomić za pośrednictwem skryptu init.d;

# /etc/init.d/xinetd start

Więcej informacji znajduje się w sekcji ósmej manuala, na stronie o in.tftpd.

Daemon tftp-hpa

Najpierw należy zainstalować pakiet tftp-hpa za pomocą następującego polecenia:

# emerge net-misc/tftp-hpa

Razem z tftp-hpa dostarczony jest skrypt init.d oraz odpowiadający mu plik konfiguracyjny conf.d. Należy upewnić się, że INTFTPD_PATH oraz INTFTPD_OPTS w /etc/conf.d/in.tftpdzgadzają się z podanymi:

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

Daemon tftp może teraz zostać uruchomiony ze skryptu init.d:

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

Więcej informacji można znaleźć w stronie manuala poświęconej tftpd, znajdującej się w sekcji ósmej.

3.  Przygotowanie obrazu tftpboot do wykorzystania przez klienta

Należy upewnić się, że dysponuje się przygotowanym obrazem netboot. Dla SPARC oraz SPARC64 obrazy dostępne są na mirrorach Gentoo w katalogu experimental/sparc/tftpboot. Zakładamy teraz, że bootowany jest system sparc64 przy użyciu pliku gentoo-sparc64-1.4_rc4-20040102.tftpboot.

Po przygotowaniu obrazu należy go skopiować do katalogu /tftpboot:

# cp gentoo-sparc64-1.4_rc4-20040102.tftpboot /tftpboot

Teraz, gdy klient netboot wykonuje zapytanie tftp, szuka pliku o nazwie składającym się z jego numeru IP w postaci szesnastkowej oraz, na niektórych architekturach, z końcówki .ARCH. Numer szesnastkowy powinien być podany wielkimiliterami.

Przewodnik konwersji z postaci dziesiątkowej na szesnastkową dostępny jest na stronie http://www.permadi.com/tutorial/numDecToHex/.

Dla leniwych/niecierpliwych, narzędzie do konwersji między postacią dziesiętną i szesnastkową dostępne jest na http://dan.drydog.com/hextemp.html

Tak więc odpowiednikiem naszego przykładowego adresu IP, 10.0.1.15, będzie:

dziesiątkowo  10  0   1   15
szesnastkowo  0A  00  01  0F

Tak więc przykładowy klient sparc64 podczas startu będzie szukał pliku o nazwie 0A00010F.

Klienty oparte na sparc będą szukały natomiast pliku 0A00010F.SUN4M, 0A00010F.SUN4C lub 0A00010F.SUN4D, zależnie od konkretnego systemu.

Alternatywnie można sprawdzić w logach tftp jakiego pliku szuka klient podczas startu.

Należy upewnić się, że demony rarpd oraz tftpd są uruchomione, następnie uruchomić klienta tak, jak jest to opisane w części "Uruchamianie klienta z sieci".

Po wydaniu polecania boot klient będzie sprawiał wrażenie zawieszonego. Teraz, na serwerze netboot, można sprawdzić dziennik systemowy w poszukiwaniu wpisu od in.tftpd.

Przykładowy wpis na serwerze z działającym sysklogd oraz tftp-hpa wygląda tak:

Jan  3 22:48:59 stargazer in.tftpd[8368]: RRQ from 10.0.1.15 filename 0A00010F

Nazwa pliku znajduje się po napisie "filename" we wpisie, w tym przypadku jest to 0A00010F.

Aby utrzymać kontrolę nad wykorzystanym obrazem netboot oraz aby umożliwić wielu maszynom korzystanie z tego samego obrazu, można stworzyć dowiązanie symboliczne do pliku o nazwie szesnastkowej. Aby dokonać tego z naszym przykładowym komputerem sparc64 oraz obrazem gentoo-sparc64-1.4_rc4-20040102.tftpboot należy wykonać następujące polecenie:

# /bin/ln -s /tftpboot/gentoo-sparc64-1.4_rc4-20040102.tftpboot /tftpboot/0A00010F

Teraz wszystko powinno już być gotowe do wystartowania!

4.  Uruchamianie klienta z sieci

Korzystając z PROM OpenBoot (OBP) na SPARCu, należy wydać polecenie:

ok boot net

Inną metodą, dostępną na pewnych maszynach, jest:

ok boot net-tpe

W ten sposób uruchomiony zostanie proces startu z sieci. Powinien być widoczny ciągle zmieniający się łańcuch znaków szesnastkowych. Kiedy obraz zostanie załadowany, jądro przejmie kontrolę i rozpocznie procedurę ładowania systemu. W przypadku obrazu sparc64 dojdzie on do znaku zachęty powłoki, z którego można rozpocząć procedurę instalacji.

5.  Znajdowanie i poprawianie błędów

Budowa wymaganego oprogramowania

Jeśli serwer netboot pracuje na systemie Gentoo/Linux oraz występują problemy z instalacją pakietów rarpd, należy przeszukać http://forums.gentoo.org oraz http://bugs.gentoo.org, aby sprawdzić czy problem przydarzył się komuś innego. Jeśli nie lub jeżeli odnalezione rozwiązania nie działają, prosimy o zgłoszenie błędu na stronie http://bugs.gentoo.org.

Po wydaniu polecenia boot net system sprawia wrażenie zawieszonego.

Prawdopodobnie plik który system próbuje załadować z serwera tftp nie jest dostępny. Na maszynie SPARC prawdopodobnie ukazałyby się następujące komunikaty:

Rebooting with command: boot
Boot device: net  File and args:

Należy dokładnie upewnić się, że plik potrzebny klientowi znajduje się w /tftpboot. Można zweryfikować nazwę pliku sprawdzając dziennik systemu. Dodatkowo, jeśli plik istnieje, klient spróbuje go załadować. Czasem, gdy pliku na początku nie było, zawiesi się, kiedy tylko się on pojawi. Aby sobie z tym poradzić należy powrócić do zachęty OBP i ponownie wykonać polecenie "boot net". Wtedy komputer powinien ściągnąć obraz i wystartować system operacyjny.

Próbuję wystartować przez sieć, ale jedyne, co widzę, to komunikaty "Timeout waiting for ARP/RARP packet".

Może to wynikać z kilku różnych problemów:

1. Należy upewnić się, że dla danego komputera istnieje wpis /etc/ethers. Jeżeli adres MAC jest nieprawidło i/lub serwer netboot nie może rozwiązać nazwy klienta, nie może udzielić niezbędnej dla klienta informacji.
2. Należy sprawdzić czy koncentrator/przełącznik ethernetowy pomiędzy serwerem oraz klientem są połączone i umożliwiają swobodny przepływ ruchu RARP. Jeśli klient nie może wysłać wiadomości do serwera lub vice-versa, to komputer nie będzie w stanie kontynuować.
3. Nikt nie odpowiada na zapytania RARPD ponieważ nikt nie słucha. Należy upewnić się, że usługa rarpd jest uruchomiona.
4. Klient uważa, że NIC jest połączony z koncentratorem/przełącznikiem do którego jest przypięty. Należy upewnić się, że dioda połączenia na przełączniku lub koncentratorze jest zapalona. Jeśli tak, to powinno się sprawdzić jak ustawiona jest wartość tpe-link-test? w OBP przy pomocy polecenia printenv tpe-link-test?. Wynikiem powinno być coś podobnego do tpe-link-test? false true. Pierwsza kolumna podaje nazwę parametru, druga aktualną jego wartość, a trzecia jego wartość domyślną. W tym przykładzie widać, że wartością jest false, więc klient nie sprawdza, czy łącze jest dostępne przed wysłaniem zapytania RARP. Dość często jest to przyczyną problemu.

Aby zmienić wartość parametru tpe-link-test? w OBP należy wydać następujące polecenie:

ok setenv tpe-link-test? true
tpe-link-test? =      true

Teraz widać, że wartość tpe-link-test? jest już true. Należy ponownie uruchomić klienta.

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