Od uživatele k adminovi — Linux po lopatě

Tahle kapitola je nad rámec zbytku kurzu. Předchozí kapitoly tě učily příkazy — co napsat, aby se něco stalo. Tahle je o něčem jiném: o myšlení. Rozdíl mezi „uživatelem, co umí pár příkazů" a „adminem" totiž není v tom, kolik příkazů zná — je v tom, jak přemýšlí, když se něco pokazí. Admin nehádá. Čte logy, mění jednu věc, ověřuje, zapisuje si, co udělal, a nikdy nezkouší naslepo na produkci. Tohle je návod na tenhle způsob přemýšlení, ne seznam příkazů.

Pár pojmů na úvod

Produkce (prod) = ostrý systém, na kterém závisí reální lidé (běžící web, server, tvůj hlavní notebook). Opak je testovací prostředí — VM nebo kontejner, kde smíš rozbít, co chceš.
Idempotence = vlastnost změny, že když ji pustíš dvakrát, výsledek je stejný jako po jednom spuštění (nic se nerozbije, nic se nezdvojí). Rozvedeno níže — je to jeden z nejdůležitějších pojmů.
Snapshot = „fotka" stavu systému nebo disku v čase, ke které se umíš vrátit (btrfs snapshot, snapshot VM). Pojistka před zásahem.
Rollback = návrat k předchozímu stavu, když se změna nepovede (obnovení ze zálohy, ze snapshotu, z gitu).
Reprodukovatelný problém (repro) = chyba, kterou umíš spolehlivě zopakovat jasným postupem. Bez repra se ladí strašně — nevíš, jestli tvoje „oprava" vůbec něco udělala.
Bus factor = kolik lidí by muselo „potkat autobus", aby projekt umřel, protože něco ví jen oni. Bus factor 1 = celé to drží v hlavě jeden člověk. Nebezpečné (rozvedeno níže).

Čti logy dřív, než začneš hádat

Nejčastější začátečnická chyba není špatný příkaz — je to hádání. Něco nejde, tak zkusím tohle, pak tamto, pak restart, pak přeinstaluju… a když to náhodou zabere, nevíš proč. Příště jsi stejně bezradný.

Admin dělá opak: nejdřív se podívá, co systém říká. Skoro každá služba na Linuxu někam píše, co se jí děje — do žurnálu (journalctl), do /var/log, na výstup příkazu. Chybová hláška není nepřítel, je to nápověda zdarma. Devětkrát z deseti tam přesně stojí, co je špatně — chybí soubor, špatné právo, obsazený port, překlep v configu.

💡 Zlaté pravidlo: přečti chybu celou a nahlas. Ne „něco to hlásí" — co přesně to hlásí? Poslední řádek výpisu bývá důsledek; ta pravá příčina je často o pár řádků výš.

Teprve když víš, co systém říká, máš právo tvořit hypotézu. Pořadí je pozoruj → pochop → zasáhni, ne „zasáhni a uvidíme".

Měň jednu věc a ověř

Když se něco pokazí a ty ve snaze to rychle spravit změníš pět věcí naráz, stane se jedna ze dvou věcí. Buď to pořád nejde — a ty nevíš, kterou z pěti věcí ještě zhoršit. Nebo to začne fungovat — a ty nevíš, která z těch pěti věcí to spravila, takže čtyři zbytečné (možná škodlivé) změny tam necháš.

Admin mění jednu věc, pak ověří, pak teprve další. Je to pomalejší o minutu, ale ušetří ti to hodiny. Vědecká metoda v malém: jedna hypotéza → jedna změna → jeden test → výsledek. Když nezabere, vrať to zpět a zkus jinou hypotézu. Nehromaď nedomyšlené změny na sebe.

🚩 „Pro jistotu jsem změnil ještě tři další věci" je červená vlajka. Jistota se nezískává množstvím změn, ale tím, že každé jednotlivé změně rozumíš.

Dokumentuj — co, a hlavně proč

Za tři měsíce budeš na svůj vlastní systém koukat jako cizí člověk. Ten řádek v configu, co jsi tak pracně vyladil — proč tam je? Co rozbije, když ho smažeš? Bez poznámky nevíš.

Dokumentace pro admina není slohovka. Jsou to tři levné návyky:

Komentář v configu přímo u nestandardního řádku: proč tam je, ne co dělá. (# zvýšeno kvůli velkým uploadům, default 1M nestačil — 2026-07). „Co" si přečteš z kódu; „proč" ne.
Changelog / deník zásahů — prostý textový soubor, kam píšeš datum, co jsi změnil a proč. I jeden řádek stačí. Až něco příště přestane jít, tohle je první místo, kam se podíváš.
Komentář v gitu (viz níže) — když configy verzuješ, samotná historie commitů je dokumentace.

Cíl: aby ses (nebo kdokoli po tobě) uměl vrátit k rozhodnutí a pochopit ho, ne ho jen vidět.

Verzuj konfigurace

Configy jsou text. Text patří do gitu. Jakmile máš /etc (nebo aspoň svoje dotfiles) ve verzování, získáš tři superschopnosti zadarmo:

Vidíš, co se změnilo. git diff ti přesně ukáže, cos v configu sáhl — i to, co změnil systémový update pod rukama.
Umíš se vrátit. Změna rozbila službu? git checkout a jsi zpátky ve fungujícím stavu za sekundu, bez hádání „co jsem to vlastně měnil".
Máš historii a odůvodnění. Každý commit má zprávu — proč ta změna. To je ta dokumentace z minulé sekce, jen automaticky uložená.

Nemusíš hned nasazovat velké nástroje. Úplný začátek je git init v adresáři s dotfiles nebo prostě kopie configu s příponou .bak a datem před tím, než ho sáhneš. Zásada je: nikdy neměň config, u kterého nemáš cestu zpět.

Automatizuj opakované — ale až tomu rozumíš ručně

Když nějakou věc děláš potřetí ručně, je čas ji napsat do skriptu. Skript se nespletě v pořadí kroků, nezapomene na jeden z nich ve tři ráno a je sám o sobě dokumentací postupu. Ruční klikání je zdroj chyb; skript je zopakovatelná pravda.

Ale pozor na pořadí — a tohle je zásadní:

⚠️ Nejdřív to zvládni ručně, pak teprve automatizuj. Kdo automatizuje postup, kterému nerozumí, jen vyrobí stroj na rychlé opakování vlastní chyby. Když se to pak rozbije, nemáš tušení kde — skript je pro tebe černá skříňka.

Automatizace není náhrada za pochopení, je to jeho zabalení. Napřed pochop každý krok ručně (a zjisti, kdy selhává). Teprve když to máš v ruce, sepiš to do skriptu — a ten skript udělej idempotentní.

Idempotence — aby změna šla pustit dvakrát

Idempotentní změna je taková, že když ji pustíš jednou nebo desetkrát, výsledek je stejný. Zn: „dej tam tenhle řádek, pokud tam ještě není" (idempotentní) versus „přidej tenhle řádek" (neidempotentní — po pátém spuštění tam máš pět kopií).

Proč na tom adminovi tolik záleží? Protože skripty a zásahy se pouštějí znovu — spadne to v půlce, zopakuješ; nevíš, jestli to už proběhlo, radši to pustíš ještě jednou; automatizace to spouští pravidelně. Když je operace idempotentní, nemusíš si pamatovat, jestli už proběhla — prostě ji pustíš a je klid.

Špatně: echo "PermitRootLogin no" >> /etc/ssh/sshd_config (každé spuštění přidá další řádek).
Lépe: nejdřív ověř/uprav existující řádek, nebo použij nástroj, který drží cílový stav (Ansible, systémové configy), ne posloupnost slepých přidání.

Mysli v „jak má výsledek vypadat" (cílový stav), ne „jaké kroky provést" (imperativní posloupnost). Cílový stav je přirozeně idempotentní.

Nezkoušej naslepo na produkci

Produkce je systém, na kterém závisí lidé — běžící web, ostrý server, tvůj hlavní pracovní notebook. Zkoušet na ní nevyzkoušené věci je jako trénovat řízení v protisměru na dálnici.

Admin má vždycky bezpečné místo na hraní:

Testovací VM nebo kontejner — rozbij, co chceš, zahoď, postav znovu za minutu. Nejlepší způsob, jak se něco naučit, je to bez rizika rozbít.
Snapshot před zásahem — než sáhneš na ostrý systém (a musíš), udělej snapshot / zálohu, ze které se vrátíš. „Cesta zpět" musí existovat dřív, než uděláš první změnu.
Odděl testování od ostrého provozu. To, že něco „fungovalo u mě", neznamená, že to poběží na produkci — jiná data, jiná zátěž, jiná verze. Otestuj tam, kde selhání nikoho nebolí.

💡 Otázka, kterou si admin klade před každým zásahem na prod: „Když tohle dopadne nejhůř, jak se vrátím do fungujícího stavu?" Když na to neumíš odpovědět, ještě nezasahuj.

Jak hledat, když nevíš

Nikdo neví všechno. Rozdíl mezi začátečníkem a adminem není v tom, že admin zná odpovědi — je v tom, že umí odpovědi rychle najít a rozpoznat dobrou od špatné.

man a --help napřed. Než hledáš na internetu, zeptej se přímo nástroje. man rsync, rsync --help — oficiální dokumentace je přesná a odpovídá tvé verzi.
Přesnou chybovou hlášku do vyhledávače. Ne „linux nefunguje síť", ale zkopíruj doslovný text chyby (bez svých konkrétních cest/jmen). Chybu, kterou vidíš ty, viděly před tebou stovky lidí.
Arch Wiki je poklad i když nejedeš na Archu — koncepty (systemd, síť, práva) jsou napříč distry stejné a Arch Wiki je vysvětluje nejlíp.
Minimal reproducible. Když se ptáš (fórum, kolega, AI), zredukuj problém na nejmenší případ, který ho pořád vyvolá. Často při té redukci příčinu najdeš sám.

⚠️ A teď to nejdůležitější: nekopíruj příkazy z internetu, kterým nerozumíš. Zvlášť ne vzorce typu curl něco | sudo bash — to znamená „stáhni cizí skript a pusť ho rovnou jako root, aniž bys ho viděl". Než něco pustíš s sudo, přečti to a pochop, co to dělá. Náhodný návod na fóru nezná tvůj systém — ty ho znát musíš.

Zálohuj před zásahem — a bus factor

Dvě věci, které oddělují amatéra od profíka, a ani jedna není o příkazech.

Záloha před zásahem je nejlevnější pojistka na světě. Chvilka teď versus hodiny (nebo nenávratná ztráta dat) potom. Než sáhneš na něco důležitého, zkopíruj to. Než upgraduješ, udělej snapshot. Než mažeš, ověř, že máš, odkud to vzít zpět. Záloha, kterou jsi nikdy nezkusil obnovit, není záloha — je to naděje; občas zkus reálně obnovit, jestli funguje.

Bus factor je o lidech. Když všechno důležité o systému víš jen ty a máš to jen v hlavě, jsi jediný bod selhání — pro projekt i pro sebe (co když jsi na dovolené, nemocný, zapomeneš?). Proto se všechno z předchozích sekcí — dokumentace, verzované configy, skripty, changelog — sčítá do jedné věci: znalost má být venku z tvojí hlavy, zapsaná tak, aby po ní mohl sáhnout někdo jiný (nebo ty za rok). Nebuď jediný, kdo ví.

Failure modes — jak se admin pozná od amatéra (podle chyb)

Zásah bez zálohy a bez poznámky. Sáhne na ostrý config, nikde záloha, nikde záznam co změnil. Když to nejde vrátit, je zle — a nikdo (ani on) neví, co se vlastně stalo.
curl … | sudo bash naslepo. Pustí cizí skript jako root, aniž ho viděl. Nejrychlejší cesta, jak si nechat rozbít (nebo kompromitovat) systém cizí rukou.
Ladění rovnou na produkci. Zkouší nevyzkoušené na ostrém systému, na kterém závisí lidé. Když to položí, položil to naostro.
Pět změn naráz. Ve snaze rychle spravit změní všechno možné. Když to zabere, neví proč; když ne, neví, co ještě zhoršit.
Znalost jen v hlavě. Žádná dokumentace, žádný changelog, žádné komentáře. Funguje to „protože to nastavil on" — bus factor 1, časovaná bomba.
Automatizace toho, čemu nerozumí. Zabalí do skriptu postup, který sám plně nechápe. Vyrobí stroj na rychlé a spolehlivé opakování vlastní chyby.

🛠️ Cvičení

Přečti chybu, nehádej. Vzpomeň si (nebo si vyrob) na situaci, kdy ti něco nešlo. Napiš, kde bys hledal, co systém říká (log, journalctl, výstup příkazu) dřív, než začneš cokoli měnit. Proč je pořadí „pozoruj → pochop → zasáhni" lepší než „zkoušej a uvidíš"?
Idempotentní, nebo ne? U každé rozhodni, jestli ji můžeš bez obav pustit dvakrát: (a) mkdir /opt/app, (b) mkdir -p /opt/app, (c) echo "line" >> soubor, (d) „zajisti, že v souboru je řádek line". Kterou bys dal do skriptu, co se spouští opakovaně, a proč?
Naplánuj bezpečný zásah. Máš změnit důležitý config na ostrém systému. Popiš svůj postup před, během a po — kde je záloha/snapshot, jak měníš (kolik věcí naráz), jak ověříš, jak by vypadal rollback, kam si zapíšeš, cos udělal.
Kdy automatizovat. Děláš stejnou sekvenci pěti kroků potřetí ručně. Řekni, jestli je čas na skript, a jednu podmínku, která musí platit předtím, než ho napíšeš.
Najdi to sám. Narazíš na neznámý nástroj foo a příkaz z fóra curl https://foo.sh | sudo bash. Popiš, jak bys postupoval bezpečně — kam se podíváš první (dvě místa), a proč ten příkaz z fóra rovnou nepustíš.

Náčrt řešení — rozbal, až si cvičení zkusíš sám

Čti logy dřív — nejdřív se podívej, co systém říká: journalctl -u <služba> -e (poslední záznamy služby), /var/log/, nebo prostě celý výstup příkazu, který selhal. Chybová hláška skoro vždy pojmenuje příčinu (chybí soubor, špatné právo, obsazený port). Pořadí „pozoruj → pochop → zasáhni" je lepší, protože zásah bez pochopení je hádání — když náhodou zabere, nevíš proč, a příště jsi stejně bezradný. Pozor: pravá příčina bývá pár řádků nad posledním řádkem výpisu.
Idempotence — (a) mkdir /opt/app NENÍ idempotentní (podruhé zařve „File exists"); (b) mkdir -p JE (podruhé v klidu nic neudělá); (c) echo >> NENÍ (každé spuštění přidá další kopii řádku); (d) „zajisti, že řádek je v souboru" JE idempotentní (popisuje cílový stav). Do opakovaně spouštěného skriptu patří (b) a (d) — dají se pustit vícekrát bez škody, takže si nemusíš pamatovat, jestli už proběhly. Pozor: mysli v cílovém stavu, ne ve slepém přidávání.
Bezpečný zásah — PŘED: udělej zálohu/snapshot configu (cp config config.bak-DATUM nebo btrfs snapshot), ověř, že máš cestu zpět. BĚHEM: změň JEDNU věc, ne pět; ideálně nejdřív na testu/VM. PO: ověř, že služba jede (systemctl status, log), zapiš do changelogu co a proč, commitni config do gitu. Rollback: obnov z .bak / snapshotu / git checkout. Pozor: „cesta zpět" musí existovat dřív, než uděláš první změnu.
Kdy automatizovat — ano, potřetí ručně je typický signál pro skript (skript se nesplete v pořadí, nezapomene krok, je sám dokumentací). Podmínka předtím: musíš každý z těch pěti kroků umět a chápat ručně včetně toho, kdy selhává. Automatizace postupu, kterému nerozumíš, jen spolehlivě opakuje tvou chybu. Pozor: skript pak udělej idempotentní, ať jde pustit znovu.
Najdi to sám — první dvě místa: man foo a foo --help (oficiální dokumentace tvé verze), pak přesný název/chybu do vyhledávače a Arch Wiki. Příkaz curl … | sudo bash z fóra NEPOUŠTĚJ rovnou — stáhne cizí skript a pustí ho jako root, aniž bys viděl, co dělá. Bezpečně: stáhni skript do souboru, PŘEČTI ho, pochop, co provede, teprve pak spusť. Pozor: náhodný návod nezná tvůj systém — odpovědnost za sudo je na tobě.

🧠 Otázky & odpovědi

Co dělá z uživatele admina, když ne znalost víc příkazů?

Způsob přemýšlení, když se něco pokazí. Uživatel, co umí pár příkazů, hádá — zkouší jednu věc za druhou, a když to zabere, neví proč. Admin pozoruje, pak zasahuje: nejdřív přečte, co systém říká (logy, chybová hláška), pak vytvoří jednu hypotézu, změní jednu věc, ověří, a zapíše si to. Není chytřejší v počtu příkazů — je disciplinovanější v postupu. Příkazy se dají dohledat za minutu; tenhle návyk je to, co odděluje amatéra od profíka.

Proč je špatně měnit víc věcí naráz, když se něco pokazí?

Protože ztratíš informaci. Když změníš pět věcí a ono to začne fungovat, nevíš, která z nich to spravila — takže tam necháš čtyři zbytečné (možná škodlivé) změny. A když to pořád nejde, nevíš, kterou z pěti ještě zhoršit. Když měníš jednu věc a ověříš, každý výsledek ti něco jasně řekne. Je to o minutu pomalejší, ale ušetří to hodiny bloudění. Jistota nepřichází z množství změn, ale z toho, že každé změně rozumíš.

Co je idempotence a proč mě má zajímat?

Idempotentní změna je taková, že když ji pustíš jednou nebo desetkrát, výsledek je stejný. Například mkdir -p (podruhé v klidu nic neudělá) versus echo … >> (podruhé přidá druhou kopii řádku). Zajímá tě to, protože zásahy a skripty se v praxi spouští znovu — spadne to v půlce, nevíš, jestli už něco proběhlo, automatizace to pouští pravidelně. Když je operace idempotentní, nemusíš si pamatovat, jestli už běžela — prostě ji pustíš a je klid. Trik: mysli v cílovém stavu (jak to má vypadat), ne ve slepém přidávání kroků.

Můžu pustit příkaz z internetu, když funguje ostatním?

Ne rovnou, a hlavně ne s sudo, dokud mu nerozumíš. Vzorec curl … | sudo bash znamená stáhnout cizí skript a pustit ho jako root, aniž bys viděl jediný jeho řádek — dáváš neznámému kódu plnou moc nad svým systémem. Náhodný návod na fóru navíc nezná tvůj konkrétní systém; to, co pomohlo někomu jinému, může u tebe škodit. Bezpečně: stáhni skript do souboru, přečti ho, pochop, co dělá, a teprve pak spusť. Odpovědnost za každé sudo je na tobě, ne na autorovi návodu.

Proč tolik dbát na dokumentaci a zálohy, když si to pamatuju?

Protože si to pamatovat nebudeš — a i kdyby, být jediný, kdo něco ví, je riziko. Za tři měsíce budeš na vlastní config koukat jako cizí člověk a nebudeš vědět, proč tam ten řádek je. Záloha před zásahem je nejlevnější pojistka: chvilka teď versus ztráta dat potom. A znalost jen v hlavě je bus factor 1 — když zmizíš (dovolená, nemoc, zapomenutí), systém drží nikdo. Proto dokumentace, verzované configy, changelog a skripty: dostat znalost ven z hlavy, aby po ní mohl sáhnout někdo jiný nebo ty za rok.