PXES Linux (http://pxes.sourceforge.net) je bezdisková linuxová distribuce vytvořená pro bezdiskové tenké klienty. Systém je bootovatelný na mnoho způsobů (včetně etherbootu a tftp), nepoužívá (na rozdíl od např. LTSP (http://www.ltsp.org)) NFS, kořenový adresář je na RAMdisku. Může fungovat jako plnohodnotný klient pro XDMCP (Xserver 4.3), VNC, ICA (Citrix), RDP (Windows Terminal Server), a další. Umožňuje velmi triviální individuální i hromadnou konfiguraci klientů, vedle toho nevyžaduje žádnou údržbu či přímé úpravy, a relativně snadné je i vysdílení lokálních zařízení (zvuk, data, tiskárny). Systém funguje již s 32Mb RAM a procesorem 486. Mateřským projektem PXES je netstation (http://netstation.sourceforge.net), sourozencem projekt thinstation (http://thinstation.sourceforge.net).
Technologie tenkých klientů (thin clients) či terminálů je aplikací klient-serverové architektury. Terminál (obecně textový či grafický) funguje doslova jako ``koncovka'' pouze zobrazující uživatelské výstupy a předávající uživatelské vstupy serveru. Spojení mezi nimi je realizováno pomocí různých protokolů, které uvádíme níže.
Pro nevýdělečné vzdělávací instituce je nízká cena přirozeně velkým benefitem, ostatní výhody ocení zvláště správce systému.
Jak se lze vyrovnat s nevýhodami provozování tenkých klientů? Závislost na fungování serveru je nevýhoda jen do té doby, než si uvědomíme, že server typicky je mnohem spolehlivější, lépe zabezpečen proti výpadkům proudu, selhání disků atd. než každá jednotlivá stanice. Přenost dat po síti je věc volby protokolu, náročnost konfigurace serveru není o mnoho větší než pro běžnou stanici (níže) a jednou z věcí, které ji mohou velmi usnadnit, je volba protokolu pro terminál.
Výkonnost serveru může představovat (zvláště vzhledem k jeho ceně) skutečný problém. Čím více tenkých klientů je však třeba obsloužit, tím jsou typicky větší úspory na hardware pro klienty. Naopak pro obsluhu aplikací menší sítě (řádově 5 10 stanic) může, zvláště v dnešní době, stačit docela běžně prodávané PC.
PXES podporuje mnoho protokolů navržených pro terminálovou komunikaci. V Linuxovém prostředí je nejzajímavější XDMCP (známý X protokol), který je také ze všech uvedených také historicky nejstarší (nyní ve verzi 11), v prostředí unixovém bezesporu zdaleka nejrozšířenější. PXES dále podporuje VNC (dnes užívaný v prostředí s různými platformami), ICA Citrix (Windows), RDP (Windows Terminal Server).
Než však je klient schopen komunikovat se serverem, musí na něm být spuštěn operační systém.
PXES bootuje jako běžný linuxový systém; upozorňujeme zejména na body, kde se odlišuje.
Etherboot (http://www.etherboot.org) je základní způsob bootování PXES (lze bootovat např. i lokálně z CDROM či USB, tuto metodu zde však neuvažujeme).
V případě lokálního bootování spustí BIOS bootsector vybraného zařízení (harddisk, disketa, vestavěný či USB flashdisk, CDROM), který dále nahraje a spustí DHCP klienta (k tomu může bootsector přichystat např. LILO). Při bootování ze sítě, pomocí speciálního protokolu podporovaného BIOSem (starší Novellovský RPL, případně novější Preboot Execution Environment, PXE podobnost s PXES je zde čistě náhodná), probíhá vše podobně: stáhne se DHCP klient a spustí se.
DHCP klient se spojí se serverem a vedle parametrů sítě obdrží i jméno souboru, který si protokolem tftp (trivial file transfer protocol) stáhne. Hlavičky etherbootu na počátku tohoto souboru určují, kam se části souboru uloží do paměti a na kterou adresu je pak předáno řízení dalšího běhu počítače. V případě PXES má etherbootový soubor (také nazývaný nbi network bootable image; k vytvoření nbi z bzImage kernelu a initramdisku slouží utilitka mknbi-linux, která je součástí etherbootu.) dvě části: bzImage kernelu a komprimovaný ramdisk.
Po spuštění kernelu je již vše stejné bez ohledu na použitou bootovací metodu.
Komprimovaný (squashfs) ramdisk obsahuje kořenový systém souborů, na kterém je busybox (http://www.busybox.org) (obsahující minimální shell a další systémové utility), kompletní xfree86 X server (http://www.xfree86.org), případně programy pro obsluhu lokálních médií (samba server ,http://www/samba.org), nbd-server (http://nbd.sourceforge.net)), zvukové karty (esd ,http://www.tux.org/~ricdude/EsounD.html), lokální tiskárny (lpd), minimální webserver (pro vzdálené zjišťování systémových proměnných apod.), telnet server, tftp klient a další.
Povšimněme si, že vzhledem k přítomnosti veškerých programů na ramdisku nepotřebuje PXES ke svému spuštění síť. Nepotřbuje ani Linuxový server (na rozdíl od např. LTSP, kde je / na NFS serveru) a může být nasazen v prostředí používajícím pouze Windows (v tom případě je nutno provozovat DHCP a tftp server na Windows).
Po namountování / se spustí init skripty. Je-li zapnuta lokální konfigurace, pomocí tftp protkolu se stáhnou sobory relevantní pro danou stanici uložené na serveru. Proběhne konfigurace vstupních a výstupních zařízení (síťová karta, myš, zvuková karta, grafická karta, monitor, datová média, USB), přičemž většina parametrů může být automaticky detekována, vygenerují se konfigurační soubory pro spouštěné služby a spoustí se.
Poslední se spouští X server. Funguje-li PXES v režimu XDMCP, server se připojí k zadanému display serveru. V jiném případě (VNC, ICA, RDP) se v rámci X serveru lokálně spustí klient obsluhující tyto protokoly.
X server běžně obsluhuje pouze grafický výstup a vstup klávesnice a myši. Ač bylo učiněno několik pokusů o integraci dalších komponent přímo do X serveru (např. XAudio, http://www.xaudio.com), všeobecně se neužívají. Proto tedy je nutné spouštět další, speciální programy.
Z důvodů velmi snadné konfigurace a zřejmě i velmi snadné integrace do prostředí Windows (např. při provozování RDP terminálů) jsou lokální datová média zpřístupněna protokolem smb (implementovaným v Linuxovém serveru Samba). Tato média (konkrétně se jedná o diskety, harddisky, CD/DVD zařízení, USB flashdisky) lze pak mountovat na potřebná místa (typicky někam na aplikačním serveru, aby na ně mohly bez problémů přstupovat aplikace) pomocí příkazu smbmount.
Nevýhoda tohoto přístupu je zřejmá: smb jako protkol poměrně vysoké úrovně (operující na souborech, adresářích atd.) zakrývá co se děje níže. K médiu nelze přistupovat jako k blokovému zařízení (tj. nelze např. formátovat diskety, měnit partition tabulku pevného disku, přečíst CD ISO image apod.), dále nelze použít volání ioctl (představující nikoliv požadavky na data, ale na samotné zařízení: např. vysunutí CD mechaniky, kontrola, zda je vložené médium; proto nelze používat např. vypalovací mechaniky, přehrávat audio CD).
Tyto problémy lze vyřešit použitím síťově transparentních blokových zařízení. Existují (minimálně) dvě implementace: :nbd (network block device), který je již dlouho součástí vanilla kernelu, server (běžící na terminálu a obsluhující požadavky na lokální média) je standardní součástí distribuce PXES. :enbd (enhanced network block device, http://www.it.uc3m.es/ptb/enbd), vzniknuvší z nbd; rozšiřuje jej o poměrně robustní mechanismus ochrany dat proti výpadkům sítě, oboustrannou cache, vícenásobné spojení různými cestami, podporu vyjímatelných médií, možnost zabezpečeného spojení (SSL), přenos některých požadavků ioctl, zmenšení části kódu přímo v kernelu. Enbd však není součástí vanilla kernelu (ke stažení jako patch a zdrojové kódy userspace programů), jeho autor však poskytuje svižnou podporu na mailinglistu.
Pro přístup k datům je tedy třeba
/dev/nd* (network device; omezený počet souborů /dev/nd* může představovat specifický problém), jež se od této chvíle chová jako skutečné blokové zařízení; zde je pochopitelně třeba mít v kernelu zavedenou podporu (e)nbd,
/dev/nd* někam do lokálního filesystému
Zřejmě je použití (e)nbd oproti smb komplikovanější; u smb stačí provést mount -t smbfs.
Zvláštností médií USB oproti jiným vyjímatelným (diskety, CD) je to, že zařízení pro přístup k nim neexistuje, dokud není médium připojeno (USB je pouze sběrnice, nikoliv mechanika: /dev/fd0 nezmizí, když se vytáhne disketa). Pokud tedy v momentě, kdy PXES generuje konfiguraci smb serveru, není zařízení přítomno a neexistuje tedy ani příslušné zařízení, smb server nemůže zprostředkovat přístup na toto médium. Proto tedy jediný způsob, jak k USB disku přistupovat je coldplugging přítomnost zařízení při startu systému a nemožnost jej za chodu měnit.
Předpokládáme, že tato drobnost bude brzy odstraněna, až PXES přejde na Linux 2.6 a hotplug.
Obsluha zvukového vstupu a výstupu je standardně prováděna přes ESD (enlightened sound daemon), obvykle podporovaný mnoha vrstvami vyšší úrovně: jmenujme alespoň aRts (zvukový server KDE, http://www.arts-project.org) a gstreamer (součást GNOME, http://www.gstreamer.net). Z jiných síťových audio systémů bylo otestováno NAS (natwork audio system, http://radscan.com/nas.html), jehož základní výhodu představuje možnost na transparentně emulovat OSS (open sound system, http://www.opensound.com) rozhraní /dev/dsp pomocí libaudiooss (http://www.mo.himolde.no/~knan/linux.html) a údajně i lepší architektura (odrážejuící se na výkonnosit a spolehlivosti) než esd; narazili jsme však na chyby v serveru (SIGSEGV apod).
Je-li k terminálu připojená tiskárna, lze ji vysdílet lokálním lpd serverem. Tato možnost nebyla námi otestována.
Zde uvedené služby slouží spíše pro správu či inspekci systému.
Primitivní webserver umožňuje sledovat vzdáleně různé zajímavé informace o terminálu. Vesměs se jedná o výstup systémových příkazů jako ifconfig, lsmod, mount atp. (Přesněji tedy jde jednak o systémové informace (verze PXES a kernelu, informace o CPU, paměti, modulech, přimountovaných filesystémech, výpis procesů, informace o síťových rozhraních, informace o grafické kartě), dále velmi užitečný seznam všech konfiguračních proměnných PXES, výpis hlášení při startu systému.)
Na PXES může volitelně bežet telnet server, umožňující vzdálené přihlášení do systému. Telnet není dle našeho názoru z pohledu bezpečnosti příliš na závadu, v případě proniknutí do stroje hrozí maximálně přístup k lokálním médiím (tedy cizím datům) či operace s nemnohými lokálními procesy. SSH server se plánuje v některé z dalších verzí PXES.
Volitelně je možné komunikovat s terminlem přes lokální konzoli, s přihlášením či bez něj. Zároveň je zde možné prohlížet základní systémové údaje (podobně jako to, vzdáleně, lze přes web server).
Pokud terminál nemá namountovaný lokální harddisk (to jsme nezkoušeli a považujeme to v běžném případě za zbytečné), vypíná se jednoduše power switchem.
Oproti jiným balíků pro tenké klienty (např. LTSP) jsou požadavky PXES velmi malé. Je to dáno též tím, že je třeba je nasazovat i ve windows-only sítích. Pro naše účely to však představuje výhodu jednoduché konfigurace. Je to DHCP server a tftp server.
Na DHCP serveru se nakonfiguruje jméno a umístění nbi, která se má stanici (etherbootu) poslat. Je-li využito možností extenzivní konfigurace klientů speciálními konfiguračními soubory (jak je popsáno níže), je možné bootovat na všech klientech stejný nbi. Pro nbi se použije (v případě námi používaného DHCP serveru od ISC (Internet Software Consortium), http://www.isc.org/index.pl?/sw/dhcp/) direktiva filename, případně lze direktivou next-server zadat adresu tftp serveru .
Tftp server se může spouštět přes (x)inetd, tedy pouze tehdy, když na něj přijde ze sítě požadavek. Veškerá konfigurace se obstará něklika málo parametry příkazové řádky (např. multicasting, maximální počet klientů, kořenový adresář (defaultně /tftpboot), které jsou, alespoň v Debianu, nastaveny po instalaci na okamžitě fungující hodnoty.
Distribuce PXES obsahuje základní systém souborů se všemi potenciálně potřebnými komponentami, ze kterých se potom podle zvolené konfigurace vybírají pouze ty potřebné. Nepovinnou součástí je program pxesconfig (napsaný v perl-gtk), pomocí kterého lze z dodaných souborů jednoduše vytvořit nbi (otázka cca 2 min a 20 kliknutí myší). Je možno vybrat typ síťové, zvukové, video karty, parametry pro kernel (např. io přo ISA síťovou kartu), způsob vysdílení lokálních médií (výše popsané smb nebo nbd), způsob přístupu ke zvukové kartě (esd), tiskárně (lpd), rozlišení a frekvence monitoru.
Zde se také zaškrtně způsob fungování terminálu: XDMCP, VNC atd. Možné je i provozování textového terminálu (telnet či ssh). Podle toho je třeba nastavit další, v případě XDMCP xdm server, způsob připojení k němu (direct, indirect, broadcast), font server, verzi X serveru (4.3 nebo 3.6).
Mnoho parametrů lze nastavit na `autodetect' (to se týká hlavně síťové karty).
Vzhledem k zabudování základní konfigurace do nbi by se zdálo, že téměř pro každý terminál je třeba vytvořit odlišný nbi. Aby to nebylo třeba, podporuje PXES vedle této, globální konfigurace, konfiguraci lokální.
Všechny konfigurační parametry uchovává PXES v proměnných shellu (jejichž názvy jsou však velmi srozumitelné). Po spojení nastavení sítě se terminál přes protokol tftp pokusí stáhnout soubory /pxes/config/default.conf a /pxes/config/<hostname>.conf (<hostname> zde představuje jméno počítače, které přiděluje DHCP), které jsou posléze interpretovány lokálním shellem. Chceme-li tedy na stanici pojmenované bach používat CDROM, která přitom není v globální konfiguraci, vytvoříme soubor /pxes/config/bach.conf (kořenový zdresář tftp není z bezpečnostních důvodů skutečný kořenový adreář serveru, ale obvykle /tftpboot), který bude obsahovat LOCAL_CDDVDROM_ENABLED=1. U většiny stanic je třeba specifikovat alespoň typ videokarty (např. X_VIDEO_DRIVER=sis), neboť autodetekce X serveru je (zejména na starších strojích) poměrně nespolehlivá.
V naší konfiguraci tedy máme jediný nbi a pro každý terminál konfigurační soubor obsahující typicky 1-5 řádků; jeden z nejsložitějších souborů vypadá takto:
X_DRIVER=sis LOCAL_FLOPPY_ENABLED=0 LOCAL_SOUND_ENABLED=1 LOCAL_SOUND_CARD='esssolo1' MOUSE_WHEEL_ENABLED=1 MOUSE_EMULATE_3_BUTTONS_ENABLED=0 MOUSE_PROTOCOL='ExplorerPS/2'
V našem případě byl jako poměrně jednoduché řešení vytvořen skript, který je volán ze souboru /etc/gdm/PreSession/Default a /etc/gdm/PostSession/Default, tj. při přihlášení a odhlášení. Ten se pokusí přes smb namountovat disketu na ~/floppy (další média na ~/cdrom, ~/flash); v případě selhání se tento adresář smaže. Uživatel tedy má média ze stanice, ke které se přihlašuje, dostupná přímo v svém adresáři, navíc pouze ta, která jsou na stanici skutečně použitelná.
Experimenty s enbd byly prováděny poměrně dlouho, nakonec však byly, pro náročnost přihlašovacích skriptů, ukončeny.
V našem případě se jednalo pouze o povolení TCP připojení ke gdm (http://www.5z.com/jirka/gdm.html) a ke zvýšení defaultního limitu připojených klientů.
Zkušebně jsme provozovali grafický terminál na strojích 486/66Mhz, 32Mb RAM, 10Mbit ISA síťovou kartou, při rozlišení 800x600. Reakce terminálu byly velmi pomalé; nejvýrazněji se na tom podepsala, podle našich pokusů, zejména pomalá síť a procesor. 32Mb RAM je pro provozování PXES dostatečné (při použití komprese ramdisku). Pro rozumnou práci s XDMCP doporučujeme 100Mbit síťovou kartu, která zvládne i graficky náročné programy, např. filmy. Většina našich terminálů má procesory alespoň typu Pentium II 200MHz a pracuje bez problémů.
Pro nabootování terminálu bootujeme z oLILOvaného harddisku, kde je miniaturní ext2 partition, na které je zlilo image z rom-o-matic (http://www.rom-o-matic.net) pro příslušnou síťovou kartu. Disk je pak možné, při bootování PXES, vypnout pomocí hdparm, aby zbytečně nehlučil.
Pro výkon celé soustavy je na straně serveru klíčový zejména výpočetní výkon, velikost RAM a propustnost LAN (daná síťovou kartou v serveru, síťovými prvky a topologií). Stroj s Pentiem4 HT a 2Gb RAM uspokojivě obsloužil cca 15 klientů používajících náročné aplikace jako openoffice.org či Mozilla. Při větší zátěži jsme však narazili na problémy zejména s rychlostí odezvy na terminálech.
V současné době nasazujeme pro cca 40 klientů duální Opteron 250 se 4Gb RAM, s 15000rpm SCSI disky zapojené v RAID1 a Gigabit Ethernetem; nainstalovaný je Debian AMD64 (http://www.debian.org/ports/amd64). Jeho předimenzování či poddimenzování se ukáže až při plném nasazení, k čemuž zatím nedošlo.