Bezdiskové stanice, DHCP, TFTP, atd.

Martin Homola, xhomola1@informatics.muni.cz


Obsah:


1. Problematika bootovania bezdiskových staníc

Fungovanie protokolov DHCP, BOOTP a TFTP je možné veľmi názorne ukázať na procese zavádzania operačného systému na bezdiskovej stanici, čiže počítača, ktorý neobsahuje pevný disk a často ani disketovú, či CDROM mechaniku, z ktorej by bolo možné zaviesť operačný systém. Najvhodnejšou cestou pre zavedenie systému v tomto prípade býva sieťové rozhranie – ethernetová karta. Iniciálny zavádzač – tzv. BootPROM bootstrap – sa v tomto prípade nachádza buď na tzv. BootPROM čipe , alebo – ak stanica disponuje mechanikou na takéto médiá – na diskete, či CD. BootPROM je EPROM čip, ktorý je možné vložiť do pätice na sieťovom adaptéri, a na ktorom obyčajne býva napálený software, ktorý dokáže sťahovať programy prostredníctvom ethernetovej siete a spúšťať ich. Štandardom v tejto oblasti je PXE od INTEL-u (Preboot Execution Environment), ktoré býva v niektorých sieťových adaptéroch inštalované už výrobcom. Ďalšími známymi riešeniami v tejto oblasti sú softwarové balíčky NetBoot a EtherBoot, šírené ako Open Source pod licenciou GNU GPL. Ich funkcie sa v mnohom prekrývajú a nie je jednoduché posúdiť, ktorý z nich je lepší a prečo. Oba umožňujú vytvoriť BootPROM bootstrap, ktorý je možné napáliť do ROM čipu sieťovej karty, alebo natiahnuť z diskety, a okrem toho ešte veľa iných funkcií. My pravdepodobne nepoužijeme ani jeden z nich, pretože nebudeme prepisovať obsah BootPROM čipov na školských počítačoch.

Na školských staniciach je možnosť bootovania cez sieť realizovaná prostredníctvom MBA (Managed PC Boot Agent) dostupného v procese bootovania tesne pred začiatkom zavádzania OS.

Úlohou BootPROM bootstrap je zistiť zo siete informácie o počítači, stiahnuť príslušné jadro operačného systému a spustiť ho so správnymi parametrami, prípadne pripojiť súborový systém. Takýto mechanizmus bootovania je výhodný v sieťach s veľkým počtom staníc, pretože umožňuje automatizáciu niektorých administratívnych úkonov – napríklad updatovania, zálohovania a pod.

1.1. Zistenie IP adresy a bootovacích parametrov

Aby mohol počítač rozumne komunikovať v ethernetovej sieti, musí najprv zistiť svoju IP adresu. To je možné pomocou protokolu RARP, DHCP, alebo BOOTP. Všetky tri vychádzajú z modelu klient-server. Zisťovanie IP adresy pomocou týchto protokolov principiálne prebieha tak, že stanica bez IP adresy (klient), identifikujúc sa svojou MAC, vyšle broadcastovo žiadosť o IP, a iná stanica, poverená odpovedaním na takéto žiadosti (server), jej zašle odpoveď. Tento mechanizmus má však značné bezpečnostné nedostatky – potenciálny útočník môže napríklad do siete nainštalovať vlastný server, ktorý bude poskytovať potenciálne škodlivé informácie. Kvôli absencii autentifikácie bootujúca stanica nevie rozlíšiť, či informácie, ktoré dostane pochádzajú z regulérneho, alebo „pirátskeho“ servera. Výsledkom podstrčenia nesprávnych informácií môže byť niekoľko staníc s rovnakými IP, alebo (uvedením nesprávnych bootovacích parametrov) zavedenie podstrčeného operačného systému a prevzatie kontroly nad klientom.(http://seclists.org/lists/bugtraq/1996/Nov/0122.html),

1.1.1. RARP (Reverse Address Resolution Protocol – RFC903)

Umožňuje iba prevod MAC adresy na IP. Pri použití tohto protokolu na bootovanie bezdiskovej stanice zo siete sa tento nedostatok zvykne riešiť tak, že bootovacie súbory pre dotyčnú stanicu sú uložené na TFTP serveri napríklad pod menom /tftpboot/<IP adresa stanice>. Neumožňuje dynamickú alokáciu IP adries. Komunikácia prebieha tak, že klient broadcastovo vyšle požiadavku na pridelenie IP adresy, a server, ktorý ju zachytí, vyhľadá vo svojej databáze príslušný záznam (dvojica MAC-IP) a odošle odpoveď. RARP server môže poskytovať svoje služby iba v rámci jednej podsiete – protokol RARP nepodporuje routovanie.

1.1.2. BOOTP (Bootstrap Protocol – RFC 951)

Umožňuje poskytnúť stanici nielen jej IP, ale aj masku podsiete, adresu gateway, hostname, broadcastovú adresu, adresu siete a cestu k súboru, ktorý si má stanica stiahnuť a spustiť. Protokol operuje na UDP portoch bootps (#67,bootp server) a bootpc (#68, bootp client), a zahŕňa iba dva typy správ: BOOTREQUEST a BOOTREPLY. Komunikácia sa skladá iba z jednej požiadavky klienta (BOOTREQUEST) a jednej odpovede servera (BOOTREPLY). Prípadné chyby v komunikácii sú riešené vypršaním limitu a retransmisiou. Prípadné požiadavky a návrhy týkajúce sa sieťových a bootovacích parametrov môže stanica oznámiť serveru „predvyplnením“ príslušných políčok v správe BOOTREQUEST.

1.1.3. DHCP (Dynamic Host Configuration Protocol)

Skladá sa z dvoch komponent: protokolu na prenos dát od DHCP servera k stanici, a mechanizmu na prideľovanie sieťových adries. DHCP umožňuje tri spôsoby prideľovania adries staniciam. Automatická alokácia automaticky pridelí stanici permanentnú IP adresu. Pri manuálnej alokácii je adresa pridelená administrátorom a DHCP je použitý iba na prenos informácie. Dynamická alokácia umožňuje prideľovať staniciam adresy len na určitú dobu (lease) a znovuprideľovať uvoľnené adresy. Adresa sa uvoľní, ak klient požiada o ukončenie, alebo ak vyprší doba, na ktorú bola adresa pridelená, ak klient nepožiadal o predĺženie tejto doby. Klient môže požiadať aj o permanentné pridelenie adresy (infinite lease), ale server nie je povinný takejto žiadosti vyhovieť.

Z pohľadu klienta je DHCP rozšírením BOOTP, a vo veľkej miere sú tieto dva protokoly kompatibilné. Po správnom nakonfigurovaní môžu navzájom spolupracovať klienti a servery BOOTP i DHCP. Rozdiel medzi nimi spočíva predovšetkým v tom, že DHCP umožňuje dynamické prideľovanie IP adries, a možnosť poskytnúť klientovi všetky parametre potrebné pre konfiguráciu IP. Formát DHCP správy je založený na formáte správ BOOTP (RFC 951) a umožňuje kooperáciu medzi BOOTP klientmi a DHCP servermi bez úprav na strane klienta. Pre komunikáciu medzi serverom a klientom, ktoré sú nie sú fyzicky v tej istej podsieti, je možné použiť BOOTP Relays.

Komunikácia prebieha tak, že klient prostredníctvom broadcast UDP vyšle do siete požiadavku DHCPDISCOVER. Požiadavka môže obsahovať parametre pre pridelenie adresy. Servery, ktoré počúvajú na porte bootps (typicky #67) môžu odpovedať správou typu DHCPOFFER, ktorá obsahuje navrhovanú IP adresu. Server by sa mal pred poskytnutím adresy presvedčiť, či je adresa skutočne nepoužívaná (ICMP Echo Request). Klient nemusí akceptovať hneď prvú DHCPOFFER, ktorú obdrží, ale môže čakať na viaceré odozvy od serverov a na základe parametrov obsiahnutých v DHCPOFFER si vybrať tú najvhodnejšiu. Svoj záujem o konkrétnu ponuku prejaví klient broadcastovým vyslaním DHCPREQUEST správy, ktorá okrem iného obsahuje i identifikátor servera, ktorého ponuku sa klient rozhodol akceptovať. Broadcastovo preto, aby sa ostatné servery dozvedeli, že ich ponuka bola odmietnutá. Akceptovaný server reaguje správou DHCPACK, v ktorej uvedie konfiguračné parametre pre klienta. Tieto parametre nesmú byť v rozpore s parametrami uvádzanými v DHCPOFFER. Ak akceptovaný server nie je schopný splniť požiadavku klienta – napríklad ak ponúkaná adresa bola medzičasom pridelená inej stanici, namiesto DHCPACK vyšle správu DHCPNAK. Ak klient obdrží DHCPNAK, alebo pri overovaní parametrov obsiahnutých v DHCPACK zistí konflikt (adresa už je používaná), alebo v určenom časovom intervale nedostane odpoveď na niektorú svoju požiadavku, reštartuje proces inicializácie. Klient môže požiadať o ukončenie pridelenia svojej IP adresy vyslaním správy DHCPRELEASE.

Klient, vysielajúci BOOTP alebo DHCP požiadavku nemusí nutne nemať pridelenú IP adresu. Oba protokoly podporujú i komunikáciu, kedy má klient adresu už pridelenú, prípadne ak pozná adresu servera a snaží sa získať doplňujúce informácie. V tomto prípade neprebieha komunikácia broadcastovo, ale je smerovaná priamo na konkrétne IP adresy.

1.2. Stiahnutie a spustenie jadra

Po zistení IP adresy stanice treba zo servera stiahnuť jadro a spustiť ho. Nemusí sa nutne jednať o jadro OS Linuxu, takýmto spôsobom sa dá nabootovať i MSDOS, alebo MS Windows. Používa sa i mechanizmus dvojstupňového zavádzania: BootPROM zavádzač (1st level bootstrap loader) stiahne a spustí iný zavádzač (2nd level bootstrap loader), a až ten zavedie jadro. Tento systém má tú výhodu, že zavádzač prvej úrovne môže byť pomerne malý a málo konfigurovateľný, a bude sa meniť len veľmi zriedkavo (update) obsahu BootPROM nie je jednoduché ani pohodlné), a zavádzač druhej úrovne môže byť zase umiestnený na serveri a veľmi jednoducho updatovateľný a konfigurovateľný. Tento systém využíva napríklad zavádzač PXELinux (podrobnejšie neskôr).

Cestu k jadru stanica získa pomocou protokolov BOOTP alebo DHCP. Na stiahnutie jadra zo serveru sa používa protokol TFTP (Trivial FTP) alebo SFTP (Simple FTP). Oba sú zjednodušenými implementáciami protokolu FTP,čo má na jednej strane výhody v jednoduchosti implementácie a nízkym nárokom na miesto (BootPROMy majú kapacitu cca 2-32kB), na druhej strane zasa nevýhodu v obmedzení funkčnosti – pre účely bootovania sú však tieto funkcie postačujúce.

1.2.1. TFTP (Trivial File Transfer Protocol – RFC 783)

Vie iba čítať súbory zo servera a písať na server, nevie vypísať obsah adresára, neimplementuje žiadnu autentifikáciu. Pracuje nad UDP, začiatok spojenia je na porte #69, ďalej pokračuje na náhodne zvolených portoch. Žiadosť o spojenie zároveň obsahuje názov súboru, s ktorý bude prenášaný, a typ správy (RRQ – Read ReQuest, WRQ – Write ReQuest) určí, či sa dáta budú zo servera čítať, alebo naň písať. Ak server nemôže požiadavke vyhovieť (súbor neexistuje, plný disk, ... ) odpovie správou ERROR, inak odošle ACK (ako odpoveď na WRQ), alebo začne posielať pakety o obsahujúce 512B dát (ako odpoveď na RRQ). Ak paket obsahuje menej ako 512B, signalizuje to koniec prenosu. Príjem každého dátového paketu potvrdí príjemca správou ACK s poradovým číslom paketu. Ak odosielateľ do určitej doby nedostane odozvu, retrasmituje posledný odoslaný paket (ACK alebo DATA).

1.2.2. SFTP (Simple File Transfer Protocol – RFC 783)

Poskytuje väčšiu funkcionalitu ako TFTP, ale je stále implementačne menej náročný (a menej výkonný) ako FTP. Podporuje samozrejme prenosy súborov, mazanie a premenovanie súborov, rozpoznávanie uživateľov, zmenu adresára a výpis obsahu adresára. Pracuje iba nad TCP. Pre komunikáciu sa vytvorí TCP spojenie na port #115, prostredníctvom ktorého klient posiela serveru príkazy a prijíma odpovede.

1.3. Pripojenie súborového systému

Jadro sa po spustení pokúsi pripojiť súborový systém. Tento môže byť na lokálnom harddisku, ramdisku, alebo pripojený cez NFS. Spôsob pripojenia súborového systému jadro zistí pomocou parametra root. Môžeme použiť jadro s initrd (initial ramdisk). V tomto prípade zavádzač natiahne jadro s initrd, namountuje initrd ako read-write root filesystem a spustí súbor /linuxrc s UID 0, prostredníctvom ktorého môže byť pripojený iný root filesystem. Ak chceme pripojiť súborový systém cez NFS, jadro musí mať zakompilovanú podporu Kernel level autoconfiguration, NFS filesystému a podporu mountovania root filesystému cez NFS. Ak nepoužívame initrd, potom jadru stačí parametrom nfsroot zadať, odkiaľ má namountovať root filesystem – podpora tohoto filesystému však musí byť zakompilovaná v jadre.

Bližšie info k initrd: ftp.kernel.org/pub/linux/kernel/current/Documentation/initrd.txt

2. Implementácia a konfigurácia

2.1. DHCP

Autorom protokolu DHCP je ISC (Internet Systems Consortium, www.isc.org, o.i. i autor BIND-u) ktoré zároveň poskytuje i voľne šíriteľnú implementáciu tohto protokolu vo forme softwarového balíčku DHCP, ktorý je okrem zdrojového kódu k dispozícii vo forme balíčkov pre väčšinu známejších distribúcií (Redhat 9, Fedora Core, Debian, a i.). Balík obsahuje DHCP server (dhcpd), klienta (dhclient) a relay agenta (dhcrelay). Inštalácia prebieha tradične:

# tar xzvf dhcp-3.0.1rc13.tar.gz
# cd dhcp-3.0.1rc13
# ./configure
# make; make install

Pre beh servera sú potrebné súbory /etc/dhcpd.conf, kde je uložená konfigurácia servera,a /var/lib/dhcp/dhcpd.leases, kam si server ukladá informácie o pridelených adresách. Ukážka dhcpd.conf:

****** /etc/dhcpd.conf ************************
 # server je jedinym zdrojom infomacii pre spravovane podsiete
 # ak nema pozadovanu informaciu tento server, tak nikto
authoritative;
 # server bude odpovedat aj na bootp queries
allow 		bootp;
 # server sa nebude starat o dynamicke updatovanie DNS
ddns-update-style 	none;
 # hostname uvedene na zaciatku sekcie host
 # bude chapane ako hostname
use-host-decl-names	on;
 # standardne trvanie pridelenia adresy (1 hodina)
default-lease-time	3600;
 # max doba pridelenia adresy (6 hodin)
max-lease-time	21600;


#parametre pre danu podsiet 
subnet 10.0.50.0 netmask 255.255.255.0 {
	 # meno podsiete
	option domain-name	"lab.fi.muni.cz";
	 # maska podsiete
	option subnet-mask 255.255.255.0;
	 # broadcastova adresa
	option broadcast-address 10.0.50.255;
	 # adresa DNS servera
	option domain-name-servers 10.0.50.1;
	 # adresa gateway
	option routers	10.0.50.1;
	 
	 # server, z ktoreho budeme bootovat
	next-server 10.0.50.1;
	  # subor, ktory treba stiahnut zo servera a spustit
	filename "pxelinux.0";
	host doto-beta {
		 # povolime bootovanie klienta doto-beta
		allow			booting;
		 # rozhranie, ktorym sa host prihlasi
		hardware ethernet	00:01:02:19:0A:25; #doto-beta eth0
		 # pridelujeme vzdy rovnaku adresu
		fixed-address 		10.0.50.2;
	}

}
*********************************************************

DHCP klient slúži na konfiguráciu sieťových rozhraní prostredníctvom protokolu DHCP alebo BOOTP. Používa súbor dhclient.conf, kde je uložená jeho konfigurácia, súbor dhclient.leases, kam si ukladá informácie o adresách, ktoré mu boli pridelené, a súbor dhclient-script, pomocou ktorého nastavuje sieťové rozhrania. Ak sa po reštarte počítača nepodarí kontaktovať DHCP alebo BOOTP server, a v súbore dhclient.leases sú adresy, ktoré sú ešte v platnosti (ešte nevypršala ich leasovacia doba), klient overí, či nie sú používané inou stanicou, a ak nie, použije jednu z nich. Klienta väčšinou ani nie je treba konfigurovať (súbor dhclient.conf je prázdny), pretože defaultné nastavenia postačujú na splnenie účelu.

2.2. TFTP

Známou a používanou implementáciou je tftp-hpa. Projekt sídli na www.kernel.org/pub/software/network/tftp/. K dispozícii je vo forme zdrojových kódov, ale aj balíčkovaný pre rôzne distribúcie (napr. Fedora Core server, klient). Server nemá žiadny konfiguračný súbor, a spúšťa sa prostredníctvom inetd (alebo xinetd). Inou známou implementáciou je Advanced TFTP

*********/etc/xinetd.d/tftp****************
# default: off
# description: The tftp server serves files using the trivial file transfer \
#              protocol.  The tftp protocol is often used to boot diskless \
#              workstations, download configuration files to network-aware printers, \
#              and to start the installation process for some operating systems.
service tftp {
  # sluzba je zapnuta
  disable = no

  # typ sluzby - datagram
  socket_type = dgram


  # pouzity protokol UDP
  protocol = udp

  # cakat kym tftp server skonci a nereagovat medzitym na dalsie spojenia
  wait = yes

  # spustit s UID root
  user = root

  # spustitelny subor 
  server = /usr/sbin/in.tftpd

  # parametre pri spusteni
  server_args = -s /tftpboot

  # povolime max. 11 spojeni z jednej IP 
  per_source	= 11

  # max. 100 pripojeni za sekundu, inak disablovat sluzbu
  # ak bola sluzba disablovana, cakat 2 sekundy a znovu ju povolit
  cps = 100 2

  # protokol IPv4 (AF_INET family)
  flags = IPv4
}
***************************************

Zaujímavý je parameter -s(spustenie v chrootovanom prostredí) – krok k bezpečnosti.Typicky sa zvykne súborový strom pre TFTP server ukladať do adresára /tftpboot.

2.3. PXELinux

Kvôli jednoduchosti a konfigurovateľnosti som sa rozhodol použiť zavádzač PXELinux (http://syslinux.zytor.com/pxe.php) z balíku SYSLinux (http://syslinux.zytor.com/) od Petra H. Anvina. Tento zavádzač pracuje na už zmienenom dvojstupňovom zavádzaní. Bootujúca stanica si najprv spustí svoj PXE klient z PROM, prostredníctvom neho zistí nastavenia siete a stiahne zavádzač PXELinux (obyčajne súbor pxelinux.0), ktorý je možné pomerne jednoducho konfigurovať, a ktorý potom stiahne a spustí požadované jadro.

Pre sprevádzkovanie stačí stiahnuť a rozbaliť distribúciu SYSLinuxu (http://www.kernel.org/pub/linux/utils/boot/syslinux/), súbor pxelinux.0 z nej skopírovať do požadovaného adresára (typicky /tftpboot) a vytvoriť konfiguračné súbory. Konfiguračný súbor sa môže vzťahovať k jednej konkrétnej, alebo k viacerým IP adresám. Konfiguračný súbor s názvom „default“ platí pre ľubovoľné rozhranie, ktoré požiada o bootovanie.

V ukážkovom súbore dhcpd.conf bol uvedený parameter filename “pxelinux.0“, ktorý (vzhľadom na to, že TFTP server beží chrootovaný v /tftpboot) ukazuje na /tftpboot/pxelinux.0.V tom istom adresári ako pxeboot.0 sa nachádza i adresár pxelinux.conf, obsahujúci konfiguračný súbor s názvom 0A003202. Názov súboru je hexadecimálnou reprezentáciou IP adresy 10.0.50.2. Na prevod adries do hexadecimálnej notácie môžeme použiť priložený nástroj gethostip:

$ ./gethostip doto-beta.lab.fi.muni.cz
doto-beta.lab.fi.muni.cz 10.0.50.2 0A003202


******/tftpboot/pxelinux.cfg/0A003202**********
# ktora konfiguracia sa ma spustat defaultne 
DEFAULT nfs

# cakaj 3 sekundy pred natahovanim jadra
TIMEOUT 30

# zobraz boot prompt
PROMPT 	1
LABEL disk
	 # cesty su relativne k TFTP server root
	KERNEL 10.0.50.2/bzImage
	 # parametre jadra
	APPEND	root=/dev/hda3
	 # pripojit k parametrom jadra i informacie o sieti 
	 # IP stanice,bootserver,gateway,netmask,
	IPAPPEND 1
LABEL nfs
	KERNEL 10.0.50.2/bzImage
	APPEND root=/dev/nfs rw nfsroot=10.0.50.1:/tftpboot/10.0.50.2 
	IPAPPEND 1
***********************************************

2.4. Súborový systém

Pre pripojenie súborového systému cez NFS je treba nakonfigurovať NFS server a vytvoriť adresár obsahujúci súbory pre root filesystem. NFS server sa konfiguruje v /etc/exports:

****** /etc/exports***************************

# rw pristup je potrebny pre rozne systemove sluzby

# Atribut no_root_squash zabezpeci, aby NFS system nepremapoval
# UID root na nejake ine, inak by niektore programy 
# nemuseli korektne fungovat.

/tftpboot/10.0.50.2	10.0.50.2(rw,no_root_squash)

***********************************************

Odkazy a použité infomačné zdroje

RFC 903 – RARP (Reverse Address Request Protocol)
RFC 906 – Bootstrap Loading using TFTP
RFC 913 – SFTP (Simple File Transfer Protocol)
RFC 919 – Broadcasting Internet Packets
RFC 783 – TFTP {Trivial File transfer Protocol}
RFC 1542 – Clarifications and Extensions for the Bootstrap Protocol
RFC 1534 – Interoperation Between DHCP and BOOTP
RFC 2131 – Dynamic Host Configuration Protocol
RFC 2132 – DHCP Options and BOOTP Vendor Extensions
RFC 3118 – Authentication for DHCP Messages
Network Boot HOWTO
Network Boot and Exotic Root HOWTO NFS-Root mini-HOWTO
NFS-Root Client mini-HOWTO
Diskless Root NFS HOWTO
Diskless root NFS other HOWTO
From PowerUp To Bash Prompt
Linux Terminal Server Project
Plume Project
Network Boot HOWTO