Instalační a uživatelský manuál pro Linux Mission 1.0. David Häring a kolektiv autorů LinuxZone

Instalační a uživatelský manuál pro Linux Mission 1.0 David Häring a kolektiv autorů LinuxZone

Impossible: Linux Mission 1.0

Obsah •

•

•

1. Úvod • 1.1 Proč zvolit Linux Mission? • 1.2 Co obsahuje Linux Mission 1.0 • 1.3 Požadavky na hardware • 1.4 Obecné poznámky k instalaci 2. Instalace • 2.2 Příprava k instalaci • 2.2 Začínáme • 2.3 Otestování instalačních médií • 2.4 Úvodní obrazovka instalačního programu • 2.5 Volba jazyka pro instalaci • 2.6 Volba klávesnice • 2.7 Volba typu myši • 2.8 Výběr grafické karty a monitoru • 2.9 Výběr typu instalace • 2.10 Rozdělení disku • 2.12 Zavaděč systému • 2.13 Nastavení sítě • 2.14 Nastavení firewallu • 2.15 Podpora dalších jazyků • 2.16 Nastavení časové zóny • 2.17 Nastavení hesla uživatele root • 2.18 Výběr software k instalaci • 2.19 Zahájení instalace • 2.20 Vytvoření zaváděcí diskety • 2.17 Dokončení instalace • 2.17 Problémy při instalaci 3. Softwarový RAID • 3.1 Hardwarové a softwarové implementace RAIDu • 3.2 Teorie fungování RAIDu • 3.2.1 RAID 0 (Nonredundant striped array) • 3.2.2 RAID 1 (Mirrored array) • 3.2.3 RAID 4 (Striped array with parity) • 3.2.4 RAID 5 (Striped array with rotating parity) • 3.2.5 Kombinace více typů polí • 3.2.6 Redundantní pole neznamenají konec záloh • 3.3 Typy polí podporovaných Linuxovým ovladačem RAIDu • 3.4 Konfigurace • 3.5 Obslužný software Raidtools • 3.6 Alternativní obslužný software Mdadm

www.linuxzone.cz strana 2 / 159

Obsah


3.7 Inicializace polí 3.8 Raid autodetect anebo raidstart? • 3.9 RAID superblok • 3.10 Perzistentní superbloky a RAID 0 / linear • 3.11 Monitorování stavu pole • 3.12 Rekonstrukce pole • 3.13 Redundantní pole: výměna disku, hot plug • 3.14 Možnosti rekonfigurace polí • 3.15 Optimalizace polí, výkon 4. LVM Logical Volume Manger (Správa logických oddílů) • 4.1 Teorie fungování LVM • 4.1.1 Mapování svazků • 4.2 Práce s LVM • 4.2.1 Inicializace disků a diskových oddílů • 4.2.2 Vytvoření skupiny svazků • 4.2.3 Vyhledání dostupných skupin svazků • 4.2.4 Aktivace skupiny svazků • 4.2.5 Deaktivace skupiny svazků • 4.2.6 Odstranění skupiny svazků • 4.2.7 Přidání fyzického svazku do skupiny svazků • 4.2.8 Odebrání fyzického svazku ze skupiny svazků • 4.2.9 Vytvoření logického svazku • 4.2.10 Odstranění logického svazku • 4.2.11 Rozšíření (zvětšení) logického svazku • 4.2.12 Redukce (zmenšení) logického svazku • 4.2.13 Získání informací o stavu svazků • 4.3 Instalace Linux Mission s využitím LVM 5. Základní orientace v systému • 5.1 Uživatelé, skupiny a přístupová práva • 5.2 Adresářová struktura v Linuxu: kde, co a jak v systému nalézt • 5.2.1 Standardy FSSTND, FHS • 5.2.2 Hierarchie svazků a adresářová struktura Linuxu • 5.2.3 Nástroje pro vyhledávání • 5.2.4 Rychlé vyhledávání souborů pomocí databáze souborů locate • 5.2.5 Vyhledávání souborů pomocí utility find • 5.2.6 Orientace v systému pomocí databáze RPM • 5.2.7 Prohledávání obsahu souborů grep • 5.2.8Nástroje pro vyhledávání s grafickým rozhraním • 5.3 Jak rozpoznat formát datových či binárních souborů? • 5.3.1 Jak file pracuje? • 5.3.2 Použití v praxi • 5.4 Dokumentace, nápověda 6. Pod pokličkou orientace v systému pro pokročilé • •

•

•

•


Obsah


6.1 Plánování, hierarchie a řízení procesů • 6.1.1 Co je proces? • 6.1.2 Vznik procesu, vykonání programu volání jádra fork() a execve() • 6.1.3 Stavy procesů • 6.1.4 Praxe: monitorování stavu procesů • 6.1.5 Plánování procesů, priorita • 6.1.6 Praxe: nástroje nice a renice pro změnu priority • 6.2 Hierarchie procesů • 6.2.1 Skupiny procesů a sezení • 6.2.2 Praxe: utility nohup, setsid a disown vyjmutí procesu ze sezení • 6.2.3 Řízení procesů, signály • 6.2.4 Praxe: ukončení procesu, nástroj kill pro zasílání signálů procesům • 6.2.5 Praxe: synchronizace rodiče s ukončením potomka • 6.2.6 Praxe: nastavení reakce na signály signal(), sigaction() • 6.2.7 Příkazový interpret a řízení procesů job control • 6.3. Jádro systému a ovladače • 6.3.1 Monolitické nebo modulární jádro? • 6.3.2 Práce s moduly balíček modutils • 6.3.3 Automatické zavádění a odstranění modulů jádrem kmod • 6.3.4 Předávání parametrů ovladačů • 6.4 Proces bootování jádra • 6.4.1 Initrd, prvotní kořenový svazek a skript linuxrc • 6.4.2 Jak vytvořit obraz initrd • 6.4.3 Skript linuxrc, interpret nash • 6.4.4 Změna kořenového svazku change_root nebo pivot_root • 6.4.5 Mkinitrd nástroj pro generování initrd • 6.5 Start systému: jakou roli hraje proces init? • 6.5.1 Inicializace systému, hierarchie procesů • 6.5.2 Úroveň běhu systému (runlevel) • 6.5.3 BSD versus System V • 6.5.4 Konfigurace init v Linuxu Mission • 6.5.5 Konfigurační soubor /etc/inittab • 6.5.6 Startovací skripty rc.sysinit a rc.local • 6.5.7 Definování služeb v jednotlivých úrovních běhu • 6.5.8 Chkconfig zjednodušení manipulace s odkazy • 6.5.9 Nastavení prostředí spouštěných procesů /etc/initrc • 6.5.10 Ovládání initu, přechod z jedné úrovně do druhé 7. Administrace systému • 7.1 Správa software • 7.1.1 Systém RPM • 7.1.2 Přidání / odstranění software dováváného s Linux Mission • 7.1.3 Yum • 7.1.4 Instalace software třetí strany •

•

Obsah



• 7.1.5 Upozornění na dostupnost aktualizací Linux Mission 7.2 Vytváření uživatelů a skupin • 7.3 Konfigurace sítě • 7.4 Konfigurace tisku 8. Grafické rozhraní X Window System • 8.1. Desktop GNOME • 8.1.1 Ovládací a stavový panel GNOME • 8.1.2 Ovládání oken • 8.1.3 Pracovní plocha • 8.1.4 Hlavní menu • 8.1.5 Správce souborů Nautilus • 8.1.6 Odhlášení ze systému • 8.2 Desktop KDE 9. Příkazový interpret Bash: nebojte se příkazové řádky 10. Tip: pracujeme se skenery 11. Tip: pacujeme s digitálním fotoaparátem •

•

• • •


Obsah


Obsah

Znáte LinuxZone.cz? Linuxzone.cz je moderní internetový magazín z prostředí informačních technologií. Zaměřuje se na operační systém GNU/Linux a problematiku svobodného a open source software. Kadý den zde vychází články ze světa GNU/Linuxu, programování, sítí a bezpečnosti, ze kterých čtenáři načerpají aktuální informace a dozví se o nejmodernějších trendech, stejně jako starých a ověřených zkušenostech jiných profesionálů. Portál Linuxzone.cz se zaměřuje na uživatele, administrátory a programátory všech kategorií začátečníky, zkušenějí i znalé profesionály. Kadý z nich si z mnoství článků vybere ten pravý. Kromě řady odborných článků jsou zde k nalezení také oddychové. Například kniní recenze, a to nejen české, ale i zahraniční literatury. Dále můete v archivu článků nalézt kupříkladu herní recenze či románový seriál Gordon, v něm se seznámíte se stejnojmenným hrdinou, počítačovým expertem Gordonem. To vše a ještě mnoho dalšího najdete na portálu Linuxzone.cz http://www.linuxzone.cz/.



Obsah

Využijte služeb Linuxcd.cz Uživatelé, kteří nemají přístup k Internetu budou mít možnost využít služeb portálu LinuxCD (http://www.linuxcd.cz). Na portálu LinuxCD bude možné objednat zaslání CD s aktualizacemi Linux Mission.



Obsah

TuxNET: při pojte se k Internetu a podpořte komunitu! Společnost Impossible provozovatel portálu Linuxzone přichází s možností, jak snadno podpořit českou linuxovou komunitu a free software projekty, které u nás vznikají. Zapojte se i vy! Co je TuxNET? TuxNET je obdobou celé řady existujících nebo nově vznikajících podobných projektů. Jde o vytáčené připojení, respektive poskytnutí zázemí pro jeho využití. To v praxi znamená, že máte k dispozici telefonní číslo, uživatelské jméno a přístupové heslo, s jejichž pomocí se můžete z celého území České Republiky připojit na Internet. Stačí vám k tomu jen obyčejná telefonní linka a modem. Vše je přitom zdarma platíte pouze standardní poplatky Českému Telecomu, nic víc. Samozřejmě se nemusíte nikde registrovat. Přístup na Internet je tedy v tomto ohledu anonymní a nevyžaduje žádné informace o vás, které by mohly být nějakým způsobem zneužity. Proč využívat TuxNET? Podobných poskytovatelů existuje mnoho, proč tedy využít právě TuxNET? Důvod je zřejmý. TuxNET totiž neslouží k obohacování gigantických společností. Výtěžek je použit na podporu a rozvoj české linuxové komunity a podporu free software. Konkrétním příkladem sponzoringu je právě projekt Linux Mission. Zbylé peníze jsou investovány do technického rozvoje služeb, a také do rozvoje portálu Linuxzone a kvality jeho obsahu. Jak využívat TuxNET? Veškeré nezbytné informace naleznete na informační stránce projektu http://tuxnet.linuxzone.cz. Služeb TuxNETu můžete samozřejmě využívat jak v prostředí operačního systému GNU/Linux, tak i MS Windows a všech dalších. Jakékoliv doplňující otázky vám rádi zodpovíme na emailové adrese [email protected].

Provozovatel:

Impossible, s.r.o.

Tel. Číslo:

971 101 203

Login:

linux

Heslo:

linux

Bližší informace:

tuxnet.linuxzone.cz



1. Úvod

1. Úvod 1.1 Proč zvolit Linux Mission? Operační systém Mission je vystavěný na bázi robustního a osvědčeného OS Linux (konkrétně vychází z linuxové distribuce Fedora Core). Na rozdíl od víceúčelových linuxových řešení je operační systém Linux Mission specificky cílený na uživatele desktopu. Mission disponuje vylepšenou interoperabilitou se systémy Microsoft Windows. Vzdálené složky jsou pohodlně dostupné přes položku "Síťové servery" v hlavním menu. Složky a soubory umístěné na počítačích vybavených operačním systémem Linux Mission lze snadno vysdílet tak, že pravým tlačítkem myši klikneme na ikonu daného objektu a v menu vybereme položku "Sdílení". Při prvním použití se automaticky vyvolá konfigurace sítě. Pro lepší interoperabilitu se systémy Microsoft Windows povoluje vestavěný firewall systému Mission provoz sítě Microsoft Windows. Omezení přístupu ke sdíleným soborům je samozřejmě možné nastavit prostřednictvím pomocníka nastavení sítě. Snadnější instalace na počítač, kde je již instalován operační systém Microsoft Windows. Pokud je instalován na jediném diskovém oddíle FAT32 nebo NTFS, instalátor Mission jej sám zmenší a vytvoří místo pro instalaci Linuxu Mission.

1.2 Co obsahuje Linux Mission 1.0? Linux Mission obsahuje předevčím software pro běžné nasazení na desktopu, ale také nástroje pro vývoj aplikací či základní serverový software: • • • • •

• • •

desktopová prostředí GNOME a KDE; kancelářský software: kompletní kancelářský OpenOffice.org 1.1.0 (obsahuje word procesor, tabulkový procesor, prezentace, grafika); internet: webový prohlížeč Mozilla a Konqueror, poštovní klient Evolution, komunikační nástroj gaim (ICQ, Jabber, IRC); práce s grafikou: bitmapový GIMP, Gtkam (podpora digitálních fotoaparátů), Xsane (podpora skenerů); serverové apklikace: webový server Apache s podporou PHP, SSL, MySQL, PostgreSQL, databázové stroje MySQL a PostgreSQL, DNS server (bind), FTP server (vsftpd), poštovní server sendmail; sdílení souborů pro klienty Microsoft Windows (Samba); podporu multimédií; nástroje pro vývoj aplikací (kompilátor, ladicí nástroje, knihovny).



1. Úvod

1.3 Požadavky na hardware • • •

procesor: Intel Pentium a kompatibilní, dop. alespoň 400 MHz paměť: minimum 64 MB, pro komfortní práci doporučeno 256MB místo na disku: instalace na pracovní stanici zabere 1.6 GB místa na disku, minimální instalace 0.5 GB. Kompletní instalace vyžaduje 2.5 GB.

1.4 Obecné poznámky k instalaci K dispozici jsou dva způsoby instalace v grafickém a v textovém režimu. Instalace v textovém režimu se může hodit zejména tehdy, vyskytneli se nějaký problém s detekcí hardware a grafický režim z toho důvodu nelze použít. Oba dva způsoby instalace nabízejí stejnou funkčnost. V průběhu instalace provádíme volby buď myší, anebo pomocí kláves "Tab" a "Enter" ("Tab" a šipky pro výběr voleb a "Enter" pro potvrzení výběru.) Pomocí volby "Další" postupujeme k dalším krokům instalace, pomocí volby "Zpět" se můžeme vrátit nazpět k předchozímu kroku. Také jsou k dispozici klávesové zkratky (vyvoláte je stiskem "Alt" + klávesa). Instalace v grafickém režimu se nejlépe ovládá myší, ale lze si vystačit i bez ní. Po celou dobu instalace se nápověda týkající se aktuálního dění také zobrazuje v levé části obrazovky (pouze v grafickém režimu) a můžeme se jí zbavit stisknutím tlačítka "Skrýt nápovědu". Stručné informace o systému (v angličtině) získáte na počátku instalace stisknutím tlačítka "Poznámky k vydání".

2. Instalace 2.2 Př íprava k instalaci Ujistíme se, že je počítač nastaven tak, že zavede systém z CD nebo DVD (pokud ne, provedeme změnu nastavení pořadí zařízení pro zavedení systému v BIOSu, viz např. následující snímek obrazovky. Nastavení BIOSu vašeho počítače se samozřejmě může lišit od toho vyobrazeného, v tom případě konzultujte příslušnou dokumentaci). Vložíme instalační CD 1 do mechaniky CD ROM a restartujeme počítač. Po restartu by měl systém bootovat z CD / DVD a zahájit instalaci.



2. Instalace

2.2 Začínáme V úvodní obrazovce nás přivítá logo Mission a v dolní části obrazovky úvodní prompt "boot:". Základní nápověda je dostupná stiskem F1 až F4. Ve většině případů zde postačí prostý stisk klávesy "Enter", což obnáší výběr instalace v grafickém režimu. Pro instalaci v textovém režimu bychom zadali "linux text". Pokud bychom měli nějaký při instalaci nepostradatelný hardware, jehož ovladač není v Mission obsažen (např. netypický SCSI řadič, ke kterému máme připojen pevný disk apod.), můžeme využit volbu "linux dd" tím instalačnímu programu sdělíme, že bude potřeba při zahájení instalace natáhnout z diskety potřebný ovladač. Budeme k tomu potřebovat tzv. "driver disk" někteří výrobci hardware jej mají na svých internetových stránkách pro některé linuxové distribuce připravené ke stažení. Pokud ovladač k danému zařízení existuje, ale předpřipravený driver disk nemáme k dispozici, je možné jej sestavit. V takovém případě se požádejte o pomoc zkušeného uživatele anebo se obraťte do konference Linux Mission. Poté je zavedeno jádro systému a proběhne detekce dostupných zařízení.



2. Instalace

2.3 Otestování instalačních médií

Pokud zvolíte "OK", instalační program nejprve zkontroluje obsah instalačních médií. Pokud jste si instalační média stáhli prostřednictvím Internetu a sami vypálili, je vhodné je nechat zkontrolovat vyhnete se případným pozdějším problémům při instalaci. Poté se nastartuje instalační program, což může na slabších počítačích chvíli trvat dole na obrazovce se mezitím objeví hlášení "Running anaconda, the Mission system installer please wait...".

2.4. Úvodní obrazovka instalačního programu



2. Instalace

Nyní máme možnost přečíst si stručné poznámky k této verzi systému Mission (stiskem tlačítka "Poznámky k vydání") a pomocí volby "Další" se přesuneme k další obrazovce, kde pokračujeme výběrem jazyka.

2.5 Výběr jazyka

Nyní volíme jazyk, který se bude používat v průbehu instalace, tedy češtinu a přejdeme na další obrazovku potvrzením volby "Další".



2. Instalace

2.6 Volba klávesnice

Nyní přichází na řadu volba rozložení kláves. Pro českého uživatele přichází v úvahu volby "Czechoslovakian" a "Czechoslovakian (qwertz)" liší se od sebe prohozením umístění písmen "z" a "y".

2.7 Volba typu myši



2. Instalace

Řadu myší je instaleční program schopen sám správně rozpoznat, v takovém případě pouze potvrďte volbu a přejděte na další obrazovku. Pokud používáte myš připojenou k sériovému portu, je potřeba zadat také kokrétní zařízení, ke kterému je připojena (např. portu COM1 v DOSu odpovídá zařízení /dev/ttyS0, portu COM2 odpovídá /dev/ttyS1 apod.). Máteli starší myš vybavenou pouze dvěma tlačíčky, ponechte také zatrhnutou volbu "Emulovat 3 tlačítka". (Pod linuxem se obvykle pracuje se všemi třemi tlačítky myši, u dvoutlačítkové myši pak prostřední tlačítko supluje současný stisk obou tlačítek myši). Pokud se vám stane, že zvolíte špatně a zjistíte, že vám v následující obrazovce myš nefunguje, vraťe se zpět k výběru myši buď pomocí kláves "Tab" a "Enter" anebo pomocí klávesové zkratky "Alt" + "z" a vyberte znovu.

2.8 Výběr monitoru

V podstatě všechny dnešní monitory i grafické karty popdporují standard DDC, který umožňuje automatickou detekci parametrů monitoru. Pokud se vám stane, že váš monitor není detekován správně, máte dvě možnosti. Tou první je ručně projít seznam monitorů známých instalačnímu programu a pokusit se jej najít. Pokud jej v seznamu nenajdete, budete muset sami zadat parametry monitoru. Pod položkou "Generic CRT Display" (používáteli klasický CRT monitor) anebo "Generic LCD Display" používáteli LCD displej zvolíte jeho rozlišení a v dolní části obrazovky můžete zkontrolovat a upravit nastavení horizontálního a vertikálního kmitočtu (tyto údaje naleznete v dokumentaci monitoru, pokud ji nemáte, lze je obvykle dohledat na Internetových stránkách výrobce podle typového čísla monitoru vytištěného na štítku umístěného někde boku nebo zadní straně monitoru). Pokud si nejste těmito parametry jisti, ponechte raději implicitní hodnoty nastavené instalačním programem zejména u staršího hardware by mohlo v případě www.linuxzone.cz strana 15 / 159


2. Instalace

chybného nastavení dojít k poškození monitoru (novější monitory se v takovém případě zpravidla samy vypnou).

2.9 Výběr typu instalace

V tomto kroku volíme typ instalace tedy podle zamýšleného způsobu nasazení systému zvolíme jednu z variant (ovlivní výchozí výběr instalovaného software, výběr software k instalaci lze samozřejmě ještě upravit): • • •

•

osobní systém instalace bude obsahovat vše potřebné pro běžnou práci (grafické prostředí, kancelářský software). pracovní stanice instalace bude obsahovat vše potřebné pro běžnou práci a kromě toho také nástroje pro vývoj aplikací a administraci systémů. server také tato volba mluví sama za sebe. Linux Mission je zaměřen především pro použití na desktopu, ale obsahuje i základní serverový software jako je webový server, databázové stroje SQL, FTP, jmenný či poštovní server. U této varianty se standardně neinstaluje grafické prostředí, ale je možné instalaci grafického prostředí později (při upřesnění výběru software k instalaci) zvolit explicitně. vlastní vhodné pro zkušené uživatele, kteří přesně vědí co od systému chtějí (t.j. jakým způsobem chtějí rozdělit diskový prostor, jaké softwarové balíčky instalovat apod.).



2. Instalace

2.10 Rozdělení disku

Tady se nám nabízí dvě možnosti: buď vše ponechat na instalačním programu, který se pokusí v závislosti na zvoleném typu instalace vytvořit optimální rozdělení disku, anebo to udělat ručně (v tom případě nám pomůže přehledný nástroj Disk Druid). Začínající uživatelé by měli rozhodně využít možnosti automatického rozdělení disku.



2. Instalace

Pokud potvrdíme volbu automatického rozdělení disku, jsme v následujícím kroku dotázáni, zda se mají před instalací Mission • •

•

odstranit všechny existující diskové oddíly, což znamená že o data na nich umístěná nenávratně přijdeme (!), odstranit pouze existující linuxové diskové oddíly t.j. pokud jsme měli instalovanou jinou linuxovou distribuci, kterou nechceme zachovat, o data na těchto linuxových oddílech opět nenávratně přijdeme (!), zachovat všechny stávající diskové oddíly a k instalaci Mission využít pouze volný prostor na disku.

V každém případě máme možnost zvolit disk(y), na které chceme Mission instalovat a kromě toho můžeme zatrhnout volbu "Prohlédnout a případně upravit vytvořené oddíly". Pokud této možnosti využijeme, v následujícím kroku můžeme pomocí nástroje Disk Druid provést úpravy.

Rozhodneteli se pro ruční rozdělení disku, měli byste dodržet následující: • •

•

je vhodné vyhradit menší diskový oddíl speciálně pro svazek /boot (bohatě stačí velikost 50 100 MB); v každém případě musíte označit oddíl, na kterém bude umístěn kořenový svazek /, bez toho není možné pokračovat dále v instalaci. Pokud nebudete definovat další oddíly, měl by být dostatečně velký na to, aby pojal celou instalaci plus místo na data uživatelů; rozhodně byste měli definovat diskový oddíl, který bude sloužit jako odkládací prostor (swap) může klidně zabírat i dvojnásobek fyzické paměti počítače. Swapovat lze samozřejmě i do souboru, který můžete vytvořit později, ovšem swapování do souboru je o něco pomalejší.



2. Instalace

Linux Mission podporuje také softwarový RAID a LVM, potřebné informace stran takové instalace najdete v kapitolách věnovaných speciálně problematice RAIDu a LVM.

2.12 Zavaděč systému Mission obsahuje zavaděč systému GRUB. Standardně bude instalován na MBR (Master Boot Record) prvního pevného disku. Pokud máme kromě Mission instalovány i další operační systémy, můžeme GRUB nakonfigurovat tak, aby nám při startu počítače nabídl možnost výběru operačního systému, který chceme spustit. Ten operační systém, který chceme nechat zavést implicitně, označíme zatrhnutím příznaku "Implicitní". Pokud některý z dalších operačních systémů, které máme instalovány v nabídce není (t.j. instalátor Mission jej sám nedetukuje), můžeme jej ručně přidat pomocí tlačítka "Přidat". Pokud používáme primárně jiný zavaděč systému, můžeme přes volbu "Pokročilé nastavení zavaděče systému" zvolit, kam se bude GRUB instalovat. Pokud chceme pro zavedení systému použít jiný zavaděč než GRUB, můžeme přes volbu "Změnit zavaděč" zvolit variantu "Neinstalovat zavaděč systému". Pak je ale na nás, abychom dotyčný zavaděč nakonfigurovali tak, aby umožnil zavedení systému Mission. Pro vyšší zabezpečení systému je možné zavaděč systému chránit heslem. Standardně je totiž při startu systému možné linuxovému jádru předat určité parametry, které lze použít např. při opravě havarovaného systému, kromě jiného je toho také možné zneužít k obejití standardní startovací sekvence a získat oprávnění privilegovaného uživatele root. Pokud zavaděč ochráníme heslem, nebude bez znalosti hesla možné této možnosti využít.

Poznámka: pokud se chceme účinně bránit proti neoprávněnému vniknutí do systému, měli bychom současně také chránit heslem BIOS počítače a zakázat zavedení systému z jiného média než pevného disku. www.linuxzone.cz strana 19 / 159


2. Instalace

2.13 Nastavení sítě V dalším kroku přichází na řadu konfigurace sítě. Instalátor nám nabídne seznam detekovaných síťových zařízení, standardně je u nich nastaveno získání konfigurace pomocí protokolu DHCP. DHCP je síťový protokol, který umožňuje prostřednictvím DHCP serveru v síti automaticky přidělovat klientům IP adresy a předat další parametry nastavení sítě jako je výchozí brána či servery DNS apod. Pokud DHCP používáte, můžete pokračovat dále. Pokud ne, pomocí tlačítka "Upravit" vyvoláme konfigurační dialog (na obrázku), kde ručně nastavíme parametry síťového rozhraní jako je IP adresa a maska sítě. Taktéž v případě nastavení jména systému zvolíme, zde se nastavuje přes DHCP anebo jej zadáme ručně. V případě, že DHCP nepoužíváme ještě musíme nastavit IP adresy výchozí brány (gateway) a alespoň jeden jmenný server (DNS). Nemámeli otřebné údaje během instalace po ruce, nic se neděje, síť je možné nakonfigurovat později po dokončení instalace.

2.14 Nastavení firewallu Používámeli síťové připojení, rozhodně bychom z důvodů zabezpečení systému měli v následujícím kroku povolit nastavení firewallu. Firewall je v podstatě ochranný filtr, který podle vámi nastavených pravidel filtruje příchozí i odchozí síťový provoz na vašem počítači. Umožňuje odstranit potenciálně nebezpečný provoz a zabránit neautorizovanému přístupu přes síť do vašeho systému (tedy pokud je firewall správně nakonfigurován). Vzhledem k tomu že na veřejné sítě a tedy i na Internet je třeba nahlížet jako na sice užitečné, ale ve své podstatě nedůvěryhodné médium, měl by každý systém, který je k takové síti připojen firewall používat. Linux Mission obsahuje vestavěný kvalitní firewall. Pokud jej zapneme (volba "Povolit firewall"),



2. Instalace

nebude systém akceptovat žádný síťový provoz zvenčí kromě takového provozu, který odpovídá na vámi inicializovaný odchozí provoz. Používáteli počítač jako pouze jako osobní systém a nehodláte na něm provozovat síťové služby, které by měly být zvenčí přístupné, je toto implicitní nastavení firewallu optimální bezpečnou volbou. Pokud hodláte nějaké zvenčí dostupné síťové služby provozovat (např. webový server, FTP server apod.), pak v nastavení firewallu zatrhněte povolení průchodu firewallem pro ty služby, které budete provozovat. Pokud vámi požadovaná služba na seznamu není, využijte políčka "Ostatní porty" (ve formátu jméno_služby:protokol anebo číslo_portu:protokol, tedy např. 5492:tcp). Upozorňujeme, že některé zpřístupnění některých služeb zvenčí s sebou nese určitá bezpečnostní rizika (např. hesla uživatelů v protokolu FTP nebo telnet lze snadno odposlechnout a zneužít k neoprávněnému přístupu do systému, stejně tak špatně nakonfigurovaný SMTP server lze zneužít k rozesílání nevyžádané pošty spamu apod.). Vybraná síťová zařízení také lze označit jako důvěryhodná, což zajistí, že síťový provoz procházející přes tato zařízení nebude firewallem filtrován. Takto je možné nakláldat se síťovými rozhraními, připojených do lokálních, chráněných sítí. Z pochopitelných důvodů se rozhodně nedoporučuje takto označit síťová rozhraní, která jsou přímo připojena do veřejných sítí (internetu).

2.15 Podpora dalších jazyků Nyní je potřeba zvolit jazyk, který bude považován za implicitní pro tento systém. Kromě toho ale můžete instalovat jazykovou podporu i pro další jazyky, mezi kterými je pak možné se za běhu systému přepínat.



2. Instalace

2.16 Nastavení časové zóny V tomto kroku vybereme časovou zónu, ve kterém se nacházíme (buď na mapě, anebo ji nalistujeme v seznamu pro Česko je to volba "Evropa/Praha"). Pokud chceme, aby systém korektně pracoval s letním časem, je vhodné mít hardwarové hodiny nastavené v čase UTC (GMT) a v tom případě zatrhneme volbu "Hardwarové hodiny používají čas v UTC".



2. Instalace

2.17 Nastavení hesla uživatele root Dále je potřeba zadat heslo uživatele root. Uživatel root slouží v systému Mission k administraci systému a má nejvyšší privilegia. I když je možné pod tímto uživatelem v systému normálně pracovat, je z důvodů bezpečnosti žádoucí, abyste okamžitě po dokončení instalace systému založili obyčejný účet nebo účty, které budete používat pro každodenní práci se systémem. Pokud budete uživatelský účet root používat výhradně k administraci systému, ušetříte se tím možnosti nechtěného poškození systému v důsledku překlepu či omylu. Ještě jednou jinými slovy: pokud v systému pracujete jako obyčejný uživatel, můžete v nejhorším poškodit svá osobní data či nastavení systém jako takový zůstává neporušen. Pokud něco smažete či přepíšete jako uživatel root, můžete způsobit nefunkčnost celého systému. Založení uživatelského účtu pro obyčejnou každodení práci se systémem by mělo to první, co po prvním spuštění Linuxu Mission uděláte.

2.18 Výběr software k instalaci Nyní máme možnost ovlivnit výběr software, který bude instalován. Implicitně jsou nastaveny skupiny softwarových balíčků v závislosti na tom, jaký typ instalace jsme zvolili v úvodu instalace (osobní systém, pracovní stanice, server). Chcemeli ponechat implicitní výběr software, zatrhneme volbu "Nainstalovat implicitní balíčky software" a pokračujeme v instalaci.



2. Instalace

V opačném případě, pokud se rozhodneme upravit sadu instalovaných balíčků software, se dostaneme k další obrazovce, kde je dostupný software rozdělen do skupin podle účelu použití. Můžeme volit instalaci jednotlivých skupin balíčků a u každé skupiny můžeme jít ještě o úroveň níže a pomocí tlačítka "Detaily" vyvolat dialog, ve kterém jsou vypsány jednotlivé volitelné aplikace a zde můžeme rozhodnout, které konkrétní aplikace se budou instalovat. Úplně dole na konci seznamu záložka "Různé volby", kde je možné zvolit "minimální" instalaci (tato je použitelná pouze pro určitá speciální nasazení systému, neboť zahrnuje skutečně jen to nejnutnější pro základní běh systému). Naopak zvolením volby "Všechno" zvolíme instalaci veškerého software, který je na instalačních médiích k dispozici.



2. Instalace

Pokud ručně zasahujeme do výběru software, instalační program se postará o kontrolu závislostí a případný potřebný software doplní k instalaci nehrozí tedy, že budeme instalovat produkt X, který ke své funkčnosti vyžaduje software Y, který ale nenainstalujeme.

2.19 Zahájení instalace Nyní máme poslední možnost se ještě vrátit zpět a případně provést změny anebo od instalace systému upustit. Do této chvíle ještě instalátor na disku nic neměnil, potvrzením tohoto kroku již začne instalační program zapisovat operační systém na disk. Pokud chcete instalaci zrušit, vyjměte instalační média a stiskněte Ctrl+Alt+Del, alternativně stiskněte tlačítko Reset počítače.



2. Instalace

V průběhu instalace instalační program vypisuje, které balíčky právě instaluje, ukazuje průběh instalace a očekávanou dobu dokončení instalace. Během instalace můžeme být v závislosti na software zvoleném k instalaci požádáni, abychom vložili další instalační médium.

2.20 Vytvoř ení zaváděcí diskety V závěru instalace máme možnost vytvoření zaváděcí diskety. Této možnosti bychom měli rozhodně využít a disketu uschovat, protože umožňuje zavadení systému např. tehdy, poškodíli se



2. Instalace

instalovaný zavaděč systému na pevném disku. Bez zaváděcí diskety se neobejdeme také v tom případě, pokud jsme v průběhu instalace rozhodli neinstalovat zavaděč na pevný disk. Také se třeba může stát, že jsme zamýšleli využít pro zavedení systému zavaděče systému třetí strany, který ale z nějakého důvodu nebude fungovat.

2.21 Dokončení instalace Nyní už zbývá pouze vyjmout instalační médium a stiskem tlačítka "Restartovat" vyvolat restart počítače (a případně ještě v BIOSu upravit pořadí zařízení, ze kterých počítač zavádí systém tak, aby zavedl OS přednostně z pevného disku).



2. Instalace

2.22 Problémy př i instalaci Pokud při instalaci narazíme na problém, můžou nám v diagnostice příčiny problému pomoci podrobná chybová hlášení, která systém vypisuje na textové konzoli. Mezi konzolemi se lze přepínat následujícím způsobem: • •

• • •

virtuální textová konzole 1: je přístupná stiskem Alt+F1 (Ctrl+Alt+F1 z grafického režimu), zde jsou obecné hlášení a chyby instalačního programu; virtuální textová konzole 2: je přístupná stiskem Alt+F2 (Ctrl+Alt+F1 z grafického režimu) na této konzoli je k dispozici příkazová řádka, kterou zkušený uživatel může využít k ručnímu odstranění problémů; virtuální textová konzole 3: je přístupná stiskem Alt+F3 (Ctrl+Alt+F1 z grafického režimu) tady instalační program vypisuje jednotlivé absolvované kroky; virtuální textová konzole 4: je přístupná stiskem Alt+F4 (Ctrl+Alt+F1 z grafického režimu) na této konzoli nalezneme výpisy a chybová hlášení linuxového jádra; virtuální konzole 7: je přístupná stiskem Alt+F7, na této konzoli běží instalační program.

Nevíteli si s nějakým problémem rady, poznamenejte si pokud možno detailní informace (použitý hardware, podrobný popis problému, chybová hlášení) a obraťte se do diskusního fóra na webových stránkách projektu Linux Mission.



3. Softwarový RAID

3. Softwarový RAID V této části manuálu naleznete informace potřebné pro provozování softwarového RAIDu v systému Linux Mission, včetně specifik instalace systému na RAID zařízení. Tato část je určená pro zkušenější uživatele a předpokládá, že čtenář je již obeznámem s principy fungování OS Linux. Disková pole (RAID) představují možnost jak zvýšit výkon / kapacitu diskového subsystémů anebo posílit jeho odolnost vůči výpadku hardware (redundance). Disková pole lze implementovat čistě na úrovni hardware, ale také softwarové na úrovni OS. Řada dnešních OS obsahuje implementace softwarových variant RAIDu a ani Linux není výjimkou. Cílem této části manuálu je poskytnout přehled o možnostech, stabilitě a výkonu softwarového RAIDu pod OS Linux Mission. Podívejme se tedy na principy fungování RAIDu, výhody / nevýhody softwarového RAIDu ve srovnání s hardwarovými řešeními, implementace RAIDu pod Linuxem, obslužný software, možnosti autodetekce a automatické sestavení poli jádrem, možnosti rekonfigurace polí pomocí nástroje raidreconf a optimalizace polí. Softwarový RAID je cenově lákavou alternativou nákladných hardwarových řešení. Další výhodou je flexibilita (např. možnost sestavení pole v degradovaném režimu, možnost eventuální částečné záchrany dat v případě výpadku celého pole, protože je známá struktura dat v diskovém poli, konverze RAID svazků z jednoho typu RAIDu na jiný). Některé z těchto možností (např. zmíněná možnost konverze jednoho typu RAIDu na jiný pomocí utility raidreconf) jsou ale spíše experimentálního rázu. Softwarový RAID je náročnější na systémové prostředky než čistě hardwarová řešení, s dnes běžných výkonnými procesory je obvykle softwarový RAID výrazně rychlejší než hardwarové varianty. Je tedy na adminstrátorovi, aby zvážil výhody a nevýhody sofwarového či hardwarového RAIDu vzhledem k aktuálním podmínkám.



3. Softwarový RAID

3.1 Hardwarové a softwarové implementace RAIDu RAID lze provozovat v podstatě dvojím způsobem. Buď je realizován v hardwaru, což obnáší speciální řadič osazený procesorem a zpravidla vybavený vlastní pamětí, která slouží jako cache. Veškeré funkce RAIDu plní řadič a z pohledu operačnímu systému se chová jako jediný disk. Tato řešení bývají poměrně drahá (Mylex, DPT nyní Adaptec, ICP Vortex, velcí výrobci PC jako HP, IBM, Compaq apod. mají své vlastní implementace). Předností hardwarových řešení bývá maximální spolehlivost a ve srovnání se softwarovou variantou RAIDu dovedou odlehčit zátěži systému. RAID ovšem také může být realizován patřičným ovladačem na úrovni operačního systému a spousta operačních systémů to také dnes umožňuje. Toto řešení může být za jistých okolností flexibilnější a rychlejší, ale také náročnější na systémové prostředky zejména na čas procesoru. V posledních letech se setkáváme i s napůl hardwarovými/softwarovými implementacemi RAIDu, kdy hardware obsahuje jen minimální podporu a většinu práce dělá ovladač; zatímco dříve existovaly hardwarové řadiče RAIDu pouze v provedení SCSI, nyní jsou dostupné také řadiče s rozhraním IDE (3ware, Promise a další). Tyto varianty jsou levné, ale řada produktů této kategorie je nevalné kvality a výkonu. Dále se budeme zabývat pouze softwarovým RAID pod Linuxem.

3.2 Teorie fungování RAIDu Dříve než se zaměříme na detaily implementace softwarového RAIDu pod Linuxem, podíváme se na princip fungování jednotlivých typů RAIDu a jejich vlastnosti.

3.2.1 RAID 0 (Nonredundant striped array) Tento typ je určen pro aplikace, které vyžadují maximální rychlost a není redundantní. Naopak je potřeba vzít v úvahu, že pravděpodobnost výpadku takového pole roste s počtem disků. Ideální použití představují audio/video streamingové aplikace, eventuálně databáze a obecně aplikace, při kterých čteme sekvenčně velká množství dat. Základní jednotkou pole je tzv. stripe (z angl. "stripe", česky pruh), což je blok dat určité velikosti (běžně 44096 kB v závislosti na aplikaci). Po sobě jdoucí data jsou pak v poli rozložena střídavě mezi disky do "stripů" takovým způsobem, aby se při sekvenčním čtení/zápisu přistupovalo ke všem diskům současně. Tím je zajištěna maximální rychlost jak při čtení tak i zápisu, ale současně je tím dána také zranitelnost pole. Při výpadku kteréhokoliv disku se stávají data v podstatě nečitelná (respektive nekompletní). RAID 0 bývá označován rovněž jako striping. Protože není redundantní, má nejvýhodnější poměr cena/kapacita. Počet disků je libovolný. Je ovšem třeba pamatovat na to, že s rostoucím počtem disků v poli roste i pravděpodobnost výpadku pole (protože výpadek libovolného disku znamená havárii celého pole); RAID 0 je tedy velmi rychlý, ale méně bezpečný než samostatný disk.



3. Softwarový RAID

3.2.2 RAID 1 (Mirrored array) RAID 1 je naopak maximálně redundantní. Rychlost čtení může být oproti samostatnému disku výrazně vyšší, rychlost zápisu je stejná jako u samostatného disku. Funguje tak, že data jsou při zápisu "zrcadlena" na všechny disky v poli (tedy v případě RAIDu 1 tvořeného dvěma disku jsou data duplikována apod.). Při čtení lze využít vícero kopií dat a podobně jako u RAIDu 0 číst za všech disků současně. (Tedy abychom byli přesní, ne tak docela. Pokud bychom chtěli na RAIDu 1 při sekvenčním čtení "stripovat" stejně jako u RAIDu 0, museli bychom číst data ze zrcadlených disku ob jeden sektor na zrcadlech totiž máme kompletní data a nevyhneme se tedy přesunům hlaviček disku. Proto nárůst výkonu nebude tak dramatický, jako u RAIDu 0). Tento typ pole je určen pro aplikace s důrazem na maximální redundanci. Výhodou tohoto redundantního řešení je stabilní výkon i v případě výpadku disku, nevýhodou je poměr cena/kapacita. Počet disků bývá buď 2 anebo libovolný, čím větší počet disků, tím větší redundance a odolnost proti výpadku.



3. Softwarový RAID

3.2.3 RAID 4 (Striped array with parity) Raid 4 je redundantní pole, které se dnes již používá málo. Jeho nástupcem je RAID 5, který je výkonnější. Funguje tak, že jeden disk je vyhrazen jako tzv. paritní disk. Na paritním disku je zaznamenán kontrolní součet (operace XOR přes data stejné pozice jednotlivých disků). Pokud tedy dojde k výpadku některého z datových disků, lze data rekonstruovat z dat zbylých disků a parity uložené na paritním disku. RAID 4 je odolný vůči výpadku libovolného jednoho disku a má tedy příznivý poměr cena/kapacita. Paritní disk ale představuje úzké hrdlo této architektury při zápisech, protože každý zápis znamená také zápis na paritní disk. Mimimální počet disků je 3.



3. Softwarový RAID

3.2.4 RAID 5 (Striped array with rotating parity) Tento typ poskytuje redundanci vůči výpadku libovolného jednoho disku s dobrým poměrem cena/kapacita a výkonem. RAID 5 je vylepšená varianta RAIDu 4 v tom, že parita není uložena na jednom vyhrazeném disku, ale je rozmístěna rovnoměrně mezi všemi disky pole, čímž se odstraní úzké hrdlo architektury RAIDu 4.



3. Softwarový RAID

Paritu lze spočítat buď tak, že skutečně načteme a XORujeme data z odpovídajících datových stripů všech disků (takto se parita počítá při inicializaci pole, vyžaduje to tedy přístup ke všem diskům). Ve druhém případě načteme původní data z datového stripu, která se mají změnit, provedeme XOR s novými daty a výsledek ještě XORujeme s původní hodnotou parity (takto se parita počítá na již inicializovaném běžícím poli). Zápis dat tedy představuje dvoje čtení (dat a parity), výpočet parity a dvojí zápis (opět dat a parity). Počet přístupů na disk při zápisu je v tomto případě konstantní bez ohledu na počet disků v poli přistupuje se vždy ke dvěma diskům a to také má za následek nižší výkon tohoto typu pole ve srovnání s redundantním RAIDem 1.



3. Softwarový RAID

V degradovaném režimu (degradovaný režim znamená stav, kdy je některý z disků z pole vyřazen kvůli hardwarové chybě) se pak musejí data uložená na vadném disku odvodit z dat zbývajících disků a parity. Na rozdíl od redundantního RAIDu 1, kde výpadek disku obvykle neznamená výrazný pokles výkonu, vykazuje RAID 5 v degradovaném režimu výrazně snížený výkon zejména při čtení. Minimální počet disků pro tento typ diskového pole jsou 3.



3. Softwarový RAID

3.2.5 Kombinace více typů polí Z definic výše popsaných typů polí vyplývá, že redundantní pole nejsou tak rychlá, jak bychom si mohli přát a naopak u RAIDu 0 nám chybí redundance. Existuje ovšem možnost, jak výhody jednotlivých typů diskových polí spojit. Tato metoda spočívá ve vytvoření kombinovaných polí, kdy disky v poli určitého typu jsou samy tvořeny poli jiného typu. Příkladem může být např. RAID 1+0, kdy jsou pole typu RAID 1 dále sloučeny do RAIDu 0. Takové pole je pak redundantní (toleruje výpadek až dvou disků), rychlejší zejména v zápisech než samotný RAID 1, a má lepší poměr cena/kapacita než RAID 1 (velikost je zde n/2 * disk a minimální počet disků je pak 4. Další možností je třeba RAID 0+1, RAID 5+0, RAID 5+1 apod.

3.2.6 Redundantní pole neznamenají konec záloh Redundantní disková pole jsou odolná pouze vůči výpadkům určitého počtu disků. Neochrání před výpadkem napájení, poškozením souborového systému při pádu celého systému nebo chybou administrátora systému. Proto je potřeba myslet i na další metody ochrany dat např. na záložní zdroje napájení (UPS), žurnálovací souborové systémy apod. a v každém případě pravidelně zálohovat.

3.3 Typy polí podporovaných Linuxovým ovladačem RAIDu Až doposud jsme se zabývali pouze teorií fungování diskových polí, podívejme se tedy jak to vypadá se softwarovým RAIDem v Linuxu. Softwarová implementace RAIDu pod OS Linux podporuje 5 typů diskových polí: •

• • • •

Linear: toto v podstatě není RAID, jedná se o možnost "pospojování" více disků do jednoho. Co se týče rychlosti, neliší se příliš od výkonu samostatných disků. Není redundantní, výhodou však je např. oproti RAIDu 0 to, že se v případě havárie jednoho z disků dají data ze zbývajících disků snáze obnovit, protože se nestripuje. RAID 0: zde je volitelná velikost stripu; tato výrazně (v závislosti na aplikaci) ovlivňuje výkon RAIDu. RAID 1: oproti klasické definici RAIDu 1 kdy se disky spojují pouze do párů, pod Linuxem můžeme vytvořit RAID 1 i z více než dvou aktivních disků. RAID 4: je sice implementován, ale funkčně nahrazen RAIDem 5 RAID 5: opět je zde volitelná velikost stripu, která ovlivňuje výkon RAIDu.

3.4 Konfigurace Pro konfiguraci softwarového RAIDu se používá konfigurační soubor /etc/raidtab, ve kterém se používají následující direktivy: •

raiddev: touto direktivou definice pole začíná, následuje označení pole. Svazky www.linuxzone.cz strana 36 / 159


• • •

• • •

• • • • •

3. Softwarový RAID

softwarového RAIDu se označují md1, md2 atd. raid-level: následuje direktivu raiddev, uvádíme zde typ pole (1 pro linear, 0 pro RAID 0, 1 pro RAID 1, 5 pro RAID 5). persistent-superblock: tato direktiva bude popsána níže, týká se kompatibility se starší verzí RAIDu. chunk-size: velikost stripu, maximální velikost je 4MB (což je dáno konstantou MAX_CHUNK_SIZE ovladače, kvůli eventuální změně by bylo nutné provést úpravu ve zdrojovém kódu a znovu sestavit linuxové jádro), udává se v kB. nr-raid-disks: zde uvádíme kolik diskových oddílů bude součástí pole. nr-spare-disks: počet rezervních disků v poli direktiva device jméno_oddílu následovaná jednou z direktiv raid-disk, sparedisk, parity-disk nebo failed-disk: tyto direktivy deklarují příslušné oddíly, které budou součástí pole. raid-disk: tento oddíl bude aktivním oddílem. spare-disk: tento oddíl bude sloužit jako rezervní. parity-disk: tento oddíl bude sloužit jako paritní disk (RAID 4). failed-disk: tento oddíl bude při inicializaci pole přeskočen (má význam pouze při sestavování pole v egradovaném stavu, viz diskuse níže). parity-algorithm: specifikuje schéma rozložení parity u RAIDu 5 (možnosti jsou: left symmetric, rightsymmetric, rightasymmetric; z podporovaných je obecně nejrychlejší left symmetric).

3.5 Obslužný software Raidtools Balíček raidtools obsahuje obslužné utility nezbytné k manipulaci s diskovými poli: • • • •

• •

•

mkraid: pro inicializaci polí; raidstart: pro spouštění diskových polí; raidstop: pro vypnutí diskových polí; raidhotadd: přidá nový diskový oddíl do aktivního diskové pole (náhradou za vadný oddíl, pokud jsou všechny oddíly pole funkční, přidá nový oddíl jako rezervní "spare disk"). Nelze tedy použít pro rozšíření kapacity pole; raidhotremove: odejme vadný diskový oddíl z~aktivního diskového pole; raidsetfaulty: označí funkční diskový oddíl jako vadný, tím umožní jeho odejmutí z pole příkazem raidhotremove (možné využití např. při testování nebo výměnách funkčních disků); raid0run: utilita pro spouštění starších polí typu linear nebo RAID 0 bez perzistentních superbloků (viz níže "Perzistentní superbloky a RAID 0 / linear").

Poznámka na vysvětlenou: Soubor raidtab odráží konfiguraci polí v době jejich sestavení, ovšem pokud třeba později vyměníme nebo přesuneme některé disky, nemusí již odrážet skutečnou konfiguraci. Pokud tedy z nějakého důvodu potřebujeme pole znovu inicializovat anebo ho jen startujeme pomocí raidstart, nesmíme zapomenout soubor raidtab ručně upravit, abychom www.linuxzone.cz strana 37 / 159


3. Softwarový RAID

se ušetřili v budoucnu nepříjemností.

3.6 Alternativní obslužný software Mdadm K balíčku raidtools existuje další alternativa tou je utilita mdadm. Tato utilita nemusí používat žádný konfigurační soubor, vše potřebné lze zadat na příkazové řádce, anebo to zjistí analýzou RAID superbloků uložených na discích (podobně funguje automatické startování polí jádrem při bootu). Cílem autora je tedy přidat výhody a robustnost, kterou poskytuje vlastnost samosestavení diskových polí jádrem a zárověň se vyhnout potenciálním konfliktům mezi neaktuální konfigurací v souboru raidtab a skutečnou konfigurací polí, ke kterým někdy může dojít, pokud používáme raidtools. Nástroj mdadm je velmi flexibilní a stabilní, takže jeho vyzkoušení/použití lze pro zkušené uživatele doporučit.

3.7 Inicializace polí Jakmile máme odpovídajícím způsobem rozdělené disky a připravený konfigurační soubor / etc/raidtab, můžeme pole inicializovat utilitou mkraid, která pole sestaví a aktivuje. Pokud zakládáme pole s perzistentními RAID superbloky (což je obvyklé, pole bez persizstentních superbloků jsou poporována jen z důvodu zpětné kompatibility viz níže), pak mkraid vypíše i pozici RAID superbloků: # mkraid

/dev/md5

handling MD device /dev/md5 analyzing super-block disk 0: /dev/sda7, 20163568kB, raid superblock \ at 20163456kB disk 1: /dev/sdb7, 20163568kB, raid superblock \ at 20163456kB

Po úspěšné inicializaci bychom měli v souboru /proc/mdstat, který obsahuje informace a aktivních polích, vidět odpovídající záznam, např: # cat /proc/mdstat Personalities : [raid0] [raid1] [raid5] read_ahead 1024 sectors md0: active raid1 sdb1[1] sda1[0] 131968 blocks [2/2] [UU]

Poté nám nic nebrání pole zformátovat např. pomocí mkfs.ext3, pokud chceme na poli provozovat žurnálovací souborový systém ext3. Utilita mkfs pro souborový systém ext2 respektive ext3 akceptuje volbu R stride=X, která udává kolik bloků souborového systému obsahuje 1 "stripe" pole. Tím pádem je také vhodné zadat ručně velikost bloku (parametr -b). Např. mějme pole typu



3. Softwarový RAID

RAID 0 s velikostí stripu 16 kB. Pokud budeme chtít použít velikost bloku souborového systému 4 kB, zadáme: mkfs.ext3 /dev/md0 -b 4096 -R stride=4

3.8 Raid autodetect anebo raidstart? Nyní tedy máme funkční diskové pole. Zbývá vyřešit způsob, jakým se bude pole vypínat při vypnutí systému a zapínat při startu systému. Jednou možností je použití utilit raidstart a raidstop. Tuto možnost využívají startovací skripty Linuxu Mission (ze skriptu / etc/rc.d/rc.sysinit je raidstart volán automaticky, existujeli soubor / etc/raidtab a raidstop je volán ze skriptu /etc/rc.d/init.d/halt.). Druhou, robustnější metodou je využití možnosti automatické aktivace polí jádrem při bootu. Aby mohla fungovat, je potřeba v prvé řadě používat perzistentní RAID superbloky a všechny diskové oddíly, které jsou součástí polí, musejí být v tabulce oddílů označeny jako typ "Linux raid autodetect", (tedy hodnota 0xfd hexadecimálně) a samozřejmě mít v jádře zapnutou podporu autodetekce RAID polí. Výhodou tohoto řešení navíc je, že jakmile je diskové pole inicializováno, nepoužívá se již pro opětovný start nebo zastavení pole konfigurační soubor /etc/raidtab. O sestavení a spuštění pole se postará ovladač RAIDu, který na všech diskových oddílech typu "Linux raid autodetect" vyhledá RAID superbloky a na základě informací v RAID superblocích pole spustí. Stejně tak ovladač RAIDu všechny pole korektně vypne v závěrečné fázi ukončení běhu systému poté, co jsou odpojeny souborové systémy. I v případě změny jmen disků nebo po přenesení disků na úplně jiný systém tedy pole bude korektně sestaveno a nastartováno. Pokud bychom chtěli používat tuto možnost, museli bychom upravit startovací skripty systému (v krátkosti: ve sktripu linuxrc ramdisku initrd je třeba spustit raidautorun a v rc.sysinit zakomentovat volání raidstart, podrobnosti viz manuálové stránky nash, initrd). Kromě toho ještě existuje další možnost, jak systému při startu sdělit, jakým způsobem má pole sestavit a to pomocí parametru jádra md přes prompt zavaděče systému.

3.9 RAID superblok Každý diskový oddíl, který je součásti raid svazku (výjimku tvoří pouze svazky bez perzistentních superbloků, viz níže) obsahuje tzv. RAID superblok Tento superblok je 4kB část RAID oddílu vyhrazená pro informace o příslušnosti daného oddílu k určitému poli a o stavu pole. Prohlédnout si jej můžeme např. pomocí utility mdadm. Pokud ji nemáme k dispozici, vypomůžeme si utilitou od (spuštěnou s vhodnými parametry, např. od -Ax -tx4) poté, co si jej příkazem dd někam zkopírujeme. Pro kontrolu, superblok vždy začíná magickým číslem 0xa92b4efc. www.linuxzone.cz strana 39 / 159


3. Softwarový RAID

Superblok obsahuje zejména následující informace: • • • • • • • • • • • •

verzi ovladače raidu, kterým byl vytvořen, jedinečný identifikátor pole, typ RAIDu, datum vytvoření RAID svazku, počty disků (aktivních, rezervních apod.), preferované vedlejší číslo RAID zařízení, stav pole, kontrolní součet superbloku, počet updatů superbloku, datum posledního updatu superbloku, velikost stripu, informace o stavu jednotlivých diskových oddílů.

3.10 Perzistentní superbloky a RAID 0 / linear Pokud provozujeme pole RAID 0 či linear, máme možnost zvolit variantu bez použití perzistentního superbloku. Volba persistent-superblock 0, znamená, že se RAID superblok nebude ukládat na disk. Tato možnost existuje z důvodů zachování kompatibility s polemi zřízenými pomocí starší verzí ovladače RAIDu, které superbloky nepoužívaly. Po vypnutí takového pole nezůstane na svazku informace o konfiguraci a stavu pole. Proto je tato pole nutné vždy znovu inicializovat při každém startu buď utilitou mkraid, nebo pomocí utility raid0run (což je pouze symbolický odkaz na mkraid) a nelze pak využít automatického startování polí jádrem při bootu. Poznámka: Na tuto volbu je třeba dávat pozor při konfiguraci pokud při konfiguraci pole RAID 0 direktivu persistentsuperblock vynecháme, použije se standardní hodnota 0, tedy pole bez perzistentních superbloků, což zpravidla není to, co zamýšlíme!

3.11 Monitorování stavu pole Aktuální stav diskových polí zjistíme vypsáním souboru /proc/mdstat. První řádek obsahuje typy polí, které ovladač podporuje (záleží na konfiguraci jádra). U jednotlivých RAID svazků je pak uvedeno které diskové oddíly svazek obsahuje, velikost svazku, u redundantních polí pak celkový počet konfigurovaných oddílů a z toho počet funkčních, následovaný schématem funkčnosti v hranatých závorkách. Následující příklad uvádí stav funkčního pole RAID 1: md0: active raid1 hdc1[1] hda1[0] 136448 blocks [2/2] [UU] Druhý příklad uvádí stav pole RAID 1 po výpadku jednoho disku, oddíl sdc1 je označen jako nefunkční (F=Failed místo čísla aktivního oddílu): md0: active raid1 sdc1[F] sdd1[0] 8956096 blocks [2/1] [U_]



3. Softwarový RAID

Třetí příklad ukazuje stav pole RAID 1, kdy probíhá rekonstrukce: md1: active raid1 hdc2[1] hda2[0] 530048 blocks [2/2] \ [UU] resync=4\% finish=6.7min

Součástí raidtools bohužel není samostatná utilita k monitorování stavu diskových polí, takže si administrátor musí vypomoci skriptem, který je pravidelně spouštěn zc cronu a kontroluje / proc/mdstat (jednoduše např. tak, že si skript na disk uloží obsah /proc/mdstat nebo jeho MD5 součet a následně kontroluje, jestli se /proc/mdstat změnil; v případě změny pak prostřednictvím emailu uvědomí administrátora). Další možnost je filtrovat systémový log. Napoak pohodlným způsobem umí monitorovat stav RAID polí nástroj mdadm (včetně možnosti zasílání zpráv emailem).

3.12 Rekonstrukce pole Redundantní typy polí je třeba po inicializaci, po výměně disku, nebo po automatickém nahrazení vadného disku rezervním (viz direktiva spare-disk v /etc/raidtab) rekonstruovat či synchronizovat. Ve všech případech systém rekonstrukci spouští automaticky. Průběh rekonstrukce je možné sledovat v /proc/mdstat (viz příklad o několik řádek výše). Rekonstrukce probíhá s nízkou prioritou, nezabere tedy čas procesoru na úkor jiných aplikací, ale bude se snažit využít maximální prostupnosti I/O zařízení. Proto můžeme po dobu rekonstrukce pozorovat zpomalení diskových operací. Maximální rychlost rekonstrukce ovšem také lze ovlivnit nastavením limitu v / proc/sys/dev/raid/speed-limit-max, výchozí hodnota je 100 kB/sec. Ovladač RAIDu umí současně spustit rekonstrukci na několika polích současně. Pokud jsou však oddíly jednoho disku součástí více polí, které by se měly synchronizovat současně, provede se synchronizace polí postupně (z důvodu výkonnosti). V systémovém logu se pak objeví neškodné hlášení typu "XX has overlapping physical units with YY": md: syncing RAID array md1 md: minimum _guaranteed_ reconstruction speed: 100 KB/sec. md: using maximum available idle IO bandwith for \ reconstruction. md: using 128k window. md: serializing resync, md2 has overlapping physical \ units with md1! md: md1: sync done. md: syncing RAID array md2 md: minimum _guaranteed_ reconstruction speed: 100 KB/sec. md: using maximum available idle IO bandwith for \ reconstruction. md: using 128k window. md: md2: sync done.



3. Softwarový RAID

V /proc/mdstat jsou ty svazky, na kterých je rekonstrukce pozastavena, označeny jako plně funkční, ale je u nich poznámka resync=DELAYED: Personalities : [linear] [raid0] [raid1] [raid5] read_ahead 1024 sectors md2 : active raid1 hdc3[1] hda3[0] 530048\ blocks [2/2] [UU] resync=DELAYED md1 : active raid1 hdc2[1] hda2[0] 530048\ blocks [2/2] [UU] resync=4\% finish=6.7min md0 : active raid1 hdc1[1] hda1[0] 136448\ blocks [2/2] [UU]

3.13 Redundantní pole: výměna disku, hot plug Pokud při čtení nebo zápisu na některý z diskových oddílů, který je součástí redundantního diskového pole, dojde k chybě, je dotyčný oddíl označen jako vadný a pole jej přestane používat. Pokud máme v daném diskovém poli zařazen jeden nebo více rezervních disků (direktiva sparedisk), je tento v případě výpadku automaticky aktivován, systém provede rekonstrukci pole a průběh rekonstrukce zaznamená do systémového logu. V opačném případě pole zůstane v provozu v degradovaném režimu, pak to v systémovém logu bude vypadat zhruba takto: kernel: SCSI disk error : host 0 channel 0\ id 4 lun 0 return code = 28000002 kernel: [valid=0] Info fld=0x0, Current sd08:11:\ sense key Hardware Error kernel: Additional sense indicates\ Internal target failure kernel: scsidisk I/O error:\ dev 08:11, sector 2625928 kernel: raid1: Disk failure on sdb1,\ disabling device. kernel: Operation continuing on 1 devices kernel: md: recovery thread got woken up ... kernel: md0: no spare disk to reconstruct\ array! - continuing in degraded mode kernel: md: recovery thread finished ...

Příjemnou vlastností diskových polí je také možnost výměny disku za chodu systému. Samozřejmě k tomu potřebujeme v prvé řadě hardware, který to umožňuje. Ovladače slušných SCSI řadičů umožňují přidávání či ubírání zařízení, to ale samo o sobě nestačí. Je zapotřebí používat SCA disky určené pro hot swap a odpovídající SCSI subsystém s SCA konektory a elektronikou, která zajistí stabilitu SCSI sběrnice při odebírání či přidávání zařízení. Existují také některé řadiče disků na bázi IDE, které hot swap podporují. Mějme pole typu RAID 1, ve kterém došlo k chybě na oddílu sdc1. Disk sdc1 je připojen ke kanálu 0 SCSI řadiče 0 a má ID rovno 4:



3. Softwarový RAID

md0: active raid1 sdc1[F] sdd1[0] 8956096 blocks [2/1] [U_]

Jak tedy probíhá výměna vadného disku SCSI, mámeli ktomu potřebné hardwarové vybavení: • •

• • • • •

provedeme raidhotremove /dev/md0 /dev/sdc1, což vyřadí vadný oddíl z pole md0, provedeme příkaz echo "scsi remove-single-device 0 0 4 0" >/proc/scsi/scsi, ovladač SCSI řadiče zapomene na zařízení na řadiči 0, kanálu 0, ID 4, LUN 0, vyjmeme vadný disk sdc, vložíme nový disk sdc, dále vykonáme příkaz echo "scsi add-single-device 0 0 4 0" >/proc/scsi/scsi, což nový disk zpřístupní systému, pomocí utility fdisk vytvoříme diskové oddíly, vykonáme raidhotadd /dev/md0 /dev/sdc1, čímž přidáme oddíl sdc1 nového disku do pole md0 a na pozadí se spustí rekonstrukce pole.

Pokud nemáme hardware potřebný k hotswap výměně disků, musíme se smířit s vypnutím systému, výměnou vadného disku a opětovným zapnutím systému. Potom stačí pouze vytvořit např. pomocí nástroje fdisk odpovídající diskové oddíly a příkazem raidhotadd je zařadit do diskového pole. Jinak příkazy pro přidávaní a ubírání SCSI zařízení jsou popsány ve zdrojovém kódu jádra (soubor linux/drivers/scsi/scsi.c).

3.14 Možnosti rekonfigurace polí Pro offline konverzi jednoho typu RAIDu do jiného lze použít nástroj raidreconf. Tento nástroj je ovšem stále ještě ve vývoji a není zcela stabilní, použití zálohy dat je v tomto případě nutností. Změnímeli velikost diskového pole, musíme pak ještě upravit velikost souborového systému (pokud používáme souborový systém ext2/ext3, můžeme použít utilitu resize2fs). Utilita raidreconf není standardní součástí Mission, je třeba ji získat z internetu.

3.15 Optimalizace polí, výkon Výkon diskových polí velmi záleží na vhodně zvolené velikosti stripu (to je samozřejmě aplikovatelné u polí RAID 0 a RAID 5). Jak jsem již zmínil, také souborový systém ext3 lze optimalizovat pro užití na diskovém poli; nástroji mkfs pro zakládání ext2/ext3 souborových systémů lze pomocí volby -R stride=XX zadat, kolik bloků souborového systému odpovídá velikosti stripu. Vhodným nástrojem pro testování propustnosti I/O subsystému jsou nástroje bonnie++, tiotest a další. Pokud jde o srovnání rychlosti softwarového RAIDu a hardwarových řešení, softwarový RAID je oproti hardwarové implementaci samozřejmě náročnější na systémové prostředky (což vzhledem k www.linuxzone.cz strana 43 / 159


3. Softwarový RAID

rychlosti dnešních procesorů nebývá problém), ale na druhou stranu bývá mnohdy rychlejší (výrazně rychlejší bývá zejména RAID 0).

4. LVM Logical Volume Manager (Správa logických oddílů) Kromě RAIDu linuxové systémy disponují ještě jednou vymožeností, která může uživatelům značně zpříjemnit život. Jedná se o LVM (Logical Volume Manager), který představuje alternativu ke klasickému rozdělování diskového prostoru. Výhodou použití LVM je např. to, že logické svazky lze (na rozdíl od použití klasických diskových oddílů) za chodu systému zvětšovat / zmenšovat, případně i přesouvat. Asi nejlepší způsob, jak výhody LVM prezentovat, je ukázat to na příkladu. Dejme tomu, že se při instalaci systému rozhodneme rozdělit disk určitým způsobem: vyhradíme si diskový oddíl pro svazek /boot, další pro kořenový svazek /, dále pro odkládací oddíl (swap) a také pro svazek / home s uživatelskými daty. Po nějaké době zjistíme, že se nám ve svazku připojeném jako /home nedostává místa, zatímco v kořenovém svazku ještě máme prozatím místa dost. V této chvíli máme několik možností, např: • • • •

můžeme systém přeinstalovat s jiným rozdělením disku, můžeme offline pomocí vhodných nástrojů (tedy např. nabootovat nějakou záchrannou distribuci) přesouvat data a upravovat velikost diskových oddílů a souborových systémů, můžeme v kořenovém svazku vytvořit nějaký adresář, do něhož se budeme někde z /home odkazovat symblickým odkazem a další uživatelská data budeme ukládat sem, můžeme si přikoupit další disk a připojit jej někam do /home.

Všechna tato řešení ale nejsou dvakrát pohodlná a tak či tak nám po nějaké době dojde místo pro změnu v kořenovém svazku a problém budeme řešit znovu. Pokud bychom používali LVM, situace by byla mnohem jednodušší. Ve chvíli, kdy nám ve svazku /home dojde místo zatímco ve svazku / máme místa habaděj, můžeme přímo za chodu systému svazek / zmenšit a o ušetřené místo rozšířit /home. Tedy žádné složité laborování s diskovými oddíly nebo dokonce reinstalace systému. Stejně tak po přikoupení dalšího disku můžeme libovolně svazky / nebo /home rozšířit o prostor nového disku. LVM se samozřejmě velmi hodí a často bývá nasazován hlavně tam, kde spravujeme rozsáhlý diskový prostor, ale jak demonstruje výše uvedený příklad, můžeme jej směle využít i na domácím systému. LVM lze také kombinovat se softwarovým RAIDem.



4. LVM Logical Volume Manager (Správa logických oddílů)

4.1 Teorie fungování LVM Nejprve je potřeba seznámit se s terminologií LVM: • •

•

•

•

volume group (skupina svazků VG): je nejvyšší administrativní jednotka v rámci LVM. Obsahuje fyzické a logické svazky. V systému může existovat více skupin svazků. physical volume (fyzický svazek PV): může to být pevný disk, diskový oddíl, ale třeba i zařízení RAID. Z jednoho nebo více fyzických svazků se následně vytváří skupiny svazků (VG). logical volume (logický svazek LV): obdoba diskového oddílu ze systémů, kde se nepoužívá LVM. Je k dispozici jako blokové zařízení, na které můžeme umístit soubrový systém. Je na adminstrátorovi kolik logických svazků a jaké velikosti uvnitř dané skupiny svazků (VG) vytvoří. Tyto logické svazky pak lze za běhu systému podle potřeby zvětšit nebo zmenšit. physical extent (PE): Každý fyzický svazek je rozdělen do menších částí, označovaných jako "physical extent" (typická velikost PE může být např. 32 MB). Určuje granularitu, s jakou je v rámci skupiny svazků rozdělován diskový prostor. V rámci jedné skupiny svazků mají všechny fyzické svazky stejnou velikost PE. logical extent (LE): Obdobě logický svazek sestává z menších částí, označovaných jako "logical extent". V rámci jedné skupiny svazků mají všechny logické svazky stejnou velikost LE, která je současně shodná s velikostí PE fyzických svazků.

Celé to pak může vypadat např. takto: mějme k dispozici dva disky (hda a hdc), na každém vytvoříme jeden diskový oddíl zabírající celý disk (hda1 a hdc1). Z obou diskových oddílů vytvoříme fyzické svazky (PV) a začleníme je do skupiny svazků pojmenované "mygroup". V rámci této skupiny svazků, která zahrnuje veškerý prostor obou dvou disků pak vytvoříme podle potřeby logické svazky (LV), na které umístíme jednotlivé souborové systémy: "rootlv" pro připojení na /), "varlv" pro připojení na /var, "usrlv" pro připojení na /usr a "homelv" pro připojení na /home.




4.1.1 Mapování svazků Při vytváření logických svazků můžeme zvolit, jakým způsobem se budou mapovat LE na PE. Můžeme zvolit buď lineární mapování, kdy jsou řazeny za sebou nejprve PE prvního fyzického svazku a teprve potom následují PE dalšího fyzického svazku (podobně jako o softwarového RAIDu typu linear). Tento případ také ilustruje první obrázek (výše). Alternativou je "stripování", které je jakousi obdobou softwarového RAIDu 0 (s tím, že granularita stripování je u softwarového RAIDu jemnější a tedy nárůst výkonnosti větší). V tomto případě se PE jedotlivých fyzických svazků střídají. Následující obrázek ukazuje situaci, kdy je v případě logického svazku "homelv" použito stripování.




4.2 Práce s LVM Teorii LVM máme ve stručnosti úspěšně za sebou, takže se můžeme pustit do praxe a seznámit se s jednotlivými nástroji pro adminstraci LVM.

4.2.1 Inicializace disků a diskových oddílů K tomu, abychom mohli používat disk (případně diskový oddíl nebo jiné blokové zařízení např. RAID) jako fyzický svazek (PV) v rámci LVM, musíme jej nejprve inicializovat. K tomu slouží utilita pvcreate, pokud bychom chtěli inicializovat jako PV diskový oddíl hda1, spustili bychom ji jednoduše takto: pvcreate /dev/hda1

Poznámka: pokud bychom chtěli jako PV inicializovat celý disk (např hdc) a pvcreate by to odmítal s tím, že disk obsahuje tabulku rozdělení disku, můžeme tabulku rozdělení disku přepsat pomocí utility dd a následně si vynutit znovunačtení tabulky rozdělení disku pomocí utility blockdev (ovšem je třeba si dát pozor na to, zda opravdu pracujeme se správným diskem jinak si připravíme horké chvilky při obnovování tabulky rozdělení disku): dd if=/dev/zero of=/dev/hdc bs=1k count=1 blockdev --rereadpt /dev/hdc




4.2.2 Vytvoř ení skupiny svazků Pro vytvoření skupiny svazků (VG) slouží nástroj vgcreate. Pokud bychom chtěli vytvořit skupiny svazků nazvanou "mygroup" obsahující dva fyzické svazky hda1 a hdc1, učinili bychom to takto: vgcreate mygroup /dev/hda1 /dev/hdc1

Můžeme přitom také zadat velikost PE (výchozí hodnota je 32 MB) a to pomocí přepínače -s.

4.2.3 Vyhledání dostupných skupin svazků Při startu systému je potřeba vyhledat dostupné skupiny svazků, což zařídí spuštění přikazu vgscan. Proto tento příkaz najdeme také ve startovacích skriptech systému.

4.2.4 Aktivace skupiny svazků Při startu systému je pak pro aktivaci již existující skupiny svazků ještě potřeba spustit vgchange -a y jméno_skupiny

Prosté spuštění vgchange -ay bez uvedení jména skupiny svazků aktivuje všechny dostupné skupiny svazků (tímto příkazem se skupiny svazků aktivují při startu systému ze startovacích skriptů systému poté, co byly pomocí vgscan vyhledány dostupné skupiny svazků).

4.2.5 Deaktivace skupiny svazků Pro deaktivaci skupiny svazků spustíme příkaz: vgchange -a n jméno_skupiny

Analogicky prostým spuštěním vgchange -a n bez uvedení jména skupiny svazků vypneme všechny skupiny svazků.

4.2.6 Odstranění skupiny svazků Nejprve musíme danou skupinu svazků deaktivovat příkazem vgchange -a n jméno_skupiny a poté ji můžeme odstranit spuštěním: vgremove jméno_skupiny




4.2.7 Přidá ní fyzického svazku do skupiny svazků K přidání fyzického svazku (PV) do skupiny svazků (VG) slouží příkaz vgaextend: vgaextend jméno_skupiny jméno_svazku

4.2.8 Odebrání fyzického svazku ze skupiny svazků Analogicky k odebrání fyzického svazku (PV) ze skupiny svazků (VG) slouží příkaz vgreduce: vgreduce jméno_skupiny jméno_svazku

4.2.9 Vytvoř ení logického svazku Pro vytvoření logického svazku slouží příkaz lvcreate. Při zakládání logického svazku musíme specifickovat jeho velikost, což můžeme učinit dvěma způsoby: bud uvedeme velikost zadáním počtu LE (velikost LE je totožná s velikostí PE v rámci dané skupiny svazků), anebo zadáme velikost v jednotkách MB nebo GB. Kromě velikosti také máme možnost zvolit způsob mapování fyzických svazků uvnitř zakládaného logického svazku (lineární nebo stripování) a pokud se rozhodneme pro stripování, pak i velikost stripu. Následující příkaz vytvoří logický svazek "testlv" ve skupině svazků "mygroup" o velikosti 100MB, fyzické svazky budou mapovány lineárně: lvcreate -L100 -ntestlv mygroup

Následující příkaz vytvoří logický svazek "testlv" ve skupině svazků "mygroup" který bude obsahovat 100 LE (velikost logického svazku tedy bude rovna 100 x velikost LE), uplatní se stripování: lvcreate -l100 -i2 -ntestlv mygroup

4.2.10 Odstranění logického svazku Před odstraněním logického svazku se ujistíme, že není používán (případně jej odpojíme příkazem umount, t.j. např. umount /dev/mygroup/testlv). Poté jej můžeme odstranit příkazem lvremove: lvremove /dev/mygroup/testlv




4.2.11 Rozšíře ní (zvětšení) logického svazku Při rozšiřování logického svazku máme několik možností, jak rozšíření specifikovat můžeme zadat o jaké množství diskového prostoru chceme svazek zvětšit anebo můžeme přímo zadat jeho novou velikost. Následující příkaz rozšíří logický svazek "testlv" o 1 GB: lvextend -L+1G /dev/mygroup/testlv

Následující příkaz rozšíří logický svazek "testlv" na celkovou velikost 10 GB: lvextend -L10G /dev/mygroup/testlv

Tím to ovšem nekončí zatím jsme pouze upravili velikost logického svazku, ale velikost souborového systému, který se něm nacházá je stále stejná. Postup se liší pro jednotlivé typy souborových systémů. Pokud používáme souborový systém ext2/ext3, použijeme utilitu resize2fs. K tomu musíme souborový systém nejprve dočasně odpojit (příkazem umount / dev/mygroup/testlv), poté jej rozšířit tak, aby zaplnil celý zvětšený logický svazek (resize2fs /dev/mygroup/testlv) a poté jej můžeme opět připojit (mount / dev/mygroup/testlv). Zdá se vám to zbytečně složité? Existuje i jednodušší varianta existuje utilita e2fsadm, která nahradí spouštění lvextend a resize2fs (stále ale musíme souborový systém před jejím použití odpojit). Pro online zvětšení (tedy bez nutnosti odpojovat souborový systém) souborového systému reiserfs slouží utilita resize_reiserfs, v případě souborového systému xfs použijeme xfs_grows, souborový systém jfs pouze znovu připojíme pomocí mount -o remount,resize.

4.2.12 Redukce (zmenšení) logického svazku LVM samozřejmě umožňuje také logické svazky zmenšovat. V tomto případě ještě předtím, než logický svazek zmenšíme, musíme zmenšit souborový systém, který se na něm nachází. Na to pozor, protože pokud na to zapomeneme a zmenšíme logický svazek aniž bychom předtím zmenšili souborový systém, velmi pravděpodobně přijdeme o některá data, která na něm byla uložena! Pokud používáme souborový systém ext2/ext3, nejprve jej odpojíme příkazem umount / dev/mygroup/testlv, potom jej zmenšíme příkazem resize2fs / dev/mygroup/testlv 524228, pak teprve zredukujeme vlastní logický svazek příkazem lvreduce -L-1G /dev/mygroup/testlv a nakonec je opět připojíme příkazem mount / dev/mygroup/testlv. Všimněme si, že utilitě resize2fs zadáváme novou velikost souborového systému v blocích. Také v tomto případě si můžeme postup zjednodušit použitím utility e2fsadm. Pokud používáme souborový systém reiserfs, je třeba jej před zmenšením také odpojit, následně jej www.linuxzone.cz strana 50 / 159



zmenšit pomocí resize_reiserfs a opět připojit. Souborové systémy xfs a jfs zmenšovat nelze.

4.2.13 Získání informací o stavu svazků K prohlížení informací o skupině svazků (VG) slouží utilita vgdisplay. Analogicky k prohlížení informací konkrétním o fyzickém svazku (PV) slouží utilita pvdisplay: pvdisplay jméno_fyz_svazku vgdisplay jméno_skupiny

4.3 Instalace Linux Mission s využitím LVM Pokud se rozhodneme pro instalaci Mission na LVM, musíme vzít na vědomí jednu věc a tou je skutečnost, že zavaděč systému LVM přímo nepodporuje. Řešení je jednoduché, prostě vyhradíme jeden malý regulérní diskový oddíl pro připojení /boot a zbytek systému včetně kořenového svazku již můžeme instalovat na LVM.

Příklad: máme k dispozici dva disky (hda a hdc). Nejprve založíme klasický diskový oddíl hda1 dejme tomu o velikosti 50 MB, který bude připojen jako /boot. Veškeré zbývající místo prvního disku využijeme pro druhý diskový oddíl hda2, který poslouží jako fyzický svazek (PV). Na druhém disku můžeme vyhradit diskový oddíl hdc1 jako swap a zbývající místo využijeme pro druhý oddíl hdc2, který využijeme jako další fyzický svazek (PV). Oba fyzické svazky začleníme do skupiny svazků (VG), kterou nazveme třeba "missionvg" a prostor rozdělíme mezi logické




svazky (LV) "rootlv" pro připojení jako kořenový svazek /, "usrlv" pro připojení jako /usr a "homelv" pro připojení jako /home. Nemusíme přitom hned rozdělit veškeré volné místo v rámci skupiny svazků, část můžeme ponechat volnou pro pozdější rozšíření logických svazků.

Zavaděč instalujeme na MBR prvního disku a zadáme, že jako kořenový svazek má připojit zařízení /dev/missionvg/rootlv.



5. Základní orientace v systému

5. Základní orientace v systému 5.1 Uživatelé, skupiny a př ístupová práva Linux je víceuživatelský systém a nelze v něm pracovat bez toho, abychom použili uživatelský účet. Každému uživateli musí administrátor systému uživatelský účet (což je privilegovaný uživatel nazvaný "root", který existuje vždy) vytvořit, teprve potom se může uživatel do systému přihlásit. Přístupové heslo uživatele "root" jste nastavili již v průběhu instalace systému, jen znovu připomenu, že tento účet byste z bezpečnostních důvodů měli používat opravdu jen k administraci systému a pro běžnou práci používat obyčejný uživatelský účet. Vytvoření obyčejného uživatelského účtu vám Mission také automaticky nabídne při prvním spuštěním systému. Každý uživatel je v systému identifikován jedinečným číslem UID (UserID) tím si ale začínající uživatel nemusí lámat hlavu, protože většina systémových nástrojů a rozhraní umí pracovat přímo s uživatelskými jmény tak a o mapování uživatelských jmen na UID se postará systém sám. Uživatele je možné v systému seskupovat do skupin, což má smysl při uplatňování přístupových práv. Např. mámeli několik uživatelů, kteří potřebují sdílet určitá data, ale tato data současně nemají být přístupná ostatním uživatelům, vytvoříme pro ně společnou skupinu a přístupová práva k souborům nastavíme odlišně pro příslušníky skupiny a zbytek světa. S přístupovými právy můžeme manipulovat např. prostřednictvím správce souborů kliknutím pravým tlačítkem myši na vybraný objekt a zvolením položky "Vlastnosti" v menu otevřeme dialog, ve kterém přes záložku "Oprávnění" můžeme prohlížet nebo měnit prístupová práva k objektu.




Vidíme, že systém rozlišuje tři skupiny práv: • • •

práva vlastníka práva skupiny práva pro všechny ostatní

U každé z těchto skupin práv můžeme přidělit nebo odebrat práva pro: • • •

čtení zápis spouštění

Samozřejmě ne všechny kombinace nastavení práv jsou smysluplná. Nastavujemeli např. práva pro spustitelný soubor, nestačí přidat jen práva ke spouštění, je také potřeba, aby bylo možné daný objekt číst. Přidělímeli obyčejnému souboru právo pro zápis, ale už ne právo pro čtení, bude sice možné soubor přepsat, ale nebudeme jej moci otevřít. Trošku jinak je to s právy u adresářů (složek). Adresáře samozřejmě nelze spouštět, v tomto případě přidělení práva pro spouštění znamená, že lze adresář otevřít. Přidělení práva pro čtení u adresáře znamená, že lze vypsat jeho obsah. Přidělení práva pro zápis u adresáře znamená, že v něm lze vytvářet nové objekty nebo naopak objekty mazat. Z toho plyne, že je např. možné adresáři přidělit právo ke spouštění (t.j. lze do něj vstoupit), ale současně odebrat právo ke čtení uživatel pak do adresáře může vstoupit, ale neuvidí jeho obsah.




Ještě důležitá poznámka: při rozhodování o povolení nebo zamítnutí přístupu systém zkouší uplatnit práva v pořadí práva vlastníka, poté práva skupiny a nakonec práva pro zbytek světa. Ale pokud je uživatel vlastníkem objektu, práva pro skupiny nebo ostatní se už neuplatní. Pokud uživatel není vlastníkem objektu ale je členem odpovídající skupiny, uplatní se práva pro skupinu, ale neuplatní se již práva pro ostatní. Teprve v případě, kdy uživatel není ani vlastníkem objektu ani členem příslušně skupiny, uplatní se práva pro ostatní. Jinými slovy, pokud si např. vlastník nastaví k objektu právo ke čtení pro "ostatní", ale nepřiděli si právo pro čtení pro sebe jako vlastníka nebo člena skupiny, je sice vlastníkem objektu (t.j. může měnit jeho přístupová práva), ale nemůže objekt přečíst. Z příkazové řádky lze k prohlížení práv použít příkaz ls, výpis o bsahu adresáře může vypadat např. takto: [dave@mission celkem 152 drwxr-xr-x 2 drwxr-xr-x 2 drwxr-xr-x 2 -r--r--r-- 1 lrwxrwxrwx 1 drwxr-xr-x 2 drwxr-xr-x 4 drwxr-xr-x 2

vmware-tools-distrib]$ ls -l dave dave dave dave dave dave dave dave

dave 4096 srp 9 23:07 bin dave 4096 srp 9 23:08 doc dave 4096 srp 9 23:07 etc dave 126164 srp 9 23:08 FILES dave 11 srp 11 18:16 INSTALL -> doc/INSTALL dave 4096 srp 9 23:07 installer dave 4096 srp 9 23:07 lib dave 4096 srp 9 23:07 sbin

Přístupová práva jsou v levé části výpisu, první písmeno označuje typ objektu ("d" pro adresář, "" pro obyčejný soubor, "l" pro symbolický odkaz) a pak již následují tři trojice symbolů práv v pořadí vlastník, skupina, ostatní: • • •

r: právo čtení w: právo zápisu x: právo spouštění

Pokud je právo přiděleno, vidíme příslušný symbol, pokud je na daném místě pomlčka, právo přiděleno není. Pro změnu nastavení práv y příkazové řádky lze použít utilitu chmod (podrobnosti viz programová dokumentace).

5.2 Adresářová struktura v Linuxu: kde, co a jak v systému nalézt "Kam jsem ten soubor asi tak mohl uložit?" nebo "Určitě jsem to už instaloval, ale kam?" to jsou otázky, které si snad každý uživatel počítače s železnou pravidelností klade. Operační systémy samozřejmě poskytují řadu nástrojů, které hledání potřebného souboru či dat usnadňují. V tomto článku si nejprve osvětlíme uspořádání souborových systémů a obvyklou adresářovou strukturu, www.linuxzone.cz strana 55 / 159



která je v linuxových distribucích zavedena a následně si pak představíme několik nástrojů, které můžeme využít k vyhledávání uložených souborů či dat.

5.2.1 Standardy FSSTND, FHS I když mezi jednotlivými linuxovými distribucemi existují drobné rozdíly, většinou se přidržují standardů, které byly vytvořeny za účelem sjednocení adresářové struktury mezi distribucemi. Jako první vzniknul standard FSSTND (Linux Filesystem Structure, poslední verze je FSSTND 1.2), který je nyní nahrazen novějším standardem FHS (Filesystem Hierarchy Standard, aktuální verze je FHS 2.2). Uživatel proto nebude mít při přechodu z jedné linuxové distribuce na druhou problémy s orientací v systému, protože základní části jsou stejné.

5.2.2 Hierarchie svazků a adresář ová struktura Linuxu Zatímco uživatelé operační systémů z dílny Microsoftu jsou zvyklí pracovat odděleně s jednotlivými diskovými oddíly (které jsou označované velkými písmeny abecedy, např. "C:", "D:"), v Linuxu je tomu jinak. Diskové oddíly, které obsahují souborový systém (tzv. svazky), tvoří hierarchii na jejímž vrcholu je tzv. kořenový svazek (root, označovaný znakem "/"). Ostatní svazky jsou pak připojeny na zvolené adresáře v kořenovém svazku atd. atd., čímž vzniká hierarchie souborových systémů. Z pohledu uživatele je to velmi pohodlné, protože uživatel vidí jediný adresářový strom a vůbec se nemusí starat o to, na kterých diskových oddílech je co uloženo. Zatímco je jednodušší instalovat celý systém na jediný svazek (/), existují také rozumné důvody, proč instalaci rozložit na více svazků. Je to o něco bezpečnější a v případě počítačových sítí oddělením dat týkajících se konfigurace systému (a tudíž specifických pro jednotlivé počítače) od dat neměnných (která mohou být společná) si usnadníme sdílení dat mezi počítači. Z těchto důvodů mohou být adresářové stromy /var, /home, /boot, /usr či /tmp instalovány na oddělené svazky, toto rozdělení také závisí na volbě typu instalace optimální rozdělení bude jiné v případě instalace typu pracovní stanice a jiné bude v případě instalace serveru. Záleží také na uživateli / administrátorovi systému, zda upřednostní pohodlí anebo o něco větší robustnost. V případě desktopu nebo domácích systémů si s tím ale nemusíme lámat hlavu, instalace, kdy je zvlášť vyčleněn pouze svazek /boot a zbytek systému je umístěn na jednom svazku je v těchto případech zcela vyhovující. Podívejme se nyní, jak taková běžná adresářová struktura v linuxovém systému vypadá a charakterizujme jednotlivé adresáře: / |-|-|-|-|-|-|--

bin boot dev etc home initrd lib

(root) (základní příkazy a nástroje) (soubory potřebné pro zavedení systému) (soubory speciálních zařízení, "device files") (konfigurace systému, nelze sdílet) (domovské adresáře uživatelů) (přípojný bod, používá se při bootu systému) (základní sdílené knihovny a moduly jádra)



|-|-|-|-|-|-|-|-`--

mnt misc opt proc sbin tmp usr var root

•

•

• • •

• • • •

• •

• •


(přípojný bod) (součást autofs) (instalace doplňkového software) (přípojný bod pro systém procfs jádra) (systémové utility nezbytné pro běh systému) (pro vytváření dočasných pracovních souborů) (běžné aplikace) (proměnlivá data) (domovský adresář uživatele root)

/ (root): tento svazek nelze sdílet, obsahuje minimum potřebné k inicializaci systému do té míry, aby mohly být připojeny ostatní souborové systémy, provedena kontrola / oprava souborových systémů nebo obnova systému ze zálohy a konečně obashuje vše potřebné k běhu systému v jednouživatelském režimu. /bin: základní systémové nástroje které se uplatní při zavádění systému (např. utilita mount pro připojování svazků apod.) a utility, které běžně používají i obyčejní uživatelé (např. mkdir, cp, příkazové interprety bash apod.). /boot: tento adresář (často na odděleném svazku) obsahuje soubory pro zavedení systému jako je obraz jádra, pomocné soubory zavaděče systému apod. /dev: obsahuje speciální soubory reprezentující zařízení. Obvykle také obsahuje skript MAKEDEV, který slouží k vytváření souborů zařízení. /etc: tento adresář obsahuje konfigurační soubory a nelze jej sdílet. Jsou zde např. soubory fstab (informace o tom, jaké svazky se mají připojit a kam), passwd a shadow (definují seznam uživatelů systému a jejich přístupová hesla), group (definuje skupiny uživatelů), inittab (konfigurace programu init, který řídí start systému) a řadu dalších. /home: tento adresář obsahuje domovské adresáře uživatelů a často bývá na odděleném svazku. initrd: tento adresář se používá výhradně jako dočasný přípojný bod při bootu, přepojuje se na něj prvotní kořenový svazek . /lib: obsahuje základní sdílené knihovny potřebné pro běh programů v /bin, /sbin a moduly jádra (/lib/modules). /mnt: slouží jako přípojný bod pro svazky, které nejsou trvale připojeny, často obsahuje podadresáře pro připojování disket (/mnt/floppy) nebo médií CD/DVD (/mnt/cdrom) apod. /misc: tento adresář používá automounter (nástroj pro automatické připojování souborových systémů) /opt: do tohoto adresáře se instaluje software, který není součástí distribuce. V minulosti se takto používal adresář /usr/local. Také tento adresář je mnohdy umístěn na odděleném svazku. /proc: tento adresář slouží jako přípojný bod pro pseudosouborový systém jádra procfs. Pokud jej používáme nalezneme v něm informace o konfiguraci a stavu systému. /sbin: systémové nástroje které se uplatní při zavádění či konfiguraci systému, na rozdíl od nástrojů umístěných v /bin nejsou určeny pro běžné používání obyčejnými uživateli (např. nástroje pro formátování disků fdisk, zakládání nebo opravu souborových systémů



• •

•

•


mke2fs a e2fsck, nástroje pro konfiguraci sítě apod.) /tmp: tento adresář slouží k vytváření dočasných pracovních souborů, obvykle je pravidelně automaticky promazáván a také může být instalován na odděleném svazku. /usr: zde jsou instalovány další aplikace a nástroje, které jsou součástí distribuce, ale které nejsou nezbytné pro start systému či běh v jednouživatelském režimu. Obsahuje mimo jiné podadresáře bin, sbin, lib podobně jako kořenový svazek, grafické rozhraní X Window System je instalováno v /usr/X11 apod. Protože je rozsáhlý a obsahuje data, která se při provozu systému nemění, lze jej s výhodou sdílet. /var: tento adresář obsahuje data, která se během provozu systému mění a nelze jej sdílet. Obsahuje např. podadresář log, ve kterém se nachází systémové logy, podadresář spool, který obsahuje tiskové fronty nebo fronty zpráv elektronické pošty, schránky elektronické pošty uživatelů apod. Často bývá instalován na odděleném svazku. /root: domovský adresář uživatele root.

5.2.3 Nástroje pro vyhledávání Pokud jde o nástroje pro vyhledávání souborů, můžeme si vybrat mezi nástroji s grafickým rozhraním a nástroji pro příkazovou řádku. Nejprve se budeme zabývat nástroji pro příkazovou řádku tady si můžeme vybrat mezi nástroji, které přímo procházejí souborový systém (find) a nástroji, které pracují s databází jmen souborů (locate). Nástroje, které pracují s databází jmen souborů jsou samozřejmě rychlejší a hodí se zejména v případech, kdy se stav souborového systému příliš němění.

5.2.4 Rychlé vyhledávání souborů pomocí databáze souborů locate Tento nástroj funguje tak, že si v pravidelných, administrátorem stanovených intervalech buduje databázi jmen souborů, ve které pak můžeme hledat bez toho abychom se zdržovali znovu a znovu procházením souborového systému. Jedná se o standardní součást linuxových distribucí a je obvykle nastaven tak, aby se databáze iniciovala jednou denně (zpravidla v noci, k inicializaci databáze slouží příkaz updatedb, který je spouštěn z cronu). Administrátor má možnost zvolit, které části souborového systému se budou indexovat (volby -u, -U) a které se mají naopak vynechat ( volby -e, --prunepaths), databáze je standardně ukládáná do souboru / var/lib/locatedb. Administrátor obvykle z bezpečnostních důvodů nechá indexovat pouze ty části systému, které používají všichni uživatelé systému. Příkaz pro inicializaci databáze může vypadat např. takto (vynecháme pracovní adresáře, přípojné body floppy a cdrom umístěné pod /mnt, a přípojné body síťových a speciálních souborových systémů): /usr/bin/updatedb -f "nfs,smbfs,ncpfs,proc,devpts" \ -e "/mnt,/tmp,/var/tmp,/usr/tmp"




Celé to ovšem nemusíme vymýšlet, protože Mission je již nakonfigurován tak, že jednou denně tuto databázi aktualizuje (viz skript /etc/cron.daily/slocate.cron). Na víceuživatelském systému je také vhodné vynechat domovské adresáře (/home), aby se v databázi neobjevily názvy důvěrných dokumentů apod. Chcemeli pak nalézt soubor např. soubor který obsahuje řetězec "resolver", spustíme locate jednoduše takto (jinak locate umí vyhledávat i podle regulárních výrazů, slouží k tomu volba -r): [dave@azucar dave]$ locate resolver /var/cache/man/cat3/resolver.3.gz /var/cache/man/cat5/resolver.5.gz /usr/share/man/man3/resolver.3.gz /usr/share/man/man5/resolver.5.gz /usr/bin/resolve_stack_dump /usr/bin/resolveip

Uživatelé si pak mohou vytvářet vlastní databáze třeba svých domovských či pracovních adresářů (volba -o nebo --output při vytváření databáze specifikuje, kam se má výsledná databáze uložit namísto standardního /var/lib/locatedb a volba -d umožní pro vyhledávání zvolit jinou databázi než tu standardní ve /var/lib/locatedb). Např. příkazem updatedb -U ~ -o ~/locate.db

vygenerujeme databázi souborů našeho domovského adresáře, která bude uložena v domovském adresáři v souboru locate.db a pokud v ní budeme chtít hledat, spustíme locate s volbou -d ~/locate.db.

5.2.5 Vyhledávání souborů pomocí utility find Nástroj locate je sice rychlý, ale protože používá databázi jmen souborů, nepracuje s aktuálním stavem souborového systému a tudíž není použitelný v případě kdy pracujeme se souborovým systémem, na kterém soubory často vytváříme nebo mažeme a také neumožňuje hleddání na základě vlastností souborů (např. typ souboru, datum změny, přístupu apod.). Standardní součástí linuxových distribucí je utilita find, která umí soubory hledat nejen podle jména, ale i podle času modifikace souboru, přístupu k souboru, modifikace iuzlu souboru, typu souboru, počtu odkazů, přístupových práv, provádět různé testy, vyhodnocovat výrazy apod. Možností je celá řada a proto je zde nebudeme popisovat, podrobné informace o používání uživatel nalezne v manuálové stránce programu. Příkaz find také umí provádět nad nalezenými soubory zadanou akci. Pro ilustraci zde uvedu jen jednoduchý příklad. Následující příklad se pokusí v adresáři /etc nalézt soubor, jehož jméno začíná na "resolv" a pokud jej nalezne, spustí ls l pro vypsání informací o souboru:




[root@mission /]# find /etc -name '*resolv*' -exec ls -l {} \; -rw-r--r-- 2 root root 0 srp 3 04:16 /etc/resolv.conf -rw-r--r-- 1 root root 0 čec 23 17:04 /etc/resolv.conf.bak

5.2.6 Orientace v systému pomocí databáze RPM Linux Mission používá obdobně jako linuxové distribuce Red Hat Linux, SUSE Linux či Mandrake Linux ke správě balíčků systém RPM (Red Hat Package Manager). Pokud potřebujeme zjistit, ke kterému balíčku daný soubor patří, spustíme rpm s volbami -qf. Např. chcemeli vědět, kam patří nástroj /bin/cp, spustíme rpm takto: [dave@mission dave]$ rpm -qf /bin/cp fileutils-4.0.36-4

Pro prohlížení obsahu nainstalovaných balíčků slouží volby -qil. RPM je sofistikovaný systém a umožňuje spustu dalších věcí týkajících se správy balíčků, to už ale není předmětem tohoto článku další informace čtenář nalezne v manuálové stránce programu rpm.

5.2.7 Prohledávání obsahu souborů grep Nástroje, které jsme doposud zmínili, umožňovali hledat soubory podle jejich názvu či vlastností. Uživatel ovšem často potřebuje hledat na základě obsahu souboru. To už ale s adresářovou strukturou linuxových systémů nesouvisí, takže zde pouze v krátkosti představíme balíčky grep a rgrep, které slouží k vyhledávání souborů na základě výskytu řetězců, které obsahují. Balíček grep obsahuje tři nástroje: • • •

grep: hledání pomocí regulárních výrazů fgrep: jednoduché a rychlé hledání bez použití regulárních výrazů egrep: hledání pomocí rozšířených regulárních výrazů

Chcemeli např. zjisti, které ze souborů s příponou ".conf" umístěných v adresáři /etc obsahují řetězec "root", spustíme grep takto: [root@mission etc]# grep -l root /etc/*.conf /etc/gpm-root.conf /etc/grub.conf /etc/ldap.conf /etc/logrotate.conf /etc/nscd.conf /etc/sensors.conf /etc/smartd.conf /etc/warnquota.conf




Utilita grep a její varianty umí také rekurzivně procházet adresáře, což je rychlejší, než kdybychom k rekurzivnímu prohledávání adresářů použili kombinaci příkazů find a grep. K rekurizvnímu prohledávání slouží volba -r.

5.2.8 Nástroje pro vyhledávání s grafickým rozhraním Také zde máme k dispozici několik nástrojů. V hlavním menu desktopu GNOME prostřednictvím položky "Hledat soubory" vyvoláme grafické rozhraní, ve kterém můžeme hledat soubory podle jména, ale také vyhledat soubory obsahující určitý text apod.

Zatrhnemeli volbu "Zobrazit více možností", můžeme vybírat další kritéria hledání, která můžeme libovolným způsobem kombinovat (viz tlačítka "Odstranit a "Přidat").

Z hlavního menu můžeme také přes položky "Internet" > "Další aplikace pro Internet" > "Internetový prohlížeč Konqueoror" spustit aplikace Konqueror, která zdaleka není jen webovým prohlížečem. Z nabídky "Nástroje" Konqueroru pak vyvoláme dialog "Najít soubor".




Také tady můžeme hledat soubory podle názvu, ale prostřednictvím záložky "Obsah" lze vyhledat soubory obsahující určitý text a konečně v záložce "Vlastnosti" můžeme hledat podle data, vlastníka souboru atd.

5.3 Jak rozpoznat formát datových či binárních souborů? V řadě operačních systémů tradičně slouží k rozpoznání typu či formátu souboru jeho přípona. Na základě přípon ve jménech souborů jsou také často přiřazovány vazby mezi typy souborů a aplikacemi, které s těmito soubory pracují a uživatelé jsou na používání přípon k rozlišení typů souborů či formátu dat zvyklí. Spoléhání se na přípony v názvech souborů ale může někdy být ošidné např. v souvislosti s existencí velkého množství virů šířených elektronickou poštou, které pro zamaskování manipulují s příponami souborů. Linuxové systémy ovšem disponují šikovným nástrojem file, který lze s výhodou použít pro rozpoznání typu či formátu souboru na základě jeho obsahu.




5.3.1 Jak file pracuje? Jedná se o nástroj pro příkazovou řádku, v nejjeddnodušším případě jej spustíme pouze se zadáním jména nebo jmen souboru, jehož typ či formát neznáme. Pro ilustraci si uveďme malý příklad: [dave@azucar dave]$ file * R-1.5.0-1.i386.rpm: RPM v4 bin i386 R-1.5.0-1 test: ASCII mail text test.html: HTML document text agt.zip: Zip archive data, at least v2.0 to extract linuxzone: directory xsane.png: PNG image data, 896 x 650, 8-bit colormap,\ non-interlaced

Utilita file provádí tři druhy testů: nejdříve zjistí pomocí volání jádra stat() o jaký typ souboru se jedná (obyčejný soubor, adresář, pojmenovaná roura, symbolický odkaz apod.). Pokud se jedná o obyčejný soubor, zkoumá jej dále a snaží se odhadnout formát souboru, tedy zda se jedná o spustitelný program a jaký, skript, nebo zda se jedná o datový soubor (např. obrázek ve formátu GIF, PostScriptový soubor atd.). Používá přitom databázi uloženou zpravidla v souboru /usr/share/magic, tato databáze obsahuje seznam běžně užívaných formátů spolu s určitou "značkou" (angl. magic), která je pro daný formát typická. Pod značkou si představme určitou pro daný formát typickou sekvenci znaků, která se vždy nachází na stejném místě od počátku souboru. Tímto způsobem lze popsat většinu datových formátů, se kterými se můžeme běžně setkat. Např. nahlédnemeli do souboru / usr/share/magic a vyhledáme definici formátu GIF, uvidíme zhruba následující: # GIF 0 string >4 string >4 string >6 leshort >8 leshort [ zkráceno ]

GIF8 7a 9a >0 >0

GIF image data \b, version 8%s, \b, version 8%s, %hd x %hd,

To znamená, že pokud soubor na počátku (pozice 0) obsahuje řetězec "GIF8", dále podle řetězce na pozici 4 rozlišíme, zda se jedná o verzi 87a nebo 89a a na offsetech 6 a 8 jsou uloženy rozměry obrázku. V praxi pak výstup vypadá takto: [dave@azucar dave]$ file multimon.gif multimon.gif: GIF image data, version 87a, 637 x 244,

File umí rozpoznat i řadu formátů spustitelných souborů pro řadu platforem: [dave@azucar dave]$ file seqstat*




seqstat:

ELF 32-bit MSB mips-2 executable, MIPS R3000_BE, version 1\ dynamically linked (uses shared libs), not stripped seqstat2: ELF 32-bit LSB executable, Intel 80386, version 1, \ dynamically linked (uses shared libs), not stripped

Jak je vidět, databáze /usr/share/magic je věc velmi užitečná. Pokud zkoumaný soubor nevyhoví žádné z definic v databázi magic a jedná se o textový soubor, pokusí se file ještě odhadnout jakou znakovou sadu soubor používá a potom se pokusí odhadnout v jakém je jazyce (např. zdrojový kód v jazyce C bude obsahovat rezervovaná slova tohoto jazyka apod.). Tyto testy jsou už pochopitelně méně spolehlivé.

5.3.2 Použití Příkaz file nabízí několik užitečných voleb (všechny zde rozebírat nebudeme, zastavíme se pouze u několika nejzajímavějších): •

-i: tato volba způsobí, že file na výstup vypíše mime typ souboru, např.:

[dave@azucar dave]$ file -i multimon.gif multimon.gif: image/gif

•

-L: tato volba způsobí, že file bude následovat symbolické odkazy, místo aby pouze vypsal, že se jedná o symbolický odkaz.

•

-s: tato volba způsobí, že se file pokusí otevřít a identifikovat soubory blokových nebo znakových zařízení (normálně file otevírá pouze obyčejné soubory). To se nám může hodit v případě, kdy potřebujeme zjistit jaký souborový systém obsahují určité diskové oddíly:

[root@azucar /root]# file -s /dev/hda /dev/hda1 /dev/hda2 /dev/hda: x86 boot sector /dev/hda1: x86 boot sector, system MSWIN4.1, FAT (12 bit) /dev/hda2: Linux rev 1.0 ext2 filesystem data (mounted or unclean)

Jak vidno, utilita file je užitečný nástroj pro příkazovou řádku, který poměrně spolehlivě rozpozná velké množství datových formátů, jeho "magic" databáze uživateli poskytne informace o tom, jak dané datové formáty rozpoznat. Tento příkaz je standardní součástí linuxových distribucí a nalezneme jej také prakticky v každém UN*Xovém systému.




5.4 Dokumentace, nápověda Linux Mission obsahuje spoustu užitečné dokumentace. V podstatě každá utilita má svou programovou dokumentaci. V linuxových systémech existuje několik systémů nápovědy: • • •

klasické manuálové stránky, systém info, desktopová prostředí mají svou vlastní dokumentaci.

K prohlížení manuálových stránek slouží v textovém režimu příkaz man, nápovědu k použití získáte zadáním man man. K prohlížení dokumentace v systému info slouží v textovém režimu utilitta info. Samozřejmě lze použít také grafická rozhraní. V dekstopu GNOME vyvoláte nápovědu z hlavního menu přes položku "Nápověda", klasické manuálové stránky jsou přístupné přes odkaz "Manuálové stránky" (předposlední položka dole), systém info je přístupný přes odkaz "Informační stránky". Pokud chcete v manuálech hledat, použijte záložku "Index":

Alternativně lze použít např. prohlížeč Konqueror (což je internetový prohlížeč, správce souborů a prohlížeč dokumentace v jednom) pokud jako URL zadáte man:/ můžete prohlížet klasické manuálové stránky, analogicky pokud jako URL zadáte info:/.




6. Pod pokličkou orientace v systému pro pokročilé 6.1 Plánování, hierarchie a ř ízení procesů V této části se budeme zabývat fungováním procesů v systému Linux. Nejprve si definujeme, co je to proces, popíšeme stavy, ve kterých se může nacházet, budeme se krátce zabývat mechanismem plánování procesů a možností ovlivnění jejich priority a mechanismy řízení procesů. Tato část je určena mírně či středně pokročilým uživatelům či administrátorům a kromě teoretického úvodu obsahuje i řadu příkladů, které uživatel využije při práci se systémem, ale některé praktické tipy využije i uživatel začátečník.

6.1.1 Co je proces? Dříve než se dostaneme k praktickým záležitostem je potřeba definovat několik pojmů, jako je jádro systému, proces, uživatelský režim či režim jádra a objasnit mechanismus vzniku procesů. Začínajícímu uživateli se možná bude tento úvod zdát zbytečně podrobný, nicméně pochopení těchto pojmů je důležité pro zbytek textu, takže doporučuji obrnit se trpělivostí a několik úvodních odstavců přečíst. Pod pojmem proces rozumíme běžící instanci programu. UN*Xové systémy, tedy systému odvozené od systému UNIX nebo systémy UNIXu podobné jako je i Linux, jsou systémy www.linuxzone.cz strana 66 / 159


6. Pod pokličkou orientace v systému pro pokročilé

víceuživatelské a podporují multitasking umožňují tedy současnou práci více uživatelů a běh více procesů současně. Ve skutečném slova smyslu může samozřejmě na jednoprocesorovém počítači být vykonáván pouze jeden proces, nicméně víceméně simultánní běh více procesů umožňuje režim sdílení času procesoru (tzv. timeshare) mezi jednotlivými procesy, kdy se procesy ve svém běhu střídají podle určitých pravidel a vytváří se tak iluze, že více procesů běží současně. K problematice plánování procesů se ovšem ještě dostaneme později. Architektura UN*Xových systémů je následující: existuje jádro systému, které obhospodařuje technické prostředky systému, plánuje vykonávání procesů a poskytuje rozhraní, pomocí kterého je možno přistupovat k technickým prostředkům a prostředkům jádra. Toto rozhraní představují tzv. volání jádra. Procesy mohou běžet ve dvou režimech: v režimu uživatelském a v režimu jádra. Proces běžící v uživatelském režimu může přistupovat pouze ke svému paměťovému prostoru, který obsahuje kód programu a jeho data a nemůže vykonávat určité privilegované činnosti související např. se stavem technických prostředků, nemůže přistupovat k paměťovým strukturám jádra či jiných procesů a podobně. Akce, které není možné realizovat v uživatelském režimu, mohou uživatelské procesy vykonávat právě pomocí volání jádra, které způsobí, že proces přejde z režimu uživatelského do režimu jádra. Procesy v systémech UN*Xového typu vznikají standardním způsobem pomocí volání jádra fork (), které způsobí jakési rozdvojení procesu. Proces, který volání jádra fork() vyvolal, se nazývá rodičovský proces (parent), pokud fork() proběhne úspěšně, vzniká nový proces tzv. potomek (child). Z toho plyne, že každý proces tedy má svého rodiče a vzniká tak hierarchie procesů. Každý proces je v systému identifikován číslem PID (Process ID). Hierarchií procesů se bude detailně zabývat později. (Uvidíme, že výše uvedené neplatí bez výjimky existuje proces, který nevzniká tímto standardním způsobem a také existuje proces, který má v hierarchii procesů zvláštní postavení, o tom ale později.)

6.1.2 Vznik procesu, vykonání programu volání jádra fork() a execve() Z pohledu programátora to vypadá takto (uvedu příklad v jazyce C, začátečníci či neprogramátoři jej mohou přeskočit): rodičovský proces zavolá volání jádra fork(), které v případě úspěchu vrátí rodiči návratovou hodnotu číslo procesu potomka, zatímco potomek jako návratovou hodnotu obdrží 0. Tím je umožněno rozlišit v kódu programu proces rodiče potomka. if (fork()==0) { /* zde pokračuje vykonávání potomka */ } /* zde pokračuje rodič*/

K vykonání jiného programu slouží mechanismus exec nahrazení procesu jiným, které realizuje volání jádra execve(). Pokud tedy chceme např. z našeho programu spustit jiný program a přitom pokračovat ve vykonávání našeho programu, musíme nejprve provést fork(), který vytvoří proces potomka a následně v kódu potomka zavoláme execve(), který způsobí nahrazení kódu potomka www.linuxzone.cz strana 67 / 159



kódem daného programu.

6.1.3 Stavy procesů Během své existence se proces může vyskytovat v různých stavech. Nyní si jednotlivé stavy v krátkosti popíšeme a vysvětlíme, jaké jsou mezi nimi vztahy, tedy jakým způsobem může proces přecházet z jednoho stavu do druhého. V UN*Xových systémech to zjednodušeně vypadá takto:

Jsou tedy možné následující stavy: • •

•

• •

1) Proces běží v režimu uživatelském. 2) Proces běží v režimu jádra. Do režimu jádra se dostane buď pomocí volání jádra, anebo tak, že dojde k přerušení. Přerušení může po uplynutí určité doby vyvolat časovač, nebo nějaký technický prostředek (prostřednictvím přerušení procesoru) signalizuje, že je potřeba ošetřit nějakou událost (např. dokončení I/O operace apod.). Po obsloužení přerušení může být vybrán k vykonávání jiný proces. 3) Proces je zablokován a čeká na dokončení I/O operace, případně na určitý signál nebo na uplynutí určitého časového kvanta. Jakmile důvod zablokování pomine, přejde do stavu připraven k běhu. 4) Proces je připraven k běhu a čeká, až bude jádrem systému naplánován k vykonávávání. 5) Proces je ve stavu mátoha (zombie). Po ukončení běhu procesu zůstává ještě v tabulce procesů záznam (který obsahuje status ukončení procesu), aby jej mohl rodičovský proces zjistit. Proces již de facto neexistuje a nezabírá systémové prostředky, vyjma záznamu v tabulce procesů.




6.1.4 Praxe: monitorování stavu procesů Stav procesu lze samozřejmě monitorovat pokud jádro obsahuje podporu pseudosoborového systému procfs, nalezneme informace o jednotlivých procesech v adresáři / proc/číslo_procesu/. Samozřejmě není potřeba procházet /proc manuálně, existuje řada nástrojů, které to umějí. Utilita ps slouží k aktuálnímu výpisu stavu procesů, utilita top slouží k interaktivnímu sledování procesů. Obojí jsou terminálové aplikace, tedy spouštějí se z příkazové řádky, ale existují samozřejmě i alternativní nástroje s grafickým rozhraním. Nebudeme zde rozebírat detailně používání ps či top, detaily čtenář nalezne v příslušných manuálových stránkách, pouze zmíníme význam symbolů popisujících stav procesu (sloupec "S" nebo "STAT" ve výpisu ps nebo top): $ ps -l F 000 000 000

S S T R

• • • •

•

UID PID 500 1012 500 13500 500 12943

PPID 1009 1012 1012

C PRI 0 74 0 69 0 78

NI 0 0 0

SZ 729 474 769

WCHAN wait4 do_sig -

TTY pts/0 pts/0 pts/0

TIME 00:06 00:00 00:00

CMD bash vi ps

R běžící nebo připraven k běhu ("runnable", ve výše uvedeném schématu odpovídá stavům 1, 2 a 4) D nepřerušitelné čekání ("uninetrruptible sleep", zpravidla čekání na dokončení I/O operace, v schématu stav 3) S přerušitelné čekání ("interruptible sleep", může být probuzen příchodem signálu nebo vypršením časového limitu, v schématu rovněž odpovídá stavu 3) T pozastaven ("stopped", pozastaven pomocí mechanismu "job control" k tomuto mechanismu řízení procesů se dostaneme později nebo je trasován, v schématu rovněž odpovídá stavu 3) Z mátoha ("zombie", v schématu odpovídá stavu 5)

Pokud v okně terminálu nebo na textové konzoli spustíme utilitu top, budeto to vypadat takto (najdeme zde i další údaje jako je např. velikost paměti procesu ve sloupci SIZE, procentuální množství paměti používané procesem ve sloupci %MEM, nebo procentuální obsazení času procesoru daným procesem ve sloupci %CPU):




V desktopovém prostředí GNOME spustíme nástroj pro sledování procesů s grafickým rozhraním přes menu "Systémové nástroje", položka "Sledování systému":

Pomocí okénka hledat můžeme snadno vyhledat procesy podle jejich názvu. Chcemeli, aby byly procesy řazeny podle abecedy, klikneme na záložku "Jméno procesu" apod. Prostřednictvím menu




"Úpravy > Nastavení" vyvoláme dialog, kde můžeme specifikovat, jaké informace o procesech se budou zobrazovat a jak čast budou informace v seznamu procesů aktualizovat.

6.1.5 Plánování procesů, priorita V úvodu jsem zmiňoval, že UN*Xové systémy podporují multitasking, který funguje na základě režimu sdílení času procesoru (timeshare). Procesorový čas je mezi jednotlivými procesy sdílen, procesy se ve svém běhu střídají podle určitých pravidel a vytváří se tak iluze, že více procesů běží současně. Rozvržení procesorového času mezi jednotlivé procesy obstarává plánovač procesů, který je součástí jádra systému. Funguje to tak, že plánovač přidělí procesor určitému procesu na určitou dobu a po jejím vypršení vykonávání procesu pozastaví a naplánuje jiný proces takový, který má nejvyšší prioritu, případně se nachází ve stavu připraven k běhu nejdelší dobu. V hodnotě priority, která je pravidelně přepočítávána, se negativně odráží i doba, po kterou proces běžel během posledního časového úseku, jehož délka je předem stanovena. Tak je zaručeno spravedlivé střídání procesů priorita procesu, který je připraven k běhu roste (do určité meze) čím déle proces čeká na zpracování a naopak priorita procesu, který v nedávné době běžel nebo běží se snižuje. K práci s časem jádro využívá časovač, který je součástí hardware a v určitém neměnném intervalu pravidelně přerušuje procesor. Jádro Linuxu ve skutečnosti podporuje kromě zmíněné plánovací politiky sdílení času (time share) také politiky pro aplikace vyžadující zpracování v reálném čase (real time policies). Jednodušší varianta politiky práce v reálném čase se nazývá FIFO (first in, first out), která funguje tak, že je k vykonávání vybrán proces s nejvyšší prioritou a ten je vykonáván tak dlouho, dokud se nevyskytne




jiný proces s vyšší prioritou připravený k běhu, nebo se nezablokuje kvůli I/O operaci, anebo sám nezavolá volání jádra pro přenechání procesoru jinému procesu. Když je proces vybrán ke zpracování, je následně přeřazen na poslední místo ve frontě (proto označení first in, first out).. Druhá varianta politiky zpracování v reálném čase se nazývá Round Robin (což by šlo přeložit jako střídání dokola). Od politiky FIFO se liší tím, že je definována maximální doba, po kterou proces může běžet bez přerušení, po uplynutí této doby je jeho vykonáváni pozastaveno a je stejně jako v předchozím případě přeřazen na poslední místo ve frontě. Obyčejný uživatel ovšem nemá možnost spouštět procesy využívající politiky zpracování v reálném čase, tuto možnost má pouze superuživatel (root). Drtivá většina procesů v Linuxových systémech ovšem pracuje v režimu sdílení času; klasické jádro Linuxu ani není navrženo pro použití v aplikacích, které vyžadují opravdu spolehlivé zpracování v reálném čase a zmíněné politiky zpracování v reálném čase také nelze uplatnit v případech, kdy je potřeba zaručit opravdu minimální prodlevy. Existuje ovšem např. projekt RTLinux (RealTime Linux), který dává mnohem lepší výsledky stran aplikací pracujících v reálném čase (kromě toho existují speciální OS vyvíjené pro tento účel, jako je např. QNX či LynxOS). Problematika plánování procesů je poměrně rozsáhlá a nebudeme zde zabývat do detailů, další informace čtenář nalezne např. v manuálových stránkách dokumentující volání jádra sched_setscheduler(2), sched_yield(2) či sched_setparam(2).

6.1.6 Praxe: nástroje nice a renice pro změnu priority Tolik k teorii, nyní se pojďme podívat, jakým způsobem může uživatel či administrátor ovlivnit prioritu vykonávání procesů. Uživatel nemůže přímo ovlivnit hodnotu priority procesu, může pouze nastavit jeden z parametrů, který se při výpočtu priority uplatní. Jedná se o tzv. hodnotu nice. Tento parametr má přípustný rozsah od 20 po 19 a udává, jak je proces "hodný" (proto také angl. název "nice") vůči ostatním. Výchozí hodnota nice je 0. Obyčejný uživatel může hodnotu pouze zvyšovat (a tím snížit prioritu daného procesu), zatímco administrátor může nastavit i zápornou hodnotu nice a tím prioritu daného procesu zvýšit. Pro manipulaci s parametrem nice slouží nástroje pro příkazovou řádku nice (spuštění aplikace s pozměněnou prioritou) a renice (pozměnění priority již běžícího procesu), ale je možno použít i jiné, interaktivní nástroje jako je top pro terminál (příkaz renice vyvoláme stiskem "r") anebo již zmíněnou utilitu pro správu procesů prostředí GNOME. Např. následující příkaz zajistí, že aplikace bude spuštěna s nejnižší prioritou: nice -n 19 cesta_k_aplikaci

Pokud pracujeme s aplikací "Sledování systému" GNOME, označíme v seznamu procesů pomocí myši dotyčný proces a přes menu, které vyvoláme stistkuntím pravého tlačítka myši vybereme položku "Změnit prioritu". Tím otevřeme dialog, ve kterém upravíme a potvrdíme změnu priority




(přesněji parametru nice).

Ve druhé části tohoto miniseriálu se podíváme, jaká je hierarchie procesů v Linuxu, krátce se zmíníme o zvláštním postavení procesu init a osvětlíme si koncept skupin procesů a sezení. Na závěr si ukážeme si praktický příklad, jak pomocí nástroje nohup spouštět procesy tak, aby nebyly po odhlášení uživatele ukončeny.

6.2 Hierarchie procesů V této kapitole se podíváme, jaká je hierarchie procesů v Linuxu, krátce se zmíníme o zvláštním postavení procesu init a osvětlíme si koncept skupin procesů a sezení. Na závěr si ukážeme si praktický příklad, jak pomocí nástroje nohup spouštět procesy tak, aby nebyly po odhlášení uživatele ukončeny. Minule jsme si definovali několik pojmů, víme co si představit pod pojmem proces, jaká je role jádra systému a přiblížili jsme si mechanismy, které jádro používá při plánování procesů, víme také jakým způsobem ovlivnit prioritu vykonávání procesu. Proces jsme si definovali jako běžící instanci programu, který standardně vzniká voláním jádra fork(). Původní proces, který fork() provede je rodičovským proces a nově vytvořený proces je potomek (child). Každý proces je v systému identifikován svým číslem PID (Process ID) a u každého procesu jádro také eviduje číslo




rodiče toto číslo je označeno jako PPID (Parent Process ID). Vzniká tak hierarchie procesů, kde každý proces má svého rodiče. Celou hierarchii procesů si můžeme vypsat například pomocí nástroje pro příkazovou řádku pstree (v grafickém režimu nám obdobně poslouží nástroj "Sledování systému"): vanvancito ~ $ pstree -p init(1)-+-apmd(508) |-atd(703) |-bdflush(6) |-crond(772) |-gdm(850)-+-X(858) | `-gdm(859)---gnome-session(872) |-gmc(14542) |-gnome-terminal(1009)-+-bash(1012)-+-pstree(20186) | | |-xemacs(12538) | | |-xosview(9199) | | `-xv(3886) | |-bash(150)--su(170)--bash(175) | |-bash(14316)---ssh(20152) | |-bash(11601) | |-bash(18144) | `-gnome-pty-helper(1011) [ ... zkráceno ...]

Vidíme, že na vrcholu hierarchie je proces číslo 1 a jedná se o program init. Tento proces má významné postavení, je to totiž proces, který je jádrem spouštěn při startu systému a tento proces pak řídí inicializaci systému včetně spouštění nakonfigurovaných služeb. Init (proces s PID=1) ve skutečnosti není úplně prvním procesem v systému existuje ještě proces číslo 0, který vzniká nestandardním způsobem jádro jej vytváří v rané fázi startu systému přímo bez použití algoritmu fork, teprve proces 1 (init) už vzniká obvyklou posloupností algoritmů fork (rozdvojení procesu) a následným uplatněním algoritmu exec (vykonání programu) v kódu potomka. Po spuštění initu se z procesu 0 stane tzv. swapper. Ve výpisu procesů běžících v systému bychom jej ale hledali marně, protože tento proces zůstane před uživatelem skrytý. Prakticky tedy na vrcholu hierarchie procesů stojí proces s PID 1, tedy init. Možná Vás napadlo, co se stane v případě, kdy je ukončen proces, jehož potomci v systému ještě existují. Systém v tom případě nastaví PPID (Parent Process ID) u těchto procesů na 1 jejich rodičem se pak tedy stane init. Startu systému a roli procesu init, včetně jeho konfigurace, se budeme ještě věnovat podrobněji ve zvláštní kapitole.




6.2.1 Skupiny procesů a sezení Kromě toho, že je každý proces identifikován svým číslem PID, rozlišuje systém ještě mezi skupinami procesů. Procesy, které patří do stejné skupiny mají shodné číslo skupiny procesů PGID (Process Group ID). V rámci skupiny procesů je jeden proces evidován jako vedoucí proces skupiny (process group leader, takový proces poznáme podle toho, že má shodné číslo PID s číslem PGID). Skupiny procesů umožnují distribuci signálů v rámci skupin. Dále existují tzv. sezení (sessions), k jejich identifikaci slouží číslo SID (Session ID). Sezení jsou skupinám nadřazené, procesy mohou přecházet mezi skupinami pouze v rámci jednoho sezení. Obdobně jako v případě skupin procesů je jeden proces vedoucím procesem sezení (session leader, poznáme jej analogicky podle toho, že má shodné číslo PID s číslem SID). Pod pojmem sezení si představme např. množinu procesů, která vznikne okolo procesu procesu login po přihlášení uživatele na konzoli anebo okolo procesu příkazového interpretu po přihlášení uživatele do vzdáleného systému apod.

6.2.2 Praxe: utility nohup, setsid a disown vyjmutí procesu ze sezení Existence skupin procesů a sezení (sessions) je opodstatněná např. si představme, že se uživatel přihlásí přes terminál do systému a spustí několik aplikací. Posléze se ohdlásí bez toho, aby zkontroloval, zda všechny aplikace, které spustil jsou ukončeny (což může být problém, neboť Linux je víceuživatelský systém a pokud by to tak kupříkladu na aplikačním serveru činili všichni uživatelé, za chvíli by byl server zahlcen takovými zapomenutými procesy). Všechny tyto procesy, které uživatel během ze svého terminálu spustil jsou ovšem identifikovatelné podle příslušnosti k jednomu sezení (session) a při odhlášení uživatele tak může vedoucí proces sezení zaslat všem těmto procesům signál k ukončení. Skupiny procesů také využívají příkazové interprety, když uživateli umožňují řídit více procesů pomocí mechanismu job control (co to je a k čemu se job control v praxi hodí si ukážeme příště). Jak to v praxi vypadá, demonstruje následující příklad: uživatel dave s UID (User ID) 1118 se přihlásil do vzdáleného systému a v shellu si spustil editor vi, pak editor vi pozastavil a příkazem ps si vypsal údaje o všech svých procesech (poznámka: své UID můžeme zjistit buď náhlednutím do souboru /etc/passwd nebe pomocí příkazu id): vanvancito ~ $ ps -u dave o uid,pid,ppid,pgid,sid,tty,comm UID 1118 1118 1118

PID 1257 1446 1451

PPID 1252 1257 1257

PGID 1257 1446 1451

SID 1257 1257 1257

TT pts/0 pts/0 pts/0

COMMAND bash vi ps

Hierarchii procesů si také pro větší názornost můžeme nechat vypsat pomocí již zmiňovaného příkazu pstree: vanvancito ~ $ pstree -p dave bash(1257)-+-bc(1450) |-pstree(1469)




`-vi(1446)

Vidíme, že všechny procesy skutečně náleží k jednomu sezení (číslo sezení je rovno 1257), rodičovským procesem procesů vi a ps je proces příkazového interpretu bash, který je současně vedoucím procesem sezení. Pokud si všimneme čísel skupin, vidíme, že procesy v rámci sezení (session) jsou každý ve zvláštní skupině (mají odlišná čísla PGID), což souvisí s mechanismem job control (pokud by si např. uživatel z editoru vi spustil další proces vyvoláním externího příkazu, měl by stejné číslo skupiny jako rodičovský proces vi). Už jsem naznačil, že na základě příslušnosti procesů k sezením má systém možnost ukončit procesy, které uživatel před odhlášením ze systému zapomněl ukončit. Někdy je ovšem žádoucí, aby toto chování bylo možné potlačit. Dejme tomu, že např. uživatel či administrátor potřebuje spustit proces, jehož provádění trvá dlouhou dobu a nepřeje si být po celou dobu v systému přihlášen (at už se jedná třeba o provedení zálohy nebo třeba offline zpracování videa příkladů by se jistě našla celá řada). Pokud by takový proces spustil obvyklým způsobem a následně se odhlásil, proces by byl ukončen. Situaci lze řešit buď tak, že proces spustíme v novém sezení existuje volání jádra setsid() a utilita setsid (pro příkazovou rádku) spouštěný proces se tak stane nezávislým na sezení příkazového interpretu a po ukončení příkazového interpretu zůstane běžet, neboť přísluší jinému sezení. (Poznámka: má to ovšem jeden háček, setsid() uspěje pouze v případě, že se proces, který setsid() volá není vedoucí proces skupiny). Druhá možnost je, že interpretu sdělíme, že daný proces má vyřadit ze seznamu aktivních úloh a nemá mu zasílat příkaz k ukončení, k tomu můžeme použít buď příkaz nohup anebo vestavěný příkaz příkazového interpretu disown. Dejme tomu, že chceme provést nějaký dlouhotrvající výpočet, který realizuje program "pocitej", s pomocí utility nohup jej spustíme takto (nezapomeňme na znak &, tedy spuštění procesu na pozadí, viz manuálová stránka příkazu nohup): vanvancito ~$ nohup pocitej &

Utilita nohup pamatuje na případný výstup programu automaticky jej přesměruje do souboru nohup.out. Kromě nástroje nohup také můžeme použít vestavěný příkaz interpretu bash příkaz disown: vanvancito ~ $ vanvancito ~ $ [1]+ Running vanvancito ~ $ vanvancito ~ $

pocitej & jobs disown %1 jobs

./pocitej &

Vidíme, že po provedení příkazu disown již příkaz jobs proces pocitej nevypsal, protože jej vyřadil ze seznamu aktivních úloh. Poznámka: Uvedené příklady s utilitami disown a nohup lze jednoduše aplikovat jen na www.linuxzone.cz strana 76 / 159



programy, které neběží v grafickém režimu.

6.2.3 Řízení procesů, signály V této kapitole se budeme zabývat mechanismy řízení procesů osvětlíme si koncept signálů a v závěru se budeme věnovat praktickým možnostem řízení procesů, které nabízí nejpoužívanější příkazový interpret Bash (mechanismus job control). Signály slouží k tomu, aby procesy informovaly o výskytu nějaké asynchronní události. Pro zasílání signálů slouží volání jádra kill(), jádro také samo může zasílat procesům signály. K tomu, aby nějaký proces mohl zaslat signál jinému procesu, musí se jednat o proces stejného uživatele, pouze uživatel root může zasílat signály libovolným procesům. Jsou tři možnosti, jak může proces na přijetí signálu reagovat: • • •

může být ukončen; může jej ignorovat; může vykonat určitou předem definovanou akci, která byla předtím zaregistrována pomocí volání jádra signal() nebo sigaction().

Existuje celá řada signálů a standardní reakce definovaná systémem na jejich přijetí je různá, pro získání představy si uveďme namátkou některé často používáné signály a standardní reakce na ně: •

• • •

• •

SIGHUP (číslo 1) signál zavěšení linky, tento signál zašle proces kontrolující terminál ostatním procesům v rámci sesion (sezení), standardní reakce na tento signál je ukončení procesu; SIGKILL (číslo 9) tento signál způsobí okamžité ukončení procesu, není možné jej odchytit či ignorovat; SIGTERM (číslo 15) signál pro ukončení procesu, standardní reakce na tento signál je ukončení procesu; SIGSEGV (číslo 11) signalizuje neoprávněný přístup do paměti, standardní reakce na tento signál je ukončení procesu a uložení obrazu paměti procesu na disk (určitě se vám již někdy stalo, že progam skončil s chybou a hlášením typu segmentation fault, core dumped); SIGSTOP (číslo 19) pozastavení vykonávání procesu; SIGCONT (číslo 18) obnovení vykonávání procesu;

Detailní popis dostupných signálů je k dispozici v manuálové stránce signal(7).

6.2.4 Praxe: ukončení procesu, nástroj kill pro zasílání signálů procesům Pro zasílání signálů procesům z příkazové řádky je možné použít utility kill nebo killall (ale také utilitu top nebo grafické rozhraní "Sledování systému" desktopu GNOME). Z názvu by se dalo usuzovat, že se jedná o nástroje určené výhradně k ukončení běhu procesů což je skutečně jejich standardní akce nicméně slouží je lze použít k zaslání jakéhokoliv signálu, nejen signálu www.linuxzone.cz strana 77 / 159



SIGTERM pro ukončení procesu. Pokud chceme určitý proces ukončit, máme na výběr ze dvou možností použít signál SIGTERM (15) anebo signál SIGKILL (9). Rozdíl mezi těmito signály je v tom, že signál SIGKILL nemůže být procesem odchycen, zatímco na signál SIGTERM může aplikace zareagovat textový editor např. může před ukončením uložit soubor apod. Nástroj kill ackceptuje jako argument číslo PID procesu, zatímco nástroj killall akceptuje jako argument jméno procesu (detaily viz příslušné manuálové stránky). Pokud bychom chtěli např. ukončit proces s číslem PID 146, učinili bychom to příkazem kill -s SIGKILL 146 anebo třeba kill -9 146. Pokud pracujeme s aplikací "Sledování systému" GNOME, označíme v seznamu procesů pomocí myši dotyčný proces a přes menu, které vyvoláme stistkuntím pravého tlačítka myši vybereme položku "Ukončit proces". Tím otevřeme dialog, ve kterém potvrdíme násilné ukončení běhu procesu. Násilné ukončení běhu procesu takovým způsobem (pomocí signálu SIGKILL) může znamenat ztrátu neuložených dat, se kterými daná aplikace pracovala.

6.2.5 Praxe: synchronizace rodiče s ukončením potomka Mnohdy je žádoucí, aby rodičovský proces poznal, kdy je proces potomek ukončen a aby znal status ukončení svého potomka (jestli byl ukončen regulérně, nebo zda došlo k chybě). Systém na to pamatuje a při ukončení procesu potomka rodičovskému procesu zašle příslušný signál (SIGCLD). www.linuxzone.cz strana 78 / 159



Standardní reakce na tento signál je jej ignorovat, je ovšem možno nastavit zachytávání signálu pomocí volání jádra signal() nebo sigaction(). Jádro dále poskytuje volání jádra wait(), waitpid() a wait4(), která slouží k čekání na ukončení běhu potomka. Demonstrujme si to na krátkém příkladu v jazyce C, detaily čtenář nalezne v příslušných manuálových stránkách: /* potřebné hlavičkové soubory */ #include <sys/types.h> #include #include <signal.h> #include <stdio.h> int CheckStatus() { pid_t pid; int status;

}

pid=wait(&status); printf("potomek: %i návratový kód: %i\n",pid,status);

int main(int argc, char **argv) { /* instalujeme signal handler, standardní reakce je signál SIGCLD ignorovat */ signal(SIGCLD,(void*)CheckStatus); if (fork()==0) { /* zde pokračuje vykonávání potomka ... */ exit(0); }

}

/* zde pokračuje rodič*/ sleep(5); return(0);

Poznámka: Pokud rodičovský proces stále běžía status ukončení svého potomka nevyzvedne, zůstane potomek ve stavu mátoha (zombie). Pokud v době ukončení potomka již rodičovský proces neexistuje, vyzvedne za něj status ukončení potomka proces init.

6.2.6 Praxe: nastavení reakce na signály signal(), sigaction() Nyní si v krátkosti ukážeme, jak v jazyce C nastavovat reakce na signály. Máme na výběr ze dvou rozhraní: starší představuje volání jádra signal(), které vychází z normy ANSI C, novější je volání jádra sigaction(), které je v souladu s normou POSIX . Dejme tomu, že programujeme systémovou aplikaci, která běží na pozadí (démon)a přejeme si, aby proces po obdržení signálu SIGHUP znovu načetl svůj konfigurační soubor a naopak aby ignoroval signály SIGTTIN, SIGTTOU a SIGTSTP: /* potřebné hlavičkové soubory */




#include <signal.h> #include <stdio.h> int LoadConfig() { /* zde ošetříme znovunačtení konfiguračního souboru ...*/ } int main(int argc, char **argv) { /* na začátku načteme konfigurační soubor, k čemuž v našem případě slouží fce LoadConfig() */ LoadConfig(); /* nastavíme signal handler pro signál SIGHUP */ signal(SIGHUP,(void*)LoadConfig); /* signály SIGTTIN, SIGTTOU a SIGTSTP budeme ignorovat */ signal(SIGTTIN,SIG_IGN); signal(SIGTTOU,SIG_IGN); signal(SIGTSTP,SIG_IGN); /* pokračuje tělo programu ... */ for(;;);

}

6.2.7 Příka zový interpret a říz ení procesů job control Příkazové interprety v UN*XOvých systémech umožňují pracovat s více programy najednou s tím, že uživatel může mezi jednotlivými procesy přepínat, může vykonávání některých činností pozastavit a posléze v nich zase pokračovat dále. V daném okamžiku ovšem nemá smysl, aby z terminálu četly nebo na něj zapisovaly všechny aplikace zárověň. Obvykle je taková aplikace jen jedna o takové aplikaci říkáme, že běží na popředí. Ostatní aplikace jsou buď pozastaveny anebo mohou běžet na pozadí v případě, že nepotřebují bezprostředně číst z terminálu nebo na něj zapisovat. Správa procesů spouštěných v rámci příkazového interpretu je realizována pomocí mechanismu job control, který využívá pro oddělení procesů běžících na popředí či pozadí odlišné skupiny procesů v rámci jedné session (sezení), jednotlivým skupinám procesů pak podle potřeby zasílá signály (podrobnosti opět viz manuálová stránka signal(7) a manuálová stránka příkazového interpretu bash). Podívejme se, jak v praxi používat mechanismus job control v příkazovém interpretu bash: •

pokud chceme spustit aplikaci na pozadí, za příkaz doplníme znak &, např: vanvancito ~ $ netscape &

•

příkaz jobs vypíše seznam procesů, které v rámci tohoto sezení běží, na procesy se budeme




odvolávat čísly, které jsou uvedeny v hranatých závorkách (nejedná se o PID procesu, je to číslo, pod kterým proces eviduje příkazový interpret v rámci mechanismu job control). Proces, který běžel na popředí jako poslední, je označen znakem +. Proces, který běžel na popředí jako předposlední, je označen znakem -. Na tyto procesy se můžeme pro větší pohodlí odvolávat i znaménky + a - namísto jejich čísel. vanvancito ~ $ jobs [1] [2][3]+

• •

•

Stopped Stopped Stopped

vi man ls bc

příkaz fg (foreground) převede daný proces do popředí, chcemeli tedy pokračovat v práci s editorem vi, zadáme fg %1. příkaz bg (background) převede daný proces do pozadí. toto má smysl tehdy, jednáli se o aplikaci, která nepotřebuje bezprostředně číst z terminálu nebo na něj zapisovat pokud by se o to pokusila, bude pozastavena do té doby, než bude vyvolána do popředí. stisknutí sekvence ^Z (ControlZ) způsobí, že bude proces běžící na popředí pozastaven. Chcemeli takto pozastavený proces poslat běžet na pozadí, použijeme následně ještě příkaz bg.

Toto je jen zkrácený popis možností, pokud se rozhodnete tento mechanismus používat, určitě si prostudujte příslušnou část manuálové stránky příkazového interpretu bash.

6.3 Jádro systému a ovladače Jádro Linuxu může být sestaveno dvěma způsoby: potřebné ovladače mohou být zakompilovány přímo do jádra anebo mohou být k dispozici formou tzv. modulů tedy ovladačů, které mohou být do jádra zavedeny nebo naopak uvolněny kdykoliv podle potřeby. Nicméně minimální sada ovladačů (t.j. ovladačů těch zařízení, bez kterých by nebylo možné systém spustit např. ovladač pevného disku apod.) musí být k dispozici již při startu systému, což se obvykle řeší za použití speciálního ramdisku "initrd". V této části manuálu se podíváme, jak to celé funguje, naučíme se pracovat s moduly a zaměříme se na co si dát pozor při eventuálním sestavování vlastního modulárního jádra. Následující kapitola se věnuje problematice zavádění modulů a popisu nástrojů pro práci s moduly.

6.3.1 Monolitické nebo modulární jádro? Linux podporuje značné množství periferií a tedy i množství ovladačů, které jsou zapotřebí k provozu běžných instalací Linuxu je velké. Ovladače mohou být přímou součástí jádra takové jádro, které obsahuje pouze zabudované ovladače nazýváme jádrem monolitickým. Většina ovladačů však může být sestavana a používána jako moduly, které lze za běhu systému v případě potřeby natáhnout nebo je naopak kdyz už nejsou zapotřebí z jádra uvolnit. Pokud je jádro www.linuxzone.cz strana 81 / 159



sestaveno s podporou modulů, hovoříme o modulárním jádře. Pochopitelně velikost jádra je omezená, takže mnohdy ani není možné sestavit monolitické jádro, které by obsahovalo všechny požadované ovladače, obvykle se tedy používají jádra modulární; jádra monolitická používají v opodstatněných případech zkušení uživatelé, kteří si je připravují podle svých potřeb. Pokud používáme modulární jádro (což je samozřejmě i případ OS Linux Mission), neobejdeme se bez balíčku modutils, který obsahuje nástroje pro práci s moduly. Jednotlivé nástroje balíčku modutils si nyní představíme a na krátkých příkladech vysvětlíme práci s moduly. Ještě doplňme, že moduly pro danou verzi jádra jsou uložené v odpovídajícím podadresáři v adresáři / lib/modules. Moduly jsou pak ještě rozděleny do podadresářů podle funkce (ovladače blokových zařízení v adresáři drivers/block, ovladače znakových zařízení v adresáři drivers/char, ovladače souborových systémů v adresáři fs atd.). Celá stromová struktura pak může vypadat např. takto (v příkladu pro jádro 2.4.22, výpis je zkrácen; (mimochodem verzi běžícího jádra zjistíme příkazem uname s volbou a, v případě jádra uloženého v souboru na disku si vypomůžeme příkazy strings a grep): / `-lib `-modules `-linux-2.4.22-1.2188.lz.1.nptl |-- build -> /usr/src/linux-2.4.22-1.2188.lz.1.nptl |-- kernel | |-- drivers | | |-- block | | | |-- loop.o | | | `-- rd.o | | |-- cdrom | | | `-- cdrom.o | | |-- char | | | `-- lp.o | | |-- i2c | | |-- media | | |-- net | | |-- parport | | | |-- parport.o | | | `-- parport_pc.o | | |-- scsi | | `-- sound | |-- fs | | |-- fat | | | `-- fat.o | | |-- isofs | | | `-- isofs.o | | `-- msdos | | `-- msdos.o | `-- net `-- modules.dep




6.3.2 Práce s moduly balíček modutils Dříve než se začneme zabývat procesem bootování modulárního jádra a záležitostí s tím spojených, podívejme se v krátkosti jakým způsobem se s moduly pracuje. Utilita depmod slouží k sestavení jakéhosi "inventáře" dostupných modulů. Obvykle je spuštěna automaticky při startu systému prostřednictvím startovacích skriptů (konkrétně v systému Mission je to skript rc.sysinit) a vygeneruje soubor modules.dep což je textový soubor, ve kterém jsou jednotlivé moduly vypsány spolu s jejich závislostmi. Depmod také použijeme případě, že dodatečně instalujeme nějaký modul pokud by modul nebyl uveden v souboru modules.dep, bylo by sice možné jej zavést, ale s mnohem menším komfortem. Např. u modulu lp.o (podpora tiskáren připojených k paralelnímu portu) bude v souboru modules.dep poznamenáno, že ke své funkčnosti vyžaduje modul parport.o (což je obecný ovladač paralelního portu nezávislý na platformě) a ten ještě na platformě PC potřebuje modul parport_pc.o. Nástroj insmod slouží k manuálnímu zavádění modulů do jádra. Obvykle je k dispozici ve dvou verzích jednak dynamicky linkované a také ve verzi staticky linkované (např. v distribucích Red Hat insmod.static), což je z toho důvodu, aby bylo možné tento nástroj použít i v případě, kdy nejsou dostupné knihovny (anebo jsou poškozené). Pokud bychom chtěli zavést modul parport, spustíme insmod parport. V případě, že chceme pouze ujistit, že daný modul natáhnout lze, můžeme použít volby -p nebo -n. Pokud použijeme pro zavedení modulu utilitu insmod, je na nás, abychom v patřičném pořadí zavedli i případné další moduly, které modul vyžaduje, v opačném případě se setkáme chybovým hlášením, že nelze modul nelze zavést neboť nelze mapovat některé symboly. Např. pokusímeli se ručně zavést modul lp, aniž bychom předtím zavedli modul parport, pokus o zavedení skončí s následující chybovou hláškou: vanvancito /usr/src/linux 48# /sbin/insmod lp Using /lib/modules/2.4.22/kernel/drivers/char/lp.o /lib/modules/2.4.22/kernel/drivers/char/lp.o: \ unresolved symbol parport_write_R5279b323 /lib/modules/2.4.22/kernel/drivers/char/lp.o: \ unresolved symbol parport_read_R806760f9 [ ... zkráceno]

Utilita rmmod slouží k uvolnění modulu z jádra. Samozřejmě je možné se zbavit pouze těch modulů, které nejsou dalšími moduly používány, pokud se pokusíme takový modul odstranit, obdržíme následující hlášení: vanvancito / 5# /sbin/rmmod parport parport: Device or resource busy

Utilita lsmod slouží k vypsání zavedených modulů, u každého modulu je vyznačeno, jestli je používán dalšími moduly a pokud ano, tak kterými. Např. následující výpis ukazuje, že modul




parport je používán moduly parport_pc a lp, naopak modul lp žádným modulem používán není. Pokud bychom tedy chtěli tyto moduly odstranit, zavoláme rmmod nejprve na modul lp, pak na modul parport_pc a na závěr na modul parport. O významu příznaku "autoclean" se zmíníme později v části věnované automatickému zavádění a odstraňování modulů: vanvancito / 12# /sbin/lsmod Module Size parport_pc 19056 lp 5200 parport 28960

Used by 1 (autoclean) 0 (unused) 1 [parport_pc lp]

K pohodlnější manipulaci s moduly je určena utilita modprobe. Ta používá výše zmíněný soubor modules.dep, ve kterém jsou popsány závislosti mezi moduly, takže není nutné zavádět jednotlivé moduly postupně, pokud bychom např. chtěli zavést ovladač bttv (ovladač pro televizní/radio tunery), postačí zadat příkaz modprobe bttv. Chcemeli pouze zjistit, jaké moduly budou v daném případě zavedeny, můžeme modprobe spustit s volbou -n: vanvancito / /sbin/insmod /sbin/insmod /sbin/insmod /sbin/insmod /sbin/insmod

140# modprobe -n -v bttv /lib/modules/2.4.22/kernel/drivers/i2c/i2c-core.o /lib/modules/2.4.22/kernel/drivers/media/video/videodev.o /lib/modules/2.4.22/kernel/drivers/sound/soundcore.o /lib/modules/2.4.22/kernel/drivers/i2c/i2c-algo-bit.o /lib/modules/2.4.22/kernel/drivers/media/video/bttv.o

6.3.3 Automatické zavádění a odstranění modulů jádrem kmod Kromě manuálního zavádění ovladačů nástroji z balíčku modutils je také možno jádro sestavit s podporou automatického zavádění modulů. Moduly pak mohou být natahovány aktuálně podle potřeby. Záležitosti týkající se podpory modulů nalezneme při konfiguraci jádra v sekci "Loadable module support", jedná se o volba "Kernel module loader". Ve starších jádrech Linuxu (dnes už historické řady 2.0.x) jsme se setkávali s démonem kerneld (což byl samostatný proces běžící mimo jádro), v novějších jádrech ale má toto na starostí vlákno jádra kmod. Kmod nabízí oproti kerneld sice omezenou funkčnost v podstatě pouze v případě potřeby spustí modprobe což se ovšem běžného uživatele nijak nedotkne. Jediná pro běžného uživatele pozorovatelná změna je ta, že kerneld sám odstraňoval po uplynutí určité doby nepoužívané moduly, zatímco na systémech používajících pro správu modulů kmod se nepužívaných modulů zbavíme pomocí periodického spuštění rmmod s příslušnými parametry z cronu cron tabulka pak může obsahovat např. následující záznam: # každých 10 minut se zbavíme nepoužívaných modulů # s příznakem autoclean */10 * * * * root /sbin/rmmod -as




Ještě doplňme, že při zavádění modulu máme možnost u modulu nastavit příznak "autoclean" (volba -k). Pokud je tento příznak nastaven, může být modul odstraněn právě spuštěním rmmod s volbou -a; máme tedy možnost zavést modul i takovým způsobem, aby nebyl po určité době automaticky odstraněn i když není používán. Protože kmod pro zavádění modulů používá modprobe, uplatní se i při automatickém zavádění modulu jádrem konfigurace uložená v konfiguračním souboru /etc/modules.conf (viz následující odstavec věnovaný předávání parametrů ovladačů).

6.3.4 Pře dávání parametrů ovladačů Řada ovladačů umožňuje nastavení různých parametrů, jako jsou např. I/O adresy či přerušení atd. Nástroj modinfo umožňuje prohlížet informace o modulu jako je popis modulu nebo zejména možné parametry (volba -p): vanvancito / 109# /sbin/modinfo --p parport_pc io int array (min=1,max=8), description "Base I/O address (SPP regs)" io_hi int array (min=1,max=8), description "Base I/O address (ECR)" irq string array (min=1,max=8), description "IRQ line" dma string array (min=1, max=8), description "DMA channel"

Příslušné parametry pak můžeme zadat utilitě insmod či modprobe při zavádění modulu, např. následující příkaz zavede modul parport_pc a požaduje inicializaci dvou paraleních portů, první na adrese 0x378 bude používat číslo přerušení 7, druhý na adrese 0x278 a číslo přerušení (IRQ) bude autodetekováno ovladačem: vanvancito / 114# /sbin/insmod parport_pc.o io=0x378,0x278 irq=7,auto

Naopak pokud by byl ovladač zakompilován v jádře přímo, potřebné nastavení bychom předali jádru při startu jako parametr. Pokud používáme jako zavaděč systému GRUB (což je případ standardní instalace Mission), doplníme je na konec řádku s direktivou kernel: kernel /vmlinuz-2.4.22-1.2188.lz.1.nptl ro root=/dev/md2 rhgb parport=0x378,7 \ parport=0x278,auto

Pokud pro zavadení jádra používáme např. zavaděč LILO, v konfiguračním souboru lilo.conf bychom uvedli následující řádek: append "parport=0x378,7 parport=0x278,auto"

Pokud používáme pro zavádění modulů utilitu modprobe anebo máme v jádře zapnutou podporu automatického zavádění modulů (ať už starší kerneld či novější kmod), což je způsob který




používá drtivá většina instalací Linuxu, pak patřičné parametry ovladačů můžeme uvést v konfiguračním souboru /etc/modules.conf. Pak bychom do konfiguračního souboru uvedli třeba následující: alias parport_lowlevel parport_pc options parport_pc io=0x378,0x278 irq=7,auto

Nástroje balíčku modutils podporují řadu dalších voleb, které tady nejsou zmíněny, stejně tak zde není detailně rozebrána syntaxe a možnosti konfiguračního souboru modules.conf. Pokud bychom zde ale chtěli probrat všechny možnosti, text by se tím redukoval na výtah manuálových stránek a ztratil na přehlednosti. Zájemce o detailnější popis tedy odkáži na příslušné manuálové stránky balíčku modutils a dokumentaci jádra.

6.4 Proces bootování jádra V této části se zaměříme na vlastní proces bootování modulárního jádra, vysvětlíme použití ramdisku initrd a představíme si nástroj mkinitrd pro generování obrazu ramdisku initrd. Pokud se přidržíme architektury Intel, vypadá proces bootování takto: BIOS načte a spustí z diskového zařízení (pevný disk, floppy, ...) zavaděč uložený v boot sektoru diskety nebo MBR (master boot record) pevného disku. Tento zavaděč (boot loader Grub, LILO apod.) pak do paměti načte vlastní jádro Linuxu a spustí jej. Jádro poté inicializuje nezbytný hardware, konzoli a zejména připojí kořenový svazek v režimu pouze pro čtení. Poté jádro spustí proces init, který očekává v souboru /sbin/init na kořenovém svazku. Proces init pak v závislosti na konfiguraci (soubor /etc/inittab) dále řídí start a konfiguraci systému což obvykle zahrnuje kontrolu souborového systému kořenového svazku, znovupřipojení kořenového svazku v režimu pro zápis, kontrolu a připojení ostatních svazků, inicializace dalšího hardware a v závěrečné fázi startu systému spuštění dalších procesů podle konfigurace (obvykle minimálně getty, který na konzoli čeká na přihlášení uživatele, případně další systémové procesy běžící na pozadí může také spustit manažer grafického prostředí X Window System jako je v případě Mission gdm Gnome Display Manager (nebo jeho alternativy kdm či starší xdm). Podrobným popisem fungování programu init se zde nebudeme zabývat, pouze dodejme, že Linuxové distribuce většinou (včetně Linuxu Mission) používají init odvozený od Systému V (na rozdíl od initu používaného v systémech BSD). Další informace týkající se fungování initu a úrovni běhu systému čtenář nalezne v programové dokumentaci. Proces init má PID (číslo procesu 1) a zůstává pak na vrcholu hierarchie procesů rodičovským procesem pro všechny další spouštěné procesy.

6.4.1 Initrd, prvotní koř enový svazek a skript linuxrc Výše uvedený popis ovšem vychází z předpokladu, že samotné jádro přímo obsahuje ovladače hardware potřebné pro počáteční inicializaci systému mimo jiné ovladač řadiče pevného disku, na kterém se nachází kořenový svazek. Vzhledem k tomu, že systém je obvykle zaváděn z pevného




disku a přitom existuje velké množství zejména SCSI řadičů z nichž každý používá odlišný ovladač, je pochopitelné, že nelze kvůli limitované velikosti jádra sestavit takové monolitické jádro, které by obsahovalo podporu pro všechen běžně používaný hardware. V minulosti se tento problém řešil tím, že existovalo několik variant bootovacích disket, uživatel si pak pro instalaci systému vybral tu, která obsahovala jádro s podporou odpovídajícího hardware. Dnes ovšem při instalaci systému vystačíme s jedním jádrem, modulárním. Problém tkví v tom, jakým způsobem patřičný modul do jádra zavést, když během startu jádra ještě není připojen kořenový svazek na kterém jsou moduly uloženy. Tento problém se řeší za pomocí ramdisku a speciálního blokového zařízení /dev/initrd. Celé to funguje tak, že zavaděč systému současně s jádrem zavede do paměti i komprimovaný obraz prvotního kořenového svazku ("initial root") a tento je pak pro jádro dostupný právě pomocí zařízení /dev/initrd. Jádro pak komprimovaný obraz prvotního kořenového svazku načte z /dev/initrd, rozbalí jej a uloží do normálního ramdisku (zařízení /dev/ram0, paměť kterou zabíral /dev/initrd je pak možné uvolnit). Souborový systém je pak ze zařízení /dev/ram0 připojen jako prvotní souborový systém v režimu pro čtení i zápis. Pokud na tomto svazku existuje spustitelný soubor linuxrc, jádro jej spustí (obvykle se jedná o skript na prvotním kořenovém svazku je pak také uložena speciální omezená verze příkazového interpretu). Na prvotním kořenovém svazku také mohou být obsaženy potřebné moduly, které jsou prostřednictvím skriptu linuxrc zavedeny da jádra. Po vykonání skriptu linuxrc jádro dle konfigurace připojí namísto prvotního kořenového svazku "normální" kořenový svazek. Pokud na tomto regulérním kořenovém svazku existuje adresář /initrd, je obsah prvotního kořenového svazku přesunut do tohoto adresáře takže může zůstat nadále dostupný. Protože je již připojen regulérní kořenový svazek, jádro dokončí start systému spuštěním programu init, tak jak je popsáno výše.

6.4.2 Jak vytvoř it obraz initrd Abychom pochopili, jak initrd funguje, popíši zde nejprve ruční postup vytvoření obrazu prvotního kořenového svazku. Následně přijde na řadu utilita mkinitrd, která initrd usnadňuje. Nejjednodušší metodou jak vytvořit obraz prvotního kořenového svazku je s použitím zařízení "loop", které umožňuje připojit souborový systém uložený nikoliv na fyzickém blokovém zařízení, ale v souboru (detaily viz např. manuálová stránka příkazu mount). Nejprve si tedy vytvoříme soubor potřebné velikosti. [root@mission /tmp]# dd if=/dev/zero of=initrd bs=300k count=1

.. a pomocí mke2fs v něm vytvoříme souborový systém (je vhodné použít volbu -m0, protože šetříme místem a je zytečné rezervovat část svazku): [root@mission /tmp]# mke2fs -F -m0 initrd




Poté jej příkazem mount připojíme: [root@azucar /tmp]# mount -t ext2 -o loop initrd /mnt

Nyní již připravíme adresářovou strukturu a nakopírujeme potřebné soubory, celý svazek může vypadat např. takto příklad uvádí obsah prvotního kořenového svazku používaného pro boot systému, kde je kořenový svazek umístěn na zařízení /dev/md0 (jedná se o diskové pole realizované jaderným ovladačem softwarového RAIDu typu RAID 1). Adresář /bin obsahuje příkazový interpret nash a utilitu insmod pro zavádění modulů do jádra (obojí staticky linkované). Adresář /dev obsahuje minimální sadu souborů reprezentujících speciální zařízení, které potřebujeme. Disky tvořící RAID svazek jsou připojeny k řadiči Symbios 53C1010 a proto je zde (v adresáři /lib) i potřebný ovladač modul sym53c8xx.o a samozřejmě ovladač SCSI disků sd_mod.o a podpora SCSI zařízení obecně modul scsi_mod.o. Dále potřebujeme patřičný ovladač raidu modul raid1.o. Boot systému řídí skriptu linuxrc, kterému se budeme detailně věnovat níže. Adresář /sysroot nám poslouží jako přípojný bod normálního kořenového svazku (potřebujeme jej v případě, že použijeme volání jádra pivot_root, toto ještě upřesníme níže). |-| | | |-| | | | | | | | | |-|-| | | | | | |-|-|-|-`--

bin |-- insmod |-- modprobe -> /sbin/nash `-- nash dev |-- console |-- md0 |-- null |-- ram |-- systty |-- tty1 |-- tty2 |-- tty3 `-- tty4 etc lib |-- sym53c8xx.o |-- ext3.o |-- jbd.o |-- raid1.o |-- scsi_mod.o `-- sd_mod.o linuxrc loopfs proc sbin -> bin sysroot

Jakmile máme prvotní kořenový svazek připraven, můžeme je pomocí programu gzip komprimovat. Pak zbývá nakonfigurovat zavaděč systému tak, aby komprimovaný obraz prvotního kořenového svazku zavedl jako initrd současně s jádrem. Používámeli jako zavaděč systému www.linuxzone.cz strana 88 / 159



GRUB, uplatníme v konfiguračním souboru grub.conf direktivu initrd např. takto: # soubor grub.conf # # Note that you do not have to rerun grub after making changes to this file # NOTICE: You have a /boot partition. This means that # all kernel and initrd paths are relative to /boot/, eg. # root (hd0,0) # kernel /vmlinuz-version ro root=/dev/md2 # initrd /initrd-version.img default=0 timeout=10 splashimage=(hd0,0)/grub/splash.xpm.gz title Mission (2.4.22-1.2188.lz.1.nptl) root (hd0,0) kernel /vmlinuz-2.4.22-1.2188.lz.1.nptl ro root=/dev/md2 rhgb initrd /initrd-2.4.22-1.2188.lz.1.nptl.img

Používámeli jako zavaděč OS LILO, opět uplatníme v konfiguračním souboru direktivu initrd a soubor lilo.conf může vypadat např. takto: # soubor lilo.conf # boot=/dev/md0 map=/boot/map install=/boot/boot.b prompt timeout=50 default=mission image = /bzImage label = mission initrd = /boot/initrd.gz root=/dev/md0 read-only

6.4.3 Skript linuxrc, interpret nash Soubor linuxrc, který jádro spustí po připojení prvotního kořenového svazku může být jakýkoliv spustitelný soubor ale obvykle se jedná o skript pro nějaký odlehčený příkazový interpret konkrétně v Mission se jedná o interpret nash. Ten podporuje jen několik málo vestavěných příkazů, jako je echo, mount, /umount, raidautorun, mkrootdev a pivot_root. (viz manuálová stránka interpretu nash). Skript linuxrc se postará o natažení potřebných modulů a inicializaci RAID svazku a v našem příkladu může vypadat např. takto: #!/bin/nash # Natažení podpory SCSI insmod /lib/scsi_mod.o # Natažení ovladače SSI disků




insmod /lib/sd_mod.o # Natažení ovladače řadiče Symbios 53C1010 insmod /lib/sym53c8xx.o # Natažení ovladače RAID 1 insmod /lib/raid1.o # Natažení ovladačů souborového systému ext3 insmod /lib/jbd.o insmod /lib/ext3.o # Připojení souborového systému /proc mount -t proc /proc /proc # Vyvolání autodetekce diskových polí softwarého RAIDu raidautorun /dev/md0 # Vytvoření blokového zařízení reprezentujícího skutečný kořenový svazek # (předali jsme jej jádru jako parametr prostřednictvím zavaděče systému) mkdevices /dev mkrootdev /dev/root # poté, co jsme v předchozím kroku zjistili kde se nachází skutečný kořenový # a vytvořili jsme odpovídající blokové zařízení jako /dev/root # nastavíme umístění kořenového svazku v jádře na /dev/ram0 # (tím zajistíme, že se neuplatní mechanismus change root - vysvětelní viz # text dále) echo 0x0100 > /proc/sys/kernel/real-root-dev # připojíme skutečný kořenový svazek mount -o defaults --ro -t ext3 /dev/root /sysroot # nyní vyvoláme záměnu prvotního kořenového svazku umístěného na ramdisku # initrd za skutečný kořenový svazek pivot_root /sysroot /sysroot/initrd # odpojíme /proc (po záměně kořenového svazku je dostupný jako /initrd/proc) umount /initrd/proc

6.4.4 Změna kořeno vého svazku change_root nebo pivot_root Nyní se podíváme, jakým způsobem dochází k záměně prvotní kořenového svazku za regulérní kořenový svazek. Nejprve si připoměňme, jakým způsobem jádru sdělujeme, odkud má připojit normální kořenový svazek. Zde máme na výběr z několika možností. Jednak se při sestavení jádra uloží do jeho obrazu výchozí nastavení (podle aktuálního umístění kořenového svazku v době kompilace), toto nastavení můžeme změnit pomocí utility rdev. Dále můžeme předat jádru při startu parametr ve formátu "root=zařízení" (toto je obvyklý způsob), o předání tohoto parametru se obvykle postará zavaděč systému (viz dokumentace zavaděče systému). Pokud při bootování používáme ramdisk initrd, máme ještě jednu možnost: svazek odkud se má připojit normální kořenový svazek můžeme specifikovat během vykonávání skriptu linuxrc zápisem do / proc/sys/kernel/real-root-dev (k tomu samozřejmě musíme nejprve souborový systém /proc připojit). A teď už pojďme k popisu mechanismu nahrazení prvotního kořenového svazku normálním kořenovým svazkem. Aby to nebylo tak jednoduché, současná jádra podporují dva mechanismy. Starší mechanismus (označovaný jako "change_root") funguje tak, že po ukončení vykonávání skriptu linuxrc jádro připojí regulérní kořenový svazek a prvotní kořenový svazek (pokud jej ještě




některý proces používá a na normálním kořenovém svazku existuje adresář /initrd) přesune do adresáře /initrd v normálním kořenovém svazku. Touto variantou se zabývat nebudeme, protože mechanismus change_root je jádrem podporován jen kvůli zpětné kompatibilitě se staršími systémy. Druhý, novější mechanismus se nazývá "pivot_root". V tomto případě se skript linuxrc po zavedení potřebných modulů postará ještě o následující: • •

•

•

vytvoření přípojného místa pro regulérní kořenový svazek, připojení regulérního kořenového svazku na přípojné místo (na tomto svazku musí existovat přípojný bod pro prvotní kořenový svazek, zpravidla se k tomuto použije adresář initrd v kořenu), přes /proc/sys/kernel/real-root-dev nastaví umístění kořenového svazku na / dev/ram0 tímto zajistíme, že po ukončení skriptu linuxrc se už neuplatní mechnismus change root, který jádro podporuje z důvodů zpětné kompatibility. provede volání jádra pivot_root, které vyvolá změnu kořenového svazku.

6.4.5 Mkinitrd nástroj pro generování initrd Pokud vám to doposud připadalo složité, nezoufejte. Současné Linuxové distribuce používají modulární jádra, ovšem aby uživatel nemusel po rekompilaci jádra obraz initrd pracně vytvářet manuálně, tak jak jsme to popsali výše, používá se utilita mkinitrd. Za předpokladu, že nebudete používat nějaké velmi netradiční konfigurace systému se ručním úpravám ramdisku initrd nemusíte obávat. Nástroj mkinitrd je skript, který ze souboru /etc/fstab zjistí na jakém zařízení se nachází kořenový svazek a ze souboru /etc/modules.conf načte seznam používaných modulů. Na základě toho pak sám vygeneruje komprimovaný obraz initrd. Na uživateli pak je aby obraz ramdisku umístil do adresáře boot a upravil konfiguraci zavaděče. Cílem této části manuálul bylo přiblížit proces bootování modulárního jádra a přípravu obrazu ramdisku initrd, další informace čtenář nalezne v příslušné programové dokumentaci (manuálové stránky initrd(4), nash(8), pivot_root(2), pivot_root(8), mkinitrd(8) a také dokumentaci jádra soubor linux/Documentation/initrd.txt, linux/Documentation/kernelparameters.txt apod.).

6.5 Start systému: jakou roli hraje proces init? V předcházející kapitole jsme se měli možnost seznámit s mechanismem bootování jádra, na tuto kapitolu nyní volně navážu a budeme se zabývat další fází startu systému vysvětlíme roli procesu init a způsoby, jakým jsou při startu konfigurovány a spouštěny služby.

6.5.1 Inicializace systému, hierarchie procesů Jakmile je do paměti nějakým způsobem jádro UN*Xového systému zavedeno a spuštěno provede jádro inicializaci svých interních datových struktur, inicializuje hardware, připojí kořenový svazek a




vytvoří prostředí procesu 0 systém dále běží jako proces 0 (zatím vše stále běží v režimu jádra). Proces 0 potom vytvoří potomka proces s PID 1, ten přejde z režimu jádra do uživatelského režimu a pomocí algoritmu exec spustí program uložený v souboru /etc/init anebo / sbin/init. Init (proces s PID 1) pak dále řídí start systému a v závislosti na konfiguraci spouští další služby. (Pozn.: různé varianty initu se instalují buď na jedno nebo na druhé místo, na což si musíme dát pozor pokud bychom nahrazovali init jeho jinou variantou). Cestu k programu init lze také předat při startu jádru jako parametr ve tvaru např. init=/sbin/init. Toto se nám může hodit, potřebujemeli z nějakého důvodu obejít standardní startovací sekvenci (např. po havárii systému, jeli pourušen program init). Pak můžeme namísto initu nechat jádro spustit přímo příkazový interpret (např. init=/bin/ash.static). V předchozím odstavci jsem použil několik důležitých pojmů, u kterých se v krátkosti zastavíme. Procesem je míněna běžící instance programu, v UN*Xových systémech (tedy systémech UNIX a systémech jim podobných včetně Linuxu) má každý proces přiděleno své číslo PID (Process ID). Proces standardně vzniká voláním jádra fork(). Původní proces, který fork() zavolá se nazývá rodičovským procesem (parent) a nově vytvořený proces se nazývá potomek (child). Vzniká tak hierarchie procesů, kde každý proces má svého rodiče (a tento je zaznamenán v kontextu procesu jako PPID procesu Parent Process ID). Proces může běžet buď v režimu jádra nebo v režimu uživatelském; proces může z režimu uživatelského přejít do režimu jádra pomocí tzv. volání jádra (např. již výše zmíněný fork() nebo exec()). Rozdíl mezi režimem jádra a režimem uživatelským je v tom, že v režimu jádra jsou přístupné i paměťové struktury jádra. Vidíme tedy, že proces 0 vzniká nestandardním způsobem jádro jej vytváří přímo bez použití algoritmu fork, teprve proces 1 (init) už vzniká obvyklou posloupností algoritmů fork (rozdvojení procesu) a následným uplatněním algoritmu exec (vykonání programu) v kódu potomka. Po spuštění initu se z procesu 0 stane tzv. swapper. Ve výpisu procesů běžících v systému bychom jej hledali marně, protože tento proces zůstane před uživatelem skrytý. Na vrcholu hierarchie procesů stojí proces s PID 1, tedy init. V případě, že je ukončen proces, jehož potomci v systému ještě existují, systém nastaví PPID (Parent Process ID) u těchto procesů na 1 jejich rodičem se pak tedy stane init.

6.5.2 Úroveň běhu systému (runlevel) Systém se vždy nachází v určité "úrovni běhu" systému (angl. runlevel). Program init podporuje 7 úrovní běhu, které jsou primárně označené číslicemi 0 až 6 (přesněji řečeno u některých variant initu je možné použít i úrovně 7 až 9, ovšem z historických důvodů se tyto nepoužívají). V každé úrovni jsou definovány určité služby, které se mají spustit, některé úrovně mají zvláštní význam (0 halt, zastavení systému; 6 reboot; 1 single user, jednouživatelský režim). Konkrétně v Linuxu Mission to funguje takto: • • •

0 "halt" zastavení systému, 1 "Single user mode" jednouživatelský režim užívaný pro administraci, 2 "Multiuser, without networking" víceuživatelský režim bez připojení k síti,



• • • •


3 "Full multiuser mode" víceuživatelský režim včetně připojení k síti, 4 "unused" standardně nepoužito, 5 "X11" totéž co úroveň 3 ale navíc spouští X, možnost přihlašování přímo v grafickém prostředí X Window System, 6 "reboot" restart systému.

Administrátor má možnost konfigurovat služby, které budou v daných úrovních běhu spouštěny, nastavit některou z úrovní běhu jako výchozí a samozřejmě i iniciovat přechod z jedné úrovně běhu systému do druhé.

6.5.3 BSD versus System V Existují dva přístupy ke konfiguraci programu init: první se historicky používal a používá v systémech odvozených od rodiny UNIXových systémů BSD a je jednodušší spouštění služeb, které v dané úrovni běhu systému mají běžet se realizuje v jednom skriptu. Druhá varianta vznikla a používá se v systémech odvozených od UNIX System V. Tato varianta je sofistikovanější (neříkám, že lepší, o tom, která z variant je lepší vedou admini s chutí od nepaměti sáhodlouhé spory). Funguje to tak, že pro každou úroveň běhu je vyhrazen určitý adresář, do kterého se umisťují buď skripty nebo odkazy na skripty, které startují jednotlivé služby a v momentě přechodu do dané úrovně se skripty v určeném pořadí vykonají. Cílem autorů initu ze Systému V bylo vyhnout se potenciálním nepříjemnostem, ke kterým může dojít pokud se třeba při automatické instalaci software zasahuje do startovacích skriptů pokud je ten skript jeden, pak chybný zásah do skriptu (třeba syntaktická chyba apod.) může při startu způsobit větší problémy než pouhé přidání dalšího skriptu do určeného adresáře (tady se v nejhorším případě prostě nová služba nespustí, ale jinak vše poběží tak jako dříve). Cenou za toto drobné zvýšení robustnosti je menší přehlednost tohoto systému v případech, kdy je provozováno velké množství služeb. Tolik k historii, teď se vraťme zpátky k Linuxu. Protože Linux zahrnuje velké množství distribucí a mezi jejich tvůrci se vyskytovali jak přiznivci BSD systémů tak i uživatelé Systému V, můžeme si vybrat. Některé distribuce jako např. Slackware tíhnou k initu ve stylu BSD, jiné, např. Red Hat tradičně používají init blížící se initu ze Systému V a další, jako např. Suse, nechávají na administrátorovi aby si zvolil, který přístup se mu jeví vhodnější. Nyní se v krátkosti podíváme jak to vypadá na Slackware (jako příklad konfigurace ve stylu BSD) a na Red Hatu (jako příklad konfigurace ve stylu System V). Jinak pro zkušenějšího administrátora samozřejmě není problém standardní init dodávaný s distribucí vyměnit za jiný, ovšem tím se zde zabývat nebudu, případní zájemci veškeré potřebé informace stran fungování initu naleznou v programové dokumentaci, příručkách distribucí apod.

6.5.4 Konfigurace init v Linuxu Mission Nejprve se podívejme, co a v jakém pořadí init provede:



•

• • •


z konfiguračního souboru /etc/inittab init zjistí, jaká je výchozí úroveň běhu systému a cestu ke skriptu, který má být vykonán po bootu systému (obvykle je to skript / etc/rc.d/rc.sysinit) spustí skript /etc/rc.d/rc.sysinit spustí všechny skripty v patřičném adresáři odpovídajícím výchozí úrovni běhu systému (posledním skriptem v tomto adresáři obvykle je rc.local) na závěr spustí programy definované v souboru /etc/inittab

6.5.5 Konfigurační soubor /etc/inittab Tento konfigurační soubor má jednoduchou syntaxi, kterou si nejlépe přiblížíme na následujícím příkladu. Každý řádek obsahuje několik údajů, jako je identifkátor položky, úroveň nebo i více úrovní běhu, při které se uplatní, způsob spouštění služby a cesta k programu, který má být spuštěn. Pokud jde o způsob spouštění např. můžeme specifikovat, že se má daný program (či skript) vykonat pouze jednou při startu systému (např. skript rc.sysinit), nebo že má být program po jeho ukončení opět spouštěn ve smyčce stále znovu (např. getty). Nebudeme se zde zabývat detailním popisem jednotlivých položek v konfiguračním souboru /etc/inittab, detaily čtenář nalezene v příslušné manuálové stránce. # zde nastavíme výchozí úroveň běhu systému, do které systém naběhne id:5:initdefault: # cesta ke skriptu, který se spouští při bootu si::sysinit:/etc/rc.d/rc.sysinit # zde definujeme, který skript init spustí po vstupu do # určité úrovně běhu, tento skript pak prochází příslušný adresář # a zapíná/vypíná služby l0:0:wait:/etc/rc.d/rc 0 l1:1:wait:/etc/rc.d/rc 1 l2:2:wait:/etc/rc.d/rc 2 l3:3:wait:/etc/rc.d/rc 3 l4:4:wait:/etc/rc.d/rc 4 l5:5:wait:/etc/rc.d/rc 5 l6:6:wait:/etc/rc.d/rc 6 # při stisku CTRL-ALT-DELETE spustíme regulérní shutdown # (jádro zašle pro stisku této kombinace kláves initu signál SIGINT) ca::ctrlaltdel:/sbin/shutdown -t3 -r now # pokud obdržíme signál od UPS, že byla dodávka el. proudu # přerušena, spustíme shutdown s rezervou 2 minut pf::powerfail:/sbin/shutdown -f -h +2 "Power Failure, shuttdown" # pokud je dodávka napájení obnovena, zrušíme běžící shutdown pr:12345:powerokwait:/sbin/shutdown -c "Power Restored" # poznámka: init reaguje na signál SIGPWR, dnes ale # obvykle spuštění shutdownu v případě výpadku napájení # obstarává přímo obslužný software UPS a nikoliv init #

v úrovních 1 až 5 spustíme na na virtuálních konzolích 1 až 6




# program mingetty a umožníme tím přihlášení v textovém režimu 1:2345:respawn:/sbin/mingetty tty1 2:2345:respawn:/sbin/mingetty tty2 3:2345:respawn:/sbin/mingetty tty3 4:2345:respawn:/sbin/mingetty tty4 5:2345:respawn:/sbin/mingetty tty5 6:2345:respawn:/sbin/mingetty tty6 # v úrovni 5 spustíme správce displeje, který se postará o přihlášení # do systému v grafickém prostředí X Window System, poběží na virtuální # konzoli číslo 7, neboť tato je první volná # (prvních 6 obsadí program mingetty) x:5:respawn:/etc/X11/prefdm -nodaemon

Malá odbočka na vysvětlenou přihlášení uživatele na textovou konzoli probíhá následovně: init spustí program getty, ten na konzoli vypíše výzvu "login:" a čeká na zadání jména uživatele. Poté co uživatel zadá jméno, proces getty vyvolá exec() a je nahrazen programem login (ovšem stále se jedná o tentýž proces, z pohledu initu tedy pořád běží). Program login se postará o autentizaci, autorizaci a přihlášení uživatele a následně pomocí fork() a exec() vytvoří nový proces a spustí příkazový interpret (shell). Jakmile uživatel chce ukončit práci se systémem, ukončí příkazový interpret, rodičovský proces login to zjistí a uživatele odhlásí. Init nyní zaregistruje ukončení procesu a znovu spustí getty.

6.5.6 Startovací skripty rc.sysinit a rc.local Skript /etc/rc.d/rc.sysinit se vykonává jen jednou a to při startu systému. Postará se obvykle o takové věci, jako je kontrola a připojení dalších svazků (na počátku je připojen pouze kořenový svazek), nastavení parametrů jádra, natažení mapy klávesnice, natažení ovladačů (modulů jádra), aktivace odkládácího prostoru (swapu) atd. Skript /etc/rc.d/rc.local se obvykle spouští až v závěru startovací sekvence bývá nalinkován v adresářích úrovní běhu jako poslední. Je možné do něj vložit různá dodatečná nastavení apod. Také jej lze s výhodou použít jako náhradu startovacího skriptu BSD initu pokud nám styl initu ze Systému V nevyhovuje, prostě budeme BSD init simulovat tak, že budeme spouštění veškerých služeb vepisovat pouze do tohoto souboru a v konfiguračním souboru / etc/inittab prostě do vybraných položek l[15] v souboru /etc/inittab uvedeme rovnou tento skript. Musíme se však smířit s tím, že instalační balíčky s tím nepočítají a tedy to budeme muset dělat ručně.

6.5.7 Definování služeb v jednotlivých úrovních běhu Nyní si probereme okomentovanou adresářovou strukturu se soubory, které init ke své práci používá: /etc/rc.d/



|-| | | | |-|-|-|-| | | | | | | |-| | | | | | | | | |-| | | | |-| |-| |-| `--


init.d |-- anacron |-- apcupsd |-- apmd `-- [ .. zkráceno .. ] rc rc.local rc.sysinit rc0.d |-- K01yum -> ../init.d/yum |-- K03messagebus -> ../init.d/messagebus |-- K05anacron -> ../init.d/anacron |-- K05atd -> ../init.d/atd [ .. zkráceno .. ] |-- S00killall -> ../init.d/killall `-- S01halt -> ../init.d/halt rc1.d |-- K01yum -> ../init.d/yum |-- K03messagebus -> ../init.d/messagebus |-- K05anacron -> ../init.d/anacron |-- K05atd -> ../init.d/atd [ .. zkráceno .. ] |-- K95kudzu -> ../init.d/kudzu |-- K96pcmcia -> ../init.d/pcmcia |-- K99microcode_ctl -> ../init.d/microcode_ctl `-- S00single -> ../init.d/single rc2.d |-- K01yum -> ../init.d/yum |-- K03messagebus -> ../init.d/messagebus |-- K05atd -> ../init.d/atd `-- [ .. zkráceno .. ] rc3.d `-- [ .. zkráceno .. ] rc4.d `-- [ .. zkráceno .. ] rc5.d `-- [ .. zkráceno .. ] rc6.d |-- K01yum -> ../init.d/yum |-- K03messagebus -> ../init.d/messagebus |-- K05anacron -> ../init.d/anacron |-- K05atd -> ../init.d/atd |-- [ .. zkráceno .. ] |-- K95kudzu -> ../init.d/kudzu |-- K96pcmcia -> ../init.d/pcmcia |-- K99microcode_ctl -> ../init.d/microcode_ctl |-- S00killall -> ../init.d/killall `-- S01reboot -> ../init.d/halt

V adresáři /etc/rc.d/init.d jsou uloženy vlastní startovací skripty jednotlivých služeb, tyto skripty jsou pak podle potřeby volány s argumentem start či stop podle toho, máli se daná služba spustit anebo ukončit. Tyto skripty spouští init automaticky při přechodu mezi úrovněmi běhu systému, také je může spouštět adminstrátor a podle potřeby pak služby kdykoliv restartovat, www.linuxzone.cz strana 96 / 159



vypnout apod. Pokud budeme chtít např. spustit webový server apache, provedeme to na standardní instalaci Linux Mission příkazem /etc/rc.d/init.d/apache start. Tyto skripty mohou umět vypisovat i iformace o stavu služby (např. /etc/rc.d/init.d/apache status nám sdělí, zda apache běží a případně vypíše čísla běžících procesů apache). Tato funkčnost ale není z pohledu fungování initu potřebná z pohledu initu skript musí akceptovat pouze parametry start a stop. Takový minimalistický skript může vypadat třeba následovně (v reálu bychom "service_daemon" nahradili názvem aplikace služby): #!/bin/sh case "$1" in start) echo "Starting service:" service_daemon && echo "service_daemon" echo touch /var/lock/subsys/service ;; stop) echo "Shutting down service:" /usr/bin/killall service_daemon && echo "service_daemon" echo rm -f /var/lock/subsys/service ;; *) echo "Usage: service {start|stop}" exit 1 esac exit 0

Tento příklad je minimalistický, ale funkční. Startovací skripty služeb dodávaných s Mission využívají knihovnu funkcí definovaných v souboru /etc/init.d/functions, detaily použití viz kterýkoliv startovací skript v /etc/init.d. Startovací skripty jsou pak pomocí symbolických odkazů linkovány do adresářů jednotlivých úrovní /etc/rc.d/rc[0-6].d/. Skripty odkazované v těchto adresářích pak init spouští automaticky při přechodu mezi úrovněmi běhu systému. Např. máme li nastavenou jako výchozí úroveň běhu systému (runlevel) úroveň 5, init postupně spustí skripty umístěné (nebo prolinkované, což je pohodlnější) do adresáře /etc/rc.d/rc5.d. Služby by ovšem měly být spouštěny v určitém pořadí a init také musí nějak poznat, jestli má určitou službu v dané úrovni spustit nebo vypnout. Podívámeli se na příklad zkráceného výpisu adresáře /etc/rc.d/rc5.d, všimneme si na první pohled podivných názvů odkazů: lrwxrwxrwx lrwxrwxrwx lrwxrwxrwx lrwxrwxrwx lrwxrwxrwx

1 1 1 1 1

root root root root root

root root root root root

13 19 13 14 13

čec čec čec čec čec

23 23 23 23 23

16:35 16:31 16:34 16:33 16:36

K01yum -> ../init.d/yum K05saslauthd -> ../init.d/saslauthd K20nfs -> ../init.d/nfs K24irda -> ../init.d/irda K35smb -> ../init.d/smb



lrwxrwxrwx 1 root [ .. zkráceno lrwxrwxrwx 1 root [ .. zkráceno lrwxrwxrwx 1 root lrwxrwxrwx 1 root lrwxrwxrwx 1 root lrwxrwxrwx 1 root lrwxrwxrwx 1 root

root .. ] root .. ] root root root root root


19 čec 23 16:43 K35vncserver -> ../init.d/vncserver 17 čec 23 16:31 S10network -> ../init.d/network 13 17 13 20 11

čec čec čec čec čec

23 23 23 23 23

16:38 16:32 16:33 16:37 16:31

S90xfs -> ../init.d/xfs S95anacron -> ../init.d/anacron S95atd -> ../init.d/atd S97messagebus -> ../init.d/messagebus S99local -> ../rc.local

Právě podle jména odkazu init poznáme, co se má se skriptem dělat. Začínáli na "K" (Kill), znamená to "tuto službu při vstupu do úrovně vypni". Naopak začínáli odkaz na "S" (Start), znamená to "tuto službu při vstupu do úrovně zapni". Pořadí je pak dáno číslem v názvu souboru, posloupnost je tedy stejná, jako vidíme ve výpisu adresáře. Po vstupu do úrovně běhu 5 tedy se tedy nejprve spustí skripty K01yum s parametrem "stop", poté K05saslauthd a tak dále až povypíná všechny služby, které má vypnout. Pak dojde ke skriptu S10network, který už spustí s parametrem "start" a skončí spuštěním skriptu S99local. Pozorný čtenář si jistě povšimnul, že jsem se v předchozím popisu pro zjednodušení dopustil jedné nepřesnosti: o spouštění skriptů v adresářích /etc/rc.d/rc[0-6].d/ se nestará init přímo, ten pouze volá skript /etc/rc.d/rc a jako argument mu předá číslo úrovně běhu (viz položky l0 až l6 v souboru inittab).

6.5.8 Chkconfig zjednodušení manipulace s odkazy Pokud se Vám zdá přímá manipulace se symbolickými odkazy příliš nepohodlná, můžete využít utilitu chkconfig. Autor tohoto nástroje se inspiroval nástrojem stejného jména v operačním systému Irix (což je UNIX System V firmy SGI). Chkconfig funguje tak, že ze startovacích skriptů služeb umístěných v /etc/rc.d/init.d načte zakomentovaný řádek s řetězcem chkconfig, viz úryvek skriptu /etc/rc.d/init.d/xinetd: #!/bin/bash # # xinetd This starts and stops xinetd. # # chkconfig: 345 56 50 # description: xinetd is a powerful replacement for inetd. [ ... zkráceno...]

Vidíme zde trojici čísel, která znamená následující: xinetd bude spouštěn v úrovních 3,4,5, startovací skript bude mít pořadí při spouštění 56 (v adresářích úrovní 3 až 5 bude tedy odkaz S56xinetd --> ../init.d/xinetd) a pořadí při vypínání bude mít 50 (v adresářích úrovní 0,1 a 6 bude odkaz K50xinetd --> ../init.d/xinetd). Následující příklad ukazuje část výpisu příkazu chkconfig --list, kde vidíme skutečně vidíme, že xinetd bude zapnut v úrovních 3,4 a 5:



xfs xinetd cups

0:off 0:off 0:off

1:off 1:off 1:off


2:on 2:off 2:on

3:on 3:on 3:on

4:on 4:on 4:on

5:on 5:on 5:on

6:off 6:off 6:off

Samozřejmě, Linux Missio také obsahuje nástroj s grafickým rozhraním, které umožňuje konfigurovat úrovně běhu a spouštěné služby jedná se o utilitu redhat-config-services:

Prostřednictvím tohoto nástroje je možné editovat úrovně běhu 3 až 5 (do konfigurace ostatních totiž není obykle nutné zasahovat).

6.5.9 Nastavení prostř edí spouštěných procesů /etc/initrc Pokud bychom chtěli modifikovat prostředí procesů, které init spouští přímo (tedy jsou uvedeny v konfiguračním souboru /etc/inittab), můžeme vytvořit skript /etc/initscript. V tomto skriptu nastavíme prostředí a následně jej pomocí exec nahradíme procesem, takový skript může vypadat takto: # #

nastavíme prostředí, init předá při spuštění 4 argumenty: #

takže bychom mohli prostředí nastavit odlišně pro různé případy

umask 022 ulimit -c 0 PATH=/bin:/sbin:/usr/bin:/usr/sbin export PATH # nahradíme skript zadaným programem (čvrtý argument skriptu) eval exec "$4"




6.5.10 Ovládání initu, př echod z jedné úrovně do druhé Protože init jako proces 1 musí být spuštěn po celou dobu běhu systému a nemůžeme jej jednoduše restartovat, musí existovat mechanismus, jak initu sdělit, že je potřeba znovu načíst konfigurační soubor nebo že má systém převést do jiné úrovně běhu. Máme zde na výběr ze dvou možností. První (omezenou) možností, je zaslání určitého signálu procesu init (po zaslání signálu SIGHUP init načte ze souboru /etc/initrunlvl nebo /var/log/initrunlvl nové číslo úrovně běhu). Druhou, preferovanou možností je použití utility telinit, se kterou init komunikuje přes rouru /dev/initctl. Pro přechod do úrovně běhu 3 bychom zadali telinit 3. Pokud bychom provedeme změny v konfiguraci /etc/inittab, vynutíme si znovunačtení konfigurace příkazem telinit q. Další podronosti čtenář nalezne v příslušné manuálové stránce. (Jinak telinit je ve skutečnosti pouze symbolickým odkazem na binárku initu, v jakém režimu má fungovat (init nebo telinit) si init snadno otestuje pomocí svého PID pokud je jiné než 1, funguje jako telinit.) Výchozí úroveň běhu také můžeme zadat jako parametr při startu jádra a to jej pak předá initu pokud bychom tedy potřebovali např. obejít nastavení v souboru inittab a nabootovat systém rovnou do jednouživatelského režimu, zadáme na promptu zavaděče GRUB prostřednictvím příkazu kernel "1" jako parametr jádra. Linux Mission také obsahuje utilitu runlevel, která vypíše aktuální a předchozí úroveň běhu systému. Informace čerpá ze souboru /var/log/utmp), následující příklad znamená, že systém nabootoval rovnou do úrovně 5 (proto je místo hodnoty přechozí úrovně písmeno N): $ /sbin/runlevel N 5

7. Administrace systému 7.1 Správa software Linuxové distribuce obecně a stejně tak i Linux Mission, neobsahují jen vlastní operační systém obsahují také celou řadu aplikací. Množství software, který uživatel při instalaci systému instaluje, tak bývá dosti úctyhodné a je potřeba, aby byl po ruce nějaký nástroj, který správu instalovaného software zastřešuje. Jednotlivý software je distribuován formou tzv. softwarových balíčků (packages). Takovým balíčkem může být např. poštovní klient Evolution, který je konrétně s dodáván jako balíček evolution-1.4.5-7.lz.1. Už z názvu balíčku je jasné, o jakou verzi programu se jedná. Rozsáhlejší programové celky ovšem mohou být rozděleny i do více balíčků. Například kancelářský balík OpenOffice.org, který je s Linuxem Mission dodáván sestává ze tří balíčků:



• • •

7. Administrace systému

openoffice.org-i18n-1.1.0-16 obsahuje slovníky pro korekci pravopisu a lokalizace (národní prostředí), openoffice.org-libs-1.1.0-16 obsahuje sdílené knihovny používané jednotlivými applikacemi OpenOffice.org openoffice.org-1.1.0-16 obsahuje vlastní aplikace OpenOffice.org (textový procesor, tabulkový procesor a další...)

Linux Mission používá pro správu instalovaného software systém RPM. Tento systém si můžeme představit jako databázi, která obsahuje informace o softwarových balíčcích, které jsou v systému nainstalovány. Databáze obsahuje podrobné informace o tom, jaké konkrétní soubory přísluší jednotlivým instalovaným balíčkům a obsahuje také informace o závislostech mezi nimi t.j. pokud např. aplikace "X" potřebuje ke svému fungování knihovnu, která je součástí jiného softwarového balíčku "Y", bude před instalací "X" požadovat, aby byla nejprve instalován balíček "Y". Se systémem správy software RPM můžeme pracovat buď přímo (z příkazové řádky), nebo prostřednictvím dalšího, nadstavbového software. Všechny tyto nástroje si nyní postupně představíme.

7.1.1 Systém RPM Jak už jsem naznačil výše, jednou z možností je pracovat s RPM přímo z příkazové řádky. K dispozici máme několik nástrojů: •

•

• •

utilita rpmquery slouží k získání informací o balíčcích, např: rpmquery -l evolution vypíše seznam souborů, které obsahuje balíček poštovního klienta Evolution rpmquery -f /etc/ntp.conf vypíše ke kterému balíčku patří soubor /etc/ntp.conf rpmquery --whatrequires evolution vypíše, které jiné balíčky na Evolution závisejí rpmquery --requires evolution naopak vypíše, co potřebuje balíček Evolution utilita rpmverify slouží k ověření integrity instalovaného balíčku, např: rpmverify evolution ověří, zda je balíček evolution kompletní a zda v instalaci nedošlo k nějakým změnám rpmverify -a zkontroluje integritu všech instalovaných balíčků utilita rpmbuild slouží k sestavení balíčků ze zdrojových kódů instalaci nebo upgrade balíčku provedeme pomocí utility rpm, např: rpm -i evolution-1.4.5-7.lz.1.i386.rpm nainstaluje balíček ze souboru evolution-1.4.5-7.lz.1.i386.rpm rpm -Uvh evolution-1.4.5-7.lz.1.i386.rpm nahradí již instalovaný balíček evolution novější verzí ze souboru evolution-1.4.5-




7.lz.1.i386.rpm Přímá práce s rpm má ale své nevýhody tou hlavní je to, že při instalaci nových balíčků závislosti je na nás, abychom vyřešili případné závislosti. Proto tyto utility zpravidla pro instalaci software přímo nepoužíváme máme k dispozici další nástroje, které jsou mnohem komfortnější. Detailní popis těchto utilit uživatel nalezne v manuálové stránce rpm.

7.1.2 Přidá ní / odstranění software dováváného s Linux Mission Pohodnou manipulaci se software dováváným s Linux Mission poskytuje utilita redhatconfig-packages, kterou můžeme spustit z hlavního menu přes položky "Systémová nastavení" > "Přidat/odstranit aplikace" (při spuštění této utility budeme dotázáni na heslo uživatele root, protože obyčejní uživatelé nemohou zasahovat do konfigurace systému):

Rozhraní je obdobné tomu, s jakým jsme se setkali už při instalaci Mission. Softwarové balíčky jsou rozděleny do tématických skupin, kliknutím na odkaz "Detaily" otevřeme dialogocé okno s výpisem jednotlivých balíčků. Ty, které jsou již instalovány jsou v seznamu zatrženy. Chcemeli některý balíček přidat, jednoduše jej kliknutím myši označíme, chcemeli nějaký balíček odinstalovat, jednoduše jej kliknutím myši odznačíme. S případnými závislostmi mezi balíčky si nemusíme lámat hlavu, protože systém to vyřeší za nás pokud některý z balíčků, který jsme si k instalaci vybrali potřebuje ještě nějaké další, budou automaticky instalovány také. Jakmile jsme s výběrem balíčků i instalaci / odstranění hotovi, dialog zavřeme a pokračujeme stistem tlačítka "Aktualizovat". Poté se objeví okno s informacemi o tom, kolik balíčků bude instalováno / odinstalováno a kolik je k tomu zapotřebí volného místa na disku.




Nyní si ještě můžeme nechat zobrazit detaily (tady uvidíme, jaké další balíčky systém vybral k instalaci, aby vyhověl závislostem mezi balíčky, které jsme si zvolili) a pokud jsme spokojeni, potvrdíme zahájení instalace / odebrání balíčků stiskem tlačítka "Pokračovat". Pak už jen podle instrukcí vložíme potřebné instalační médium a počkáme, až bude instalace ukončena.

7.1.3 Yum Yum je velmi šikovný nástroj pro správu software a aktualizace systému. Jedná se o utilitu pracující v textovém režimu, se kterou lze pracovat interaktivně, ale také je možné jej spouštět na pozadí a s jeho pomocí provádět automatické updaty systému. Yum naváže spojení se serverem, na kterém se nachází úložiště dostupných balíčků a aktualizací pro danou verzi systému Mission (nemusíme nic konfigurovat, po instalaci systému je již vše nakonfigurováno jen pro úplnost, konfigurační soubor je umístěn v souboru yum.conf) a stáhne si potřebné informace o dostupných balíčcích. Na základě těchto informací pak sám vyřeší případné závislosti mezi balíčky, které hodláme instalovat / aktualizovat. Yum pracuje v několika režimech: www.linuxzone.cz strana 103 / 159


•


instalace: pokud bychom chtěli instalovat aktuální verzi balíčku recode, spustili bychom yum např. takto (nově instalujeme balíček recode): # yum install recode Gathering header information file(s) from server(s) Server: Linuxzone Linux 0.9 - i386 - Base Server: Linuxzone Linux 0.9 - i386 - Released Updates Finding updated packages Downloading needed headers Resolving dependencies Dependencies resolved I will do the following: [install: recode 3.6-12.0.i386] Is this ok [y/N]: y Running test transaction: Test transaction complete, Success! recode 100 % done 1/1 Installed: recode 3.6-12.0.i386 Transaction(s) Complete

•

update: v tomto režimu můžeme aktualizovat buď konkrétní balíček či skupinu balíčků, např. tímto příkazem spustíme aktualizaci balíčku gimp: # yum update gimp

anebo také můžeme yum nechat vyhledat všechny dostupné aktualizace a všechny instalované balíčky, pro které existují aktualizace updatovat najednou: # yum update

•

pokud chceme pouze zjistit, jestli existují aktualizace něčeho, co máme instalováno, spustíme yum takto: # yum check-update Gathering header information file(s) from server(s) Server: Linuxzone Linux 0.9 - i386 - Base Server: Linuxzone Linux 0.9 - i386 - Released Updates Finding updated packages Downloading needed headers Name Arch Version Repo ------------------------------------------------------------------------gimp i386 1:1.2.5-2 updates-released

•

V tomto příkladu vidíme, že bychom měli aktualizovat balíček gimp. pokud si chceme jen prohlédnout, jaké balíčky jsou dostupné či získat různé informace o



• •


dostupných balíčcích, spustíme yum v režimu list nebo info režim search lze využít k vyhledání balíčku, pokud si nepamatujeme jeho přesný název (yum vyhledá daný řetězec v názvech a popisech balíčků) pro odstranění balíčků slouží režim remove

Poznámka: Yum je velmi flexibilní nástroj, podrobný popis jeho možností najdete programvé dokumentaci. Při prvním spuštění si yum stahuje souhrnné informace o balíčcích (tzv. hlavičky), které jsou na daném serveru (úložišti) dostupné což nějakou chvíli trvá, pokud máte pomalé spojení do Internetu. Protože některé balíčky jsou poměrně velké, nemusí být stahování aktualizací tímto způsobem zejména pro uživatele používající vytáčené připojení k Internetu to pravé. V tom případě si lze vypomoci tím, že si potřebné aktualizace doneseme na CD a yum nakonfigurujeme tak, aby pracoval s lokálním úložištěm aktualizací (detaily viz programová dokumentace).

7.1.4 Instalace software tř etí strany Pokud chceme instalovat nějaký software, který není dodáván s OS Mission, je nejvhodnější získat jej ve formě .rpm balíčku. Ten pak nainstalujeme jednoduše tak, že otevřeme okno správce souborů a balíček otevřeme dvojklikem levého tlačítka myši. Nejprve se objeví dialogové okno, ve kterém jsme dotázáni na heslo uživatele root (obyčejný uživatel není oprávněn instalovat nový software). Jakmile heslo zadáme, objeví se okno se souhrnými informacemi o balíčku a stačí stiskem tlačítka "Pokračovat" potvrdit instalaci. U software, který není primárně určen pro Linux Mission (nebo jemu příbuznou distribuci Fedora Core 1) se může stát, že narazíme na problémy se závislostmi. Nabízíli výrobce software software ve staticky linkované verzi (t.j. nepoužívající sdílené knihovny), sáhneme v takovém případě po této verzi.

7.1.5 Upozornění na dostupnost aktualizací Linux Mission Pokud jsme připojeni k Internetu, ve stavovém panelu desktopu GNOME i KDE se ve výchozím nastavení nachází na pravém okraji ikona appletu, který signalizuje dostupnost aktualizací. Pokud jsou k dispozici aktualizace, svítí zde vykřičník v červeném poli, pokud na něj klikneme levým tlačítkem myši, otevřeme okno se seznamem dostupných aktualizací.

7.2 Vytvář ení uživatelů a skupin K vytváření uživatelských účtů a skupin slouží utilita redhat-config-users, kterou spustíme z hlavního menu přes "Systémová nastavení" > "Uživatelé a skupiny".




Nového uživatele v systému vytvoříme kliknutím na ikonu "Přidat uživatele", tím vyvoláme dialog, do kterého zadáme potřebné údaje: • • •

• •

• •

uživatelské jméno (z praktických důvodů by nemělo být příliš dlouhé, nesmí obsahovat háčky a čárky); plné jméno uživatele tato položka je nepovinná; heslo, tady platí, že bezpečné heslo by nemělo být triviální tedy mělo by obsahovat kombinaci malých a velkých písmen a čísel a to takovou, aby nebylo snadno uhodnutelné. Mělo by být také dostatečně dlouhé osm znaků postačuje; zvolíme výchozí přihlašovací shell t.j. příkazový interpret, který se spustí po přihlášení uživatele na textovou konzoli nebo v okně terminálu; zvolíme, zda chceme pro uživatele vytvořit domovský adresář, kde bude moci ukládat svoje data (domovské adresáře zpravidla vytváříme tak jak je přednastaveno jako podadresáře v / home); zvolíme, zda bude pro uživatele vytvořena také vlastní skupina; každý uživatel je v systému identifikován číslem UID (UserID), tady máme možnost zadat UID přímo ručně (pouze pro ty, kteří vědí co dělají pozor na to, abychom nechtěně nevytvořili dva účty se stejným UID).




Obdobně novou skupinu uživatelů založíme kliknutím na ikonu "Přidat skupinu". V tom případě pouze zadáme název skupiny a volitelně můžeme ručně nastavit GID (GroupID). Z příkazové řádky můžeme nastavovat hesla uživatelů pomocí utility passwd, změnit shell můžeme pomocí příkazu chsh. Pro úplnost doplním, že konfigurační soubory týkající se uživatelských účtů jsou umístěny v /etc/passwd (seznam uživatelů), /etc/group (seznam skupin) a /etc/shadow (soubor se stínovými hesly).

7.3 Konfigurace sítě Pokud jsme při instalaci Mission nekonfigurovali síťová zařízení anebo prostě chceme konfiguraci sítě změnit, použijeme utilitu "Nastavení sítě" (redhat-config-network). Najdeme ji přes položky "Systémová nastavení" > "Síť" hlavního menu. Před spuštěním tohoto nástroje se nás systém dotáže na heslo uživatele root, protože obyčejní uživatelé nemohou měnit konfiguraci sítě. Chcemeli upravit konfiguraci některého zařízení, vybereme jej myší a stiskneme tlačítko "Upravit".




Pro vytvoření nového síťového připojení použijeme tlačítko "Nový" a následně vybereme typ síťového zařízení (ethernet, modem, ...).

7.3.1 Konfigurace zař ízení v síti Ethernet V případě připojení k síti Ethernet pak v dalším kroku zvolíme: • • •

zda se má zařízení automaticky aktivovat po startu počítače, zda budou obyčejní uživatelé smět toto zařízení zapínat a vypínat (např. pomocí "Systémové nástroje" > "Ovládání síťových zařízení" z hlavního menu) zda pro konfiguraci daného síťového zařízení budeme využívat protokol DHCP anebo budeme síťové zařízení konfigurovat ručně. (Protokol DHCP umožňuje prostřednictvím DHCP serveru v síti automaticky přidělovat klientům IP adresy a předat další parametry nastavení sítě jako je výchozí brána či servery DNS apod.)

Pokud jsme zvolili ruční konfiguraci síťového rozhraní, vyplníme parametry síťového rozhraní jako je IP adresa a maska sítě a zpravidla také adresu výchozí brány (t.j. brány, přes kterou bude směrován veškerý provoz směřující mimo lokální síť.)




Nyní můžeme konfiguraci uložit a zkusit nově nakonfigurované zařízení aktivovat.

7.3.2 Konfigurace vytáčeného připo jení V případě konfigurace vytáčeného připojení (dialup) zvolíme v prvním kroku jako typ zařízení modem a dále pokračujeme takto: •

• •

nejprve se systém pokusí modem detekovat a následně nám předloží parametry vybraného zařízení; pokud se nepodaří systému modem detekovat, zobrazí chybové hlášení a v tom případě budeme muset cestu k zařízení upravit ručně (např. mámli externí modem připojen k prvnímu sériovému portu, bude se jednat o zařízení /dev/ttyS0). Lze zde také zvolit rychlost modemu, zda se bude při vytáčení používat tónová nebo pulsní volba apod. v dalším kroku pokračujeme vyplněním telefoního čísla, uživatelského jména a hesla (tyto údaje získáme od poskytovatele připojení) a ještě názvu poskytovatele připojení v dalším kroku zvolíme, zda nám bude automaticky přidělována IP adresa, nebo zda budeme používat statickou IP adresu (zpravidla je IP adresa přidělována dynamicky).




Nyní můžeme konfiguraci uložit a zkusit nově nakonfigurované zařízení aktivovat. Pokud jsme při konfiguraci povolili obyčejným uživatelům zařízení zapínat/vypínat, budou jej zapínat a vypínat pomocí "Systémové nástroje" > "Ovládání síťových zařízení" z hlavního menu.

7.3.3 Ostatní nastavení Pomocí záložky "DNS" v hlavním okně aplikace "Nastavení sítě" můžeme upravit konfiguraci resolveru, t.j. zadat IP adresy serverů služby DNS, kterých se bude náš systém dotazovat při překladu IP adres na doménová jména a naopak. Pomocí "Počítače" můžeme upravovat statický seznam IP adres a jmen počítačů (sem se obvykle zapisují IP adresy a jména počítačů umístěných na lokální síti).

7.3.4 Profily Zejména uživatelé přenosných počítačů ocení možnost definování síťových profilů, je tak možné definovat několik konfigurací sítě, mezi kterými je možné se přepínat.

7.4 Konfigurace tisku Konfiguraci tiskárny vyvoláme přes položky "Systémová nastavení" > "Tisk" z hlavního menu. Stisknutím tlačítka "Nový" spustíme konfiguraci nové tiskové fronty: •

nejprve vyplníme jméno fronty (bez mezer, pokud možno krátké) a volitelně popis,




•

v dalším kroku zvolíme, zda se jedná o lokální nebo síťovou tiskárnu a zvolíme zařízení, ke kterému je tiskárna připojena,

•

v předposledním kroku vybereme typ tiskárny (ovladač) buď v seznamu tiskáren najdeme podle výrobce přímo model odpovídající naší tiskárně, anebo můžeme zvolit ponechat jako výrobce volbu "Obecný" a vybrat některý z dostupných typů,



•


poté už jen potvrdíme souhrnné informace, po dokončení konfigurace systém odešle na tiskárnu testovací stránku a pokud je vše v pořádku, můžeme konfigurační nástroj opustit.

8. Grafické rozhraní X Window System Po startu systému Mission se na monitoru objeví úvodní obrazovka, kde je uživatel vyzván k zadání svého uživatelského jména a poté hesla. Pokud je uživatelské jméno i heslo zadáno správně (pozor na malá a velká písmena), je uživatel přihlášen a spustí se zvolené desktopové prostředí. Linuxové systémy totiž zpravidla disponují více než jedním desktopovým prostředím, která se mezi sebou liší organizací, ergonomií a filozofií práce. Znamená to, že uživatel si může vybrat, jaký typ a vzhled desktopu mu vyhovuje. Linux Mission obsahuje dva nejčastěji používané desktopy: GNOME a KDE. Jako implicitní (výchozí) je nastaven desktop GNOME.



8. Grafické rozhraní X Window System

V dolní části úvodní obrazovky je několik ikon, které zpřístupňují volbu jazyka, volbu sezení (výběr některého z dostupných desktopových prostředí), možnost ukončení běhu systému a možnost restartování systému.

8.1 Desktop GNOME Výchozí vzhled desktopu GNOME je ilustruje následující obrázek. V dolní části obrazovky je imístěn stavový a ovládací panel, který obsahuje spouštěč hlavního menu, zástupce běžně používaných kancelářských aplikací a další ovládací prvky, se kterými se seznámíme níže. V levé horní části obrazovky jsou pod sebou umístěny ikona reprezentující zástupce domovského adresáře přihlášeného uživatele ("Domov"), ikona "Začněte zde" zpřístupňuje některá nastavení systému a pod ní je umístěn koš.

8.1.1 Ovládací a stavový panel GNOME Následující obrázek ukazuje detail panelu. Panel GNOME ve výchozím nastavení obsahuje:

1. Spouštěč hlavního menu. Kliknutím na ikonu s logem Linuxu Mission vyvoláme hlavní




menu, pomocí kterého můžeme spouštět aplikace nebo provádět akce jako zamknutí obrazovky nebo odhlášení uživatele. 2. Spouštěč internetového prohlížeče Mozilla. 3. Spouštěč poštovního klienta Evolution. 4. Spouštěč aplikace OpenOffice.org Writer (textový procesor kompatibilní s aplikací Microsoft Word). 5. Spouštěč aplikace OpenOffice.org Impress (prezentace obdoba aplikace Microsoft PowerPoint). 6. Spouštěč aplikace OpenOffice.org Calc (tabulkový procesor kompatibilní s aplikací Microsoft Excel). 7. Přepínač pracovních ploch. Desktopová prostředí v Linuxových systémech zpravidla podporují tzv. virtuální pracovní plochy. Znamená to, že i když máme před sebou jen jednu obrazovku, můžeme pracovat s několika pracovními plochami jako kdybychom měli monitorů více. V daný okamžik na monitoru vidíme jen jednu z nich a prostřednictvím přepínače ploch se mezi nimi můžeme přepínat. V praxi tak můžeme mít na první ploše např. spuštěný kancelářský balík OpenOffice.org a na další ploše můžeme pracovat s Internetem atd. Ušetříme si tím neustálé zmenšování, zvětšování a přesouvání oken jednotlivých aplikací jednoduchým kliknutím myši jen přepínáme pracovní plochy. Okna aplikací lze samozřejmě mezi jednotlivýmí pracovními plochami přesouvat a to buď přes menu okna anebo přímo přetažením zmenšeného symbolu vybraného okna v přepínači ploch myší z jedné plochy na druhou. 8. Seznam oken spuštěných aplikací. Kliknemeli na tlačítko reprezentující zvolenou aplikaci levým tlačítkem myši, okno minimalizujeme (pokud bylo aktivní), vyvoláme okno aplikace na popředí (byloli překryto jinými okny nebo nebylo aktivní) anebo okno otevřeme (byli li minimalizované). Kliknemeli na tlačítko reprezentující zvolenou aplikaci pravým tlačítkem myši, vyvoláme menu jehož prostřednictvím můžeme opět provádět běžné operace jako např. okno aplikace minimalizovat, maximalizovat, zarolovat či měnit velikost okna. pracovní plochu. 9. Správce tisku. Kliknutím na ikonu vyvoláme rozhraní správce tisku, kde můžeme sledovat tiskovou frontu anebo upravit nastavení tiskáren. 10.ovladač hlasitosti. Prostřednictvím tohoto appletu můžeme ovládat zvukovou kartu. 11.Aktualizace systému. Tato ikona signalizuje, zda jsou dostupné aktualizace systému (pokud je systém připojen k Internetu a jsou dostupné aktualizace software, svítí červený vykřičník). 12.hodiny.

8.1.2 Ovládání oken Na dalším obrázku jsou označeny ovládací prvky oken aplikací:




1. Zde je přístupné menu, prostřednictvím kterého lze provádět všechny dostupné manipulace jako je minimalizace / maximalizace, změna velikosti okna, zarolování okna, přesun okna na jinou pracovní plochu apod. Abychom nemuseli kvůli každé takové akci vyvolávat menu, jsou nejčastější úkony rychle přístupné pomocí dalších ovládacích prvků. 2. Pomocí horní lišty okna můžeme oknem pohybovat po pracovní ploše (přidržením levého tlačítka myši), dvojklik na lištu způsobí zarolování (odrolování) okna a pomocí pravého tlačítka myši vyvoláme menu (stejně jako u 1). 3. Pomocí této ikony okno minimalizujeme (skryjeme). 4. Pomocí této ikony okno maximalizujeme (okno pokryje celou obrazovku). 5. Pomocí této ikony vyvoláme uzavření okna případně ukončení aplikace. 6. Přidržením levého tlačítka myši v tomto místě (ale také kdekoliv na hraně okna) můžeme měnit velikost okna. Aktivní okno, t.j. okno se kterým právě pracujeme je vždy zvýrazněno (odlišnou barva horní lišty). Chcemeli se přepnout do jiného okna, klikneme na něj myší. Alternativně můžeme mezi okny přepínat opakovaným stiskem kombinace kláves Alt+Tab.

8.1.3 Pracovní plocha Kliknemeli na pozadí pracovní plochy levým tlačítkem myši, vyvoláme tím pracovní menu, pomocí kterého můžeme na plochu umisťovat spouštěče (zástupce aplikací či složek), vytvářet nové složky (adresáře), otevřít okno správce souborů, spustit terminál s příkazovým interpretem (příkazová řádka), měnit pozadí pracovní plochy a také ručně připojovat / odpojovat diskety, média CD/DVD a další.




Pomocí levého tlačítka označujeme objekty na ploše a dvojklikem na zvolený objekt spustíme aplikaci (jednáli se o spouštěč aplikace), otevření složky ve správci souborů (jednáli se o adresář), otevření dokumentu atd.

8.1.4 Hlavní menu Jak už bylo řečeno výše, hlavní menu GNOME vyvoláme kliknutím na ikonu s logem Mission umístěnou v panelu úplně v levém dolním rohu obrazovky. V dolní části menu jsou důležité položky umožňující uzamknutí obrazovky (spustí se šetřič obrazovky a pro opětovné odemčení obrazovky bude vyžadováno zadání hesla uživatele) a dále položka odhlášení uživatele.

Z hlavního menu je možné spouštět buď již předdefinované aplikace, které jsou pro přehlednost rozděleny do tématických skupin (včetně systémových aplikací pro konfiguraci systému), anebo vyvolat dialog pro spuštění libovolné aplikace pomocí položky "Spustit aplikaci...". Takto můžeme spouštět aplikace s grafickým rozhraním, ale i nástroje pracující v textovém režimu (v tom případě zatrhneme volbu "Spustit v terminálu"). Aplikaci také můžeme předat ke zpracování libovolný soubor (viz položka "Spustit se souborem").




8.1.5 Správce souborů Nautilus Desktop GNOME obsahuje správce souborů Nautilus. Jak už bylo zmíněno výše, okno správce souborů vyvoláme např. kliknutím pravého tlačítka myši na pozadí pracovní plochy a zvolením položky "Otevřít nové okno" v pracovním menu, dvojklikem na ikonu "Domov", případně dvojklikem na zástupce jiné složky (adresáře) umístěného na pracovní ploše, nebo také z hlavního menu (položka "Domovský adresář"). Nautilus podporuje několk variant vyobrazení objektů (ikony, seznam, adresářový strom atd.) a samozřejmě také podporuje mechanismus "drag & drop" (t.j. přesun objektů přetažením myší).

8.1.6 Odhlášení ze systému Chcemeli ukončit práci se systémem, vyvoláme z hlavního menu položku "Odhlásit se". Tím otevřeme následující dialog, kde potvrdíme jednu ze tří možností: • • •

Odhlásit se: sezení uživatele bude ukončeno, uživatel odhlášen a objeví se opět přihlašovací obrazovka Linuxu Mission. Vypnout počítač: sezení uživatele bude ukončeno, uživatel odhlášen a následně bude ukončen běh systému. Restartovat počítač: sezení uživatele bude ukončeno, uživatel odhlášen, bude ukončen běh systému a počítač se restartuje.




8.2 Desktop KDE Jak už bylo řečeno dříve, Linux Mission neobsahuje jen deskopové prostředí GNOME, ale také KDE. Linux Mission standardně spouští desktop GNOME, chceteli pracovat s tímto alternativním prostředím, musíte jej zvolit (dříve než se jako uživatel přihlásíte zadáním uživatelského jména a hesla). Slouží k tomu menu, které vyvoláte kliknutím myši na symbol "Sezení" nachází se vlevo dole na úvodní přihlašovací obrazovce:

V menu zvolíme položku "KDE". Pokud bychom později chtěli nastavit desktopové prostředí KDE jako výchozí, spustíme utilitu switchdesk (je dostupná v hlavním menu mezi "Systémovými nástroji" jako "Desktop Switching Tool"). Jak je vidět na následujícím obrázku, na první pohled je vzhled desktopu včetně menu a ovládacího / stavového panelu organizován obdobně jako desktop GNOME. Také základní filosofie práce je stejná (včetně konceptu virtuálních ploch). To je záměr, neboť to usnadní orientaci zejména začínajícím uživatelům. pokročilý uživatel si samozřejmě může vzhled a chování desktopu nastavit podle svého gusta.




9. Př íkazový interpret Bash: nebojte se př íkazové ř ádky V této kapitole se budeme zabývat příkazovým interpretem Bash, což je nejrozšířenější příkazový interpret (shell) ve světě Linuxu a je také uživatelům Mission nastavován jako výchozí. Postupně se probereme všemi jeho taji a prozkoumáme nejrůznější zákoutí tohoto mocného nástroje, který je o hodně víc než jen interpret příkazů... Příkazový interpret neboli shell je jedním z nejsilnějších nástrojů v Unixových systémech. Kdo si někdy v Microsoft Windows otevřel "MS DOS Shell", může si myslet, že Unixové shelly, mezi něž patří i BASH, budou něčím obdobným. Avšak tento názor není zdaleka přesný. Unixový shell je velmi univerzální nástroj, pomocí něhož může uživatel nejen jednoduše komunikovat se systémem a ovládat jej, ale především ho může využít také jako programovací jazyk, tedy ke psaní nejrůznějších skriptů, které mu v konečném důsledku výrazně usnadní práci s řešením nějakého problému. Existuje celá řada shellů, které se v mnoha věcech mohou lišit. Troufám si říct, že nejrozšířenějšími shelly v Linuxu jsou BASH a TCSH. (To potvrzují i výsledky ankety realizované na serveru Linuxzone 86% hlasujících preferovalo BASH). Každý z shellů má něco navíc oproti ostatním a nabízí určité specifické možnosti, které jiný nenabízí. V základních věcech se však chovají téměř úplně stejně. V tomto textu se ale budeme věnovat výhradně shellu BASH. Téměř každá naučný text o programování začíná nudnou kapitolou o historii a vývoji daného jazyka nebo nástroje. Pokusím se tento trend porušit, abychom se obratem dostali k praktickým




záležitostem. Ve zkratce snad jen řeknu, že BASH (BourneAgain Shell) je rozšířením staršího BSH (Bourne Shell), který se dříve hojně používal snad na všech Unixech. BSH nedisponoval některými důležitými vlastnostmi, jako např. pokročilejší editací příkazové řádky nebo správou úloh. BASH je jedním z nástupců tohoto nástroje a efektivně řeší a odstraňuje nedostatky BSH. (pozn.: Seznam všech shellů, které jsou dostupné ve vašem systému můžete najít v souboru /etc/shells; do každého z těchto shellů se přepnete tak, že jednoduše zadáte na příkazové řádce jeho název.) Než přikročíme ke psaní skriptů a dalším pokročilým operacím, díky nimž si shelly získaly takovou popularitu, musíme se nejprve co nejvíce sblížit s BASHem a pochopit principy jeho fungování.

Pohyb v historii příka zů Začneme tím, že se podíváme na ukládání historie příkazů. Přepněte se do textové konzole anebo otevřete okno terminálu (položka "Otevřít terminál" pracovního menu, které vyvoláte kliknutím pravého tlačítka myši kdekoliv na volnou pracovní plochu). Měli byste vidět výzvu příkazového řádku. Já ji budu pro jednoduchost nahrazovat znakem dolaru, tedy $. Nyní napište samostatně několik příkazů. Například ls (enter), ps (enter), w (enter). Když se teď budeme chtít probírat historií příkazů a znovu použít například příkaz ls, stačí jen třikrát stisknout šipku nahoru a máme ho opět na příkazové řádce. Tímto způsobem tedy listujeme v historii. Samozřejmě, že když si to rozmyslíme a budeme chtít raději vypsat procesy, stačí stisknout šipku dolů a jsme na ps. Může se stát, že ve vašem systému nebudou šipky při pohybu v historii reagovat, resp. nebudou pro pohyb v historii použitelné. V takovém případě zkuste použít následující příkaz: $ set -o emacs

Od této chvíle by měl být váš problém vyřešen a šipky by měly reagovat správně. Když už máme nastaven Emacsový styl procházení historie (nazvaný podle editoru Emacs), neměli bychom také opomenout kombinaci CTRL+R. Když v shellu zadáte tuto kombinace, můžete v historii vyhledat příkaz, jehož podobou si nejste jisti. Stačí jen zadat část tohoto příkazu a v historii bude objeven (je to elegantnější a přeci jen jednodušší než history | grep hledany_text).

Výpis historie příka zů Umíme se v historii pohybovat pomocí šipek. Jak skvělé... Co takhle si ale historii vypsat, abychom měli přehled v tom, co vlastně máme za možnosti. K tomu slouží příkaz history. Jestli mohu doporučit, používejte spíše zápis history | tail, který vypíše posledních deset použitých příkazů. V opačném případě se vypíše kompletní historie, která může být (v závislosti na nastavení shellu) velmi dlouhá. Výpis příkazů vypadá jednoduše. Na levé straně máme označení příkazu pořadovým číslem v




historii, kde jsou příkazy počítány od prvního vzestupně.

Spuštění příka zu z historie Ne vždycky může být výhodné prohledávání historie pomocí šipek. Někdy je jednoduší jen odkázat shell na číslo příkazu z historie (tento příkaz může být například velmi daleko od současné pozice a je tedy mnohem jednodušší nechat si vypsat historii a následně spustit příkaz pomocí jeho identifikátoru než hodinu ťukat na šipku nahoru). Zvolený příkaz z historie vyvoláme pomocí příkazu ! následovaného pořadovým číslem v historii. Tedy například !356 spustí příkaz, který se v historii nachází na 356. místě. Vcelku zajímavou možností je také použití příkazu !-x, kde x je pozice příkazu v historii odzadu. Například tedy !-16 spustí šestnáctý příkaz odzadu (= od současné pozice) bez ohledu na jeho identifikační číslo. Vykřičník má mnoho použití a můžeme jej uplatnit i ve variantě !text, kdy bude spuštěn poslední příkaz z historie, který začíná specifikovaným textem. Tedy například !ls může spustit ls -la, apod. Další variantou je použití !?text?, kdy bude vyhledán a spuštěn poslední příkaz v historii, který obsahuje specifikovaný text. Abych nebyl obviněn ze zatajování informací, uvedu ještě, že můžeme použít příkaz !!, pomocí kterého spustíme poslední provedený příkaz v historii. Je to tedy jakási obdoba šipky nahoru. Další zajímavostí je také možnost spuštění většího počtu příkazů automaticky. Tedy vlastně znovuspuštění určité části historie. Tuto část můžete předem vyeditovat a upravit dle svých požadavků. Slouží k tomu příkaz fc. Nejjednodušší variantou je, že spustíte pouze fc a v defaultním textovém editoru (nejčastěji vi) se vám objeví poslední příkaz. Ten můžete dle libosti upravit a při skončení práce s editorem bude proveden. Užitečnější možností je zadání rozmezí v historii, tedy fc od do, kde od představuje startovní pozici (číslo příkazu v historii) a do koncový bod. V editoru se pak objeví příkazy, které se nachází v tomto rozmezí, opět je můžete upravit a po opuštění editoru budou postupně provedeny. Poznámka: chceteli pracovat s jiným editorem než je vi, můžete nastavit proměnnou prostředí FCEDIT nebo EDITOR (o tom, jak nastavit proměnnou se dočtete dále). Pokud nevíte, jak s editorem vi pracovat, prostudujte si manuálovou stránku vi nebo můžete spustit vimtutor.

Výpis př íkazu z historie V předchozím oddíle jsme si uvedli několik možností, jak spustit nějaký příkaz z historie. Co však uděláme, když chceme příkaz jenom vypsat? Můžeme chtít například vypsat poslední uvedený příkaz nebo padesátý příkaz odzadu. Jak to ale uděláme, abychom jej nespustili?




Je to velmi prosté. Použijeme příkaz echo. Tato utilita vrací jako svůj výstup zadaný text nebo zpracované funkční proměnné. Například tedy pro výpis padesátého příkazu odzadu stačí napsat echo !-50 nebo pro výpis posledního použitého příkazu echo !! (nebo jednoduše stiskneme šipku nahoru :)).

Délka historie a její ukládá ní Když si vypíšete nastavení vašeho systému, najdete v něm proměnné HISTSIZE a HISTFILE. Stačí napsat set | grep hist, resp. echo $HISTSIZE a echo $HISTFILE a sami uvidíte. Proměnná HISTSIZE určuje velikost historie na vašem systému. Tedy počet příkazů, který bude do historie zaznamenán. HISTFILE zase určuje cílový soubor, kde se bude historie hledat a kam se bude ukládat. Obě tato nastavení můžete dle svých požadavků změnit. Stačí napsat HISTSIZE=xxx, kde xxx představuje konkrétní číselnou hodnotu. Obdobně lze změnit také proměnná HISTFILE.

Úlohy a ř ízení procesů Nyní se podíváme na úlohy, jejich správu a řadu souvisejících věcí, probereme spouštění úloh na popředí a na pozadí a přesouvání úlohy mezi těmito dvěma režimy. Linux, respektive Unixové systémy obecně, dokáže zpracovávat větší množství úloh najednou. Pro uživatele je pak dobré vědět co jeho systém dělá, kdy to dělá, proč to dělá a především jak je možné tuto činnost efektivně řídit. Příkazový interpret BASH mu k tomu nabízí celou řadu nástrojů. Nejprve si ale povězme, co to ta úloha vlastně je... Stručně řečeno, je to jeden nebo více spuštěných procesů. Jedna úloha tedy nevynucuje přítomnost pouze jednoho procesu, ale může jich využívat více. Úloha může být spuštěna na popředí nebo na pozadí. Uživatel pak tedy logicky potřebuje nástroje, pomocí kterých bude schopen spustit úlohu jak na popředí, tak na pozadí a také mezi těmito dvěma stavy libovolně přepínat. Stejně tak je důležité mít nějaký nástroj na pozastavení běžící úlohy. Pozastavení běhu úlohy Snad na všech unixových systémech je implicitně k tomuto účelu nastavena kombinace kláves CTRL+Z. Toto nastavení lze samozřejmě změnit pomocí příkazu stty, ale tím se zde zabývat nebudeme. Můžeme si ukázat, jak takové pozastavení běhu úlohy vlastně vypadá: $ pr CTRL+Z [1]+ Stopped

pr

$ cat



CTRL+Z [2]+ Stopped

cat

$ jobs [1]- Stopped [2]+ Stopped

pr cat


Jako první jsme spustili příkaz pr, který očekává zadání nějakého vstupu ze STDIN (standardního vstupu). Pozastavili jsme jeho běh pomocí kombinace kláves CTRL+Z a spustili další příkaz cat který taktéž očekává zadání další informace ze STDIN. I běh této úlohy pozastavíme stisknutím uvedené klávesové zkratky a necháme si vypsat seznam spuštěných úloh. K tomu standardně slouží příkaz jobs. Jak vidíme, ve výpisu dostaneme seznam všech pozastavených úloh, které jsou číslovány od nejstarší k nejnovější. Úloha, se kterou systém pracoval naposledy, má u sebe znaménko +, úloha, se kterou pracoval na předposledy, je označena . Ostaní úlohy nemají na tomto místě žádné označení. Provádění úlohy na popř edí/pozadí Budemeli chtít nyní některou z úloh oživit, stačí ji například převést do popředí. K tomu můžeme využít příkazu fg. Zadámeli tento příkaz bez parametru, bude systém komunikovat s poslední úlohou ze seznamu (tj. s úlohou označenou znaménkem +). U výše uvedeného příkladu by to tedy vypadalo následovně: $ fg cat

A program by nyní opět čekal na zadání vstupních informací ze standardního vstupu STDIN. Obdobně můžeme také převádět úlohy na pozadí. Slouží k tomu příkaz bg. Jeho použití je obdobné jako u předchozího. Bylo by ale jistě dobré upozornit, že nemusíte nutně pracovat jen s poslední úlohou. Klidně můžete zvolit jakoukoliv jinou úlohu, kterou jste dříve pozastavili v běhu. Stačí pak u příkazu bg nebo fg jednoduše uvést znak procenta následovaný číslem úlohy v seznamu, tedy například: $ bg %1

Tento příkaz převede na pozadí první spuštěnou úlohu, tedy v našem případě pr.

"Musí zemřít !" Aby toho nebylo málo, povíme si ještě, jak je to vlastně s ukončováním běžících úloh. To, že nějakou úlohu pozastavíme, totiž ještě zdaleka neznamená, že by byla ukončena. Stále zatěžuje www.linuxzone.cz strana 123 / 159



systémové zdroje a stále máme možnost s ní dále pracovat. Když ji však ukončíme, uvolní se systémové prostředky a úloha přestane figurovat ve výpisu. Tím se tedy zruší i její pořadové číslo a to je uvolněno pro další úlohy, které spustíme. Nutno podotknout, že pokud skončí svůj běh úloha s nižším číslem, zůstává úlohám na vyšších místech jejich identifikátor nadále přiřazen. Vraťme se ale zpět k ukončování běžících úloh. K tomuto účelu využíváme primárně příkazu kill s parametrem identifikujícím příslušnou úlohu. Tato identifikace je stejná, jako v předešlých případech, tedy opět %x, kde x symbolizuje pořadové číslo spuštěné úlohy. Je také nezbytné upozornit, že abychom se dozvěděli o ukončení úlohy, je nutné stisknout dvakrát klávesu Enter, čímž se dostaneme ke kýženému výpisu informace o ukončení běžící úlohy. Není to způsobeno žádnou závadou, ale prostou činností shellu. Po prvním stisknutí klávesy Enter zjistí příkazový interpret, že příslušná úloha byla pozastavena a upozorní nás na to. Po dalším stisknutí dojde ke zjištění, že úloha byla ukončena a vypíše nám tuto informaci.

Úlohy v popře dí a na pozadí Ve stručnosti jsme si už řekli několik obecných informací o úlohách běžících na popředí a úlohách běžících na pozadí. V krátkosti tedy jen doplním, že běh na pozadí je takový stav, kdy úloha je spuštěna, ale nepřijímá žádný vstup z terminálu a nebrání v další činnosti na tomto terminálu. Zatímco běh na popředí je logicky pravým opakem přijímá vstup z terminálu a blokuje jej pro sebe. Pro úplnost ještě doplním, že pozastavená úloha je taková, která momentálně neběží, ale ještě neukončila svou činnost. Uvedli jsme si už jeden způsob, jak převádět běžící úlohu z popředí na pozadí. Neřekli jsme si ale, jak spustit úlohu na pozadí už od začátku. Je to velmi prosté. Stačí za příkaz napsat znak &. Systém nám pak vypíše číslo této úlohy, takže ji budeme moci dle libosti průběžně sledovat. V praxi to pak může vypadat nějako takto: $ cat & [1] 1797

Od této chvíle bude úloha spuštěna na pozadí.

Zasílání signálů Po dalším týdnu jsme zpět se seriálem o programování v BASHi. V dnešní části se podíváme na signály v Linuxu. Rozlišíme si je a povíme si, jak s nimi pracovat. To ale není vše. Aby toho nebylo málo, nahlédneme dnes konečně i pod pokličku skutečného programování a ve stručnosti zavítáme do světa proměnných... Unixové operační systémy mohou procesům zasílat nejrůznější signály (viz také kapitola "Řízení procesů, signály" v části "Pod pokličkou orientace v systému pro pokročilé"), kterými je informují o nějaké situaci a tím řídí jejich činnost. Asi nejčastěji používaným signálem je SIGTERM, avšak s www.linuxzone.cz strana 124 / 159



pomocí programu kill můžeme zasílat i jiné signály. Seznam signálů, které podporuje váš systém, získáte pomocí příkazu kill -l: $ kill -l +---------------+--------------+--------------+-------------+ | 1) SIGHUP | 2) SIGINT | 3) SIGQUIT | 4) SIGILL | | 5) SIGTRAP | 6) SIGIOT | 7) SIGBUS | 8) SIGFPE | | 9) SIGKILL | 10) SIGUSR1 | 11) SIGSEGV | 12) SIGUSR2 | | 13)SIGPIPE | 14) SIGALRM | 15) SIGTERM | 17) SIGCHLD | | 18) SIGCONT | 19) SIGSTOP | 20) SIGTSTP | 21) SIGTTIN | | 22) SIGTTOU | 23) SIGURG | 24) SIGXCPU | 25) SIGXFSZ | | 26) SIGVTALRM | 27) SIGPROF | 28) SIGWINCH | 29) SIGIO | | 30) SIGPWR | | | | +---------------+--------------+--------------+-------------+

Jak vidíte na výpisu, každý signál má své unikátní jméno, kterému předchází předpona SIG. K zaslání tohoto signálu některému procesu můžete u příkazu kill využívat buď číslo tohoto signálu nebo jeho jméno bez prefixu SIG. Například tedy kill -9 %7 je ekvivalentní s příkazem kill -KILL %7. Jestliže použijete příkaz kill bez specifikace zasílaného signálu, bude automaticky odeslán signál číslo patnáct, tedy SIGTERM. Ten "požádá" proces o jeho ukončení a dá mu možnost, aby po sobě "uklidil", tedy zlikvidoval dočasné soubory a další specifické věci. Jestliže je však tento signál programem ignorován, bude zaslán jiný signál číslo devět, tedy SIGKILL. Ten už program ignorovat nemůže a dojde k jeho okamžitému ukončení (bez "uklizení"). Už jsme si povídali o pozastavování úloh a procesů. Pokud nemůžeme z nějakého důvodu pozastavit proces využitím klávesové kombinace CTRL+Z, stačí, když danému procesu zašleme signál SIGSTOP. K opětovnému spuštění můžeme zaslat signál s číslem osmnáct, tedy SIGCONT. Dalším signálem, který stojí za bližší pohled z hlediska terminálových aplikací, je SIGWINCH. Ten je programu zaslán v případě, že terminál změní svoje parametry, tedy například při změně velikosti okna emulátoru terminálu, čímž dojde ke změně počtu sloupců a řádků. V řadě aplikací musí být zaslání tohoto signálu následováno příkazem pro překreslení obrazovky (nejčastěji klávesová kombinace CTRL+L). Jen ještě malá poznámka na závěr zasílat signály může uživatel pouze svým procesům. Výjimku tvoří samozřejmě privilegovaný uživatel root, který může zasílat signály všem procesům bez výjimky. Důvod je prostý ochrana procesů jiných uživatelů před nevyžádaným ukončením či změně chování.




Konečně programujeme aneb proměnné v teorii i praxi Po krátkých povídáních o úlohách, procesech, běhu na pozadí a na popředí, tedy stručně řečeno o principech fungování příkazového interpretu v systému Linux, se konečně dostáváme k praktickým záležitostem, které zužitkujeme při psaní skriptů. Nejprve zavítáme do světa proměnných.

Co je proměnná? Každý, kdo někdy alespoň přičuchl k programování nebo absolvoval střední školu, jistě ví, že proměnná zastupuje nějakou proměnlivou hodnotu. Můžeme ji na začátku přiřadit jednu výchozí hodnotu a tu pak v průběhu programu nějakým způsobem měnit. Například pokud proměnnou a nastavíme na počáteční hodnotu 7 a v průběhu programu zadáme příkaz a=a*3, bude hodnota této proměnné 21 a nikoliv sedm, jako na začátku. Jak prosté. Proměnná je tedy nějaký pojmenovaný prostor, pro nějž nadefinujete hodnotu (textovou nebo číselnou) a tuto hodnotu využíváte, dokud není změněna.

Cesty k programům Asi nejjednodušším využitím proměnné v příkazovém interpretu je nastavení cesty ke spustitelným souborům. Protože se na různých platformách či v různých distribucích Linuxu může lišit toto umístění, není nikde pevně zakomponováno a je nastaveno pomocí proměnné PATH. Díky této proměnné docílíme toho, že po zadání nějakého příkazu není prohledáván celý adresářový strom našeho systému, ale je postupně nahlédnuto do všech specifikovaných adresářů, v nichž máme umístěny spouštěné programy a v prvním adresáři, kde je takový program nalezen, toto hledání skončí a příkaz se provede. Pokud nalezen není, oznámí nám interpret chybu, respektive vypíše hlášku o nenalezení požadovaného programu. Taková jednoduchá cesta pro vyhledávání by mohla vypadat například nějak takto: /usr/local/bin:/usr/bin:/usr/X11R6/bin:/usr/sbin:/bin:/sbin

Jak vidíte, jednotlivé adresáře jsou odděleny dvojtečkou (typický oddělovač pro systémy Unix). V praxi to pak vypadá tak, že nejprve je prohledáván adresář /usr/local/bin, v případě nenalezení pak /usr/bin, apod. Postupuje se tedy krok za krokem od začátku cesty. Přesné nastavení vaší cesty pro vyhledávání spustitelných programů, získáte výpisem proměnné PATH, což provedete pomocí příkazu echo $PATH na příkazovém řádku. Systém vám pak jednoduše vypíše celou cestu, tedy dvojtečkou oddělený seznam všech adresářů, které budou postupně prohledávány.




Změna hodnoty proměnné Již víme, co je to proměnná a jaké jsou její základní vlastnostmi v operačním systému Linux. Zatím umíme vypsat obsah proměnné, ale ještě nevíme, jak ho změnit. Je to prosté. Na příkazovém řádku zadáme identifikátor proměnné a po vzoru klasické matematické syntaxe zapíšeme novou hodnotu. Zde je nutno odlišit dva různé případy: •

Nahrazení obsahu proměnné: V tomto případě dojde k přepsání aktuální hodnoty proměnné novou hodnotou. Docílíme toho prostým zápisem promenna=hodnota. Tedy například: $ PATH=/sbin:/bin

•

Tím dojde k nastavení hodnoty proměnné PATH tak, aby spustitelné soubory byly vždy vyhledávány pouze v adresářích /sbin a /bin nezávisle na předchozím nastavení této proměnné. Doplnění stávajícího obsahu proměnné Toto je druhá varianta, se kterou se setkáme. Například pokud je hodnota proměnné PATH nastavena pouze na vyhledávání v adresářích /sbin a /bin, můžeme doplnit, že se mají spustitelné soubory vyhledávat ještě v adresáři /usr/local/bin a /usr/bin. Docílíme toho obdobným zápisem, jako v minulém případě, avšak budeme uvažovat adiční zápis, tedy promenna=$promenna:hodnota Všimněte si znaku dolaru u identifikátoru proměnné za rovnítkem. Tento zápis bude příkazovým interpretem nahrazen aktuální hodnotou proměnné a k té se následně přidá dopsaná hodnota. V praxi tedy bude celý zápis vypadat nějak následovně: $ PATH=$PATH:/usr/local/bin:/usr/bin

Další proměnné prostř edí Když už jsme si tolik pověděli o proměnné PATH, neměli bychom v našem povídání opomenout také proměnnou MANPATH. Její využití je obdobné, jako u předešlé, avšak neslouží k vyhledávání spustitelných souborů, ale k vyhledávání umístění manuálových stránek. Veškerá práce s touto proměnnou je samozřejmě zcela analogická k předchozímu výkladu. Také nesmíme opomenout proměnnou HOME. V ní je totiž uložena cesta k domovskému adresáři uživatele. Obsah této proměnné neměňte. Ve starších Unixech, resp. v Bourneshellu, který byl předchůdcem dnešního příkazového interpretu BASH nebylo možné odkazovat na domovský adresář pomocí vlnovky, tedy např. cd ~. Místo toho se používal zápis cd $HOME. Efekt je www.linuxzone.cz strana 127 / 159



stejný. Enormně důležitou systémovou proměnnou, nebo abych byl přesný konfigurační proměnnou je také PWD. Zde je uložena cesta k aktuálnímu adresáři. Použijeteli tedy echo $PWD, výstup bude shodný s příkazem pwd. Opět hodnotu této proměnné neměňte. Některé proměnné jsou zkrátka určeny k tomu, aby si je uživatel nastavil dle svého přání (nebo spíše potřeb) a tím si systém upravil na míru. Jiné proměnné však měnit nesmíme, chcemeli zachovat dobrou funkčnost našeho příkazového interpretu. Teď se podívejme na proměnnou MAILCHECK. Ta slouží k nastavení intervalu, kdy příkazový interpret kontroluje, zda nemáte novou poštu. Nastavímeli tedy hodnotu této proměnné na 600 (hodnota je uváděna v sekundách), bude BASH každých deset minut provádět kontrolu na nově příchozí poštu. Ovšem, když už jsme začali o těch emailech, nesmíme opomenout také proměnnou MAILPATH. Opět se zde dostáváme k analogii s proměnnou PATH nebo MANPATH. Hodnotou této proměnné je totiž řada dvojtečkou oddělených adresářů, v nichž bude interpret příkazů hledat soubory s poštou. Co si probereme dál... Proměnnou HISTSIZE. O té jsme si již povídali hned v prvním díle našeho seriálu. Ale pro úplnost si stručně zopakujeme, že slouží k nastavení velikosti historie uchovávaných příkazů. Nebo přesněji když nastavíme hodnotu HISTSIZE na deset, budeme mít v historii příkazů uložených posledních deset použitých příkazů. Doporučuji ale zvolit poněkud vyšší hodnotu. :) Líbí se vám výzva vašeho intepretu příkazů nebo byste ji raději změnili na něco jiného, lepšího? Žádný problém! Máme tady proměnné PS1 a PS2. Nejprve se podíváme na první z nich. Pokud zapíšete například PS1='Tohle je vyzva: ', bude se jako výzva příkazového řádku (tzv. primární prompt) objevovat tato věta. Všimněte si mezery mezi dvojtečkou a apostrofem. Tato mezera bude totiž oddělovat výzvu interpretu od zadávaného textu na konzoli. Ale máme zde ještě druhou proměnnou PS2. Ta se uplatní např. tehdy, odešlemeli neúplný příkaz Bash nám tím dává najevo, že očekává jeho doplnění. Standardně je sekundární prompt nastaven znak >. Tedy například: $ > > >

for soubor in *wav; do play $soubor done

Tímto příkladem jsem tošku předběhl výklad, nicméně vidíme, že jsem vlastně interpretu zadal krátký program (skript), který obsahoval cyklus for. Bash ví, že u cyklu for musím uzavřit tělo cyklu mezi klíčová slova do a done a proto s provedením příkazu čekal, dokud jsem jej nezadal




celý a po tu dobu se místo obvyklého promptu $ zobrazoval sekundární prompt >. Jinak smysl tohoto příkazu byl jednoduchý: vezmi všechny soubory v současném adresáři, které končí na "wav" a přehraj je postupně přehrávačem zvukových souborů pro příkazovou řádku.

Proměnné ovlivňující nastavení terminálu Nastavení každého terminálu je, tak jako spousta jiných věcí v Linuxu, definováno pomocí proměnných. Ty určují, jak bude systém s vaším terminálem komunikovat a jak jej bude vlastně interpretovat. Základní proměnné, které určují vlastnosti terminálu, jsou DISPLAY, TERM, LINES a COLUMNS. Poslední dvě nechte nastaveny na implicitních hodnotách. Určují funkční rozměr obrazovky terminálu, tedy přesněji LINES udává počet řádků terminálu a COLUMNS specifikuje počet znaků na řádku. Proměnná DISPLAY je využívána grafickým rozhraním X Window Systemu a určuje, na kterou obrazovku bude směrován grafický výstup programů, které na tomto počítači běží. X Window System je totiž schopný obstarávat chod několika obrazovek využívaných jedním uživatelem. Obsah této proměnné je tvořen jménem počítače a číslem displeje (dvě čísla oddělená tečkou). Tyto údaje jsou odděleny dvojtečkou. Poslední proměnnou, která nám ještě zbývá, je TERM. Ta systému sděluje, který terminál používáte a jaké jsou jeho vlastnosti (možnost používání barev, možnost pohybu kurzoru, apod.). Znalost těchto proměnných a jejich využití je nezbytná, pokud chcete svůj terminál přizpůsobit svým přáním a požadavkům.

Obyčejné (obecné) proměnné Teď se ale pojďme podívat na trochu jinou problematiku, kterou jsou tzv. obyčejné (obecné) proměnné. Linux, stejně jako unixové operační systémy, svého uživatele nijak netlačí do kouta, pokud jde o využívání proměnných. Nemusíme se soustředit pouze na systémové proměnné se speciálním významem, můžeme si vytvořit libovolné množství vlastních obyčejných proměnných. Jejich jména však nesmí kolidovat se systémovými proměnnými. Proč ale vůbec vytvářet nějaké vlastní proměnné? Tady už se dostáváme hlavně k problematice tvorby skriptů. Můžeme si například do proměnné nastavit počet iterací nějakého cyklu, prohledávanou lokalitu na disku, název vygenerovaného souboru, apod. Další využití je také v jisté možnosti zjednodušení práce se systémem. Můžeme si například v příkazovém interpretu nastavit, že proměnná ADRESA bude obsahovat adresu k nějakému adresáři na disku. To uděláme jednoduše ADRESA=$HOME/Desktop/test/vypis. V tuto chvíli můžeme jednoduše používat příkazy jako cd $ADRESA nebo třeba rm $ADRESA/test.txt. Nemusíme se tedy vypisovat s dlouhým názvem adresáře, který třeba často používáme.




O proměnných prostředí už jsem se zmínil v minulosti. Princip je jednoduchý. Proměnné jsou většinou přístupné pouze z právě aktuálního příkazového interpretu. Pokud se rozhodnete je využívat i ze spuštěných programů, musíte je nejprve vyexportovat do vašeho prostředí. Prostředí je jakýsi souhrn informací o aktuální konfiguraci, který je složen z některých proměnných interpretu. Tyto proměnné jsou pak dostupné běžícím programům. Můžeme se například rozhodnout vytvořit proměnnou WWW_HOME (tu využívají některé webové prohlížeče k nastavení domovské stránky) a její obsah vyexportovat. Vypadá to tedy následovně: $ WWW_HOME='http://www.linuxzone.cz' $ export WWW_HOME

Jak prosté. Od této chvíle bude příslušná proměnná přístupná aplikacím, které z příkazového interpretu spouštíme.

Konfigurace interpretu startovací skripty Při spuštění interpretu je vždy proveden jeden nebo více startovacích skriptů. To, který skript bude proveden, záleží na nastavení přihlašovacího interpretu. Tedy toho, se kterým budete pracovat po přihlášení do systému. Ten pak čte další konfigurační soubory. Protože náš seriál je věnován příkazovému interpretu BASH, nebylo by jistě na škodu říci, které konfigurační soubory spouští. Jako první je spuštěn /etc/profile. Následně je vyhledáván (v uvedeném pořadí) některý ze souborů: ~/.bash_profile, ~/.bash_login nebo ~/.profile. Při nalezení některého z nich přestane s vyhledáváním a obsah tohoto souboru načte. Jestliže není BASH nastaven jako přihlašovací interpret, spouští skript uložený v souboru . bashrc, který se nachází v domovském adresáři uživatele. Kromě startovacích skriptů však existují také takové skripty, které se provádějí vždy při ukončování interpretu. V případě BASHe je tímto skriptem ~/.bash_logout. Zde můžeme uvést další parametry, které se provedou při ukončování naší práce.

Speciální znaky a řídí cí sekvence Nyní se podíváme na jednotlivé druhy uvozování speciálních znaků, proměnných a příkazů. Probereme si apostrofy, uvozovky, zpětné lomítko a obrácené apostrofy a samozřejmě odlišnosti mezi těmito způsoby uvozování. Jestliže chceme v příkazovém interpretu BASH pracovat se speciálními znaky nebo proměnnými, měli bychom si ze všeho nejdříve vysvětlit rozdíl mezi jednotlivými druhy uvozování hodnot, protože právě s nimi budeme pracovat asi nejvíce. Máme celkem čtyři možnosti uvození: •

Apostrofy (') www.linuxzone.cz strana 130 / 159


• • •


Uvozovky (") Zpětné lomítko (\) Obrácené apostrofy (`)

Různé možnosti uvozování se od sebe liší svými vlastnostmi. A musíme podotknout, že právě tato odlišnost, která v sobě zároveň skrývá i ohromnou všestrannost, je jednou z nejsilnějších zbraní příkazového řádku a umožňuje nám provádět hotová kouzla. Nejvíce však tyto možnosti oceníte při vlastním psaní skriptů. Pojďme si teď ale povědět něco o jednotlivých způsobech:

Apostrofy První důležitou věcí je, že řetězec uvozený apostrofy není v žádné své části nahrazen zástupnou hodnotou. Pokud tedy uvedeme znaky jako * nebo ., budou tyto interpretovány vždy pouze jako znak a nebude za ně nic dosazeno. Stejně tak pokud napíšete echo '$HOSTNAME', bude výstupem pouze řetězec $HOSTNAME a nikoliv hostname vašeho počítače. Veškerý text, který je uveden mezi apostrofy, je interpretován jako jeden souvislý celek. Pokud jsou zde tedy uvedeny mezery, nijak to neovlivní práci systému. Kdybyste kupříkladu zadali příkazu grep parametry linux zone lz.txt, bude si myslet, že hledaný řetězec je pouze linux a zone spolu s lz.txt jsou dva různé textové soubory. Jestliže však zapíšete grep 'linux zone' lz.txt, bude mít příkaz jasno a bude v souboru lz.txt vyhledávat řetězec linux zone. Nutno podotknout, že tuto konverzi zástupných znaků na hodnoty neprovádí samotná aplikace, ale právě interpret příkazů, tedy v našem případě BASH. Jak je to prosté... Jediným znakem, který nemůžeme vložit mezi apostrofy, je další apostrof. Ve chvíli, kdy bychom jej totiž do zadaného textu vložili, představoval by párový apostrof k prvnímu a tím by zadaný řetězec ukončil.

Uvozovky Tady je to náročnější. Uvozovky sice také zajistí, že bude celý text brán jako argument, ale nebude to tak jednoduché, jako v případě apostrofů. Zde již budou zachovány některé funkce interpretu příkazů. Například pokud vyzkoušíte "*", dočkáte se výstupu znaku *. Nejlépe je to patrno například u echo "*". Jak to tedy s tím nahrazováním je? Vypnuto je nahrazování jmen, ale příkazy historie, proměnné, znaky uvozené zpětným lomítkem nebo obrácené apostrofy (viz dále) zůstávají nadále aktivní a budou interpretovány tak, jako kdybyste je zapsali přímo na příkazový řádek samostatně bez uvození. Jednotlivé způsoby mezi sebou můžeme i efektivně kombinovat. Často se používá kombinace uvozovek a obrácených apostrofů (viz dále). Pokud například zkusíte zadat: ls "ècho /




home`", dočkáte se skutečně výstupu seznamu souborů v adresáři /home.

Zpětné lomítko Zde je situace velmi jednoduchá a pokud jste někdy zkoušeli alespoň trochu programovat, zřejmě už víte, co můžete čekat. Zpětné lomítko uvozuje vždy jeden znak, který je interpretován jako speciální. Existuje celá řada takových kombinací. Například \u symbolizuje uživatelské jméno právě aktivního uživatele, \n zase nový řádek. Když budeme chtít vypsat obrácené lomítko, můžeme k tomu využít zápisu \\ a pro apostrof pak zase \', čímž předejdeme tomu, aby interpret příkazů pokládal lomítko nebo apostrof, které chceme vypsat, za speciální přepínač. Další důležitou vlastností zpětného lomítka je možnost vypnutí speciálního významu některých znaků. Pokud tedy zapíšeme \* nebo \~, budou znaky * a ~ interpretovány jen jako obyčejné znaky bez jakéhokoliv nahrazování.

Obrácené apostrofy Posledním typem uvození jsou obrácené apostrofy. Díky nim můžeme vsunout výstup jednoho příkazu do druhého. Příkaz zadaný mezi obrácenými apostrofy je tedy nahrazen svým výstupem, který může být například předán ke zpracování dalšímu příkazu. Tedy kupříkladu echo `whoami`. Mezi obrácenými apostrofy opět můžeme dle libosti využívat řadu speciálních znaků nebo příkazů historie a proměnných, které budou dále interpretovány. Znalost různých vstupů uvozování textu, speciálních znaků a příkazů, je naprosto nezbytná při psaní skriptů nebo pokročilých operacích v příkazovém interpretu Linuxu. Doporučuji proto, abyste se před dalším studiem dobře seznámili s uvedenými způsoby a rozdíly mezi nimi. Zkuste také říci, co se objeví po zadání následujících příkazů. Následně si své odhady ověřte přímo v BASHi: 1) $ 2) $ 3) $ 4) $ 5) $

echo -n "Hostname meho pocitace je $HOSTNAME" echo -n 'Hostname je: $HOSTNAME' ls 'ècho /bin`' ls * cd "~"

Podmíněné versus sekvenční provádění příka zů V této části našeho průvodce programováním příkazového interpretu BASH budeme zabývat www.linuxzone.cz strana 132 / 159



podmíněným prováděním příkazů. ještě předtím se však podíváme na sekvenční provádění příkazů, které nás mírně vtáhne do celé problematiky. Kdo někdy alespoň zkoušel programovat, jistě se dostal do kontaktu s cykly a podmínkami. Ten, kdo se zatím programování nevěnoval, však rychle pochopí, o co vlastně jde. Podmíněné provádění příkazu znamená, že daný příkaz, nebo sekvence příkazů, je proveden v závislosti na splnění podmínky. Můžeme to vyjádřit schématem: KDYŽ PLATÍ PODMÍNKA, PROVEĎ PŘÍKAZ. Pokud je tedy zadaná podmínka splněna, bude příkaz proveden, v opačném případě jej bude interpret ignorovat. Cyklické provádění je založeno na podmínkovém. Jedním z jeho základních schémat je: PROVÁDĚJ PŘÍKAZ DOKUD PLATÍ PODMÍNKA. U samotné podmínkové konstrukce dojde k provedení pouze jednou v závislosti na splnění porovnávané podmínky. Avšak v případě cyklu se příkaz (nebo blok příkazů) opakuje do doby, dokud je (nebo dokud není závisí na konkrétním cyklu) splněna zadaná podmínka.

Sekvenční provádění příka zů BASH nám kromě výše uvedených možností nabízí také tak zvané sekvenční provádění příkazů. Jde vlastně o to, že mu zadáme několik příkazů a ty jsou nezávisle na okolnostech a výsledcích předešlých příkazů postupně prováděny tak, jak jsou napsány. Abychom mohli sekvenční provádění vyzkoušet, vytvoříme si jednoduchý skript. Veškeré skripty v BASHi musí na prvním řádku obsahovat: #!/bin/bash

Jedná se o cestu k interpretu příkazů (pokud byste někdy pracovali se systémem, kde je umístěn jinde což se může stát vyhledejte si jej příkazem whereis bash a zapište platnou cestu pro váš systém). Jako další již zadáváme jednotlivé příkazy a konstrukce, které chceme v BASHi provést. Nezapomeňte však po skončení práce změny v souboru uložit a změnit mu práva na spustitelná (např. chmod 777 skript.sh). Nyní soubor spustíme ./skript.sh a provede se jeho obsah. Sekvenční provádění příkazů má, jak je patrno, jednu ohromnou nevýhodu. Pokud například vytvoříme sekvenci těchto příkazů: cd trial mkdir adresar cd adresar cp /etc/passwd /home/kmartin/test/triol/adresar rm passwd




Je zřejmé, že jsme se dopustili několika chyb nebo alespoň jedné chyby a jedné "špatnosti". Tou špatností je uvedení příkazu cd trial na začátku skriptu. Co když umístíme skript nějakým omylem do jiného adresáře než do /home/kmartin/test, kde by se měl logicky nacházet? V takovém případě se dočkáme hned dvou chybových hlášek a zůstaneme na původním umístění. Druhou závažnou věcí je překlep, kterého jsme se dopustili při kopírování souboru /etc/passwd. Cílový adresář je podadresářem v trial, nikoliv triol. Docílíme tedy další chybové hlášky a žádný soubor se nezkopíruje (pokud samozřejmě v /home/kmartin/test nemáme ještě nějaký adresář triol :)). Z těchto dvou chyb nám plynou dvě poučení vždy je dobré uvádět cesty v absolutní formě (tj. cd /home/kmartin/test). Tím předejdeme možným komplikacím při přenášení skriptu. Dále pak vždy pečlivě kontrolujte to, co píšete některé překlepy mohou být i osudné... A mimochodem, z vlastní zkušenosti doporučuji nepoužívat při sekvenčním provádění příliš mnoho příkazů rm. Na to už doplatilo hodně lidí. Vždy je lepší si smazat soubory či adresáře ručně. Nikdy nevíte, co se může stát...

Podmíněné provádění př íkazů Tolik tedy v krátkosti k sekvenčnímu provádění příkazů. Nyní přejděme dál. Podíváme se na podmíněné provádění příkazů. Pozor, nebude řeč o podmínkách jako takových, tedy příkazech if & spol. Nejprve si vysvětlíme, jak BASH zpracovává příkazy, respektive vyhodnocuje úspěšnost jejich provedení. Jestliže na příkazové řádce zadáme nějaký příkaz a potvrdíme klávesou Enter, máme logicky pouze dvě možné varianty odpovědi buď se příkaz provede bez komplikací nebo se neprovede a BASH ohlásí chybu. Pokud toto provedeme interaktivně, jistě dokážeme celou situaci vizuálně vyhodnotit. Pokud však pracujeme se skripty, musíme vyhodnocovat tuto situaci automaticky. Slouží k tomu proměnná $?. Pro začátek můžete vyzkoušet na příkazové řádce zadat: $ cd /etc $ echo $?

Co bude výstupem? Pokud nepoužíváte nějakou zcela extrémně zmutovanou distribuci Linuxu, pak se vám na obrazovce objeví 0. Nula jako návratový kód symbolizuje bezchybné provedení předchozího příkazu. Když však zadáme: $ cd /hura_slava_bash_je_nejlepsi!!! $ echo $?




Zřejmě bude výstupem 1. Pochybuji, že někdo z vás má v rootu standardně adresář / hura_slava_bash_je_nejlepsi!!!. Číslo jedna jako návratový kód symbolizuje chybné provedení předchozího příkazu. Můžeme dokonce jít tak daleko, že příkaz samotný bude vyjádřením svojí pravdivostní hodnoty: $ $ $ $

true echo $? false echo $?

Když vyzkoušíte výše uvedené příkazy, získáte postupně odpovědi 0 a 1. Všechny tyto triky zužitkujeme při konstrukci podmínek a cyklů. Nicméně pozor, návratová hodnota příkazu nemusí být pouze nula nebo jednička. Různé chybové hlášky jsou interpretovány různými čísly. Například pro příkaz, jehož výstupem je "command not found" získáme po zadání echo $? hodnotu 127. Když už jsme se naučili zjišťovat návratový kód příkazu, můžeme toho využít při konstruování složitějších příkazů. BASH toto umožňuje velmi efektivně, zkrátka můžeme zadat několik příkazů, které se provedou postupně v závislosti na návratové hodnotě předchozího příkazu.

Seznamy Nyní jsou na řadě seznamy k jejichž realizaci používáme operátory && a ||. Oba tyto operátory slouží také k podmíněnému zpracování příkazu na základě návratové hodnoty příkazu předešlého. Často používaná kombinace je například make && make install. Operátor && zajistí, že se následující příkaz provede v případě, že ten předchozí byl proveden úspěšně. Operátor || funguje opačně příkaz se provede, pokud předchozí skončil neúspěšně. Jak už jsem řekl, časté využití těchto operátorů je při instalaci. Zkrátka jen spustíme skript s názvem například instaluj.sh, který provede sekvenci příkazů ./configure && make && make install a program bude nainstalován. Nemusíme tedy nezkušeného uživatele zatěžovat s nějakými instalačními procedurami. Tyto operátory však můžeme využít i k jiným účelům. Například: cd archiv && rm -r neco. V tomto případě máme naprostou jistotu, že skript, který bude obsahovat tento řádek, smaže podadresář neco v adresáři archiv. Nemusíme se tedy bát toho, že jej spustíme v nějakém jiném adresáři a napácháme tím nějakou škodu s největší pravděpodobností totiž jeho provádění skončí ihned po prvním příkazu, který dopadne neúspěšně. A podívejme se ještě na jeden zajímavý operátor !. O vykřičníku už jsme si povídali v souvislosti s historií příkazů. Avšak nezaměňujte tato dvě jeho využití. Pokud nějakému příkazu předřadíme vykřičník, dosáhneme přepólování návratové hodnoty tohoto příkazu, přičemž na činnosti příkazu




samotného se nic nezmění. Podívejme se na příklad: $ echo "neco" neco $ echo $? 0 $ ! echo "neco" neco $ echo $? 1

Využití tohoto operátoru je vhodné zejména ve skriptech, které předáváte dalším lidem. Je totiž zřetelnější a jasnější než operátory && a ||, které jej dokážou v mnoha ohledech zastoupit/nahradit. Příkazový zápis, kde jednotlivé položky jsou od sebe odděleny operátory && nebo ||, nazýváme seznam.

Podmínkové konstrukce Konečně se tedy dostáváme k podmínkovým konstrukcím, jež můžeme v BASHi vytvářet. Základní forma podmínkové konstrukce je tvořena klíčovými slovy if, then, else a fi. Za if následuje seznam příkazů, od nichž se očekává návratová hodnota 0 nebo 1. Následuje slovíčko then, které říká interpretu, co má v případě úspěšného provedení příkazu udělat. Potom je podmínková konstrukce buď ukončena (slovíčkem fi) nebo je dále prodloužena o větev else, která je následována seznamem příkazů, co budou vykonány při nesplnění podmínky. Dále pak existuje ještě klíčové slovo elif, které je synonymem pro else if, tedy zápis další podmínky, která rozšiřuje podmínku původní. Dnes se však zaměříme především na jednoduché podmínky se základním větvením. Uveďme si pro ilustraci malý příklad: if cd zkouska then echo "Adresar zmenen." fi

Pokud vytvoříte skript, který by obsahoval tuto konstrukci, docílíte výpisu hlášky "Adresář změněn." ve chvíli, kdy dojde k přejití do adresáře zkouska. Pokud k tomuto přechodu nedojde (skript se nenachází ve stejném adresáři, jako podadresář zkouska), nevypíše se nám na obrazovku zkrátka nic jen chybová hlášku systému, že adresář nebyl nalezen. Jak je to prosté. O trochu složitější pak bude následující podmínková konstrukce, která nám již nějaký výstup zprostředkuje:




if cd zkouska then echo "Adresar zmenen." else echo "Chyba - adresar nebyl nalezen." fi

Podobně, jako v předchozím případě, také zde nám skript po svém spuštění vypíše na obrazovku hlášku "Adresář změněn.", když dojde k přejití do podadresáře zkouska. Pokud však tento adresář nebude nalezen, vypíše se nám chybová hláška systému a text "Chyba adresář nebyl nalezen.". Abychom si to však ještě trochu ztížili, přidáme další větev, které bude vévodit naše avizované elif: if cd zkouska then echo "Adresar zmenen." elif cd /home/martin then echo "Jsi doma." else echo "Chyba - adresar nebyl nalezen." fi

V tomto případě jsme přidali konstrukci, která při neúspěšném provedení příkazu "cd zkouska" zajistí provedení příkazu "cd /home/martin". Podle výsledku této procedury se pak rozhodne o koncové akci. Možné výstupy jsou tedy tři: • • •

"Adresář změněn." pokud se přepneme do adresáře zkouska "Jsi doma." pokud se přepneme do domovského adresáře "Chyba adresář nebyl nalezen." pokud žádný z uvedených adresářů neexistuje nebo není přístupný z dané pozice

Příka z test Nyní navážeme na problematiku podmínkových konstrukcí příkazového interpretu BASH a budeme se zabývat příkazem test, který se v podmínkách skriptů velmi často vyskytuje a jehož dobrá znalost použití je pro psaní vlastních skriptů nezbytná právě tento příkaz se totiž v podmínkových konstrukcích používá asi nejčastěji. Povíme si, jak testovat vlastnosti a atributy souborů a vše si předvedeme na řadě praktických ukázek. Již umíme používat konstrukce podmínkových příkazů a jejich větvení. Dnes naše znalosti obohatíme o testování souborů a adresářů pomocí příkazu test. Právě tento příkaz se totiž v podmínkových konstrukcích používá asi nejčastěji. Než přejdeme k popisu jeho činnosti, předvedeme si drobný příklad. www.linuxzone.cz strana 137 / 159



if test -d home then cd home else echo "home není adresar... :-/" fi

Příkazem test s parametrem -d zjistíte, zda analyzovaný soubor je adresářovým souborem. Nebo abych byl přesnější návratová hodnota příkazu bude 0, pokud uvedený argument je adresářem. Můžeme tedy tento příkaz využít pro zjištění vlastností souboru či adresáře. Pokud nás zajímá, zda je testovaný argument klasickým souborem, využijeme k tomu parametr -f. Když chceme testovat, jeli argument symbolickým odkazem, máme k dispozici parametr -L. Tím jsme tedy vyčerpali seznam voleb, které slouží k rozlišení typů souborů. Avšak tím možnosti příkazu test nekončí. Můžeme jej využít i k otestování práv volba -x prověří, zda má daný uživatel právo na spuštění souboru, volba -r nás zase informuje o tom, jestli můžeme soubor číst a volbou -w prověříme, zda máme právo na zápis do souboru. Tedy například: if test -w /etc/shadow then echo "Enjoy :-)" else echo "Sem samozrejme pristup nemate." fi

Máme k dispozici ale i řadu dalších voleb. Často využívanou je například -s, která nám sdělí, jestli má soubor nenulovou délku (tedy hodnota true, tj. 0, bude vrácena v případě, že soubor není prázdný). Můžeme využít i volbu -e, která nás zase informuje pouze o existenci souboru, nezávisle na jeho obsahu pokud je tedy soubor prázdný, bude podmínka splněna a interpret nám vrátí hodnotu 0 (stejně jako v případě, že soubor prázdný není). To ale stále není všechno. Můžeme jednotlivé podmínky spojovat slouží k tomu volby -a, která symbolicky zastupuje AND a znamená, že musí být splněny všechny podmínky (respektive podmínka na levé i pravé straně výrazu) a volba -o, která logicky zastupuje OR a vyjadřuje, že podmínka bude splněna, pokud bude vyhovovat alespoň jedna z možností. Pro názornost si uveďme příklad: Chceme zjistit, jestli soubor nic.txt existuje a má nulovou délku. Využijeme k tomu volby -e a negovanou volbu -s. Ano, volby můžeme i negovat. Jednoduše jim předřadíme vykřičník, čímž změníme jejich "polaritu". V praxi to tedy bude vypadat následovně: if test -e nic.txt -a ! -s nic.txt then echo "Soubor existuje, ale ma nulovou delku\!"



else fi


echo "Soubor neexistuje nebo neni prazdny\!"

Jak je to snadné... Ale může to být ještě snazší. Konstrukci příkazu test totiž můžeme efektivně nahradit hranatými závorkami. Tato možnost se využívá velmi často, protože usnadňuje orientaci v kódu a zvyšuje jeho přehlednost. Navíc ušetříme dva stisky kláves, což už přece jenom stojí za to. ;) Když se tedy rozhodneme přepsat výše uvedený příklad do této formy, získáme následující podobu: if [ -e nic.txt -a ! -s nic.txt ] then echo "Soubor existuje, ale ma nulovou delku\!" else echo "Soubor neexistuje nebo neni prazdny\!" fi

Tolik tedy k příkazu test a jeho použití. Shrňme si ještě v tabulce nejčastěji používané volby, které nám tento příkaz nabízí. Upozorňuji, že jejich výčet není zdaleka úplný. Test je plnohodnotným příkazem Unixu, takže jeho uplatnění je velmi široké. Pro podrobný popis tohoto příkazu si prostudujte jeho manuálovou stránku, nebo ještě lépe info stránku.

Volba Význam a

Zastupuje AND musí být splněny podmínky na obou stranách

d

Identifikuje adresář

e

Zjistí, zda soubor existuje (nezkoumá jeho délku)

f

Zjistí, zda se jedná o běžný soubor

L

Zjistí, zda se jedná o symbolický odkaz

o

Zastupuje OR musí být splněna alespoň jedna podmínka

r

Zjistí, zda má uživatel právo na čtení souboru

s

Zjistí, zda soubor existuje a má nenulovou hodnotu

w

Zjistí, zda má uživatel právo na zápis do souboru

x

Zjistí, zda má uživatel právo na spuštění souboru




Podmínky a větvení př íkaz case Nyní už umíme otestovat téměř vše :), takže se můžeme podívat, jak podmínky využít při větvění programového kódu pomocí příkazu case a také na práci s cykly. Tento příkaz vlastně není ničím jiným než zjednodušeným zápisem podmínkové konstrukce if then - else. Používáme jej tam, kde se interpret rozhoduje mezi větším počtem možností. Ukážeme si pro ilustraci jednoduchý příklad: ZVIRE=pes case $ZVIRE in kocka) echo "Kocky mam rad na smetane." ;; kralik) echo "Kralik na smetane chutna stejne, jako kocka." ;; pes) echo "Pes je nejlepsi s knedlikama." ;; *)

echo "Tak tohle jsem jeste nejedl." ;;

esac

Jestliže tento skript spustíme, výstupem bude "Pes je nejlepsi s knedlikama.". Jak vidíme, každá takováto konstrukce je uvozena nějakým prvotním přiřazením. Následně zkoumáme toto přiřazení a na základě vyhodnocení podmínky získáme výsledný výstup. Pokud žádná z uvedených podmínek nevyhovuje, provede se větev s hvězdičkou. Celou konstrukci pak ukončíme slovíčkem esac (pro ty, kteří pomaleji chápou řada konstrukcí při psaní skriptů se ukončuje uvozujícím slovíčkem napsaným pozpátku, viz např. if - fi. Totéž platí i u case - esac). To však stále není všechno. Příkaz case totiž umožňuje ve výčtu porovnávaných výrazů uvést paralelně více podmínek pro jednu možnost. Aby to bylo srozumitelnější, ukážeme si opět jeden příklad: PES=knirac case $PES in dobrman) echo "BDSM obojek z nej dela zabijaka." ;;




knirac|foxterier) echo "Rad kroupe mysi." ;; dalmatin) echo "Viz Disney." ;; *)

echo "To neznam... neni to kocka?" ;;

esac

Jestliže hodnota proměnné $PES bude knirac nebo foxterier, bude vždy provedena stejná podmínka a vypíše se tedy stejný text "Rad kroupe mysi." Stačí použít rouru a můžeme takto oddělit libovolné množství výrazů, pro něž bude daná podmínka platit. Zkuste si teď sami vytvořit skript, který vytiskne větu "Perfektni serial" v případě, že hodnota proměnné TV bude nastavena na simpsonovi nebo pratele. Jestliže bude hodnota této proměnné nastavena na esmeralda, vytiskne se "To je ale blbost, FUJ!" (nezapomeňte na zvláštní chování vykřičníku). V případě, že bude nastavena jiná hodnota, zobrazí se "To neznam, ale urcite je to pekna blbost. Radsi sed u PC a uc se BASH."

Cykly A konečně příchazejí na řadu cykly... Co je to vlastně cyklus? Cykly slouží k opakovanému provádění příkazu nebo sekvence příkazů. Toto opakované provádění je závislé na platnosti nebo neplatnosti dané podmínky. V zásadě můžeme cykly rozdělit na dvě skupiny s podmínkou na začátku a s podmínkou na konci. Jestliže je podmínka uvedena na začátku, znamená to, že se její platnost ověří před samotným provedením těla cyklu a jestliže podmínka nevyhovuje, cyklus se neprovede. Když ale máme podmínku uvedenou až na konci cyklu, provede se tento cyklus logicky minimálně jednou, protože interpret postupuje po jednotlivých řádcích kódu a než se dostane k podmínce, projde už jednou celým cyklem. Teprve pak se rozhodne, zda se vrátí ještě na začátek cyklu a celý jeho obsah provede ještě jednou nebo jestli bude pokračovat v provádění zbytku programu. Tímto dělením se však nebudeme dále zabývat, neboť v BASHi nemá příliš velký význam. Cyklus for Tento cyklus nachází své nejčastější uplatnění při práci se skupinou souborů. Tedy například pokud chcete vytvořit zálohu všech souborů v nějakém adresáři v podobě soubor.zaloha, je cyklus for ideálním prostředkem. Ukážeme si to hned na jednoduchém příkladu:




for soubor in * do cp $soubor $soubor.zaloha done

V tomto případě je hvězdička postupně nahrazena jednotlivými názvy souborů z aktuálního adresáře. Pro každý tento soubor je pak jednotlivě provedena akce, která je uvedena mezi klíčovými slovy do - done. Cyklus while a until Zatímco cyklus for prochází seznam jednotlivých položek, cyklus while, respektive until, provádí zadanou akci, dokud platí příslušná podmínka. Kupříkladu můžeme chtít procházet jednotlivé adresářové úrovně, v nichž se nachází adresář logy. Tedy například: while cd logy do pwd done

Výpis pak bude následující: /etc/logy/ /etc/logy/logy/ /etc/logy/logy/ logy/ /etc/logy/logy/ logy/logy/ bash: logy: No such file or directory

Jestliže je návratová hodnota posledního příkazu v seznamu rovna nule, provede se akce, uzavřená mezi klíčovými slovy do - done. Cyklus until funguje zcela analogicky, pouze s tím rozdílem, že cyklus je prováděn, dokud návratová hodnota není rovna nule. Jak je to prosté, že... Cykly s pevně daným počtem opakování Nejedná se o nic jiného, než předchozí cykly, se kterými se však pojí proměnná, která udává počet jednotlivých provedení cyklu. Budeme například chtít vytvořit padesát adresářů se jménem pokus-xx, kde xx bude nahrazeno číslicí od 01 do 50. Provedeme to následovně: POCET=0 while [ $POCET -ne 50 ] do




POCET=èxpr $POCET + 1` mkdir pokus-$POCET done

Syntaxe příkazu i jeho použití je zřejmé. Jediným prvkem, který je zde nový, je přepínač -ne (not equal). Ten symbolizuje, že daný cyklus se bude provádět, dokud se hodnota proměnné $POCET nebude rovnat padesáti. Existují i další přepínače ty shrnuje následující tabulka:

Př epínač Význam eq

je rovno

gt

je větší

lt

je menší

ge

je větší nebo rovno

le

je menší nebo rovno

Skupiny př íkazů Příkazový interpret umožňuje seskupit několik jednotlivých příkazů do skupin příkazů. To nám umožňuje zadat provedení většího množství příkazů najednou s tím, že jako návratový status skupiny příkazů obdržíme návratový status posledního vykonaného příkazu ze skupiny příkazů. V konečném důsledku to může vést k ovlivnění běžícího programu nebo například k zajištění efektivního běhu programu na pozadí či v rámci vnořeného interpretu příkazů. Vnořený interpret příkazů je takový, který je spuštěn v rámci aktuálního interpretu příkazů. Přestože dědí všechny vlastnosti aktuálního interpretu, změny, které ve vnořeném interpretu provedeme, nemají vliv na aktuální interpret. Než si předvedeme nějaký ukázkový příklad, měl bych ještě zmínit, že BASH nám pro uzavření příkazů do skupiny umožňuje použít jak složené, tak kulaté závorky. Pokud zvolíme závorky složené, docílíme toho, že jednotlivé příkazy budou prováděny v rámci aktuálního interpretu příkazů budou tedy jen uzavřeny do jednoho celku. Pokud se rozhodneme pro závorky kulaté, budou příkazy provedeny v rámci vnořeného interpretu, takže budou uzavřeny do jednoho celku a navíc jejich chování nebude mít vliv na aktuální interpret. A teď už přejděme k jednoduchému příkladu, ať si vše předvedeme v praxi. Nejdříve si vytvořte adresář "adresar", se kterým budete dále pracovat. Nyní jako první proveďte tuto skupinu příkazů: ( cd adresar; pwd ); pwd




Následně vyzkoušejte: { cd adresar; pwd }; pwd

Měli byste vidět jeden zásadní rozdíl. Pokud jste se před zahájením běhu skriptu nacházeli například v adresáři /home/allah, po spuštění první konstrukce byste měli obdržet následující výpis: /home/allah/adresar /home/allah

Zatímco po spuštění druhé konstrukce by výstup vypadal následovně: /home/allah/adresar /home/allah/adresar

Vidíme tedy rozdíl mezi prací s aktuálním a vnořeným interpretem příkazů v praxi. Je to prosté. Jaké má však celá věc využití v praxi? Něco málo jsem už naznačil. Avšak využití těchto konstrukcí je mnohem širší. Často se například setkáváme s možností spuštění skupiny příkazů na pozadí. To se hodí zejména při práci s dlouhotrvajícími automatizovanými programy. Podívejme se na jednoduchý příklad: ( cd /home/allah; for mesita in `find . -type d -print`;\ do ls -laF $mesita >> /home/buddha/allah-info.txt; done ) 2> /dev/null &

Na první pohled se může zdát celá skupina mírně nepřehledná, ale už na druhý pohled názor jistě změníte. Všimněte si především, že jsem použil kulaté závorky, abych nezatěžoval svůj aktuální interpret a předal tak veškerou činnost vnořenému interpretu příkazů. Když je skupina příkazů přesunuta na pozadí, získá interpret příkazů ihned návratový kód nula.

Možnosti zjednodušení aliasyfunkce Ne vždy se nám zrovna chce psát rozsáhlejší skupiny příkazů. Z tohoto důvodu nabízí Unixy jedno velké zjednodušení, které čtenářům tohoto seriálu nebudu ani příliš podrobně představovat jedná se o aliasy. Ty umožňují přiřadit jednomu slovu nebo příkazu vlastnosti jiného příkazu či právě skupiny příkazů. Tyto aliasy se ukládají mj. do souboru .bashrc. Pro ilustraci uvedu jeden z nich, který najde své uplatnění mezi těmi, kteří na svém PC využívají dualboot: alias cecko="mount /dev/hda1 /mnt/cecko"




Když nyní na příkazovém řádku napíšeme cecko, provede se ve skutečnosti příkaz mount / dev/hda1 /mnt/cecko a připojí se tak disk C z MS Windows (pokud je samozřejmě umístěn na /dev/hda1 což ovšem dosti často bývá). Samozřejmě tento příkaz může použít pouze uživatel root. Ostatní se budou moci spokojit pouze s daty z fstab, takže mohou napsat například alias cecko="mount /mnt/cecko", pokud je /mnt/cecko ve fstab definováno. Aliasy jsou jistě srozumitelné každému, kdo s Linuxem, resp.Unixy obecně, pracuje déle než týden. Poněkud náročnější, jsou ale funkce.

Funkce Syntaxe funkcí je o něco málo složitější než je tomu v případě aliasů. Avšak jejich upotřebení je mnohem efektivnější. Umožňují totiž zpracovávat argumenty příkazu zapsané na příkazové řádce a dokáží vracet návratové hodnoty programům, které je zavolaly. Předvedeme si jednu velmi oblíbenou funkci, na kterou můžete často narazit: function apath { [ -d $1 ] && export PATH=$1:$PATH }

Slovíčko function předchází názvu funkce, kterou definuje. Za tímto názvem pak následuje složená závorka z čehož plyne, že funkce bude provedena v rámci aktuálního interpretu a změny, které budou provedeny, přetrvají i po jejím ukončení. Výraz $1 zastupuje první parametr uvedený na příkazovém řádku (další parametr by byl uložen v proměnné $2, apod.). Celá uvedená funkce závisí na jednom parametru jménu zadaného adresáře. Pokud tento adresář existuje což testuje konstrukce [ -d $1 ] (viz příkaz test) bude přidán k obsahu proměnné PATH. Jak prosté. Ještě bych měl zmínit, že běh funkce končí ve chvíli dosažení ukončovací složené závorky anebo při provedení příkazu return, který do těla funkce můžeme začlenit. V tom případě bude návratová hodnota funkce odpovídat návratové hodnotě naposledy provedeného příkazu avšak můžeme návratovou hodnotu také explicitně definovat, například return 0, apod. Jestliže se rozhodneme pro explicitní definici, bude mít vyšší prioritu než skutečná hodnota a bude tedy navrácena místo ní.

Štábní kultura Při psaní skriptů shellu by se měla dodržovat určitá "štábní kultura", tedy soubor typografických pravidel, která mají zajistit, že se ve vašem skriptu vyzná i někdo jiný než vy. To je samozřejmě důležité zejména při psaní Open Source / Free Software programů, kdy do zdrojových kódů nahlížejí mnohdy třeba i desetitisíce lidí z celého světa.




Základem všeho jsou komentáře. Ve skriptech je uvozuje znak #, tedy "křížek". Vše, co následuje na daném řádku za tímto křížkem, bude interpretem ignorováno. Je vhodné používat komentáře na začátku každého skriptu sem se hodí napsat k čemu příslušný skript slouží. Pak je také vhodné komentovat každou složitější konstrukci, aby nikdo nemusel složitě pátrat, co která část programu vlastně dělá. Další důležitou věcí je odsazování vnořených struktur. Pokud píšeme cykly nebo podmínky, neměli bychom zapomínat, že jejich tělo je oproti podmínce odsazeno vždy alespoň (nejlépe) o dvě mezery. Tato hodnota je empiricky ověřena jako nejvhodnější a je lepší než použití tabulátoru, který je v různých editorech interpretován odlišně a zabírá zbytečně mnoho místa. Související části zdrojového kódu by měli patřit k sobě a jednotlivé celky by měly být vzájemně odděleny prázdným řádkem. Zvýší se tak přehlednost zdrojového kódu. Tato pravidla platí samozřejmě nejen pro psaní skriptů v BASHi, ale při jakémkoliv programování. Snažte se je proto dodržovat. Kdo nezvládne "štábní kulturu", ten nezvládl programování. Předveďme si dva malé ukázkové příklady. Rozhodněte sami, který z nich je asi ten lepší. :) #!/bin/bash select JIDLO in kure husa kachna pes fazole do if [ $JIDLO = "pes" ] then echo "NO FUJ\!" break fi echo "Hmmm... taky bych si dal." done

A teď druhá verze... #!/bin/bash # Tento skript zkouma vase psychopatologicke sklony, # ktere jsou zavisle na vasi oblibene strave. # Autorem je MUDr. Johnny Tux, DrSc. - [email protected] select JIDLO in kure husa kachna pes fazole do # zkoumani sklonu k tyrani pejsku a kocicek if [ $JIDLO = "pes" ] then echo "NO FUJ\!" break fi echo "Hmmm... taky bych si dal."




done # ---=== EOF ===---

Interaktivní výběr Výše uvedeným příkladem se dostáváme zároveň k další užitečné věci interaktivnímu výběru z nabídnutých možností. Slouží k tomu konstrukce select-do-done. Do určité míry je syntaxe této konstrukce shodná s příkazem case. Výše uvedený příklad asi jasně demonstruje, jak vlastně funguje.

Speciální proměnné Velmi užitečnou věcičkou jsou speciální proměnné, které BASH využívá. O některých jsme si už povídali a dnes se zaměříme na podrobnější rozbor dvou takových proměnných. Jsou jimi $@ a $#. Do proměnné # se ukládá počet argumentů na řádce. Proměnná @ pak obsahuje všechny tyto parametry oddělené mezerou (správně bych měl říci, že oddělovacím znakem je první znak proměnné IFS (interfieldseparator), ale to je standardně právě mezera, takže se tím nebudeme dále zabývat). Ukážeme si opět jednoduchý příklad: #!/bin/bash # Ukazkovy skript. :-) echo echo echo echo

"Tento skript se jmenuje $0." "Pri spusteni mu bylo zadano $# parametru:" $@ "$1 $2 $3 $4 $5 $6 $7 $8 $9 $10"

# EOF

V uvedeném příkladu využíváme jak výše uvedené proměnné, tak i proměnné, reprezentující jednotlivé poziční parametry, tedy 09. První taková proměnná $0 obsahuje první parametr na příkazové řádce, tedy zřejmě název skriptu například ./skript.sh. Proměnné $1$9 obsahují jednotlivé další parametry z příkazové řádky. Jak ale vidíte, využili jsme v příkladu i proměnnou $10. Vyzkoušejte jak bude interpretována, pokud zadáte na příkazovou řádku skutečně deset parametrů. Nebudu vás napínat. Výstupem bude nesmysl obsah proměnné $1 následovaný číslicí 0. Jak to tedy napravit? Nebojte se, není to zase tak těžké. Stačí namísto $1 zapsat ${10} Alternatvině také můžeme použít šikovný příkaz shift, který každou proměnnou přečísluje. Ukážeme si předchozí příklad ve variantě pro patnáct argumentů s použitím příkazu shift.




#!/bin/bash # Ukazkovy skript - v.2. :-) echo "Tento skript se jmenuje $0." echo "Pri spusteni mu bylo zadano $# parametru:" echo $@ echo "$1 $2 $3 $4 $5 $6 $7 $8 $9" shift 6 echo "$4 $5 $6 $7 $8 $9" # EOF

Teď se tedy každá poziční proměnná počínaje parametrem číslo 7 a výše přečísluje tak, že se ocitne na pozici o 6 nižší. Takže z proměnné číslo číslo deset bude proměnná číslo čtyři, z jedenáctky pětka a podobně. Tímto příkladem náš tutoriál programování interpretu BASH ukončíme.



10. Tip: Pracujeme se skenery

10. Tip: Pracujeme se skenery Chystáte se pořídit si ke svému linuxovému desktopu skener? Problematice skenování jsme se již jednou věnovali, tentokrát se pro změnu podíváme na možnosti využití USB skenerů řeč bude konkrétně o skenerech Epson, které jsou pod Linuxem velmi dobře podporovány. Úvodem si řekneme pár slov o architektuře rozhraní SANE, potom projdeme postup zprovoznění USB skeneru s důrazem na skenery Epson a nakonec si představíme některé aplikace, bez kterých se při skenování neobejdeme, včetně nástroje Image Scan!, který je určen speciálně pro skenery Epson. Původní článek věnovaný problematice skenování pod Linuxem, který popisuje zprovoznění SCSI skeneru pod Linuxem najdete zde.

Rozhraní SANE a TWAIN Protože výrobci skenerů používají řadu proprietárních protokolů, aplikace obvykle nepracují se skenery přímo, ale používají standardizované aplikační rozhraní. Výrobce skeneru pak ke svému produktu obvykle dodává ovladače, které určité rozhraní podporují. Běžně se setkáme se dvěma API, jedním je TWAIN, které je běžné v prostředí MS Windows, naopak pod Linuxem se používá téměř výhradně rozhraní SANE. SANE (z angl. Scanner Access Now Easy) tedy definuje jednotné aplikační rozhraní (API), přes které aplikace se skenery (a nejen skenery, také případně také kamerami apod.) pod Linuxem a řadou dalších (nejen UN*Xových) systémů pracují. Detailní specifikace rozraní je k dispozici na domovské stránce projektu SANE (http://www.mostang.com/sane). Naopak na platformách Microsoft Windows či Apple dominuje rozhraní TWAIN a tato dvě rozhraní jsou zcela rozdílná. Autoři SANE toto API vytvářeli s tím, aby toto rozhraní snadno umožňovalo přistupovat k zařízením i přes síť, s čímž architektura TWAINu nepočítá. Existují ale projekty WinSANE a SaneTWAIN, které skenery připojené k Linuxovým systémům zpřístupňují na počítačích s Microsoft Windows (WinSANE či SaneTWAIN pak vystupuje jako TWAIN kompatibilní ovladač a i na počítačích s Microsoft Windows je pak možné používat obvyklé TWAIN kompatibilní aplikace; nemohu se zde ale vyjádřit ke kvalitě těchto nástrojů, protože s těmito platformami nepracuji pokud máte někdo zkušenosti, můžete je napsat do diskuse pod článkem.)

Architektura SANE SANE rozlišuje mezi "frontendem" a "backendem". Frontend nebo klient je jakákoliv aplikace, které prostřednictvím SANE API přistupuje ke skeneru. Součástí distribuce SANE je např. utilita scanimage (určená pro příkazovou řádku) nebo xsane (grafický klient pro X Window System), ale také démon saned, který zpřístupňuje skener po síti.




SANE backend je ovladač, který komunikuje na jedné straně s aplikací (frontendem či klientem), na straně druhé přímo ovládá dané zařízení a stará se o přenos a konverzi dat. Backend (ovladač) obvykle obsahuje podporu pro více příbuzných modelů, např. SCSI skenery UMAX jsou podporovány ovladačem sane-umax, většina skenerů Epson (SCSI, USB i s paralelním rozhraním) je podporována ovladačem sane-epson apod. Některé ovladače (backendy) nekomunikují se vstupními zařízení přímo např. sane-v4l může komunikovat prostřednictvím rozhraní Video4Linux s kamerou, ovladač sane-net umožňuje přistupovat prostřednictvím sítě ke skenerům připojeným k okolním počítačům (na kterých běží saned). Jak to může vypadat, ukazuje následující schéma: počítač 1 počítač 2 +--------------------------------+ +----------------------------+ | | | | | xsane (SANE klient) | | xsane (SANE klient) | | | | | | | | | | síť | | | | sane-epson ------- saned <----------> sane-net (libsane-net.so)| | (libsane-epson.so) | | SANE backend | | SANE backend | | | | | | | | +--------|-----------------------+ +----------------------------+ | skener

Podporované skenery Pod Linuxem lze provozovat skenery s rozhraním SCSI (toto rozhraní je rychlé, nicméně od SCSI rozhraní se upouští a dnes jsou v SCSI provedení dostupné pouze dražší modely skenerů), skenery komunikující přes paralelní port (také od něj se upouští, navíc nevýhodou je pomalost rozhraní) nebo rozhraním USB (většina dnes dostupných skenerů), ale také třeba s rozhraním IEEE1394 (FireWire): Přehledné seznamy skenerů podporovaných pod Linuxem jsou k dispozici rovněž na stránkách projektu SANE (viz také odkazy v závěru článku): • • •

sanebackend search možnost vyhledávání podle modelu, listování podporovanými modely skenerů... stránka věnovaná skenerům vybavených paralením portem stránka venovaná skenerům s rozhraním USB

Před koupí skeneru bychom se rozhodně měli ujistit, že skener je skutečně pod Linuxem podporován (je uveden na seznamu podporovaných skenerů, pozor typ skeneru musí doslovně souhlasit!) a případně dohledat konkrétní zkušenosti uživatelů v diskusních listech týkajících se SANE nebo i jinde (groups.google.com). Bohužel rozšíření Linuxu na desktopu stále jěště není velké, a tak zde uživatelé často narážejí na nezájem výrobců hardwaru podpořit nebo alespoň umožnit vývoj potřebných ovladačů pro SANE, což ve svém důsledku významně redukuje možnost




uživatelova výběru. To ovšem neznamená, že by se dnes nedal vybrat skener dle vašich představ a požadavků na kvalitu nebo i cenu, jenom je potřeba věnovat výběru skeneru větší pozoronost.

Skenery Epson Pokud předchozí odstavec vyzníval poněkud pesimisticky, mohu vás ujistit, že jsou mezi výrobci skenerů i takoví, kteří v dostatečné míře umožňují nebo dokonce vývoj ovladačů pro Linux podporují a snad nejlépe je na tom v tomto směru právě Epson. Jak je to tedy s podporou běžně dostupných USB skenerů Epson (detailní informace najdete na seznamech podporovaných skenerů, viz také odkazy výše): • • •

1 většina USB skenerů Epson (např. modely Perfection 1240U/Photo, 1640SU, 1650/Photo, 1660/Photo, 2400/Photo, 2450/Photo) jsou podporovány backendem saneepson. modely Perfection 1250/Photo a 1260/Photo jsou podporovány backendem pro skenery (Plustek) a také nástrojem (Image Scan!) Perfection 660 tento model obsahuje čipovou sadu LM9832 a je podporován v rámci projektu Snapscan (Snapscan).

Zprovoznění USB skeneru Zprovoznění podporovaného USB skeneru nepředstavuje žádný zásadní problém, po připojení skeneru k USB portu by se měl objevit v seznamu připojených USB zařízení v souboru / proc/bus/usb/devices a také bychom jej měli vidět v "Prohlížeči hardware", s tím, že je mu přiřazen ovladač "scanner":

Pokud se stane, že skener jako USB zařízení vidíme, ale nemá přiřazen ovladač "scanner", musíme se sami postarat, aby systému explicitně aby tento ovladač použil. Nejprve si vyhledáme detailní informace o skeneru spustíme jako uživatel root /usr/sbin/kudzu -s -p a v části výstupu týkající se skeneru vyhledáme položky "vendorId" a "deviceId", např.: class: OTHER bus: USB detached: 0




driver: scanner desc: "Seiko Epson Corp. Perfection 2400 Photo" usbclass: 0 usbsubclass: 0 usbprotocol: 0 usbbus: 1 usblevel: 1 usbport: 0 usbdev: 2 vendorId: 04b8 deviceId: 011b usbmfr: EPSON usbprod: EPSON Scanner

Nyní natáhneme modul scanner (příkazem /sbin/modprobe scanner) a předáme mu identifikaci zařízení jako parametry, např. pro tento konkrétní model skeneru takto: modprobe scanner vendor=0x04b8 product=0x011b

Do budoucna si můžeme ušetřit práci zadáním parametrů do /etc/modules.conf. options scanner vendor=0x04b8 product=0x011b

Pokud vše funguje tak, jak má, uvidíme v systémovém logu podobné hlášení: hub.c: new USB device 00:07.2-1, assigned address 3 usb.c: USB device 3 (vend/prod 0x4b8/0x11b) is not claimed by any active \ driver.usb.c: registered new driver usbscanner scanner.c: USB scanner device (0x04b8/0x011b) now attached to scanner0 scanner.c: 0.4.13:USB Scanner Driver

Pokud narazíte při zprovozňování USB zařízení na problémy, dobrým zdrojem informací je již zmiňovaná dokumentace na stránkách www.linuxusb.org. Nyní je tedy skener systémem rozpoznán a zbývá ještě nakonfigurovat sane. Konfigurace SANE je uložena v adresáři /etc/sane.d/. Soubor dll.conf obsahuje seznam ovladačů, které jsou k dispozici. Adresář dále obsahuje konfigurační soubory jednotlivých ovladačů nás bude zajímat soubor epson.conf, který obsahuje konfiguraci ovladače sane-epson. Nám postačí pouze přidat řádek: usb /dev/usb/scanner0

Funkčnost sane si z příkazové řádky ověříme pomocí nástroje scanimage: $ scanimage -L device èpson:/dev/usb/scanner0' is a Epson GT-9300 flatbed scanner




Aplikace scanimage nástroj pro př íkazovou ř ádku Součástí distribuce sane je utilita scanimage. Jedná se o nástroj pro příkazovou řádku, který ale zpřístupňuje všechny funkce a nastavení, které ovladače jednotlivých typů skenerů nabízejí a samozřejmě také umí přistupovat k skenerů přes síť, pokud to konfigurace umožňuje. Spustímeli jej s parametrem --help, získáme nápovědu a pokud spolu s --help zadáme volbou -d zařízení, vypíše také všechna možná nastavení pro daný typ skeneru. Skenovaný obrázek pak scanimage posílá na standardní výstup. Podporuje výstup ve formátech PNM a TIFF. $ scanimage -d net:vanvancito:epson:/dev/usb/scanner0 \ -x 100mm -y 100mm --resolution 600 --format tiff --mode color \ --depth 8 --verbose > test.tiff scanimage: scanning image of size 2360x2362 pixels at 24 bits/pixel scanimage: acquiring RGB frame

Pro ilustraci tento příkaz oskenuje v barvě čtverec rozměru 10 x 10 cm z pravého horního rohu v rozlišení 600 dpi, přes síť ze skeneru připojeného k hostiteli "vanvancito" a uloží obrázek ve formátu tiff do souboru test.tiff: xsane Toto je nejvíce používané GUI nástroj pro skenování pod Linuxem. Můžeme jej používat jako samostatnou aplikaci, ale funguje i jako zásuvný modul pro Gimp. (Pak se v menu "Soubor" objeví položka "Získat", přes kterou xsane plugin spustíme. Xsane obsahuje vše, co bychom od takového software očekávali: získání náhledu, možnost manipulace s řadou parametrů (jas, kontrast, gamma korekce atd.), obrázky ukládá ve formátech jpeg, png, pnm, ps, raw a tiff. Pokud máme k počítači připojenou tiskárnu, můžeme xsane použít v režimu kopírování nebo také jako fax, mámeli fax modem. Ovládání je poměrně snadné.




Image Scan! software pro skenery Epson Pro skenery Epson je také k dispozici software přímo od výrobce (viz odkazy ke stažení v závěru kapitoly). Image Scan! (z příkazové řádky spouštěn jako iscan) je GUI nástroj s poměrně jednoduchým rozhraním, nicméně je vysoce funkční. Uživatele zejména potěší to, že je vystavěn na obdobných algoritmech jako obslužný software dodávaný pro platformu Microsoft Windows a i když na první pohled nenabízí tolik možností jako xsane, je stabilní a také díky přednastavení parametrů výrobcem pro jednotlivé modely skenerů dává velmi dobré výsledky. Může fungovat také jako zásuvný modul Gimpu (obdobně jako v případě xsane stačí doplnit symbolický odkaz do adresáře s pluginy Gimpu). Obrázky umí ukládat ve formátech PNM a PNG, pokud máte tiskárnu Epson, můžete také využít linuxový software pro tyto tiskárny rovněž z dílny Epsonu Photo Image Print System pro kvalitní tisk ve foto kvalitě.




Skenování z negativu Pokud jde o skenování z negativu / pozitivu, můžeme použít jak xsane, tak Image Scan!. Skenování je ale mnohem snazší s Image Scanem. Xsane sice obsahuje přednastavené parametry pro některé druhy filmů, ale bez dalších úprav naskenovaných obrázků v Gimpu se většinou neobejdeme. Naproti tomu autokorekční algoritmy iscanu dávají velmi slušné výsledky alespoň pokud jsem měl možnost posoudit jak při skenování z negativu na filmech Agfa, Kodak a Konica, tak i při skenování z pozitivu.




Skener v síti Sdílení skenerů je jednoduchá. Na straně serveru, ke kterému je připojen skener je potřeba nakonfigurovat démon saned. Nejprve založíme uživatele a skupinu saned, pod kterou saned poběží (z bezp. důvodů není rozumné nechat saned běžet pod uživatelem root) a upravíme přístupová práva ke skeneru tak, aby jej uživatel saned směl používat. Saned používá konfigurační soubor saned.conf, který obsahuje seznam strojů, ze kterých bude akceptovat spojení. Protože je ale spouštěn prostřednictvím démona xinetd a Linuxové distribuce zpravidla obsahují tcp_wrapper, postačí do souboru saned.conf zapsat jediný znak "+" což znamená, že saned bude akceptovat spojení odevšad. Vlastní kontrolu přístupu k skeneru pak na serveru upravíme v souborech /etc/hosts.deny a /etc/hosts.allow, které nabízejí mocnější syntaxi (viz dokumentace tcp_wrapper, např. manová stránka hosts.allow a tcpd). Dále pak musíme upravit konfiguraci xinetd a definovat zde službu sane: # soubor /etc/xinetd.d/sane # # default: on # description: saned scanner service service sane { flags = REUSE socket_type = stream wait = no user = saned.saned



server log_on_failure disable }


= /usr/sbin/saned += USERID = no

Na obou počítačích pak musíme službu zanést do souboru /etc/services, který obsahuje seznam běžně používaných síťových služeb a jim přiřazených čísel portů. Do /etc/services přidáme následující řádek: sane 6566/tcp # SANE network scanner daemon

Na klientském počítači se ještě ujistíme, že je v konfiguračním souboru sane dll.conf povoleno použití síťového ovladače (řádek obsahující slovo "net" musí být odkomentován). Pokud jsme vše správně nakonfigurovali, můžeme na klientském počítači spustit scanimage s nám již známou vobou -L a ve výpisu dostupných zařízení by se měl skener připojený k serveru objevit: $ scanimage -L device 'net:vanvancito:epson:/dev/usb/scanner0' \ is a Epson GT-9300 flatbed scanner

Když už jsme u toho síťování, existuje také projekt sane-cgi, který poskytuje webové rozhraní k SANE.

Závěrem... Většina dnes běžně dostupných skenerů je dodávána s rozhraním USB, ovšem ne všechny USB skenery je možné provozovat pod Linuxem. Skenery EPSON patří mezi ty dobře podporované (i když i tady je vhodné si toto před koupí skeneru ověřit) což je výsledkem solidního přístupu výrobce k linuxové komunitě. Velkým plusem je v případě skenerů Epson dostupnost software Image Scan!, který umožňuje i pod Linuxem zcela bezproblémové skenování i z transparentních předloh. Při psaní tohoto textu jsem měl k dispozici skener Epson Perfection 2400 Photo a výsledný dojem z tohoto skeneru a jeho využití pod Linuxem je velmi dobrý.

Odkazy Rozhraní SANE, TWAIN: • •

Domovská stránka SANE Domovská stránka TWAIN

Podporované skenery: • • •

Skenery podporované SANE Skenery s paralelním portem Skenery s rozhraním USB www.linuxzone.cz strana 157 / 159


• •


Snapscan Ovladač ppSCSI

Obslužný software podporující SANE: • • • • •

Xsane aplikace pro X Window System (SANE) Image Scan! software pro skenery Epson (SANE) QuiteInsane rozhraní SANE pro X11 na bázi Qt Scan Lite rozhraní SANE v Javě Sanecgi www rozhraní k SANE

Diskusní skupiny, další dokumentace: • • • • •

Diskusní listy SANE Color management plugin pro Gimp SANE FAQ Skenování negativů s Gimpem Průvodce konfigurací USB zařízení pod Linuxem

Projekty stojící mimo SANE: • •

Projekt Primax (skenery nepodporované SANE) Projekt HPOJ podporující HP OfficeJet

Software zajišťující kompatibilitu mezi SANE TWAIN: • •

WinSANE SaneTWAIN



11. Tip: pracujeme s digitálním fotoaparátem

11. Tip: pracujeme s digitálním fotoaparátem Pro práci s digitálními fotoaparáty js k dispozici aplikace gtkam, která je přístupná z hlavího menu přes položky "Grafika" > "Digital Camer Tool". Po spuštění se gtkam sám pokusí detekovat připojené zařízení, alternativně můžeme prostřednictvím dialogu zařízení vybrat ručně.

Jakmile je správně nastaveno zařízení, můžeme pomocí jednoduchého grafického rozhraní prohlížet, stahovat nebo mazat uložené snímky. Gtkam podporuje standard EXIF, je tedy možné také stáhnout i EXIF data s jednotlivými obrázky.

Pro úpravu obrázků lze s výhodou použít kvalitní bitmapový editor Gimp, který je také s Mission dodáván.


Instalační a uživatelský manuál pro Linux Mission 1.0. David Häring a kolektiv autorů LinuxZone

Recommend Documents