Hlavní navigace

Debian stable na serveru po letech a jak dál (2)

4. 1. 2005
Doba čtení: 8 minut

Sdílet

Pokračování a závěr pindání "Jak se jeden Debianista naštval a tak dále". Kde brát nové aplikace a jejich čerstvé verze. Troška historie a nějaké ty výhledy, možnosti, co dál.

V tomto dílu se podíváme na to, jak se dá Woody modernizovat a jak se Debian chce poprat s takto dlouhým vývojovým cyklem.

Novější aplikace

V dnešní době se opravdu velmi často setkávám se situací, kdy zákazník pro svou práci vyžaduje něco, co není k dispozici ve starém dobrém Woodym. Případně je k dispozici, ale ve velmi komplikované podobě. Řešení „testing na serveru“ z dříve uvedených důvodů odmítám (jen jednou jsem byl k tomu okolnostmi donucen, dodnes nesu následky, a to ten server není tak úplně Sarge, jen chroot), a tak je třeba se poohlédnout jinde. A zcela „nečekaně“ tento problém neřeším jen já. Kouzelné slovíčko zní backport, tj. přenesení novější verze aplikace do prostředí stable.

Backportů existuje v dnešní době obrovské množství. Moje první setkání s tímto „přístupem“ pochází z doby předchozí stable verze, potato. Tehdy se Adrian Bunk rozhodl, že Woodymu to prostě dlouho trvá a lidé by rádi využili předností nové řady kernelu, 2.4. Ovšem to vyžadovalo nějaké ty změny i v userspace oblasti, minimálně novější modutils. A tak vytvořil neoficiální repository právě pro potato versus kernely 2.4.x.

Pro mnoho lidí včetně mě to bylo velmi přínosné, Bunk pravidelně toto repository udržoval, staral se o backporty a aplikoval i různé externí potřebné patche tak, aby vše v pohodě fungovalo. Pak přišel Woody a valná většina lidí si zachovala představu o tom, co je externí repository, snad jen proto, aby od Blackdownu získávala balíčky JDK.

Jenže velké proklamace, jak nové metody vývoje pro Sarge zkrátí vývojový cyklus, se minuly účinkem. A tak se mezi neoficiálními externími repository začalo kromě JDK (a případně tolik žádaným Marillatovým s Mplayerem a dalšími zásadními balíčky pro desktop) znovu objevovat Bunkovo repository, které s sebou přinášelo nové verze GCC, nová jádra, čerstvou Mozillu, Spamassassin a další a další. Bohužel, další a další. Prostě úplně vše, co Bunk potřeboval, krásně vzájemně provázané. Nemálo dalších externích repository bralo jako prerekvizici balíčky od Bunka. Jenže. Jenže když někdo chtěl jen vybrané aplikace, často narazil na vzájemné závislosti. Buď vše, nebo problémy. A navíc Bunk pomalu přestával mít to původní nadšení, přestal repository udržovat. Dnes už je neudržované.

Tou dobou také existovala a stále bobtnala stránka se seznamy různých externích repository. Nejen s backporty pro Woodyho, ale také s neoficiálními balíčky pro Sida například. Bohužel ji ale její správce přestal udržovat. Náhrada naštěstí na sebe nenechala dlouho čekat a byla mnohem inteligentnější – www.apt-get.org. Hezký vyhledávač ve všech známých externích repository. Udržovaný, pravidelně obcházející jednotlivá repository a zjišťující změny stavu.

Každé takové repository vznikalo podle potřeb svého správce. Občas ty potřeby byly tak přehnané, že jejich správce backportoval snad všechny balíčky, které používal. Ten stav trvá částečně dodnes a stále platí, že je nutné velmi dobře prostudovat konkrétní repository, sledovat, jak se o něj jeho správce stará, a zda nabízí přesně to, co potřebujeme.

V této chvíli bych rád zmínil jedno repository, které se stalo celosvětově populárním a má původ u nás. Práce na debian.malyjar­da.cz byly určeny pro nasazení na desktopech, proto se jim více nebudu věnovat. Ale na každý pád si jejich autor vydobyl respekt v komunitě.

Zdálo by se, že stav je víceméně silně chaotický. Naštěstí tomu tak úplně není. Z celého tohoto procesu se vylouply minimálně dvě repository, které si zaslouží pozornost.

To první, www.dotdeb.org, proto, že nabízí přesně to, co mnozí admini potřebují, Apache, PHP, MySQL. A také vše potřebné okolo qmailu pro dnešní poštovní server (SA a ClamAV). Protože osobně se qmailu vyhýbám v maximální možné míře, zkušenosti mám pouze s tou WWW částí. A ta se ukazuje dobrou, pravidelně udržovanou. Pro ty, kteří by rádi Apache 2 s PHP, mám jedno slovo – hledejte. Lze najít nějaká ta neoficiální repository, ale třeba vás délka hledání odradí od komplikací spojených s jeho nasazením (to je snadné), ale hlavně s jeho udržováním (netriviální vzhledem k neexistenci skutečně kvalitních udržovaných backportů PHP pro Apache 2).

Dnešním vrcholem neoficiálních repository, čnícím vysoko nad chaosem, je pak www.backports­.org. Osobní projekt Norberta Tretkowského, který se pokusil vytvořit alternativu ke všem ostatním neoficiálním backportům. Na základě relativně přísných pravidel zde vznikají backporty aplikací s maximálně minimalizovanou provázaností s jinými backporty. Kdo chce, může je mít všechny, ale také může využívat jen přesně to, co skutečně potřebuje. Generované Packages jsou tvořeny tak, že pro každou aplikaci nabídnou právě to minimální množství nutných backportů. Jak to využít, jsem naznačil již dříve, v části o aktuálním kernelu.

Tretkowského repository navíc není dnes již pouze jeho soukromým projektem, o většinu balíčků se tam starají jiní lidé, často jejich správci z Debianu. Existují tendence něco takového zoficiálnit v rámci Debianu, Tretkowski před časem slíbil, že vyčistí své skripty pro tvorbu a údržbu takového repository a nabídne je veřejně. No, uvidíme. Na každý pád je toto repository něčím opravdu výjimečným v oblasti Debianu.

Zde jsem původně chtěl sepsat postup, jak vytvářet vlastní backporty a udržovat lokální firemní repository ve stylu Backports.org, ale v průběhu psaní článku jsem dospěl k přesvědčení, že nemusí obsahovat návody, které jsou popsány jinde na mnoha různých místech mnoha různými slovy. A tak dnes odkážu pouze na balíčky jako debhelper a dpkg-dev. Činnost to určitě v mnohých případech není snadná a navíc končí až ve chvíli příchodu nového stable, který z vás sejme povinnost vytvářet si nové opravné backporty.

Jen se trošku zastavím u malého, ale mocného balíčku equivs. Předem varuji před jeho použitím mimo akutní případy. Můžete si jeho neopatrným využitím totiž zcela nabourat závislosti mezi balíčky. Oč vlastně jde? Tento balíček je schopen na základě dobře napsaného control souboru (pár ukázkových si nese v rámci své dokumentace) vytvořit dummy balíček, který slouží jen k uspokojení hloupě sestavené závislosti nějakého balíčku na jiném. Za normálních okolností by k něčemu takovému docházet nemělo, ale v oblasti užití backportů (a nejen v ní) se občas stane, že závislost je splněna jiným způsobem, než balíček připouští. A pak equivs může být řešením.

Výhled a závěr

Předchozí povídání čtenáře v krátkosti seznámilo s dnešními možnostmi udržování potřebné čerstvosti stable Debianu. A jaké jsou vlastně výhledy do budoucna?

O obecném problému nárůstu délky vývojového cyklu Debianu se snaží lidé okolo Debianu diskutovat neustále (viz Centrální diskusní wiki). Nabízí se řada možností (včetně takových, jako je zcela zrušit stable, což naštěstí nemá valnou podporu, zdá se). Klidně přispějte se svým pohledem, nebo některé podpořte, rozveďte. Myšlenky nepochybně vítány.

Už je tomu pár měsíců, co se v debianích listech diskutoval nejbolestivější problém, aktualizace balíčků, které to skutečně potřebují pravidelně. Typickým příkladem jsou IDS nebo antivirus, kterému se nemění jen virová báze, ale také vlastní stroj. A tak vzniknul návrh na volatile.debi­an.net, repository, které by mělo obsahovat takovéto backporty. Ale nejen přímo rekompilace balíčku, spíše aplikace nutných částí kódů na starší verze. Netriviální úkol, velmi náročný, teprve realita ukáže, na kolik je takové řešení životaschopné.

Další zajímavou alternativu představuje snaha některých Debianistů poskytovat do budoucna bezpečnostní opravy i pro testing. V první fázi tato skupina prošla všechny dostupné seznamy známých chyb, aby ověřila, zda v unstable Debianu nezůstalo něco neopraveno. Ukázalo se, že nikoliv, že žádná stará chyba si tam nelebedí. Zároveň sestavili seznam balíčků, které čekají na opravy v testingu, neustále ho udržují a Joey Hess, jeden z vůdčích členů skupiny, posílá nepravidelně reporty o aktuálním stavu. Seznam to není úplně krátký, některé problémy v něm jsou dlouhodobějšího rázu. Naštěstí v něm aktuálně není žádná akutně kritická věc.

Jak je vidět, lidem v Debianu není situace lhostejná, hledají se cesty, jak dále nabízet jednu z nejlepších distribucí a zároveň myšlenek dále všem, kteří by toho rádi využívali a stali se součástí neuvěřitelně rozsáhlé spolupráce lidí, kterou Debian představuje.

Tento článek si kladl za cíl trošku zhodnotit aktuální možnosti a představit možnosti budoucí. Nabídnuté aktuální řešení není optimální, jak lze namítnout. Většina backportů se stává skutečností až ve chvíli, kdy se stanou součástí oficiálního Debianu, minimálně unstable větve. Tím se neeliminuje problém bezpečnostních updatů. Ale minimalizuje se, protože rozumný administrátor na svých systémech používá jen ty aplikace, které skutečně potřebuje, a tak také používá pouze ty backporty, které skutečně potřebuje. A ty si průběžně sám hlídá skrze hlášení chyb pro konkrétní balíčky v Debianu a také pravidelným pročítáním listů, jako je Bugtraq, případně listů, které se týkají upstream verze dané aplikace. Zároveň se snižuje riziko ztráty dat či výpadku služby, protože měněných věcí je minimum a prošly několika stupni testování.

Samozřejmě to má své mouchy. Některé aplikace lze jen velmi obtížně přenést do staršího prostředí. Typickým příkladem je amavisd-new, který v novějších verzích mívá problémy s Woodyho verzí perlu při komunikaci přes socket. Sám znám dvě řešení. Místo socketu užít port, nebo přikompilovat ručně čerstvý Perl jako druhý, pouze pro amavis. Který užívám, si čtenář může sám vybrat. Tímto jsem chtěl říci, že nasazení backportů také není bezproblémové a je třeba si stav alespoň trošku hlídat.

Správa serveru není odpočinková záležitost (i když, jak se to vezme), je třeba se jí pravidelně věnovat, protože skutečně bezchybných aplikací je poskrovnu (ani DJB není neomylný).

root_podpora

Tak, pindání je konec, je třeba se zase věnovat něčemu smysluplnějšímu. Na závěr bych chtěl poděkovat Tomáši Horylovi a Tondovi Královi za odbornou i jazykovou kritiku a samozřejmě Johance za to, že mě opatrným šťouráním dotlačila tohle sepsat, a také za to, že to přečetla a opravila. Bohužel má snaha, aby to hodila do koše, se minula účinkem.

Nezbývá mi nyní než doufat, že alespoň někdo to dočetl až sem, a hlavně, že alespoň někdo z článku získal nějakou podnětnou informaci. Long live and prosper, Debian.

Byl pro vás článek přínosný?