Jak už jsem naznačil, distribuce zaměřené na běžné uživatele obsahují grafické nástroje pro správu systému. Pomocí těchto nástrojů je možné realizovat většinu nastavení systému v pohodlí grafického rozhraní. První věc, kterou byste měli učinit, je tyto nástroje alespoň trochu prozkoumat, podívat se, co všechno nabízí. Měli byste také najít správce balíčků, pomocí kterého můžete snadno a rychle nainstalovat další software.

Každá linuxová distribuce se dá spravovat i z příkazové řádky. Konfiguraci tvoří obyčejné textové soubory, které se dají otevřít jakýmkoliv editorem. S pomocí nástrojů příkazové řádky je možné realizovat mnohé. Ovšem, je potřeba do toho investovat více času. Je na vás, který způsob si vyberete. Tento "ruční" způsob správy systému většinou umožňuje více, ale je složitější. Grafické nástroje umožňují méně, ale jsou snadní k použití.

Bez dokumentace to opravdu nejde, a to zejména, pokud přecházíte z jiného operačního systému, a jste navyklí na jiný styl správy systému. Primárním zdrojem informací by pro vás měla být příručka k distribuci, kterou používáte. Tu nemůže dokumentace na těchto stránkách v žádném případě nahradit. Každá distribuce má totiž svoje charakteristiky a specifika, které vám žádná obecná dokumentace nesdělí. Není ani na škodu projít další dokumentaci, a to zejména, pokud něčemu nerozumíte nebo se chcete něco dozvědět. Práce s dokumentací je podstatným prvkem správy systému.

Dokumentaci GNU/Linuxu můžeme rozdělit do následujících kategorií:

Manuálové stránky a programovou dokumentaci byste měli najít minimálně v částečně počeštěné verzi ve většině přívětivých distribucí. Přeložené bývají dokumenty k nejčastěji používanému softwaru, zbytek dokumentace je v angličtině. K manuálovým stránkám se dostanete různými způsoby. Nejpohodlnější cestou v menu KDE je Centrum nápovědy spustitelné ručně příkazem khelpcenter, které shromažďuje jak část programové dokumentace, tak unixové manuálové stránky. Prostředí Gnome má k dispozici program gnome-help, který však integruje méně dokumentace. Z příkazové řádky je možné dostat se k dokumentaci pomocí příkazu man, který má syntax man program. Dokonce i tento příkaz sám o sobě má manuálovou stránku - man man.

Klasické manuálové stránky se dělí podle sekcí:

Sekci je možné specifikovat man číslo_sekce program, takže v situaci, kdy má program více manuálových stránek, můžete tu, kterou chcete, specifikovat. Například man 7 ip. Ne vždy ale víme, který příkaz (resp. program) se na co hodí, a k tomu existuje jakýsi index popisků jednotlivých programů, ve kterém je možné vyhledávat buď pomocí man -k hledaný_výraz nebo pomocí ekvivalentního příkazu apropos hledaný_výraz. Je možné specifikovat i číslo sekce, kterou chcete prohledat (a odfiltrovat tak popisy knihovních funkcí) pomocí přepínače -s, takže například apropos -s 1 mp3.

Pokud známe příkaz, ale nevíme, co přesně dělá, můžeme vyvolat onen krátký popisek příkazem whatis, například whatis ip. Pokud má stejný program či výraz více manuálových stránek v různých sekcích (například zrovna zmíněný příklad), vypíše nám příkaz whatis popisky ze všech sekcí.

Vyhledávat lze však i fulltextově, tedy v obsahu manuálových stránek, příkazem man -K hledaný_výraz (unixové systémy rozlišují velká a malá písmena, proto se argument -k liší od argumentu -K). Pozor, takové vyhledávání může trvat velmi dlouho a je určitě vhodné specifikovat hledané sekce parametrem -S (lze jich specifkovat více, oddělovač je čárka). Například man -S 8,9 -K memory.

Kromě manuálových stránek existují ještě stránky programu info, které některé projekty upřednostňují. Ty podporují hypertextové odkazy.

Manuálové stránky mají svou předepsanou strukturu, která vám pomůže se v nich velmi rychle orientovat:

Ne každá manuálová stránka musí být takto vybavena a dlužno dodat, že ani tento seznam není zcela kompletní. Podstatnými částmi je stručný přehled, který vás rychle obeznámí se syntaxí daného příkazu, popis, který tuto část rozvede do patřičné hloubky, někde nechybí ani příklady použití (velmi užitečná věc, mimochodem), samozřejmě nelze zapomenout na autora a copyright, ale bývá vhodné si všímat i souvisejících odkazů, které vám řeknou, kam ještě nahlédnout (příbuzná či přímo související témata).

Ne všechna dokumentace je ve formě manuálových stránek, část této dokumentace (někdy podstatná část) se nachází v adresáři /usr/share/doc. Mohou tam být distribučně specifické záležitosti (třeba jak nastavit postgresql server v Debianu) nebo zbytky dokumentace z původního zdrojového balíčku (README, INSTALL, přehled změn, ap.).

Systémová dokumentace je veškerá dokumentace vztahující se ke GNU/Linuxu obecně. Nebývá součástí linuxových distribucí, nachází se v knihovnách, knihkupectvích, na webu, popřípadě v podobě audiovizuálních dat. Tato dokumentace vám pomůže ozřejmit řadu záležitostí, zejména funkčních principů, popřípadě praktických rad a postupů, které si jen těžko osvojíte studiem programové dokumentace.

Kromě zmíněných zdrojů existuje The Linux Documentation Project^[14], který si klade za cíl sumarizovat širokou škálu poznatků o GNU/Linuxu. Hodit se mohou i odkazy v závěru této dokumentace.

Každá linuxová distribuce má svá specifika. Informace o nich naleznete v dokumentaci vydávané přímo k vaší distribuci, ať už v podobě tištěné či elektronické. Jejich znalost je klíčová pro každého uživatele (resp. správce) dané distribuce a může vám nejen objasnit celou řadu záležitostí, ale především vám poskytne návody, jak si práci s distribucí usnadnit a jak předejít eventuelním problémům, popřípadě jak je řešit.

Dokumentace GNU/Linuxu má i svá úskalí. Tím nejzřejmějším je její ohromující množství. To je důvodem, proč je třeba naučit se v dokumentaci vyhledávat (resp. filtrovat přebytečná data). Dalším problémem může být charakter dokumentace. Na tomto faktu se podepisuje skutečnost, že programovou dokumentaci píší programátoři, kteří mají tendenci být buď příliš odborní, nebo málo podrobní (tvorba dokumentace je zpravidla nejméně příjemnou činností při vývoji programu). Nedostatek dokumentace existuje spíše u okrajového softwaru, rozhodně ne u klíčového, ale přílišná odbornost nebo komplexnost dokumentace může působit problémy. Na druhou stranu, i špatná dokumentace je lepší než žádná.

Dokumentace má také tendenci zastarávat a pokud si uvědomíme rychlost, s jakou GNU/Linux roste, dostane tato záležitost zcela nový rozměr. Pokud si budete listovat nějakou knihou o GNU/Linuxu nebo budete-li číst nějaký starší článek či dokument na webu, mějte na paměti, že čas mohl od doby napsání dokumentu postoupit natolik, že se okolnosti změnily. Ne všechno se ale mění, jsou záležitosti, které platily před deseti lety a budou platit i za dalších deset.

Chce-li uživatel nainstalovat, odstranit či aktualizovat balíčky, použije za tímto účelem správce balíčků. Správce balíčků se podívá do databáze, vyřeší závislostní vazby a vyžádá si potvrzení od uživatele, je-li s vyřešením závislostí spokojen. Následně stáhne pomocí svých nástrojů sám všechny potřebné balíčky a ty nainstaluje, balíčky označené pro odinstalaci ze systému odstraní. Aktualizace databáze správce balíčků se děje buď automaticky před provedením jakékoliv operace (tak činí např. Yum), nebo ručně, kdy si o to uživatel požádá (tak činí např Apt).

Virtuální balíček je speciální typ balíčku, který neobsahuje žádnou komponenetu, pouze závislostní informace. Možností jeho využití je celá řada, přičemž nejběžnější je seskupování balíčků, které na sobě přímo nezávisí, ale tvoří určitý celek (například distribuci grafického prostředí se základní sadou softwaru pro desktop). Instalací takového balíčku pak díky závislostem nainstaluji snadno daný celek, aniž bych musel vybírat desítky programů zvlášť, neboť ty na sobě přímo nezávisí. Z uživatelského hlediska je nejpodstatnější, že nevadí, když jej odinstalujete.

Ukažme si to celé na příkladu. V distribuci Ubuntu je virtuální balíček ubuntu-desktop, který sám neobsahuje žádnou funkcionalitu, ale závisí na všech komponenetách, které tvoří základ distribuce Ubuntu (systémové komponenety, prostředí Gnome a řada uživatelských aplikací). Pokud se rozhodnu, kupříkladu, odstranit program Evolution, na kterém mj. onen virtuální balíček závisí, zahlásí mi správce balíčků, že hodlá odstranit i onen virtuální balíček, ubuntu-desktop. Jelikož tento balíček neposkytuje žádnou funkcionalitu, nemusím se obávat a nechám jej odstranit.

Jiným příkladem jsou běžnější virtuální balíčky, třeba balíček kde. Ten závisí na všech oficiálních součástech prostředí KDE, i takových, které nejsou k jeho běhu nutné. Pokud chci tedy nainstalovat standardní distribuci prostředí KDE, stačí mi nainstalovat tento virtuální balíček (správce balíčků mi pak nabídne všechny jeho závislosti, které právě tvoří standardní distribuci prostředí KDE). A opět, pokud některou komponenetu nezávislou pro běh samotného KDE budu chtít odinstalovat, nabídne mi správce balíčků jeho odstranění. Tady to na první pohled vypadá hrozně (chce odinstalovat kde), ale vzhledem k tomu, že je to pouze virtuální balíček, nehrozí žádné riziko, takže to mohu bez obav povolit. Naopak, pokud by mi nabídl odstranění mnoha balíčků začínající na "kde" včetně "kdebase-bin", pak je mi jasné, že se jedná o klíčovou komponenetu KDE a nic odinstalovávat nebudu.

Jediné, co zbývá na uživateli, je vybírat, které programy chce mít nainstalované a které ne, popřípadě, ze kterých repositářů se má tahat software. Vše ostatní zařídí správce balíčků sám, včetně vyřešení závislostí a stažení ze sítě.

Správce balíčků lze ovládat pomocí příkazové řádky nebo přes adekvátní grafické nástavby. My si ukážeme na příkladu práci s obojím. Pozor, distribuce využívají různé správce balíčků, a proto nelze zaručit, že bude vše úplně stejné ve vámi zvolené distribuci. Tyto rozdíly by však mělo odstranit prostudování distribuční dokumentace.

Ukažme si na příkladech, jak vypadá práce se správcem balíčků, třeba na správci Apt, který je typický pro distribuce založené na Debianu (Ubuntu, Linspire, Xandros,apod.). Práce s ním je poměrně jednoduchá. Zkusíme pomocí něj nainstalovat program Filelight. Nejprve aktualizujeme databázi:

apt-get update

Nyní nainstalujeme program Filelight:

apt-get install filelight

A nyní ho zkusíme odinstalovat:

apt-get remove filelight

Aktualizace veškerého softwaru se provede příkazem:

apt-get upgrade

Někdy se člověku může hodit mít možnost požadovaný balíček vyhledat. Zkusíme si vyhledat nějaký program na ripování DVD:

apt-cache search dvd rip

Řekněme, že jedna z možností, balíček dvdrip, se nám zamlouvá. Mohli bychom si vyžádat popisek balíčku:

apt-cache show dvdrip

Více informací ke správci balíčků Apt naleznete v příslušné dokumentaci.

Grafické nástavby správců balíčků v distribucích se chovají velmi podobně. Někde bývají rozděleny do více modulů (jeden pro instalaci, druhý pro odinstalaci, třetí pro aktualizaci), jinde je všechno pohromadě. V našem příkladu, programu Synaptic, je všechno pohromadě. Je možné současně označit balíčky pro instalaci, aktualizaci i odinstalaci, a nechat správce balíčků, ať všechno udělá najednou. K dispozici jsou i některé pokročilé funkce jako upřednostnění specifické verze balíčku (pomocí této funkce je možný downgrade balíčku). Samozřejmostí jsou integrované vyhledávací funkce a filtry.

Po označení všech požadovaných balíčků stačí použít tlačítko "realizovat", a veškeré změny se začnou provádět. Aktualizovat databázi repositářů je možné pomocí tlačítka "aktualizovat". Tlačítko "aktualizovat vše" automaticky vybírá všechny kandidáty pro aktualizaci, aby se s tím člověk nemusel namáhat ručně (ekvivalent příkazu apt-get upgrade).

Tento postup důrazně nedoporučuji, pokud máte možnost použít správce balíčků a příslušné repositáře. V případě, že nutně potřebujete nějaký software, který v repositářích není, máte dvě možnosti, jak jej do systému přesto nainstalovat, i když tak přijdete o možnost balíček automaticky aktualizovat.

tar xzvf rocksndiamonds-3.1.2.tar.gz

tar xjvf rocksndiamonds-3.1.2.tar.bz2

unzip rocksndiamonds-3.1.2.zip

cd rocksndiamonds-3.1.2

./configure

make

su -c checkinstall

sudo checkinstall

rpm -ivh rocksndiamonds-3.1.2-i386.rpm

dpkg -i rocksndiamonds-3.1.2-i386.deb

sudo dpkg -i rocksndiamonds-3.1.2-i386.deb

Jak jste si všimli, správa softwaru s použitím správce balíčků je velmi jednoduchá. Navíc, oficiální repositáře obsahují balíčky prověřené, otestované a digitálně podepsané. Jejich funkčnost a bezpečnost by tedy měla být zaručena. Občas se sice stane, že některý málo použivaný balíček nefunguje (nebyl dostatečně otestován), ale tyto případy jsou výjimečné. Naopak správa softwaru bez použití správce balíčků je poměrně složitá, a funkčnost či bezpečnost daných balíčků vám nikdo nezaručí. Výjimku tvoří komerční software, který v repozitářích není (přirozeně), ale lze po zaplacení stáhnout příslušný balíček a nainstalovat jej (příkladem může být Cedega).

Mým doporučením je, abyste v každém případě preferovali správce balíčků. Je to snadné a v rámci každé slušné distribuce byste měli mít softwaru v repozitářích více než dost, abyste nemuseli balíčky instalovat ručně kdo ví odkud. Řada distribucí mívá neoficiální repositáře, kde naleznete hromadu dalšího softwaru, včetně toho, který z nějakých důvodů (např. licenčních) nemohl být umístěn do oficiálních repositářů (multimediální kodeky s patentově chráněnými technologiemi, apod.). Tyto neoficiální repositáře bývá vhodné lokalizovat a přidat do správce balíčků (informace o nich bývají v distribuční dokumentaci, FAQ, wiki, eventuelně na fanouškovských stránkách či v příslušných diskusních fórech).

Pokud vám nějaký program citelně chybí, a není ani v oficiálních a ani v neoficiálních repositářích, ještě je možné jej najít ve specializovaných repositářích. Ty bývají velmi malé, třeba pouze pro daný program, ale v našem případě postačí. Samozřejmě doporučuji obezřetnost a nedoporučuji takový repositář přidávat, pokud na vás působí nevěrohodně.

Budete-li chtít instalovat stažený balíček pomocí nízkoúrovňového nástroje, který neřeší závislosti (jenom na ně upozorňuje), ujistěte se, že je z důvěryhodného zdroje, a hlavně nevypínejte kontrolu závislostí. A pokud budete instalovat program ze zdrojových kódů, používejte checkinstall.

Není-li hardware zprovozněn, nezbývá než se podívat, jak to vlastně s podporou daného hardwaru je. Za tímto účelem pomůže pět zdrojů informací:

Zprovoznění nejběžnějšího hardwaru bude nepochybně již obsaženo v distribuční příručce nebo adekvátních on-line zdrojích. Typicky je to zprovoznění 3D akcelerace. Pokud máte exotičtější zařízení, nezbývá než hledat v jiných zdrojích.

Vyhledávače představují způsob, jak velmi rychle najít požadovanou informaci. Prostě jako vyhledávací výraz napíšete název hardwaru a přidáte klíčové slovo "linux" nebo název distribuce, kterou používáte. S trochou štěstí hned natrefíte na návod, jak zařízení zprovoznit.

Stránky s informacemi o podpoře hardwaru v GNU/Linuxu umí být také cenným zdrojem informací, protože leckdy obsahují i příslušné návody, nebo alespoň nějaké tipy. Odkazy na některé z těchto webů naleznete níže.

Diskusní fóra a e-mailové konference bývá také dobré prohledat, zejména ty, které jsou určeny pro vaši distribuci. Je velmi pravděpodobné, že s daným kouskem hardwaru měl už někdo jiný problém, a vy se tak můžete rychle dostat k návodu nebo příslušným dokazům.

Pokud má vaše distribuce rozsáhlejší portál, je dobré se na něj podívat a zjistit, neobsahuje-li informace vztažené k hardwaru, nebo alespoň diskusní fóra či e-mailové konference věnované dané distribuci.

Pak už zbývá jenom prokousat se nalezenými informacemi a zkusit patřičné postupy aplikovat. Většinou se jedná o kompilaci modulu pro jádro, který si stáhnete od někud z Internetu. Kompilace modulu už v dešní době není takový problém, stačí patřičné vývojové nástroje, vývojové balíčky pro jádro (kernel-headers, kernel-source, apod.), a pak postupovat podle přiloženého návodu.

V případě, že byste si rádi pořídili hardware tak, abyste měli jistotu, že bude v GNU/Linuxu podporován, máte několik možností. Můžete si najít prodejce, který vám s výběrem hardwaru pro GNU/Linux pomůže. Ne každý má ale takové štěstí, a proto nám nakonec nezbyde než si informace vyhledat sami. Google a další vyhledávače jsou opět nedocenitelným pomocníkem. Existují ale také weby zabývající se mapováním podpory hardwaru v GNU/Linuxu. A tam bývá dobré nakouknout nejdříve.

Českým uživatelům se bude určitě hodit odkaz na web ABC Linuxu^[15], kde naleznete uživatelskou databázi kompatibility hardwaru. Důležité je, že často obsahuje i návody ke zprovoznění daného kousku. A pokud vaše hledání neuspěje, hned po ruce máte diskusní fórum, kde můžete hledat dále.

Logy jsou záznamy o proběhlých událostech. Jsou uložené v adresáři /var/log. Složení tohoto adresáře bývá distribučně specifické, nicméně při pohledu na názvy souborů vám rychle dojde, k čemu každý slouží. Hlavní log je zpravidla uložen v souboru messages, doplňující, detailnější log pak v souboru syslog (v některých distribucích není). To je také první místo, kam byste se měli podívat.

Jednotlivé služby mají svoje vlastní logy, takže třeba X-server má svůj vlastní log Xorg. Pokud nefunguje grafické prostředí, je tohle místo, kam byste se měli podívat.

Jelikož probíhající události logy zaplňují, provádí se jejich rotace (aby se časem nezaplnil disk). Po určité době (nebo při překročení určité velikosti) se log zpravidla zkomprimuje a uloží do stejného adresáře do souboru se stejným názvem zakončeným číslem (tj. třeba messages.1). Takhle se postupuje dále do určitého čísla, a pak následuje výmaz.

Jak číst logy? Logy jsou obyčejné textové soubory (lze je tedy otevřít jakýmkoliv textovým prohlížečem nebo editorem), ve kterých je na každé řádce zaznamenána jedna událost. Na začátku řádku je časový údaj značící, kdy událost proběhla. V příkazové řádce můžete snadno použít filtrační systémy, které vám umožní zobrazit přesně ty informace, které potřebujete (grep, sort, head, tail, apod.). Existují ale i prohlížeče logů v grafickém prostředí, v rámci prostředí KDE je to ksystemlog, pro Gnome existuje gnome-system-log.

Z logů tedy vyčtete, co se stalo a kdy se to stalo. Tyto informace můžete poměrně snadno využít k lokalizaci a průzkumu eventuálního problému. Kupříkladu, díky logům jsem mohl snadno odhalit, že za přerušením spojení nestojí vada mého modemu, ale poskytovatel připojení, který mne po 24 hodinách prostě odstřihnul.

Snadný přístup k nedávným událostem zaznamenaným linuxovým jádrem umožňuje program dmesg, po jehož zadání se jednotlivé události vypíší.

Tvorbu logů zajišťuje zpravidla démon syslog, který má konfigurační soubor v /etc/syslog.conf. Jeho úpravou lze velmi precizně řídit, které informace se budou zapisovat do kterého logu. Výchozí nastavení ale většinou bývá zcela postačující.

Grafické prostředí nabízí mj. program hardinfo, který vám přehledně zpracuje informace o zjištěném hardwaru. To ovšem umí i ovládací centra distribucí Mandrake či SUSE. Je dobré vědět, že existuje program lspci (existují i další, třeba lsusb) z balíku pciutils, který sice pracuje v příkazové řádce, ale který vám vytáhne informace o zjištěném hardwaru v podobě, která je ideální k operaci kopíruj a vlož. Můžete samozřejmě také přímo použít rozhraní jádra v /proc, konkrétně v následujících souborech:

Expertům přijdou vhod ještě následující soubory:

Tyto nástroje slouží ke sledování určitých hodnot, událostí a procesů při běhu systému. V grafickém prostředí oceníte zejména následující nástroje:

Pro příkazovou řádku existuje celá řada nejrůznějších utilit sloužících ke sledování stavu systému:

Informace vstažené k síťování:

netstat -tupan

Může se stát, že vám nefunguje nějaký program. Pak se hodí několik šikovných nástrojů. Podotýkám, že tohle je už záležitost pro minimálně začínající programátory a velmi pokročilé uživatele.

Základním nástrojem pro analýzu běhu programu je řádkový strace, který spustíte s parametrem v podobě programu, který chcete analyzovat. Strace vám pak začne poskytovat informace o systémových voláních a signálech analyzovaného programu. Analýzou průběhu operací můžete zjistit, na čem přesně program krachne.

Pokud máte problém s během programu, může tak být v extrémních případech (nepoužívali jste správce balíčků k instalaci softwaru) kvůli chybějící závislosti. Závislosti programů (alespoň na knihovnách) získáme pomocí příkazu ldd, jehož parametrem je spouštěcí soubor daného programu. Ten můžete najít třeba pomocí programu locate nebo find.

Zabezpečení integrity dat je mj. důvodem zamykání mechanik. Pokud však si však nějaké zařízení zarezervuje nějaký neposlušný program a vy netušíte, který by to mohl být, použijte příkaz lsof na daném zařízení, třeba takto:

lsof /dev/hda

Můžete k tomu potřebovat práva uživatele root. Příkaz vypíše název a PID programů, které dané zařízení používají. Ty pak můžete využít jako parametry programu kill (viz Správa procesů níže).

Tyto programy již známe ze sekce Info o systému. V grafickém prostředí jsou to ksysguard, gnome-system-monitor či qps. Pro příkazovou řádku to jsou programy top či htop, ps a kill.

Pokud proces běží správně, nemá uživatel většinou důvod do jeho běhu nějak zasahovat. Ale někdy se proces zblázní a začne působit problémy, ať už vytížením procesoru, zabráním velkého množství paměti či pouhým zamrznutím. V takovém případě se hodí vědět, jak ho zabít, tedy násilně ukončit. V grafickém prostředí k tomu slouží program xkill, který je v prostředí KDE implicitně namapován na klávesovou zkratku Ctrl+Alt+Esc. Lze k tomu samozřejmě použít i výše zmíněné programy. V příkazové řádce lze použít program kill, který de facto slouží k zasílání signálů procesům.

Signál program zachytí a zachová se podle něj. Nejdůležitější jsou signály SIGTERM a SIGKILL. První požadá program o ukončení, druhý ho bez milosti sestřelí. To je důvod, proč doporučuji programu nejprve zaslat signál SIGTERM, a teprve pak SIGKILL. V případě, že program zareaguje na SIGTERM, může se pokusit ještě nouzově ukončit a uložit rozpracovaná data. Použití programu kill je samozřejmě popsáno v jeho manuálové stránce, ovšem přesto si dovolím malou ukázku v kombinaci s programem ps. Řekněme, že nám zamrznul program gmpc, a my se jej pokoušíme ukončit. Nejprve bychom měli zjistit jeho PID:

ps aux | grep "gmpc"

Co jsme udělali? Spustili program ps s parametry aux, které nám vypíšou všechny relevantní informace o všech procesech. My ale nechceme informace o všech procesech, a proto jsme výstup programu ps přesměrovali na vstup filtrovacího programu grep, který "propustí" pouze řádky obsahující gmpc. Výsledkem je výpis podobný tomuto:

michal 18406 0.0 1.5  83992 16216 ? S 00:59 0:05 gmpc

Hned první číslo zleva je námi hledané PID, které použijeme jako parametr programu kill. Pokud nezadáme číslo signálu, je zvolen SIGTERM.

kill 18406

Program se však stále neukončil, a proto mu posíláme devátý signál, tedy SIGKILL:

kill -9 18406

Zkusím uvést ještě jeden užitečný program, a tím je killall, který umožňuje poslat signál procesu nebo procesům podle jejich jména a nikoliv podle PID. Pomocí něj by stačilo zapsat:

killall gmpc

Ale pozor, tento program pošle signál všem procesům, které se jmenují tak, jak to specifikujete. Můžete takto nechtěně zabít i program, který nechcete. To je důvod, proč jej uvádím na konec. Onen první způsob je sice zdlouhavý, ale poměrně jistý.

O signálech jako takových se dozvíte více v odkazech a samozřejmě v adekvátní manuálové stránce:

man signal

V unixových systémech je třeba velmi precizně řídit priority jednotlivých procesů. K tomu se používá číselná hodnota, která ovlivňuje, jak moc mu jádro dává přednost před ostatními procesy. V jistých systémech se toto číslo nazývá "priorita" a platí, že čím vyšší číslo, tím vyšší priorita. V unixových systémech je to ale přesně naopak. Toto číslo udává slušnost (niceness), tedy čím vyšší číslo, tím méně jej jádro upřednostňuje před ostatními. V GNU/Linuxu je slušnost udávána v celých číslech v rozmezí -20 až 19, přičemž záporná čísla jsou vyhrazena pouze pro nastavení uživatelem root. Je jasné, že běžně smíte měnit slušnost pouze těch procesů, které vám patří. Jste-li root, můžete vše.

Slušnost procesu můžeme změnit v grafickém prostředí pomocí výše zmíněných nástrojů, nebo můžeme použít příkazovou řádku a programy nice a renice. Program nice spouští program s danou prioritou, program renice mění prioritu běžícího procesu. Použití si demonstrujeme na příkladě:

nice -n 19 slušňák

Výše zmíněný příkaz spuští program slušňák s maximální slušností. Při běhu procesu ale zjistíme, že by bylo dobré jeho slušnost snížit na 5. Použijeme tedy příkaz renice, ovšem nejprve musíme zjistit PID daného procesu (viz výše). Dejme tomu, že slušňák běží pod PID 7432:

renice 5 7432

Interaktivní manažery procesů, ať již pro příkazovou řádku (např. htop) či pro grafické prostředí (ksysguard, qtop, atd.), umožňují provádět změny "slušnosti" procesů velmi pohodlně.

V GNU/Linuxu existuje mechanismus na omezování procesů a uživatelů. Je možné omezit v rámci procesu množství paměti a vytížení procesoru, v rámci uživatele množství spuštěných procesů, počet přihlášení a řadu dalších záležitostí. Vše se nastavuje v /etc/security/limits.conf nebo příkazem ulimit. Vypsáním následujícího příkazu můžete zjistit, jak jste omezeni:

ulimit -a

Více informací se dozvíte v manuálových stránkách interpretu Bash:

man bash

Většina serverů má nějaké počáteční nastavení, které umožní jejich běh, aniž bychom je museli nastavovat. Přívětivé distribuce mohou mít nastavovací klikátka pro některé ze serverů, ale většinou budeme servery konfigurovat klasickým způsobem, přes konfigurační soubory v /etc podle dostupné dokumentace, kterou nalezneme mj. v /usr/share/doc, v distribuční dokumentaci, na stránkách projektů, apod.

Následuje popis některých serverů, o kterých by měl každý uživatel GNU/Linuxu vědět.

Je nad slunce jasné, že kterákoliv služba přístupná z Internetu je potenciálně riziková. I proto je důležité si pořádně projít dokumentaci a nastavit server správně. Stejně tak je důležité pravidelně aktualizovat. Pokud nechcete, aby byly služby přístupné z Internetu, nastavte adekvátně příslušné služby (zakažte jim "poslouchat" na síti) nebo firewall.

Jelikož se jedná o prokročilé téma, už si nevystačíme s grafickým prostředím, ale budeme muset pracovat s příkazovou řádkou. Swap můžete za běhu systému odstavit, přidat další či měnit jeho prioritu. Swap se vytvoří na blokovém zařízení (třeba /dev/hda3) takto:

mkswap /dev/hda3

Zařadí se do používání takto:

swapon /dev/hda3

A vyřadí se takto:

swapoff /dev/hda3

Je samozřejmě možné vytvořit swap v souboru. Pochopitelně to má smysl pouze, pokud víte, co děláte. Jste-li začátečníci, tak se této kapitolce obloukem vyhněte.

K vytvoření swapu ze souboru lze použít modul loop, který umí ze souboru udělat blokové zařízení. Nejprve vytvoříme vhodný soubor:

dd if=/dev/zero of=soubor_swap bs=1M count=512

Tento příkaz slouží ke kopírování dat z jednoho souboru do druhého. Jako vstupní soubor (parametr if) použijeme generátor nul /dev/zero, jako výstupní soubor (parametr of) použijeme náš budoucí soubor se swapem. Nastavíme velikost bloku pro čtení a zápis na 1MB a určíme, že se překopíruje 512 bloků, tedy 512 MB. Nyní zavedeme příslušný modul:

modprobe loop

Použijeme program losetup k propojení blokového zařízení /dev/loop0 s naším souborem:

losetup /dev/loop0 soubor_swap

Následně vytvoříme swap na daném blokovém zařízení:

mkswap /dev/loop0

A zařadíme jej do používání:

swapon /dev/loop0

Vyřadit jej z používání můžeme pomocí:

swapoff /dev/loop0

Zrušit "spojení" mezi blokovým zařízením /dev/loop0 a naším souborem můžeme příkazem:

losetup -d /dev/loop0

Jak se ale systém zachová, když paměť opravdu dojde, a nebude místo ani v RAM, ale ani ve swapu? Linuxové jádro používá techniku zvanou "memory overcommiting", která programům dovolí říci si o více paměti než je k dispozici. Je to dáno tím, že si programy mnohdy říkají o více paměti, než pak skutečně využijí. Jenomže, co se stane, když paměť dojde? Pak nastupuje nefalšovaný zabiják, oom-killer, rutina, která se pokusí odhadnout, který program je nejméně důležitý, a ten sestřelí.

Ono je ale velice těžké přesně odhadnout, který program je vhodné sestřelit a který ne. Takže se často stává, že zabiják sestřelí proces, který potřebujeme zachovat, zatímco ten, který situaci způsobil, zůstane nedotčen. Toto chování můžeme ovlivnit. Kromě možnosti přeprogramovat danou rutinu je možné použít rozhraní jádra v souboru /proc/sys/vm/overcommit_memory (povolení memory overcommiting, hodnota 1 povolí, hodnota 0 zakáže). Overcommit memory tedy zakážeme pomocí:

echo "0" > /proc/sys/vm/overcommit_memory

Nebo elegantněji:

sysctl -w vm.overcommit_memory=0

Permanentní nastavení můžeme provést v souboru /etc/sysctl.conf, kam zapíšeme následující rádku:

vm.overcommit_memory=0

Ještě než začneme pracovat s nějakým konfiguračním souborem, měli bychom se podívat na jeho dokumentaci. Ta se může ukrývat buď v manuálových stránkách, nebo může být k dispozici přímo v daném konfiguračním souboru ve formě komentářů. Komentář je uvozen křížkem (#) a to, co za ním následuje, nebere program při procházení konfiguračním souborem v potaz. Komentářů můžeme využít i při editaci konfiguračního souboru a k dokumentaci změn.

Před úpravou konfiguračního souboru je dobré si vytvořit jeho zálohu, pro každý případ. Práci s komentáři si ilustrujeme na následujících dvou příkladech. Máme následující řádku v souboru /etc/fstab:

/dev/sda2 /media/sda2 ext3 defaults 0 2

My ale nechceme, aby se /dev/sda2 mountovalo při startu počítače. Ovšem nejsme si až tak jisti, že to někdy nebudeme znovu potřebovat, a proto řádku nesmažeme, pouze zakomentujeme:

#/dev/sda2 /media/sda2 ext3 defaults 0 2

Uvažme situaci, že chceme pouze změnit parametry připojení souborového systému, ale nevíme jistě, co to udělá. Proto si původní řádku zálohujeme a na nové budeme experimentovat:

#/dev/sda2 /media/sda2 ext3 defaults 0 2
/dev/sda2 /media/sda2 ext3 ro 0 0

Nezřídka se nám může hodit opatřit jistou změnu komentářem, třeba abychom ji opět našli, a po čase opět pochopili, proč jsme to vlastně tenkrát dělali:

#2006-08-22 (Michal): Pryc s tim, na /dev/sda2 je ted Gentoo
#/dev/sda2 /media/sda2 ext3 defaults 0 2

Dosud jsme probírali konfiguraci systému jako takového, ale kam se ukládají nastavení programů, které spustíte? Ta se ukládají do vašeho domovského adresáře, zpravidla jako skryté soubory (v unixových systémech jsou skryté soubory ty, které obsahují tečku na začátku svého jména). I tady platí, že se převážně jedná o textové soubory, které lze upravovat, zálohovat či přenášet na jiné unixové systémy.

V extrémně nepravděpodobném případě se může stát, že si nějaký špatně napsaný program uloží konfiguraci, která způsobí, že spadne při příštím spuštění. V takovém případě postačí najít příslušný konfigurační soubor a buď jej odstranit, nebo někam přesunout, program si ho vytvoří automaticky při dalším spuštění.

Prvních 512 bytů na pevném disku tvoří MBR, kde se nachází zavaděč operačního systému (446 bytů), následuje tabulka rozdělení disku (partition table), kde jsou po 16 bytech uloženy informace o každém ze čtyřech primárních oddílů. MBR je zakončeno 2 byty tvořící tzv. magic number.

Pevný disk je rozdělen na jednotlivé oddíly (partitions). Omezení v podobě 4 primárních oddílů se obchází tak, že se jeden z primárních oddílů nastaví jako rozšířený, a v jeho útrobách pak mohou vznikat další, rozšířené oddíly. Podstatné je, že v každém oddílu může být jiný souborový systém.

Mezi důsledky této šedé teorie patří několik důležitých praktických poznatků:

Filesystém, alias souborový systém, je metoda ukládání dat na pevný disk tak, abychom byli schopni tato data opět přečíst zpět. Zdá se to možná banální, ale je to extrémně důležité. Díky souborovým systémům můžeme ukládat svoje data do souborů v adresářové struktuře, a hlavně, opět je přečíst. Ovšem souborové systémy jsou v dnešní době přeci jen složitější. Důraz je kladen i na bezpečnost uložení dat, rychlost přístupu k datům a na řadu dalších faktorů.

Jednou z podstatných vlastností moderních souborových systémů je systém pro zajištění konzistence dat v případě výpadku. Žurnál je, zjednodušeně, oblast, kam se zapisují informace o právě prováděných transakcích (zápis dat do souboru, apod.). V případě výpadku se ze žurnálu zjistí, které operace proběhly a které nikoliv. Tak lze velmi snadno dostat souborový systém opět do konzistentního stavu, a to bez nutnosti provádění složitých a zdlouhavých prověřování.

Mezi žurnálovací souborové systémy patří v GNU/Linuxu ext3, reiserfs, jfs, xfs. Naopak ext2 žurnálovací není, a proto jej doporučuji nepoužívat. Říkám to zejména proto, že ve starších dokumentacích bývá ext2 často zmiňován. Dnes už však není důvod nepoužít ext3. Zejména pak proto, že ext2 a ext3 jsou mezi sebou kompatibilní a jeden lze přeměnit na druhý a zpět (zprovozněním nebo zrušením žurnálu pomocí tune2fs).

V unixových systémech jsou filesystémy připojovány do jednotné adresářové struktury. Na disku můžeme mít tedy teoreticky řadu oddílů, přičemž na každém bude jiný souborový systém. Ale z hlediska uživatele budou Linuxové souborové systémy jsou založeny na unixových souborových systémech.

Pokud chceme připojit nějaký souborový systém do adresářového stromu, použijeme k tomu příkaz mount nebo adekvátní grafické nástavby (viz dokumentace k distribuci). Toto budeme pochopitelně realizovat pouze v situaci, kdy nedojde k automatickému připojení, jak bývá obvyklé pro řadu přívětivých distribucí. Příkaz mount má celkem jednoduchou syntaxi:

mount -t filesystem /dev/zarizeni /mnt/adresar

Zpravidla můžeme volbu -t (specifikace typu souborového systému) s parametrem určujícím souborový systém vypustit, mount se pokusí typ souborového systému určit sám. Stačí tedy použít zkrácenou syntax:

mount /dev/zarizeni /mnt/adresar

Tento příkaz připojí blokové zařízení /dev/zarizeni na adresář /mnt/adresar. Z praktického hlediska, pokud budu chtít připojit souborový systém (ext3) na třetím (primárním) oddíle primárního IDE pevného disku na sekundárním IDE řadiči do adresáře /home/repository, použiji příkaz:

mount -t ext3 /dev/hdc3 /home/repository

Můžeme také použít zkrácenou verzi s autodetekcí souborového systému:

mount /dev/hdc3 /home/repository

Někdy se můžou hodit i určité volby, které jsou k dispozici pod parametrem -o, třeba následující příkaz připojí stejný souborový systém pouze pro čtení:

mount -t ext3 -o ro /dev/hdc3 /home/repository

Další možnosti viz manuálová stránka k příkazu mount.

man mount

Souborový systém můžeme odpojit pomocí příkazu umount, takto:

umount /dev/hdc3

Pokud na souborovém systému, který chceme odpojit, provádí nějaký program nějakou činnost, nepůjde odpojit. Nejjednodušším řešením takové situace je daný program ukončit nebo v něm přejít do jiného adresáře. Pokud nevíme, který program zrovna na souborový systém přistupuje, použijeme příkaz lsof, který nám to zjistí:

lsof /dev/hdc3

Nebo můžeme riskovat a nechat systém násilně ukončit všechny programy pracující s daným zařízením (užívejte velmi opatrně):

kill -9 $(lsof -t /dev/zarizeni)

Souborový systém lze odpojit i násilím, ale to je dobré provádět pouze, pokud jsou všechny osatatní možnosti vyčerpány:

umount -f /dev/hdc3

Ještě lze použít parametr -l, který souborový systém okamžitě vyřadí z hierarchie, ale reference na něj odstraní později:

umount -l /dev/hdc3

Chceme-li připojovat nějaký souborový systém při každém startu, upravíme konfigurační soubor /etc/fstab. Jeho syntax je v podstatě velice jednoduchá, na každém řádku je záznam pro jeden souborový systém s následujícími parametry:

Typická řádka by tedy mohla vypadat nějak takto:

/dev/sda1 /media/card1 vfat ro,user,noauto 0 0

Výše zmíněná řádka by zajistila připojení zařízení /dev/sda1 obsahující souborový systém typu vfat na přípojný bod /media/card1 s volbami ro (připojení pouze pro čtení), user (povolí uživatelům připojovat souborový systém) a noauto (nepřipojí souborový systém hned po spuštění počítače. Prvního čísla bych si nevšímal a dal bych na jeho místo nulu (pokud nepoužíváte k zálohování program dump). Druhé číslo označuje pořadí při provádění kontroly souborového systému pomocí programu fsck. Nula značí vyjmutí z kontroly při startu počítače, jedničku by měl mít pouze kořenový souborový systém, pro ostatní je dvojka nebo nula.

V zásadě, dostat smazaná data z linuxových oddílů je velmi těžké, až zhola nemožné. Existuje sice několik neoficiálních nástrojů, ale těmi lze napáchat více škody než užitku (je důrazně doporučena záloha oddílu před jejich použitím). Proto nemohu než doporučit důležitá data zálohovat a při mazání si dávat opravdu pozor.

Pokud si smažete omylem opravdu extrémně cenná data, jejichž zálohu nemáte k dispozici, můžete se pokusit data obnovit sami (viz dále) nebo obrátit na specializované společnosti zabývající se záchranou dat.

Pokud je poškozená tabulka rozdělní disku, nebo se nám podařilo ji upravit a následně zjistit, že jsme zapomněli zálohovat důležitá data, není ještě všechno ztraceno. Můžeme použít programy jako gpart^[16] nebo testdisk^[17], které jsou schopné poškozenou tabulku rozdělení disku rekonstruovat.

Je-li možné souborový systém, který chceme prověřovat, odpojit, učiníme tak. Pokud to možné není, musíme jej přepojit do režimu pouze pro čtení. Chceme-li to provést se souborovým systémem, který je používán, nezbyde než ukončit všechny procesy využívající daný souborový systém. Pokud chceme za běhu zkontrolovat kořenový oddíl, musíme přejít do jednouživatelského režimu pomocí příkazu init 1, následně souborový systém přemountujeme jenom pro čtení. Za předpokladu, že tím naším filesystémem je /dev/hda1, zapsali bychom:

mount -o remount,ro /dev/hda1

A teprve teď bychom se mohli pustit do kontroly souborového systému.

fsck /dev/hda1

Je-li souborový systém vážně poškozen, pak jej raději před pokusy o nápravu zálohujeme, třeba pomocí programu dd:

dd if=/dev/hda1 of=/mnt/sitovy_disk/zaloha_hda1

Je-li poškozeno samotné zařízení, na kterém se souborový systém nachází, pak přidáme parametr noerror a specifikujeme rozumnou velikost bloku (v tomto případě 512 bytů):

dd if=/dev/hda1 of=/mnt/sitovy_disk/zaloha_hda1 noerror bs=512

Máme-li připravený obraz poškozeného oddílu, můžeme na jeho kopii provádět záchranné operace. Můžeme se pokusit souborový systém opravit:

losetup /dev/loop0 /mnt/sitovy_disk/zaloha_hda1_kopie

Tento příkaz asociuje zařízení /dev/loop0 s kopií našeho poškozeného souborového systému. To způsobí, že k němu budeme moci přistupovat jako k normálnímu blokovému zařízení. Toho využijeme a ihned na něm spustíme fsck:

fsck /dev/loop0

Fsck se pokusí opravit daný souborový systém. Když skončí, můžeme se pokusit opravený souborový systém připojit, tentokrát specifikujeme i souborový systém:

mount -t ext3 /dev/loop0 /mnt/zachrana

Pokud se nám oprava nepovede, jelikož je poškození souborového systému příliš veliké, zkusíme třeba program Foremost^[18], který projde náš obraz a extrahuje z něj známé typy souborů. Můžeme samozřejmě zvolit i další software. V nejzazší nouzi se ještě můžeme obrátit na specializované společnosti zabývající se záchranou dat.

Existují dva typy kernelů, kernel vanilla, tedy čistý, neopatchovaný, oficiální kernel, který můžete stáhnout z kernel.org, a distribuční kernel, tedy ten, který za vás již sestavil správce vaší distribuce. Distribuční jádra bývají různě patchované a bývají nastavené tak, že se spustí takřka na jakémkoliv hardwaru. Používají k tomu právě LKM a možnost zavést moduly podle toho, jaký hardware je v počítači nalezen. To značně zvyšuje robustnost systému, který je pak možné přenášet mezi počítači s minimálními změnami.

Měl bych dodat, že k hlídání změn v hardwaru při běhu systému (např. připojení USB zařízení) se používá speciální démon - hotplug (momentálně již ve většině distribucí nahrazen systémem udev). Ten hlídá, co se změní a adekvátně se přizpůsobí (zavede patřičné moduly).

Poněkud podrobnější pohled do linuxového kernelu nabízí dokument Kernel Hacking HOWTO^[19] (doporučuji spíše programátorům).

Předně je třeba říci, že kompilaci kernelu většinou nebudete potřebovat provádět. Doby, kdy to bylo nutné, jsou již dávno pryč. Dnes máte v linuxových distribucích k dispozici modulární, předem nastavená a vyladěná jádra, která jsou navíc v případě objevení nějakého problému patchována a vy si prostřednictvím balíčkovacího systému můžete stáhnout aktualizaci.

Kompilace kernelu je vhodná, pokud toužíte po optimalizaci jádra přímo pro váš počítač (ať již optimalizace pro použitý procesor, nebo pro použitý hardware - zvolení jenom těch modulů, a vlastností, které chcete), popřípadě v oněch velmi vzácných případech, kdy distribuční jádra nemají něco, co vy nutně potřebujete.

Pro kompilaci kernelu potřebujete kompilátor (gcc), eventuelně některé další nástroje (něco pro snadné vytváření initrd, třeba initrd-tools). Další ingrediencí jsou zdrojové soubory jádra. Distribuční jádro má zdroj v balíčku kernel-source (může se ale jmenovat i jinak), vanilla jádro si můžete stáhnout z www.kernel.org.

Postup kompilace je následující:

Více informací naleznete v odkazech v závěru kapitoly. Nejnáročnější procedurou je vlastní konfigurace jádra, tedy výběr toho, co bude do kernelu zakompilováno a co ne. Je třeba si dávat pozor, abyste do jádra zahrnuli podporu všeho důležitého (grafika, myš, klávesnice, apod.). Pokud nepoužíváte iniciální ramdisk (viz níže), pak musíte zajistit, aby ovladače řadiče a souborových systémů byly v jádře zakompilovány na pevno (ne jako moduly).

Pokud se vám to napoprvé nepodaří, nezoufejte a zkuste konfiguraci poopravit (nepoužívejte v takovém případě příkaz make mrproper, jelikož ten vám vymaže uloženou konfiguraci). Ke zjištění toho, co všechno musíte do jádra zahrnout, vám mohou sloužit příkazy jako lsmod, který vypíše zavedené jaderné moduly, popřípadě lspci či dmesg. Hodí se také dostupné informace v /proc.

Může se stát, že budete potřebovat ručně zkompilovat nějaký jaderný modul pro vaše jádro, třeba s proprietárním ovladačem k některému kousku hardware, který díky licenci nemůže být součástí jádra. Samozřejmě předpokládám, že máte k dispozici nějaký podrobný návod, který vám řekne, co a jak nastavit.

Kromě standardní kompilační sady (kompilátor gcc) budete potřebovat i hlavičkové soubory jádra. Pokud používáte distribuční jádro, pak je zpravidla najdete v balíčku, jehož název bude vypadat podobně jako kernel-headers-x.y.z.a (kde x.y.z.a je verze jádra). Pokud jste si zkompilovali vlastní jádro, pak je máte k dispozici v adresáři se zkompilovaným jádrem (zpravidla někde v /usr/src, ale to byste měli vědět, když jste si ho zkompilovali sami).

Jeden problém, který se zde může vyskytnout, je situace, kdy budete jaderný modul kompilovat pomocí jiné verze kompilátoru než samotné jádro. V takovém případě nemusí jaderný modul fungovat. Pokud fungovat nebude, a nepodaří se vám jej zavést ani pomocí insmod -f soubor_s_modulem, zřejmě vám nezbyde než zkompilovat vlastní jádro. Distributoři na toto však zpravidla pamatují a většinou to lze vyřešit aktualizací balíčku s jádrem.

Jak jsme si říkali, moduly jsou umístěny v adresáři /lib/modules. Pokud máte jako modul zakompilovanou podporu souborového systému (nebo zařízení), na kterém se tento adresář nachází, pak za normálních okolností kernel nenabootuje a zpanikaří. Neumí totiž řešit situaci “Co bylo dříve, slepice nebo vejce?”. K tomu, aby se mohl dostat k modulům potřebuje “vidět” záznamové zařízení a “rozumět” souborovému systému, na kterém se moduly nachází, ale pokud jsou ovladače (drivery) onoho souborového systému nebo daného zařízení zakompilovány jako moduly, pak se k nim nedostane a nemá šanci to přeusmívat.

K řešení tohoto problému slouží initrd, což je malý, zkomprimovaný souborový systém, který se zavede za kernel do paměti, ten jen pak rozbalí, připojí na kořenový souborový systém a postupuje podle jeho startovacího skriptu. Tento souborový systém obsahuje mj. i moduly potřebné k zavedení systému. Vytváří se příkazem mkinitrd. U novějších distribucí to je mkinitcpio.