Tlustý Klient - dejme hlavy dokupy

29.1.2007 16:02 | Přečteno: 2386× | Linuxové báchorky | poslední úprava: 30.1.2007 08:27

Zdravim

Po nenalezeni zadneho obecneho systemu pro sprovozneni tlustych klientu jsem se vrhl do tvorby systemu vlastniho.

Ve zkratce: Tlusty klient je vykonny bezdiskovy pocitac, bootuje ze site a / pripojuje pres sit. Veskere programy bezi lokalne. Zajímavé? Čtěte dále...

V tuhle chvili jsem ve stavu kdy mam jadro, to nabootuje, pripoji rootfs, nabehnou vsechny sluzby, grafika, vsechno funguje. Konfiguraci mam resenou lehce podobne jako LTSP. Jako jedna z prvnich sluizeb (po siti) si skript zjisti IP adresu kompu a podle toho spusti skript. Skriptu je tamnekolik: all - spusti se vsude, 192.168.1.10 - pro konkretni pocitac, prozatim jen podle IP adresy a nakonec default v pripade nenalezeni konkretni konfigurace. Potrebuju doresit 2 problemy.

1) Konfigurace X serveru:
S tim, ze nemuzu mit jen tak nainstalovane nvidia i ati binarni drivery jsem se prozatim smiril. Planuju to provozat na mixu intel, starsich ati (opensource) a starsich nvidia grafikach. Pochopitelne vsemozny monitory. No chci aby to bylo univerzalni. Cili otazka zni, je mozne napsat xorg.conf tak, aby jel vsude s akceleraci? Proste univerzalni pro vsechny? Nebo jestli existuje nejakej autodetekcni program? Dodnes si pisu konfigurak sam na miru. Nebo druhe reseni, nejakym zpusobem vzdy pri bootu prepisovat /etc/X11/xorg.conf podle zrovna bootujiciho kompu. Kdyz jich bude bootovat naraz vicero, tak se to muze pohadat. Asi by i slo spustit X a vnutit mu jiny konfig nez /etc/X11/xorg.conf, ale to je na muj vkus uz moc velky zasah do spoustecich skriptu a to se mi nelibi. Nebo to nejak resit pomoci symlinku. Nejaky napad?

2) Sdílení adresáře /var:
Jak známo, /var nelze sdílet mezi různými instancemi systému a musí být r/w. V tuhle chvili jsem na něm nedělal žádnou změnu, čili je r/w a sdílenej všemi klienty. To má za následek, že klient sice nastartuje bez zjevného problému, ale při regulérním shutdownu se snaží mazat pidy, o kterých si myslí že jsou jeho a přitom jsou sdílený. Napadlo mě vytvořit nějaká skelet /var a ten při přihášení nového klienta kopírovat na /var-192.168.1.2 a klient by si to potom bindoval na /var. Potíž je, že některé adresáře uvnitř chci mít sdílené, např db balíčkovacího systému. Standardní /var má i několik set mega. Také je možnost jen vyjmenovat adresáře, které nechci sdílet a skript by už používal skelety pro každý zvlášť a bindoval taky každý zvlášť. Nějaký nápad?

Zatím je to řešené pro Arch Linux, ale není větší probém to překopat na jakoukoliv distribuci, nechci aby to bylo moc distribučně závislé. Ve výsledku to bude spíš návod a sada jednoůčelových skriptů než nějakej ucelenej balík.

Připomínky vítány.

Zdeněk

       

Komentáře

[Luk]

Sdílení adresáře /var:

/var na RAMdisku a odtud symlinky, kam je potřeba (třeba k balíkům).

[Michal Vyskočil]

Také je možnost jen vyjmenovat adresáře, které nechci sdílet a skript by už používal skelety pro každý zvlášť a bindoval taky každý zvlášť. Nějaký nápad?

Osobně mi přijde lepší vyjmenovat adresáře, které mají být sdílené, s tím, že po zkopírování skeletonu /var se jednotlivé sdílené podadresáře připojí na to správné místo.

Něco jako

for DIR in cache/apt/ cache/debconf/; do
    mkdir -p /var/$DIR
    mount server/$DIR /var/$DIR
done

[hajma]

kdysi jsem si s tím hrál, třeba ti to k něčemu bude: http://www.abclinuxu.cz/blog/hajma/2005/4/19/84255

[Josef Kufner]

ad 1: Konfigurace X serveru:

Podívej se, jak to dělají Live distra.

ad 2: Sdílení adresáře /var:

Tady se ti také bude hodit něco z live distribucí. Pomocí unionfs můžeš mít mountnutý /var ze sítě jako read-only a změny si ukládat do paměti. Stejně, jako to dělají live distra s / na CD.

Na instalci balíčků na jednotlivých stanicích se vykašli. Pro stanici bude systém prostě neměnný a veškeré změny dělej na serveru (třeba po ssh ze stanice). Budeš mít tak zajištěno, že se dvě stanice nebudou přetahovat o jeden balíčkovací systém, bude to bezpečnější (i kdyby ses postavil na hlavu, tak to prostě nezničíš jinak než ze serveru) a na pohodlí to mnoho neubere (jedno ssh spojení).

[Honza "tux" Friesse]

Psal jsem na toto téma bakálářskou práci. Stavěl jsem na Debianu a myšlenka byla taková, že se nainstaluje Debian přes debootstrap, pak se do toho nahrají soubory, které pozmění proces bootování (lépe řečeno, jen přidávají do rcx.d). Byla k tomu i utilitka, co parsovala INI soubor do Bash skriptu, která uměla jednoduchou děďičnost, a sloužila k nastavení parametrů dle IP. Celkem to celé i zveřejnil, jen nevím, jestli se bakalářské práce zveřejnit smějí.

[petr_p]

Nove X servery umi bezet bez konfiguracniho souboru a autodetekci poznat spoustu hardwaru. Pokud ale mas nejake stare karty nebo monitory, tak se smir s rucne psanymi konfiguraky. Navic takove veci jako alternace mezi OS a uzavrenymi ovladaci (kvuli OpenGL) nebo konfigurace dalsich vystupu (TV, multihead apod.) je velmi specificka vec. Muzes se pokusit napsat skript, ktery podle informaci z PCI sbernice a logu X serveru (X -probeonly), identifikuje HW a podle toho sahne pro spravny konfigurak.

Co se tyce /varu, tak ten ja resim prekopirovanim skeletu do adresare exportovaneho pro zapis (ale jedna se jen o tenke klienty -- X, lpr, esd, mixer, sshd, mtools -- /var je maly).

Mozna by stalo za to zvazit pouzit nejakeho copy-on-write prekryvneho souboroveho systemu (squashfs?) ukladajiciho data do RW NFS nebo jen do RAM disku. Tim by se ale zkomplikoval pripadny upgrade na serveru za soucasneho behu klienta.

A nakonec databaze balicku: Pokud touzis po tom, ze z libovolneho klienta nainstalujes balicek a ostatni klienti jej budou mit okamzite k dispozici, tak na to zapomen. Nevim, jak to funguje na Archu, ale mnoho balickovacich systemu ukryva do balicku postinstalacni skripty ci prepisuje konfiguraky. A tohle vyresit neni vubec jednoduche. Nakonec zkoncis s tim, ze vsechny soubory specificke pro klienta budes linkovat do RW adresare nebo nutit programum jinou cestu ke konfigurakum.

Napr. na FI MU se pouziva nasledujici system: Klienty maji vlastni disky, na kterych je nainstalovana distribuce (v soucasnosti Fedora). Po bootu se rsyncem obsah lokalniho systemu aktualizuje proti zrcadlu na serveru (mozna nejakemu referencnimu klientovi). Na lokalnich systemech jsou nejake zakladni programy a pak velke molochy jako X, KDE, Gnome apod. Na tomto celem bezi system modulu, coz je sada skriptu, ktere zpristupnuji programy nainstalovane do specialniho adresare, ktery se mountuje ze serveru a je jen pro cteni a je spolecny vsem klientum. Aktivace modulu prakticky jen zkontroluje existenci modulu pro danou platformu a pak pripise do promennych PATH, LD_LIBRARY_PATH, MAN_PATH apod. cesty ke konkretnimu baliku.

[trekker.dk]

A nakonec databaze balicku: Pokud touzis po tom, ze z libovolneho klienta nainstalujes balicek a ostatni klienti jej budou mit okamzite k dispozici, tak na to zapomen. Nevim, jak to funguje na Archu, ale mnoho balickovacich systemu ukryva do balicku postinstalacni skripty ci prepisuje konfiguraky.

To by ale nemuselo vadit, pokud ten disk na síti bude pro roota (který instaluje ty balíky) r/w a všechny stroje budou používat stejný adresář /etc. Vzhledem k tomu, že ty stroje nemají mít disk, nemůže postinstalační skript udělat nic, co by se neprojevilo na ostatních strojích.

Přepisování konfiguráků ... nevím, jak jinde, ale v Debianu se instalátor ptá, jestli přepsat nebo ponechat. Navíc dává možnost srovnat obsah původního a nového, což by se dalo použít, pokud by určitý konfigurák měl více verzí pro různé stroje.

[petr_p]

Pokud budou mit vsechny stanice stejny obsah FS, tak to problem neni. Jenze prave ten problem tazatel ma. Takze zacnou orgie se vsemi temi symlinky apod.

Podle mne v pripade heterogenniho prostredi je potreba udelat zvlast systemovou cast, ktera bude resit odlisnosti jednotlivych stanic, a zvlast aplikacni cast. Rekneme ze rozumnym rozdelenim balicku na dve skupiny by se to dalo vyresit, ale hlidani pri upgradu nechci videt.

Ano, nektere distribuce konfiguracni soubory sami od sebe nemeni, ale jak rikam, Arch neznam (s hruzou vzpominam na SuSE).

[trekker.dk]

ad 1: Pokud tě nenapadne nic lepšího, můžeš udělat několik verzí xorg.conf a k nim symlinky xorg.conf-ip.ad.re.sa Při bootování se potom odpovídající konfigurák stáhne a přejmenuje předtím, než začne startovat X.

[Zdeněk Štěpánek]

Dnes jsem sice vyresil jeste treti problem, a to ten aby jadro pri svem bootu ziskalo IP adresu z dhcp tesne pred pripojenim NFS rootfs, ale s vyse uvedenymi problemy jsem nehnul.

Asi tak nejvetsi dilema mam, zda jako prvni resit /var nebo xorg.conf.

Ale rozhodle jsem se pro xorg.conf, stahnul SLAX a neobjevil absolutne nic, jeste ho budu muset prolizt jednou.

V nejakym live nebo v necem takovym jsem uz nejaky univerzalni konfig nasel pred casem. Byl zalozen na tom, ze je tam sekce device a screen nekolikrat. U kazdeho device je uveden jiny ovladac. Sekce screen jsou stejny.

Srdcem vseho je toto:

Section "ServerLayout"
Identifier     "X.org Configured"
Screen         "Screen-ati"
Screen         "Screen-nvidia"
Screen         "Screen-i810"
Screen         "Screen-vesa"
InputDevice    "Mouse0" "CorePointer"
InputDevice    "Keyboard0" "CoreKeyboard"
EndSection

Spoleha se to na fakt, ze pritomna je jen jedna grafika a tudiz inicializace vsech ostatnich screenu zkonci chybou. Na ATI 7000 to funguje, ale na i910 to nahodi 640x480 a basta fidly.

Porad se nemuzu rozhodnout zda jit cestou naproste autodetekce (at uz formou super-multi.xorg.conf nebo nejakyho programu co vyplivne konfig nebo skriptu co zjisti typ graficky a podle toho pouzije pripraveny konfig) nebo druha moznost mit pripraveny konfigy pro kazdej komp zvlast? Nebo to nejak zkombinovat? Rad bych aby to bylo prijatelne reseni pro vsechny a ne jen pro me,protoze bych to logicky smeroval jen na pocitace, kde to pobezi, coz jsou cca 4 mozne kombinace vga-monitor.

Zdenek

[Petr "Glubo" Sýkora]

Na řešení /var by možná bylo dobré zvážit použití UnionFS, které je hojně používáno různými livecd. Jde v zásadě o virtuální filesystem, který dokáže transparentně "spojit" více adresářu do jednoho, s tím, že se nastaví, do kterého z nich se zapisují změny.