Instalační a uživatelský manuál pro Linux Mission 1.0

Transkript

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 Impossible: Linux Mission 1.0
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é
•
•
•
•
•
www.linuxzone.cz strana 3 / 159
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 www.linuxzone.cz strana 4 / 159
• 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 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/. www.linuxzone.cz strana 6 / 159
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. www.linuxzone.cz strana 7 / 159
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). www.linuxzone.cz strana 9 / 159
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. www.linuxzone.cz strana 10 / 159
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í. www.linuxzone.cz strana 11 / 159
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ší". www.linuxzone.cz strana 13 / 159
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ě
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.). www.linuxzone.cz strana 16 / 159
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. www.linuxzone.cz strana 17 / 159
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ší. www.linuxzone.cz strana 18 / 159
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. www.linuxzone.cz strana 21 / 159
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". www.linuxzone.cz strana 22 / 159
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. www.linuxzone.cz strana 23 / 159
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. www.linuxzone.cz strana 24 / 159
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. www.linuxzone.cz strana 25 / 159
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). www.linuxzone.cz strana 27 / 159
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. www.linuxzone.cz strana 28 / 159
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. www.linuxzone.cz strana 29 / 159
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. www.linuxzone.cz strana 30 / 159
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. www.linuxzone.cz strana 31 / 159
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. www.linuxzone.cz strana 32 / 159
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. www.linuxzone.cz strana 33 / 159
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. www.linuxzone.cz strana 34 / 159
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. www.linuxzone.cz strana 35 / 159
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
•
•
•
•
•
•
•
•
•
•
•
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
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.
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
blocks [2/2] [UU] resync=4\% finish=6.7min
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: www.linuxzone.cz strana 42 / 159
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
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. www.linuxzone.cz strana 44 / 159
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. www.linuxzone.cz strana 45 / 159
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í. www.linuxzone.cz strana 46 / 159
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
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. www.linuxzone.cz strana 52 / 159
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. www.linuxzone.cz strana 53 / 159
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. www.linuxzone.cz strana 54 / 159
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,
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: www.linuxzone.cz strana 59 / 159
[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". www.linuxzone.cz strana 61 / 159
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. www.linuxzone.cz strana 62 / 159
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. www.linuxzone.cz strana 64 / 159
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:/. www.linuxzone.cz strana 65 / 159
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
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
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ů. www.linuxzone.cz strana 68 / 159
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): www.linuxzone.cz strana 69 / 159
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. www.linuxzone.cz strana 74 / 159
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
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
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).
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 <unistd.h>
#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
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
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, www.linuxzone.cz strana 92 / 159
•
•
•
•
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: www.linuxzone.cz strana 93 / 159
•
•
•
•
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
# 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
# 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
[ .. zkráceno .. ]
|-- K95kudzu -> ../init.d/kudzu
|-- K96pcmcia -> ../init.d/pcmcia
|-- K99microcode_ctl -> ../init.d/microcode_ctl
`-- S00single -> ../init.d/single
rc2.d
`-- [ .. zkráceno .. ]
rc3.d
`-- [ .. zkráceno .. ]
rc4.d
`-- [ .. zkráceno .. ]
rc5.d
`-- [ .. zkráceno .. ]
rc6.d
|-- [ .. 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,
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: www.linuxzone.cz strana 98 / 159
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.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ů: www.linuxzone.cz strana 100 / 159
•
•
•
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. www.linuxzone.cz strana 102 / 159
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". www.linuxzone.cz strana 105 / 159
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). www.linuxzone.cz strana 106 / 159
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íť.) www.linuxzone.cz strana 108 / 159
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). www.linuxzone.cz strana 109 / 159
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. www.linuxzone.cz strana 112 / 159
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í: www.linuxzone.cz strana 114 / 159
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ší. www.linuxzone.cz strana 115 / 159
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"). www.linuxzone.cz strana 116 / 159
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. www.linuxzone.cz strana 117 / 159
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. www.linuxzone.cz strana 118 / 159
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? www.linuxzone.cz strana 121 / 159
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
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
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í. www.linuxzone.cz strana 125 / 159
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. www.linuxzone.cz strana 126 / 159
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
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. www.linuxzone.cz strana 129 / 159
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
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: www.linuxzone.cz strana 136 / 159
if cd zkouska
then
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
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: www.linuxzone.cz strana 141 / 159
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. www.linuxzone.cz strana 145 / 159
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. www.linuxzone.cz strana 147 / 159
#!/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. www.linuxzone.cz strana 148 / 159
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. www.linuxzone.cz strana 149 / 159
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é. www.linuxzone.cz strana 153 / 159
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ě. www.linuxzone.cz strana 154 / 159
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. www.linuxzone.cz strana 155 / 159
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
•
•
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. www.linuxzone.cz strana 159 / 159

Instalační a uživatelský manuál pro Linux Mission 1.0

Transkript

Podobné dokumenty

Příručka správce operačního systému Linux

Softwarový RAID a LVM

Acronis® Disk Director® 12 User`s Guide

Jak použít Open Clipart Library ve školství, nám

Nebezpečný Google – vyhledávání důvěrných

Praktické návody HOWTO Emacs pro začátečníky

o Linuxu

Zkouška zručnosti