Portál AbcLinuxu, 5. května 2025 10:34
Článek lehce navazuje na návod k NIS+NFS+LTSP. Minule jsme nakonfigurovali Linuxový počítač tak, aby se na něj šlo přihlásit jménem a heslem ze serveru. Dnes tento počítač téměř bezpracně naklonujeme na prakticky neomezené množství stanic.
Princip je velmi jednoduchý. Systém není uložen na lokálním pevném disku, ale na serveru v síti, a tak všechny stanice sdílejí jeden disk s jedním systémem. Použité protokoly a služby jsou jen DHCP, TFTP a NFS, takže nic složitého.
Etherboot je program, který obsahuje ovladač pro síťovku, DHCP klienta a TFTP klienta. Roste na adrese www.rom-o-matic.net. Je možné ho získat v mnoha variantách - podle toho, odkud bude startovat. Nejdůležitější jsou asi varianty pro floppy disk, LILO/GRUB/SYSLINUX formát a PXE formát. Pro test je nejvhodnější použít obraz pro disketu, stačí ho pomocí
dd if=etherboot.zdsk of=/dev/fd0
nahrát na disketu a nabootovat. Později si popíšeme elegantní řešení multibootu s Windows pomocí GRUBu. Na zmíněné webové stránce je potřeba zvolit konkrétní model síťové karty, formát etherbootu podle zvoleného média a je dobré ještě otevřít rozšířené vlastnosti, kde se první políčko ptá na timeout; je vhodné nastavit -1 a timeout vypnout, aby se ihned bootovalo ze sítě bez ptaní. Možnost výběru bootování z HDD/Floppy/Sítě není v etherbootu moc dobrá, protože je čistě textová a to by dnes při snaze prosadit Linux neuspělo. A navíc mi to moc nefungovalo.
Máme tedy etherboot na disketě. Zkuste z ní nabootovat. Etherboot se musí ohlásit, najít síťovku, ukázat MAC adresu a snažit se z DHCP získat IP adresu. Pokud používáte nejrozšířenější DHCP server, tedy linuxový ISC DHCPd, je nutné stanici definovat napevno, tedy svázat MAC a IP. Jinak se bude etherboot tvářit, že DHCP server nefunguje, jakoby stále vyhledává, až skončí na timeoutu. U DHCP serveru na Windows Server 2003 toto není nezbytně nutné: pokud definujeme jméno souboru a kořenovou cestu (probereme za chvíli) jako parametry pro celý obor, etherboot adresu dostane.
Do DHCP musíme přidat 3 informace. První je adresa TFTP serveru, druhá je jméno bootovacího souboru, tedy odkud má etherboot stáhnout linuxové jádro, a poslední je NFS adresa kořenového filesystému. Ukázky vydají za tisíc slov:
host tlustoch1 {
hardware ethernet 00:01:02:B1:43:A3;
fixed-address 192.168.10.10;
next-server 192.168.10.2;
filename "/tftpboot/lts/zavadec.nbi";
option root-path "192.168.10.2:/";
}
Direktiva next-server určuje adresu TFTP serveru pro případ, že by byla odlišná od adresy brány. Filename je jméno NBI jádra a root-path je cesta, odkud si Linux připojí root filesystém. Není nezbytně nutné použít přímo / ze serveru, je možné mít v adresáři připravenou nějakou jinou distribuci.
Jako perličku k samostudiu přikládám rezervaci pro klienta používajícího PXE. Princip je stejný, jen se nejprve stáhne samotný etherboot a ten až potom stáhne NBI jádro.
host xltest {
hardware ethernet 00:04:76:9B:99:2E;
fixed-address 192.168.10.11;
next-server 192.168.1.10;
if substring (option vendor-class-identifier, 0, 9) = "PXEClient" {
filename "/tftpboot/lts/etherboot.zpxe";
} else if substring (option vendor-class-identifier, 0, 9) = "Etherboot" {
filename "/tftpboot/lts/zavadec.nbi";
}
}
Důležité jsou parametry 17, 66 a 67. Parametr 66 je analogií k next-server. Možnosti je možné definovat jak pro celý obor (ozubená kolečka), tak pro každého klienta zvlášť (ozubený počítač). Já osobně mám celý obor nastaven pro tenké klienty a tlustým klientům přenastavím parametr 17 a 67. Jestli jde pomocí Windows serveru bootovat klienty pomocí PXE, jsem nezjistil, ale podle toho, co jsem naklikal, to zřejmě nejde; nikde není k vidění možnost odesílat různá jména souborů podle toho, kdo se ptá. Případně mě prosím v diskuzi opravte, tenhle systém používám jen z donucení.
Pokud máme konfiguraci DHCP hotovou, etherboot musí dostat z DHCP IP adresu a začít pomocí TFTP stahovat soubor, což se mu ze zjevných příčin zatím nepodaří.
TFTP je věc vcelku jednoduchá. Je potřeba mít TFTP server nainstalovaný a spustit:
in.tftpd -l /tftpboot/lts/ -r blksize
Uvedená cesta definuje adresář, ze kterého lze stahovat soubory. Vzhledem k absenci jakékoliv bezpečnosti u TFTP nedávejte do adresáře zbytečnosti. V konfiguraci DHCP ale musí být absolutní cesta, tedy včetně /tftpboot/lts/. Parametrem -r lze zapnout různé workaroundy pro bugovité implementace TFTP klienta. To sice není problém etherbootu, ale zůstalo mi to tam po testech PXE se síťovkami od Intelu a 3comu.
Zde se již dostáváme k distribučně závislým věcem. Já jedu na Arch Linuxu a jedno z přání při implementaci tlustých klientů bylo použití distribučního jádra bez jakýchkoliv úprav. Jádro z Archu splnilo mé požadavky na výbornou. Neručím tedy za to, že to bude fungovat i s výchozími jádry jiných distribucí. Jak jsem již předeslal, NBI jádro je vlastně běžné linuxové jádro slepené s initramdiskem. Nejprve si tedy vyrobíme initramdisk tak, aby obsahoval ovladače pro všechen možný hardware.
Konfigurace pro mkinitcpio - mkinitcpio-kernel26.conf:
MODULES="" FILES="" HOOKS="base net udev ide scsi sata usbinput raid filesystems"
A initramdisk vytvoříme:
mkinitcpio -c mkinitcpio-kernel26.conf -g init.cpio.gz
Jádro použijeme výchozí z distribuce, tedy /boot/vmlinuz26 a výsledné NBI jádro nasypeme rovnou, kam patří. NBI jádro vytvoříme tímto příkazem:
mkelf-linux /boot/vmlinuz26 init.cpio.gz \ --append="ip=:::::eth0:dhcp vga=773 quiet" \ --output=/tftpboot/lts/zavadec.nbi
Soubor init.cpio.gz můžeme teď klidně smazat. Vysvětlení určitě zaslouží direktiva --append. Především říká jádru, že si má nakonfigurovat síťovku eth0 pomocí dhcp. Zárověň to implikuje snahu o připojení kořenového filesystému přes NFS. Že jádro použije mód s vyšším rozlišením a při bootu nebude ukecané, jsou už věci vcelku podružné. K dalšímu studiu doporučuji soubor /usr/src/linux/Documentation/nfsroot.txt.
V tuto chvíli by mělo jádro na klientech startovat, získat IP adresu (konfigurace se vypíše na monitor) a snažit se připojit kořenový filesystém přes NFS, na čemž dojede. Pokud tedy nedojede poněkud dříve, můžeme přikročit ke konfiguraci NFS.
O připojování NFS oddílů jsem již něco napsal v prvním dílu seriálu o NIS+NFS, takže jen stručně. U tlustých klientů je nesmírně důležitá rychlost komunikace mezi klientem a serverem, protože pomalý disk je katastrofa a pomalé NFS je katastrofa ještě horší.
/etc/exports:
/ 192.168.0.0/255.255.0.0(rw,no_root_squash,sync,subtree_check)
9 z 10 zarytých linuxáků se nyní musí ježit vlasy hrůzou na hlavě a ježí se správně. Pokud by si někdo do sítě připojil počítač s vlastním rootem a připojil se na naše NFS, má roota i na serveru. Pokud pomineme omezení na hardwarové úrovni, tak správným řešením je jednak omezit povolené IP adresy na co nejmenší rozsah, (případně nesdílet kořenový oddíl serveru, ale mít distribuci v adresáři a sdílet ten), squashovat roota a v této distribuci mít roota s UID 65535. Nedokážu si představit, co by se dělo, kdyby se démony pod rootem na stanici nemohly dostat ke svým datům na serveru. Potenciální útočník bude moci zkompromitovat distribuci v adresáři, ale ne hlavní systém. Je možné také adresář nasdílet jen pro čtení, ale to by vyřešilo z části jeden problém a přineslo jiné. Nápady na zabezpečení jsou vítány.
S NFS sice nejsme moc spokojeni, ale funguje. V tuto chvíli by měla již distribuce nabootovat až k loginu, i když je možné, že to během bootu zakřičí několik chyb. To proto, že se teď 2 instance téhož systému perou o adresáře /var/run apod. Jedna na serveru a druhá na klientu. Proto přichází na scénu sada skriptů s názvem ThickScripts.
Obecně platí, že každý linuxový systém musí mít adresář /var připojen i pro zápis a nemůže být sdílený. Toto pravidlo není nutné, ba ani vhodné aplikovat na celý /var, ale jen na některé podadresáře, např /var/log, /var/run atd. Nabízejí se 2 řešení. Jednak můžeme mít soubor obsahující filesystém a ten mít extra pro každou stanici a vždy si ho připojit, nebo použít ramdisk a vždy při startu systému v ramdisku vytvořit potřebnou adresářovou strukturu. Já jsem zvolil řešení s ramdiskem. Výhodou je jednodušší implementace, nevýhodou zase to, že vše v ramdisku se při vypnutí ztratí - ale mrzet by nás mohly leda tak logy. ThickScripts vytvoří ramdisk v adresáři /thickramdisk, uvnitř připraví adresářovou strukturu a jednotlivé adresáře se bindují na svá místa ve /var, kde přebijí sdílené adresáře ze serveru.
Další důležité věci, které ThickScripts řeší, je např. pokus o nalezení SWAP oddílu na HDD a jeho připojení, zkopírování správného xorg.conf do /etc/X11/, nastavení hostname na tvar 192-168-22-33, nastavení zvuku, atd.
ThickScripts v principu není nic jiného než několik málo bashových skriptů. Jako první se zavádí skript all. V něm je právě již zmíněné vytvoření ramdisku, připojení SWAPu atd. Následuje zjištění IP adresy klienta a pokus o nalezení skriptu, který je pojmenován stejně jako zjištěná IP adresa. Pokud ho najde, tak ho spustí. Pokud ho nenajde, spustí skript s názvem default. Já tyto skripty spouštím i na serveru; mám tím zaručené jednotné prostředí a jistotu, že to funguje.
Jak jsem již předeslal, používám distribuci Arch Linux, tak je ThickScripts postaven pro Arch. Ale po drobných úpravách není problém to spustit i na jakékoliv jiné distribuci. Distribučně závislé jsou v podstatě 2 věci. Jednak prvotní skript thickscripts, který je v adresáři /etc/rc.d a chová se jako služba. Systém ho spustí hned po inicializaci sítě. Tam jsou příkazy stat_busy a stat_done, která zajistí obarvení výstupu dle zvyklostí distribuce. Lze je klidně vypustit, stejně tak jako includování konfiguračních souborů Arch Linuxu.
/etc/rc.conf:
... # - prefix a daemon with a @ to start it up in the background # DAEMONS=(syslog-ng network thickscripts portmap ... # End of file ...
/etc/rc.d/thickscripts:
#!/bin/bash
. /etc/rc.conf #arch-specific
. /etc/rc.d/functions #arch-specific
TSPATH="/thickscripts"
case "$1" in
start)
stat_busy "Starting ThickScripts" #arch-specific
echo "ThickScripts: loadings system settings for all hosts"
$TSPATH/all
echo "done"
echo
IP=`ip a s eth0 | grep -m 1 "inet " | cut -d " " -f 6 | cut -d / -f 1`
if [ -f $TSPATH/$IP ]; then
echo "ThickScripts: loading system settings for $IP"
$TSPATH/$IP
else
echo "ThickScripts: system settings for $IP not found, using defaults"
$TSPATH/default
fi
echo "done"
stat_done #arch-specific
;;
stop)
stat_busy "Stopping ThickScripts" #arch-specific
echo "Nothing to stop..."
stat_done #arch-specific
;;
*)
echo "usage: $0 {start|stop}"
esac
exit 0
Druhá distribučně závislá věc je samotný skript all, protože tam je nutné vypsat jaké adresáře se budou připojovat z ramdisku. Pokud si nainstalujete nějaký program a ten bude vyžadovat adresář /var/log/program, je nutné provést změnu v tomto skriptu.
/thickscripts/all:
#!/bin/bash
#do not remove this entry, only edit, please
TSPATH="/thickscripts"
RAMDISK="/thickramdisk"
swapdsk=`fdisk -l | grep -m 1 "Linux swap" | cut -d " " -f 1`
if [ ! $swapdsk == "" ]; then
echo "Activating swap $swapdsk"
/sbin/swapon $swapdsk
fi
IP=`ip a s eth0 | grep -m 1 "inet " | cut -d " " -f 6 | \
cut -d / -f 1 | sed 's/\./-/g'`
hostname $IP
mkdir -p $RAMDISK
mount -t tmpfs none $RAMDISK
cp -f $TSPATH/xorg.conf-default $RAMDISK/xorg.conf
rm -f /etc/X11/xorg.conf
ln $RAMDISK/xorg.conf /etc/X11/xorg.conf -s
mkdir -p $RAMDISK/var/run/
mount -o bind $RAMDISK/var/run/ /var/run/
mkdir /var/run/avahi-daemon
mkdir /var/run/cups
...
...
Nakonec se spustí skript s názvem jako IP adresa, případně skript default. Zde je příklad. Za zmínku stojí nastavení konfiguračního souboru xorg.conf. Skript all vezme výchozí konfigurační soubor (měl by tak nějak fungovat všude) a pod jménem xorg.conf ho nakopíruje do ramdisku, smaže soubor nebo symlink v /etc/X11/ a z tohoto adresáře udělá symlink na právě zkopírovaný soubor. Pokud chceme použít jinou než výchozí konfiguraci, stačí přepsat soubor v ramdisku. Jelikož symlink vede do lokálního ramdisku, není třeba se obávat restartu X na klientovi, použije se vždy správný soubor.
/thickscripts/192.168.3.19:
#!/bin/bash #do not remove this entry, only edit, please TSPATH="/thickscripts" RAMDISK="/thickramdisk" # ### ---insert your own rules bellow this line--- ### /sbin/modprobe floppy cp -f $TSPATH/xorg.conf-nv $RAMDISK/xorg.conf
Domovskou stránku projekt nemá. Balík ThickScripts je ve stavu, jak teď funguje (čili včetně konfigurace mých klientů), ke stažení zde: thickscripts.tar.bz2.
Systém funguje, ale má jednu zásadní nevýhodu, bootuje pořád z diskety, což není vždy ideální; navíc u tlustých klientů lze disketovku normálně používat. Bohužel ve školním prostředí bychom asi tvrdě narazili na nepochopení z řad vedení, kdyby na počítačích nebyl systém Windows, proto nakonfigurujeme multiboot. Přítomnost harddisku v počítači je výhoda, mimo jiné na něm můžeme mít SWAP. Při instalaci Windows stačí myslet a nechat na disku 500 MB volných.
Já jsem si modifikoval SLAX Linux na CD, přidal jsem oficiální balíček s Grubem a ještě vytvořil vlastní balíček, ve kterém byl /boot/grub z Arch Linuxu, včetně konfiguračního souboru. Ten byl pozměněný, aby primárně startoval Windows a na druhém místě byl Linux. Timeout jsem zvolil 20 sekund. Etherboot se startuje stejně jako linuxové jádro, jen nemá žádné parametry ani initramdisk. Po běžné instalaci Windows jsem tedy nabootoval SLAX, s pomocí skriptu vytvořil 50MB ext2 oddíl a zbytek jako swap. Typicky hda1 - Win, hda2 - ext2 a hda3 - swap. Na ext2 oddíl jsem pak nakopíroval /boot/grub a do /boot nakopíroval etherboot. Nezapomeňte, že etherboot musí být vytvořen jako LILO/GRUB/SYSLINUX typ a pro síťovku, která je zrovna v počítači. Nakonec stačilo:
grub-install --root-directory=/mnt/hda2 /dev/hda
Modul pro SLAX obsahující etherboot pro "3c90x" a "tulip" mohu poskytnout. Jinak stačí využít linux-live, kde jsou skripty pro převod adresáře na SLAX balíček a opačně.
Skript pro zjednodušení instalace:
umount /mnt/hda* echo "hda2 - Linux" echo "hda3 - Linux swap" fdisk /dev/hda mke2fs /dev/hda2 mkswap -v1 /dev/hda3 mkdir /mnt/hda2 mount /dev/hda2 /mnt/hda2 mkdir /mnt/hda2/boot mc
V současné chvíli se distribuce ze serveru duplikuje na klienty, ale to v řadě případů nestačí. Museli bychom mít uživatele na serveru, což sice můžeme, ale lze použít i NIS+NFS popsané v odkazovaném seriálu. Prima věc je, že pokud to rozjedeme na serveru, ypbind a připojení /home se bez práce provede i na klientech - ale nezapomeňte, že od teď se na hlavní server bude připojovat ne jeden klient, ale celá řada. Tentýž server lze zároveň použít jako LTSP server a v podstatě bezpracně zlinuxovat jak učebnu se starými počítači, tak i novou od Indoše, což je typická situace na řadě škol.
PS uznavám, že to bije do očí
).
3.4.2007 21:13
xxx | skóre: 42
| blog: Na Kafíčko
Jj souhlasim. Jakmile ma clovek jednou uzivatele v ldapu, je dobre velmi rychle zapomenout na vsechy ty groupadd atp. Ty totiz pracuji primo se soubory v /etc. Ja si nakonec zvykl na praci s webovym phpldapadminem. Dalsi moznosti je napsat si nejake vlastni skripty.
Co se tyce passwd. Tak to funguje. Pokud je ale potreba pomoci passwd menit hesla jinym uzivatelum, je nutne v nastaveni LDAP modulu pro PAM, rict, aby se root bindoval s jinou "identitou" a to s takovou, ktera ma pristup k posixPasswordu ostatnich useru. Normalne je user bindlej jako on sam, tudiz smi menit jen sam sebe.
Jinak LDAP je hezkej, ale obcas je to velkej boj s nastavenim. Hlavne s pravama
2.4.2007 11:41
m$ lipo $m | skóre: 19
| blog: čaj o páté
| Redmond
2.4.2007 18:23
freshmouse | skóre: 42
| blog: Bruno Banány
< / žádný flame>
Když použijeme NFS pro připojení celého /home adresáře, má to jednu zásadní chybu: adresář se připojí ještě před tím, než se někdo k počítači vůbec přihlásí, navíc jsou připojeny (a potenciálně přístupné) adresáře všech uživatelů, ne jen toho jednoho, který s počítačem bude pracovat. To je IMHO architektonicky špatně a je to velká bezpečnostní mezera* Server neví, kdo u počítače (klienta) sedí, prostě jen slepě poskytuje data a věří klientskému počítači, že se o autorizaci postaral.
Za správné bych považoval to, že by se nepřipojoval celý /home, ale pouze adresář jednoho konkrétního uživatele, a to na základě jeho jména a hesla. Jenže když si domácí adresář bude připojovat sám uživatel, musí být přihlášený, jenže háček je v tom, že ve chvíli kdy je přihlášený, už musí být domácí adresář dostupný, tedy připojený.
Chtělo by to tedy, aby se po zadání jména a hesla v GDM/KDM připojil domácí adresář daného uživatele a potom mohlo naběhnout uživatelovo oblíbené KDE/Gnome.
Napadá mne použít SSHFS pro připojení ~/ Používám ho třeba pro on-line editaci www stránek a je to docela použitelné. Výkonnostně je to někde jinde než NFS nebo SAMBA, ale bezpečnostně taky Navíc "velká data" by si mohl uživatel zpracovávat na nějakém lokálním disku a až nakonec je nahrát do svého síťového domácího adresáře. Pro ty ostatní věci (nastavení programů, textové dokumenty...) by i tenhle FS měl stačit.
Takže pár otázek nakonec: Je SSHFS příliš pomalý nebo by šel použít? Víte o něčem lepším? Jak nacpat skript pro připojení disku mezi správce přihlášení a start KDE/Gnome (skript musí mít k dispozici heslo uživatele)? Neexistuje už nějaké hotové řešení tohohle všeho?
*) asi řeknete, že se mají počítače zabezpečit fyzicky, nebo že NFS serveru má být povolený přístup jen z některých IP adres. Ale to je podobně děravé řešení, jako když ve windows šlo shodit zaheslovaný spořič obrazovky vložením zvláštního CD.
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.
2.4.2007 22:49
2.4.2007 23:52