Tento článek jsem nosil v hlavě několik posledních měsíců. Vznikl jako důsledek stavu, který se výrazně rozmáhá poslední rok. A neprozřetelně jsem se o něm zmínil před Johankou, když jsme vedli debatu o PR MS. Tento článek si neklade za cíl být tím jediným správným, ideálním, dokonalým, ale představuje některé alternativy, které jsou pro mnohé široce známé, pro jiné jsou stále nejasné. Cílem je poskytnout jistý přehled v tomto tématu. Je určen hlavně administrátorům serverů, ale některé postupy jsou zajímavé i pro klientské stanice v podnikové sféře. Prostě všude, kde je důležitá bezpečnost a stabilita, dostupnost služeb.
Je docela možné, že ve chvíli, kdy článek vyjde, konečně Security team a ftp-masters dokončí nové řešení pro bezpečnostní záplaty, začnou se objevovat přímo bezpečnostní záplaty pro Sarge a bude nám zbývat nějaký ten týden, měsíc k novému stable. Ale za dva roky se situace může opakovat. Proto tento článek je i trošku nadčasový, tedy pokouší se o to. Dává přehled, jak lze v dnešní době vylepšovat stávající stable a k závěru také přehled o diskutovaných řešeních. Od čtenáře vyžaduje, aby měl již aspoň částečné znalosti správy nějakého systému založeného na Debianu. Není manuálem, spíše povídáním o situaci.
Stále více administrátorů systémů založených na Debianu nasazuje na své servery nestabilní verze Debianu. Ať už testing větev, nebo unstable větev. Tito lidé to dělají v naprosté většině případů ze dvou důvodů, z neznalosti, nebo z lenosti. V každém případě tímto způsobem výrazně zvyšují pravděpodobnost ztráty dat, výpadku poskytované služby a nabourání systému třetí stranou, což je nejhorší, protože to v sobě nese i předchozí dva problémy.
Důvody pro ztráty a výpadky jsou zřejmé, příchodem nových, neotestovaných balíčků v nemálo případech dojde k nějakému problému. Správci balíčků určitě nemohou postihnout všechny situace. I když v dnešní době pro nemálo výrazných změn existuje navíc prostředí experimental, ve kterém se testují různé rozsáhlejší změny komplexních či nových balíčků, stále tyto výpadky hlavně u větve unstable hrozí. Sám jsem takhle prošel několika výpadky i ztrátami dat ještě v dobách, kdy kódové jméno pro budoucí stable verzi znělo Woody. Od té doby se navíc mnohé změnilo, narostla komplexnost aplikací i jejich vzájemná provázanost, tím se pravděpodobnost vzniku chyby zvýšila (a někdy se, hlavně v unstable verzi, stane skutečně nemilá věc, jako je už relativně dávný problém vzniklý chybou v PAMu, kdy nebylo možné se přihlásit do systému). Slova jako testovací a nestabilní mají ve světě Debianu svou váhu.
Ještě mnohem horší je situace v případě zabezpečení takovýchto systémů. V případě unstable větve se každá bezpečnostní záplata dostává do systému v rámci nahrání nové verze příslušného balíčku. Nikdo ale neříká, jak dlouho bude trvat, než se vůbec tato nová verze stane součástí unstable. To záleží čistě na vůli správce daného balíčku (případně může být nová verze nahrána i někým jiným v formě NMU, ale to není až tak obvyklé). Zde tedy vzniká někdy i několikatýdenní prodleva. Situace v případě testing verze je ještě složitější, protože se do ní dostávají verze pouze z unstable (v dnešní době potenciálně i přes proposed-updates a čistě teoreticky i skrze security team, ale o tom později, ve výhledu, co nás možná čeká a snad nemine).
Přemýšlel jsem nad tím, zda tu dál plivat oheň na užívání Sarge na místech, kam nepatří, ale stejně by se to minulo účinkem, a tak se raději dál budu zabývat tím skutečně podstatným, tedy jak mít Woodyho (a okolo roku 2007 Sarge) v rozumné potřebné míře up-to-date.
Hodně času uplynulo od doby, kdy vyšla poslední verze Debianu – Woody. Mnoho se za tu dobu změnilo. Byla to doba, kdy slovo spam nemělo téměř význam. Doba, kdy open source SQL servery stále nosily plenky. Alternativy k sendmailu nebyly tak mocné jako dnes. A samozřejmě mnohem více. Vlastně lze už začít tím úplně základním, instalací nového hardware, se kterým si původní kernel 2.4.18 na originálních boot-floppies občas nerozumí.
Instalace
V dnešní době je skutečně často problém úspěšně nainstalovat Debian na server, hlavně na profi servery s novými SCSI řadiči, ale i obyčejné SATA řadiče jsou pro boot-floppies nepřekonatelným problémem. V takovém případě jsou tři cesty k úspěchu (tedy, je jich více, ale s těmito mám zkušenosti a jsou šířeji užívané).
První je vytvoření vlastních boot-floppies. Jedná se o dobře zdokumentovanou proceduru používanou často v dřívějších časech, když na originálních médií chyběl nějaký potřebný ovladač. Dnes ale tento selfmade způsob upadá, užíván bývá jen výjimečně, když nikdo jiný před námi zrovna nepotřeboval to co my a nevystavil takový instalátor veřejně.
Druhou možností je dnes opravdu široce užívaný způsob nabootování s pomocí Knoppixu a pak užití debootstrapu, který je Knoppixem podporován.
Zkrácený popis takové instalace začíná tím, že si nejdříve samozřejmě s pomocí utilit jako fdisk a mkfs.xxx připravíme disk, na který chceme instalovat. Vybranou partition si pak přimountujeme do nějakého adresáře a můžeme se vrhnout na debootstrap.
Debootstrap (případně jeho nová podoba cdebootstrap) zvládne nainstalovat Debian do zvoleného adresáře bez potřeby dpkg. Je komponentou boot-floppies a je užíván k instalaci různých chrootů, což se hodí i pro naše potřeby. Jak jej užít, tj. jak napsat ten jeden řádek, který stáhne a rozbalí vše potřebné, lze najít v dokumentaci této aplikace, základní forma je přibližně tato:
debootstrap woody /mnt/woody-disk ftp://ftp.cz.debian.org/debian Více o debootstrapu lze najít v jeho manuálové stránce (pár zajímavých přepínačů). Pouhý debootstrap ale nestačí, je třeba takto čistě nainstalovaný systém jednak podpořit instalací novější verze kernelu (kde jej například získat, viz dále) a mírně jej dokonfigurovat (ukázka postupu), základem je použití chrootu, základní konfigurace pomocí base-config, konfigurace lila atd.
Třetí možností je projekt Hilux, který v první fázi přinesl široce rozšířené možnosti instalace, v dnešní době si více hraje na komplexní aktualizaci Woodyho, ale stále je plně využitelný pro instalace. Mimochodem, na stránce projektu najdete i odkaz na aktuální seznam různých alternativních a aktualizovaných instalátorů pro Debian. V průběhu života Woodyho jich vzniklo opravdu nepřeberné množství, většina jich zhyne záhy po vydání Sarge, ale některé se nepochybně udrží dále. Třeba zajímavý DFS lze již dnes užít jako alternativu k instalátoru Sarge, ale i Woodyho. Vždy je dobré si u konkrétního instalátoru přečíst, jak funguje a co je třeba provést po úspěšné instalaci, jak provést konfigurování atp.
Nový kernel
Nyní jsme se dostali do stavu, kdy máme nainstalovaný nový systém. Nebo máme starý, ale přidali jsme do něj novou kartu. Prostě staré dobré jádro 2.4.18 (jedno z nejlepších z řady 2.4, první skutečně použitelné, že, velký, neomylný LT…) už nám nestačí.
Možností je mnoho. Kernel-package pro vytvoření balíčků s image kernelu potřebuje prostě jakýkoliv strom se zdrojovými kódy kernelu. Lze užít i čistou vanillu. Ovšem pro ty, kteří ví, jak nevhodné je to řešení, je pak řešením tato řádka:
deb ftp://ftp.backports.org/debian woody kernel-source-2.4.27 Těm, kteří netuší, co znamená, doporučuji prostudovat dokumentaci k apt, už takhle článek neskutečně nabobtnal. K Backports.org se ještě vrátím později, kernel poskytovaný v něm je odvozen od vybraných verzí z oficiálních zdrojů Debianu včetně potřebných bezpečnostních záplat a případných nutných úprav.
Pro ty zoufalce, kteří musí užít kernel řady 2.6, je k dispozici několik balíčků na Backports.org, jak jader jako 2.6.7 (jedno z lepších, i když v péči LT asi žádné nebude dobré, ať už to konečně předá AC nebo AB, a ať se i s AM věnují 2.7), tak i potřebné module-init-tools. K tomu bych rád poznamenal, že užívaní vanilla kernelu řady 2.6 se skutečně na serveru nevyplatí, sám velký LT a jeho sekundant AM tvrdí, že stabilita je na distribucích, jich se netýká. Ach jo…
Nyní máme nainstalovaný základní systém v podobě Woodyho. Dost často nám to stačí, nepotřebujeme žádné nové aplikace a další díl tohoto pindání nás nezajímá. Pokud tomu tak není, případně se chcete dozvědět něco o možném směřování Debianu ohledně problematiky prodlužujícího se vývojového cyklu, počkejte si na druhý díl.
