S již hotovým toolchainem jsme připraveni pustit se do tvorby našeho vlastního systému. Tvořit se bude opět ve speciálně
nastaveném shellu v našem standardním systému, takže během dlouhých kompilací můžeme bez problému pracovat tak, jak jsme
zvyklí, jen si občas odskočíme do terminálu a zadáme další kompilaci.
Chrootnuté prostředí
Toolchain se tvořil v prostředí speciálního uživatele, k tomuto účelu vytvořeného, z toho důvodu, že bylo potřeba mít
některé systémové proměnné nastavené trochu jinak než obvykle, ale jinak se používaly nástroje z hostitelského systému.
V takovém případě je tvorba pod speciálním uživatelem vhodná. Při tvorbě systému je to ale jinak. Nyní potřebujeme mít
zcela izolované prostředí, jakýsi systém v systému. Toho se dá celkem snadno docílit prostým přesvědčením shellu, že
jistý adresář, dle našeho výběru, je „kořenový“, tedy „/“. Od toho okamžiku se celá podvětev stromové struktury adresářů,
jejímž nejvyšším bodem je onen námi vybraný adresář, chová jako samostatná stromová struktura a my nemáme možnost jakkoliv
přistoupit k čemukoliv mimo ni. Takovými přesvědčovacími metodami disponuje příkaz chroot a v knize LFS je použit takto: chroot "$LFS" /tools/bin/env
-i \ HOME=/root TERM="$TERM" PS1='\u:\w\$ ' \ PATH=/bin:/usr/bin:/sbin:/usr/sbin:/tools/bin \ /tools/bin/bash --login +h
kde proměnná LFS představuje adresář s přimountovaným LFS oddílem. Ostatní
parametry zařídí v pořadí, jak jsou uvedené – vynulování systémových proměnných v chrootnutém prostředí, nastavení nových
proměnných HOME, TERM, PS1, a PATH. Poslední
parametr spustí bash a vypne jeho hashování (ono +h). Co to znamená to hashování? Bash si normálně
poznamenává spouštěné příkazy, aby nemusel pořád procházet adresáře v proměnné PATH. V případě, že je
použit takto poznamenaný příkaz, neprohledává se PATH, ale rovnou se spustí tentýž konkrétní program
jako v předchozím případě. Při tvorbě systému ale chceme, aby se nově vytvořené nástroje začaly používat okamžitě. Z
toho důvodu je hashování vypnuto, takže Bash musí poctivě procházet adresáře v PATH jeden za
druhým. Vzhledem k tomu, že adresář /tools/bin je až na konci tohoto seznamu, bude vždy použit každý nově nainstalovaný
program okamžitě po nainstalování jeho binárek do některého z adresářů /bin, /usr/bin
, /sbin nebo /usr/sbin – prostě proto, že je tam Bash najde dříve.
Při tvorbě toolchainu v minulém díle jsme se drželi dokumentace LFS víceméně doslovně. Vymýšlet nějaké
úpravy u toolchainu nemá totiž moc smysl, vzhledem k tomu, že jde pouze o dočasné nástroje, které použijeme ke zbudování
vlastního systému a vzápětí je odstraníme. Ale toto již neplatí při budování vlastního systému. Zde už je nutno brát
LFS knihu poněkud odlišně. Jistě, i nadále kniha provádí procesem tvorby systému krok po kroku s
vysvětlením všech voleb a příkazů. Ale účelem knihy není, aby tvůrce slepě následoval její postup. Kdepak. Kniha pouze
předkládá učebnicový model s tichým předpokladem, že si ho každý přiohne svým představám a potřebám. Tvůj systém
- tvá pravidla.
LFS postup se snaží držet se obecně zavedených linuxových standardů
The Linux Standard Base a taktéž stromová struktura v něm použitá ctí zásady Filesystem Hierarchy Standard , tak aby byl
výsledný systém jednoduše použitelný standardním způsobem. Je dobré si uvědomit, že odchylovat se od standardů je
samozřejmě povolené, jenom je třeba k tomu přistupovat promyšleně a být smířen s tím, že to většinou znamená práci
navíc.
Správa software v novém systému
Před samotnou tvorbou systému je vhodné si nejprve pořádně promyslet pár věcí. Především ty, které by se později měnily
docela těžko. Zde platí ono staré dobré pořekadlo – dvakrát měř a jednou instaluj.
První ze dvou základních věcí, které bychom měli dobře uvážit, je, jakým způsobem budeme v našem systému spravovat
software. Dokumenty LFS si totiž s touto věcí hlavu nelámou, a vše se v nich instaluje přímo do
systému pomocí make install. Problémem tohoto způsobu je, že my vlastně nevíme, co se kam
nainstalovalo, a nemáme tudíž způsob, jak to lehce, v případě potřeby, odstranit. Taktéž dohledat informace o tom, co je
vlastně nainstalováno, a k čemu patří jaký soubor, je takřka nemožné.
Dalo by se celkem dlouho diskutovat, zda je vůbec nějaké takové organizování software potřeba. Jistě v dokonalém světě
by potřeba nebylo – všechno by se totiž do systému pomocí make install hladce nainstalovalo, nikde by
nic s ničím nekolidovalo a všechno by hned fungovalo. A nikdy bychom to nepotřebovali odinstalovávat. Protože svět není
dokonalý, nefunguje to tak. Stane se, že po nainstalování daný program nefunguje tak, jak jsme si představovali a je
třeba jej odinstalovat. Chtít mít proces přidávání a odebírání software plně pod kontrolou je, dle mého názoru, dobré
rozhodnutí.
Protože tvoříme svůj vlastní systém, můžeme si sami rozhodnout, jakým způsobem budeme proces správy kontrolovat. Pojďme
se tedy podívat, jaké máme možnosti. Následující výčet není ani zdaleka úplný, jistě existují i další způsoby. Pokud o
nějakých víte, podělte se o ně s námi v případné diskusi pod článkem.
Balíčky
Nejpoužívanějším systémem správy software jsou klasické balíčkovací systémy, známé z většiny distribucí. Aplikace či
knihovny či cokoliv dalšího pak přicházejí do systému jako balíčky. Tyto balíčky příslušný balíčkovací systém vezme,
rozbalí, soubory z nich nakopíruje na definované lokace a udělá si záznam ve své databázi, co nainstaloval a kam. Tyto
informace jsou nám potom kdykoliv na požádání k dispozici a taktéž slouží při případném odinstalovávání. Stačí požádat
balíčkovací systém, aby ze systému odebral ten a ten balíček, on se podívá do databáze, vytáhne si informace, které
soubory je třeba odstranit a tyto odstraní, načež si odstraní i záznam o tom, že ten balíček vůbec kdy viděl.
Distribuční balíčky v sobě, kromě samotného software, nesou spoustu dalších informací. Důležitý je především seznam
závislostí. Drtivá většina programů totiž ke svému fungování potřebuje knihovny, které autor programu při jeho vývoji
použil. Distributor, který vytváří balíček, do něj tedy uvede, na jaké knihovně je program závislý. Takže při pokusu o
instalaci tohoto programu chytré balíčkovací systémy napřed stáhnou z distribučních repozitářů požadovanou knihovnu a
nainstalují ji, takže následně instalovaný program ji už v systému má, a může být zkompilován. Ty méně user-friendly
aspoň upozorní, že chybí ona knihovna, a dokud ji nenainstalujeme, tak nám instalaci programu nepovolí (pokud nepoužijeme
násilí). A pak jsou taky takové, které si s nějakými závislostmi hlavu nelámou vůbec, a je na uživateli, aby si zjistil,
co k provozování programu potřebuje, a taky to obstaral.
Pokud se rozhodneme v našem systému použít balíčkovací systém, budeme si balíčky vytvářet sami. Není tedy třeba vůbec
uvádět žádný seznam závislostí. Nebudeme totiž mít v tomto případě k dispozici žádný repozitář a balíčkovací systém by
tak neměl jak tyto závislosti řešit. Není to vlastně ani potřeba, protože si program kompilujeme sami ve svém systému a
tudíž tam ony potřebné knihovny už být musí, jinak by se nám program zkompilovat ani nepovedlo. Narazit můžeme, leda
pokud bychom z nějakého důvodu něco odinstalovali – při samotné odinstalaci by nás totiž nic neupozornilo na fakt, že to,
co mažeme je potřeba pro deset dalších programů, které bez toho nebudou fungovat. Ale na to bychom vzápětí přišli velmi
rychle sami.
Pěkný návod jak ve svém systému zprovoznit a používat debianovský dpkg, je na LinuxFromScratch.org
Samostatné adresáře
Další možností je mít pro každou aplikaci zvláštní adresář. Při instalaci se prostě místo standardního umístění nechá
aplikace nainstalovat do námi určeného adresáře. K tomuto účelu může dobře posloužit například adresář
/opt. Tento způsob vyžaduje drobné poinstalační úpravy. Minimálně proměnnou PATH je
potom potřeba doplnit o nový adresář, a do /etc/ld.so.conf dodat záznam o novém adresáři s knihovnami,
pokud chceme, aby o nich systém „věděl“. Odinstalace by pak probíhala prostým smazáním adresáře a odstraněním těchto
úprav. Informace o tom, co je vlastně v systému nainstalované, by pak bylo možné zjistit třeba pomocí ls /opt
Systém založený na majitelích souborů
Velice zajímavá myšlenka je využít odlišných majitelů souborů. Pro názornost – pro instalaci mplayeru
se vytvoří speciální uživatel se jménem mplayer a pod tímto uživatelem se provede samotná instalace.
Soubory, které tak budou nainstalovány, budou mít majitele mplayer, čímž jsou jednoznačně a lehce
odlišitelné od souborů jiných aplikací. Na tomto základě pak probíhá celá správa software, která má díky tomu některá
velmi zajímavá specifika a možnosti. Například instalace neprobíhá s právy roota, což opatrnější z nás určitě ocení.
Domovské adresáře těchto uživatelů se dají krásně použít pro přehledné uložení hromady informací vztahující se k danému
balíčku včetně zdrojových kódů. Situace, kdy jedna aplikace při instalaci přepíše nějaký soubor jiné aplikace, jsou takřka
vyloučené. Taktéž odstranit při odinstalaci soubor patřící jiné aplikaci není zrovna snadné. Detaily jsou výborně
popsány v samostatném článku.
Vlastní řešení
V neposlední řadě si můžeme nějaký ten systém pro správu software vytvořit sami. Klidně za pomoci Bashe
a základních GNU utilit. Napsat si pár šikovných skriptíků, které by v podstatě simulovaly základní
funkce klasických balíčkovacích systémů nemůže být pro zdatnějšího linuxáka příliš velký problém. V podstatě jde
pouze o to udržet si přehled, kam co instalujeme, takže při instalaci si toto prostě někam poznamenat a následně to na
základě tohoto záznamu dokázat odinstalovat. Je to sice tak trochu objevování kola, ale fantasii a iniciativě se meze
nekladou.
Taky je samozřejmě možné použít kombinaci některých výše uvedených způsobů, klidně i všech. Například základní systém
LFS instalovat s prefixem /usr, jak je tomu v knize, přímo natvrdo do systému, každou
další aplikaci do vlastního adresáře v /opt a knihovny pomocí nějakého balíčkovacího systému umísťovat
do /usr/local. Jediné, na čem záleží, je, abyste se v tom sami vyznali, a aby se vám to používalo pohodlně.
Tou druhou základní věcí, kterou je třeba rozhodnout hned na začátku, je rozložení adresářů. Jak už jsem psal,
LFS staví na osvědčeném modelu dle FSH, ale nic nám nebrání si tu strukturu adresářů
přestavět plně podle svých představ. Je ale třeba myslet na to, že s modelem FSH počítají všichni
vývojáři a ačkoliv jde drtivá většina software donutit, aby se nainstalovala tak, jak my chceme a kam chceme, může to být v
některých případech opravdu pracné. Některé aplikace mají dokonce natvrdo nastavené, co kde mají hledat, a pak je třeba
speciálně pro ně vytvářet příslušné symlinky. Už se nejspíš budu opakovat, ale rozhodnutí je plně na tvůrci
systému, jeho budoucím uživateli, a vyhovující je tedy to, co jemu samotnému vyhovuje.
Tvorba systému
Poté co se rozhodneme jak budeme software spravovat, můžeme se konečně pustit do samotné tvorby vysněného systému.
Chrootneme se do tvůrčího LFS prostředí, vytvoříme si na disku strukturu adresářů a pustíme se do
kompilace balíčků tak jak jdou za sebou v knize LFS. Ačkoliv máme knihu při ruce, uzpůsobujeme si
veškeré parametry skriptu configure tak, aby vyhovovaly naším potřebám, především pokud jsme nějakým
způsobem měnili strukturu adresářů, je třeba na toto myslet a příslušnými parametry skriptu configure
definovat nová umístění. Připomínám, že veškeré parametry, kterými můžeme toto nastavovat, se dají zjistit spuštěním
configure s parametrem –help. Při třetím kroku svaté trojice postupujeme v souladu se
systémem správy software, pro který jsme se rozhodli.
Tentokrát se začíná instalací hlavičkových souborů Linuxového API. Ty se vydolují ze zdrojových kódů linuxového jádra,
nejlépe toho, který posléze použijete k běhu systému. Následuje opětovné přeložení a instalace glibc.
Tentokrát už opravdu finální verze. Zdrojové kódy obsahují i možnost otestování zkompilovaných binárek, zda se vše
přeložilo správně. Je rozumné tento test v tomto okamžiku provést, ačkoliv to o dost prodlouží celý proces instalace.
Je lepší případné problémy odhalit hned, než později pracně zjišťovat při podivném chování systému, kde je chyba.
Následují staré známé binutils, opět s doporučením provést kontrolní testy. Po nich přijdou na řadu dvě
matematické knihovny a následuje finální verze gcc. A pak už to jede jeden balíček za druhým, celkem
jich je asi padesát. I za předpokladu, že nenarazíte na žádný problém, tak to trvá dlouho (není to na jeden večer, spíš
na víc), a je to celkem monotónní a únavná práce. Doporučuji doplnit tuto základní kolekci software o nějaký internetový
prohlížeč, například lynx, elinks nebo něco podobného a taky Midnight
Commander nám v novém systému, který nebude disponovat žádným GUI jistě prokáže neocenitelné služby. Naopak se
dá předpokládat, že GRUB je již nainstalován v rámci systému, ve kterém tvorbu LFS
provádíme, a můžeme ho tedy s klidem vynechat aspoň do chvíle, než se rozhodneme odstranit starý systém a z nového udělat
náš hlavní.
Poté co je vše zkompilováno a nainstalováno, zbývá vytvořit bootovací skripty a udělat náš nový systém bootovatelný. LFS používá klasický SysVinit, známý z většiny distribucí, a přichází s kolekcí vlastních bootovacích skriptů. Existují ale i jiné možnosti než SysVinit, například Upstart nebo Initng. Klasická struktura skriptů používaná s SysVinit se možná může zdát někomu zbytečně nepřehledná a složitá. Při tvorbě vlastního systému můžeme zjednodušit boot a jeho konfiguraci, jak jen to jde. Vzhledem k tomu, že tvoříme systém ušitý na míru našim potřebám, může být plně dostačujícím řešením klidně i jeden jediný hlavní skript plus po jednom skriptu na každý runlevel. Pro inspiraci, jak vytvořit přehledné a jednoduché bootovací skripty, se můžete podívat na LinuxFromScratch.org.
Nyní nás čeká velké finále. Máme nainstalován všechen potřebný software, napsané bootovací skripty, zbývá zkompilovat a nainstalovat jádro neboli kernel, příslušně upravit menu.lst v našem hostitelském systému a restartovat. V menu GRUBu vybereme náš nový systém a pak už se můžeme kochat rychlým bootem našeho nového, vlastního systému.
Tak a máme nový linuxový systém, co s ním teď dál? Pracovat v textovém režimu sice může někomu stačit a tím zde jeho cesta víceméně končí, ale pokud chceme plnohodnotný desktopový systém, čeká nás ještě spousta práce. A o té si povíme v příštím, závěrečném díle.
