Bootojeme po síti II

Bootojeme po síti - část II
1. pxelinux
Pxelinux je derivátem projektu Syslinux (syslinux.zytor.com), který téměř jistě znáte, tedy pokud jste
někdy instalovali nějaké distro jako Debian, Mandrake, Fedora, nebo prostě bootovali Danix.Je to ten
zavaděč, který se vám objevil při prvním nabootování z diskety, nebo CD.
Výhodou Pxelinuxu je hlavně větší flexibilita - kromě jádra linuxu dokáže zavést i jiné věci, nás
zajímá zejména to, že dokáže zavést další PXE bootstrap, tedy třeba pxegrub... uvidíme dále.
PXElinux rozlišuje soubory podle přípon. Z toho nás hlavně zajímá, že pro PXE bootstrap je potřeba
přidat příponu ".0" Pokud soubor nemá příponu, nebo má nějakou nerozpoznanou, je brán jako jádro
linuxu.
Jaký konfigurační se použije? Sice je možné, podobně jako u PxeGrubu nastavit konfigurační soubor
pomocí speciální dhcp option, ale lepší je spolehnout se na "vrozenou" inteligenci. Pxelinux totiž
hledá svůj konfigurační soubor na TFTP serveru v tomto pořadí:
/pxelinux.cfg/01-88-99-aa-bb-cc-dd
;MAC adresa
/pxelinux.cfg/C000025B
; IP adresa v HEX <- 192.0.2.91
/pxelinux.cfg/C000025
/pxelinux.cfg/C00002
/pxelinux.cfg/C0000
/pxelinux.cfg/C000
/pxelinux.cfg/C00
/pxelinux.cfg/C0
/pxelinux.cfg/C
/pxelinux.cfg/default
Takže v jednoduché konfiguraci stačí nazvat konfigurační soubor jako default a umístit ho do
podadresáře pxelinux.cfg tftp serveru. Pokud bychom se např chtěli omezit na ČVUT, pojmenujeme
soubor "9320" (147d -> 93h; 32d -> 20h).
Obsah konfiguráku nastíním nejlépe příkladem:
default local
prompt 1
timeout 300
display boot.msg
F1
F2
F3
F7
boot.msg
linst.msg
danix.msg
snake.msg
label local
localboot 0
append -
#uvodni splash
#splashe po stisknuti ruznych klaves
# lokalni boot, s kompletnim odebranim Pxe
label dos
# bootovani dosu pomoci specialniho bootstrapu
kernel tipundi2.0
append label memdos
# bootovani dosu pomoci memdisku
kernel memdisk
append initrd=unditcpip.img keeppxe
label memtest
kernel memtest
append -
#proste memtest
label lt
# takhle se bootuje LTSP.org
kernel ltsp/bzImage-2.4.24-ltsp-1
append init=/linuxrc rw root=/dev/ram0 initrd=ltsp/initrd-2.4.24-ltsp-1.gz
LABEL danix
#a takhle danix
KERNEL danix/vmlinuz
APPEND nfsdir=192.168.0.1:/mnt/extra/MOON/Install/Os/Linux/DaNiX/cd nodhcp
lang=cs ramdisk_size=100000 init=/etc/init noeject noprompt nomce vga=791
initrd=danix/miniroot.gz quiet wheelmouse BOOT_IMAGE=knoppix
2. memtest
Nejjednodušší je nabootovat ze sítě memtest (memtest86.com). To je totiž vlastně falešný kernel který
ověří paměť. Namá žádné nastavitelné parametry, takže není co řešit.
3. memdisk
Memdisk je také součástí projektu Syslinux a slouží k bootování dosu z netradičních médií, jakým síť
určitě je. Opět se jedná o "falešný kernel" který načte jako svůj inicalizační ramdisk do paměti obraz
diskety (nebo jiného média) a pověsí se na INT13, tedy obsluhu disků, kde způsobí přesměrování
obsluhy reálné diskety na obsluhu fiktivního disku, vytvořeného z obrazu v paměti.
V praxi to vypadá tak, že při bootu se připojí na pozici "A:" obraz z paměti, ze kterého se bootuje a na
pozici "B:" se přesune reálná disketová mechanika. Nyní je na nás, abychom v DOSu rozchodili síť a
napojili se třeba přes SMB na nějaký server. To je možné udělat například pomocí Microsoft
Lanmanager client, který se dá odkudsi z Internetu stáhnout. Detailní popis je nad rámec této
přednášky, případné zájemce odkazuji na podrobné prostudování nějakého obrazu, který funguje.
Poznámka: Pro rozjetí sítě Microsoft v DOSu je potřeba tzv. NDIS ovladač síťové karty, to je soubor s
příponou .dos - najdete ho na CD ke každé slušné síťové kartě. Můžeme se ale obejít i bez něj existuje totiž wrapper, který se chová jako NDIS ovladač, ale přítom příkazy pouze zabaluje do
příkazů UNDI (to je ten ovladač který je vestavěn v bootROM síťové karty). Díky tomu se nám stane
nabootovaný DOS nezávislý na konkrétním HW počítače. Je však potřeba nějak říci pxelinuxu, že
nemá PXE stack odebírat z paměti - to se dělá přidáním parametru "keeppxe".
Ještě jedna poznámka: Zjistil jsem, že místo memdisku je lepší použít přímo PXE bootstrap od firmy
3Com, protože obsahuje i prográmek freemem, který dokáže po úspěšném nabootování odstranit obraz
diskety z paměti a přemapovat zpět fyzickou diskatu na A:. Tento bootstrap vygenerujete spolu s
obrazem diskety pomocí Windowsového programu imgedit, který je součást balíku firmy 3com
"util430.exe". Na webu 3com hledejte "3CMBA-D".
4. danix
Danix je česká mutace světoznámé distribuce Knoppix. Tato distribuce umožňuje mimo jiné také
režim "Knoppix-TerminalServer", ve kterém se samotný počítač s knoppixmem stane serverem, který
umožní ostatním stanicím ze sítě nabootovat danix přes síť. Na nás tedy zbývá přenést konfiguraci na
jiný počítač, tak aby nám na serveru nemusel běžet Danix (já vím, že je to skvělý OS, ale na servery
se věru nehodí :-) Takže nejprve nabootojeme danix, spustíme "knoppix-terminalserver" a proklikáme
průvodce.1
Poté, co průvodcem projedeme, uložíme si potřebné soubory z adresáře /tftpboot. Zejména se jedná o
konfigurační soubor pxelinuxu, samotné jádro a inicializační ramdisk. Také pohledem do souboru
"/etc/exports" zjistíme, že je potřeba exportovat přes NFS obsah CD s danixem, takže na server buďto
zkopírujeme obsah Danix LiveCD, nebo jeho ISO obraz, který přes loopback (mount -o loop
danix.iso /mnt/danix) připojíme a připojený vyexportujeme. Cestu k exportovanému obrazu musíme
předat kernelu danixu v konfiguračním souboru pxelinux.cfg, viz výše.
1 Pokud je počítač v tuto chvíli připojen do veřejné sítě, doporučuji na chvíli vytáhnout kabel z karty, protože průvodce
se pokusí spustit DHCP a než ho stihneme killnout, mohl by nás nějaký aktivnější administrátor zardousit UTP
kabelem :-)
Tím je konfigurace hotova.
Více info
20server
viz:
http://www.danix.cz/Members/Kato/Tbery/termserv/view?searchterm=terminal%
5.Terminálový server
Danix je sice pěkný, ale někdy se hodí mít namísto hromady samostatných klientů jeden "tlustý"
server, který poskytuje prostřednictvím X protokolu své prostředky a mnoho "tenkých" klientů.
Nejdříve si vysvětlíme, jak vlastně X funguje. X window system se dělí na servery a klienty. Servery
komunikují s hardwarem a přes hardware s uživatelem. Když spustíte samotný X server, uvidíte
pouze známý černobílý vzorek a ukazovátko ve tvaru X. Aplikace, které v X window systému
spouštíme jsou tzv. X klienti. Ti navážou přes síť (většinou přes loopback, nebo tzv. unix domain
socket) spojení se serverem a požádají ho o např. nakreslení okna. Server jim na oplátku posílá
informace o tom, kam uživatel klikl myší, atd.
Důležité je hlavně uvědomit si, že každý "tenký klient" je pouze X server, ten "tlustý server" obsahuje
pouze X klienty, kteří se připojují k X serverům. Z tohoto popisu je jasné, že ten "tlustý server" se
nějak můsí dozvědět, kde všude běží X servery, aby s nimi začal komunikovat. K tomu se používá
protokol XDMCP (X Display Manager Control Protocol.) Tímto protokolem se každý X server ohlásí
"Display Manageru", kterýžto s ním začne komunikovat. Display manager zná asi každý, je to ten
program, co zobrazuje dialogové okno s přihlašovacím jménem a heslem, pokud se přihlašujete přes
X Window System.
V praxi to tedy probíhá takto: Na "tlustém serveru" běží X display manager (xdm, kdm, nebo gdm).
Ten poslouchá na portu protokolu XDMCP. Jakmile se spustí nějaký "tenký klient", popátrá obvykle
vysíláním (X -broadcast), nebo přímým pořadavkem (X -query a.b.c.d) po serveru, na kterém běží
XDMCP povolený display manager. Když ho najde, oznámí mu: "jsem tady!" a vymění si s ním
autorizační údaje (standardně jsou totiž X servery nastaveny tak, aby si jen tak někdo nemohl na
serveru cokoli spustit). Nato display manager pošle na X server svoje přihlašovací okno a pokud dojde
k úspěšnému přihlášení, nastaví přihlásivšímu uživateli proměnné DISPLAY a X_AUTHORITY tak,
aby každý nově spuštěný klient (tedy program) posílal svůj výstup na "tenkého klienta". Protože
unixové systémy mají opravdový multitasking a multiusering, není problém, když takovýchto klientů
bude víc než jeden.
Celý problém tedy lze rozdělit na následující podproblémy:
1. Zprovoznit na "tlustém serveru" X display manager tak, aby přijímal požadavky od vzdálených
počítačů protokolem XDMCP.
2. Vytvořit malou live distribuci, která nastartuje ze sítě na každém "tenkém klientovi" a spustí na
něm X server.
Začneme tím jednodušším, a to konfigurací X display manažeru. Máme na výběr 3 druhy: xdm, který
je součástí balíku X Window system; kdm, který je součástí KDE a nakonec gdm, který je součástí
Gnome. My se zaměříme na kdm, čiště z osobních preferencí.
kdm se konfiguruje velice podobně jako xdm, hlavním rozdílem je umístění konfiguračních souborů,
které je:
•
V případě xdm v adresáři /etc/X11/xdm/
•
V případě kdm v adresáři /usr/kde/3.4/share/config/kdm/
Zde se nacházejí soubory, které konfigurují celé chování programu kdm. Nás z toho zajímá hlavně:
1. Hlavní konfigurační soubor kdmrc, kde je úplně na konci obvykle zakázán protokol XDMCP:
[Xdmcp]
Enable=false
2. Konfigurační soubor Xaccess omezující přístup, který ovšem bývá nastaven správně:
*
#any host can get a login window
Po úpravě těchto konfiguračních souborů a restartu, resp. reloadu kdm by již mělo být možné připojit
se přes X vzdáleně. To nejlépe vyzkoušíme tak, že na jiném počítači spustíme X -query a.b.c.d, kde
a.b.c.d je adresa, nebo název počítače s XDM. V případě, že nám na jiném počítači už běží X,
vyzkoušíme funkčnost pomocí příkazu Xnest :1 -query a.b.c.d 2
Pokud nevidíme nic než jen černobílý vzorek a kurzor ve tvaru X, je kromě chyby v nastavení xdm
také možná chyba v nastavení firewallu jiného počítače. Ten se totiž po spuštění X serveru chová jako
server (nečekaně :-) a poslouchá na tcp portu (6000 + číslo displeje). Na ten port se taky xdm snaží
připojit.
Teď je na řadě ta složitější část. Když už totiž chceme tenkého klienta, tak obvykle chceme, aby byl
opravdu tenký, což v našem případě znamená zejména bez pevného disku. Zde narážíme na problém,
že většina běžných distribucí se bez harddisku neobejde. Existují ale nejméně dva projekty, které se
zaměřují přímo na vytvoření live distribuce, která nastartuje ze sítě a spustí X server - starší a klasický
Linux Terminal Server Project - ltsp.org a novější, netradiční PXES Universal Linux Thin Client pxes.sf.net. Oba si popíšeme.
Linux Terminal Server Project
LTSP.org je mini distribuce se vším všudy, včetně balíčkovacího systému. Nebudu zde popisovat
postup instalace, jenom podotknu, že pro Gentoo linux je připraven ebuild a howto na
http://www.gentoo.org/doc/en/ltsp.xml, pro ostatní distribuce buď existuje také balíček, nebo lze
nainstalovat ručně. V tom případě si stáhneme malý balíček s instalátorem, který spustíme a on nám
nabídne seznam balíků, které můžeme nainstalovat, ty pak stáhne a nainstaluje. Tento instalátor nám
také pomůže s nastavením celého serveru, včetně xdm, dhcp, tftp, nfs.
LTSP.org se skládá ze tří základních částí:
1. obraz kernelu, který bude nabootován na každém tenkém klientu
2. obraz inicializačního RAMdisku, který se předá při vzdáleném bootování kernelu a slouží hlavně
pro navázání komunikace s NFS serverem a připojení kořenového stromu NFS.
3. vlastní kořenový strom, který je ze serveru vyexportován přes NFS.
Vzhledem k tomu, že ve stromu LTSP nejsou z úspory místa žádné vývojové nástroje, je dost
problematické do distribuce jakkoli zasahovat, a to i například pro nastavení českého prostředí
(klávesnice.)
PXES Universal Linux Thin Client
PXES je už podle názvu univerzálním tenkým klientem, který je svým zezřením i způsobem instalace
co nejvíce přiblížen uživatelům MS Windows. Kromě X protokolu navíc podporuje i Microsoftí RDP,
Cytrix ICA, VNC, a jednoduchou lokální plochu. Na rozdíl od LTSP.org nepoužívá NFS strom, ale
pouze obraz kernelu a inicializační RAMdisk, který má 16 MB a používá komprimovaný souborový
systém squashfs. Díky tomu k rozchození stačí pouze tftp a dhcp. Preferovaný způsob instalace
spočívá ve stažení binárního obrazu RAMdisku a kernelu a jejich nakopírování do kořene tftp serveru.
Je také možné stáhnout zdrojový strom a inicializační RAMdisk si upravit podle svých potřeb, k
tomuto však chybí dokumentace :-(
Každý PXES klient navíc obsahuje SSH server, přes který lze klienta obsluhovat a také VNC server,
kterým lze sledovat přesný obsah obrazovky klienta.
2 Xnest je takový zvláštní prográmek, který je součástí X window systému a chová se zároveň jako klient i server. Jako
klient se chová pro X server ve kterém je spuštěn, ale zároveň se chová jako server, to znamená, že na jeho ploše si
mohou kreslit klienti, kteří se k němu připojí. Parametr :1 je na příkazovém řádku proto, aby se Xnest spustil jako
server s číslem 1 - defaultně se spouští s číslem 0, to ale už je zabrané "rodičovským" X serverem.
Společné problémy terminálových serverů
Když už se povede spustit tenkého klienta, narazíme na několik dalších problémů, které mají obvykle
společného jmenovatele: snažíme se používat něco ze "svého" počítače (kterýžto je tenkým klientem),
a přitom používáme prostředky serveru, který se proti tomu obvykle brání.
•
Zvuk na tenkých klientech. Pokud jsou na serveru v pořádku práva, neměl by povolit komukoli
zapisovat do /dev/dsp. Díky tomu si programy vyžadující zvukový výstup budou stěžovat. Řešit se
to dá jedině použitím zvukového serveru, který podporuje síťovou transparentnost, to znamená
například esd nebo nas. Všechny aplikace navíc musí daný zvukový server podporovat, což je
problém zejména u komerčních produktů, jako Real Player, Flash, Skype, ...
•
Lokální zařízení na tenkých klientech. Občas si člověk chce z počítače něco odnést na flash disku,
nebo CD, někdy možná i na disketě. Místo toho se ale snaží otevírat disketu na serveru. Na to
existuje řešení, které spočívá ve spuštění NBD (Network Block Device) serveru na každém
klientovi a úpravě mount a umount skriptů. NBD pak vyexportuje z každého klienta blokové
zařízení jako takové a vlastní akt přimountování proběhne na serveru.
Závěr
Tento text byl napsán v Openoffice.org 1.1.4. Za všechny překlepy se omlouvám. Případně uvedené
ochranné známky patří jejich vlastníkům. Tento text může být v nezměněné podobě libovolně šířen.
Ondřej Caletka
20. 9. 2005
[email protected]