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]
