ZMD - úvod ke správě balíčků

Nejsem asi jediný, kdo je z posledního vývoje ZENu v SuSE Linuxu tak trochu jelen, a nebudu ani první kdo se pokouší si celou věc vyjasnit. Celá historie započala v SuSE přechodem pod Novell před necelými třemi roky, a stopy ZENu najdete snad ve všem co vzniká pod křídly Novellu. ZEN works je letitá skupina produktů, které sloužily původně na správu a distribuci programů na stanice (především pod Windows od verze 3.1 výše), později se k tomu přidala i správa serverů (ZEN Works for servers) a handheldů s OS Palm nebo Windows Mobile (ZEN Works for handhelds). ZENWorks se staly součástí dalších produktů a leccos najdete v komerčních Novell Small Business nebo Novell Open Workgroup Suite stejně jako v openSUSE, kde si malou část týkající se aktualizací a instalací balíčků popíšeme.

Plný ZENWorks je založen na distribuované databázi eDirectory (v odlehčené podobě i lokální), do které se registrují stanice, uživatelé a software (i s licencemi) a namísto obíhání jednotlivých počítačů při instalacích/upgradech softwaru se udělá referenční instalace do sítě (zaznamenají se změny v registrech a v souborech na stanici) a definice pravidel, co který uživatel/stanice má mít nainstalováno, a vše se automaticky roznáší po stanicích v síti podle potřeby tak, jak se v ní pohybují uživatelé a jejich počítače.

S přechodem SuSE pod Novell se samozřejmě rozšířila skupina spravovaných systémů i na Linux, především na jakýkoli SuSE a odvozený (OES), ale v principu je systém připraven na jakoukoli RPM distribuci (s deb balíčky však, pokud vím, zatím nepočítá). V první fázi vývoje se adaptoval pro tento účel Red Carpet Manager (převzatý z Red Hatu a Ximianu), v druhé fázi se Novell pokouší vytvořit nadstavbovou databázi nad RPM, ve které se registrují instalační zdroje a vyhodnocují závislosti o něco pokročilejším způsobem, než to umožňuje RPM databáze. Aby se ušetřilo na vývoji celého systému, udržuje se společná kódová báze se správou Windows, a proto byla zvolena platforma .NET Framework a její implementace Mono v Linuxu, což přináší, spolu se zjevně špatně optimalizovaným kódem, obrovskou náročnost na systémové zdroje počítačů které mají být tímto systémem spravovány.

Základem správy balíčků je nadále RPM databáze, která existuje nezávisle, ve stejné podobě jak ji známe. Příkazy RPM jsou volané jednotnou knihovnou LibZYPP která tvoří most mezi RPM a metadatabází SQLite kterou udržuje služba ZMD (ZENworks management daemon). LibZYPP umí vyhodnocovat navíc závislosti, k tomu slouží skupina programů Libzypp ZMD helpers jako např. update-status, parse-metadata nebo transact. Pokud budete chvíli sledovat činnost počítače po startu pomocí příkazu top, tak uvidíte, že tyto programy zaberou (spolu se samotným ZMD) po dobu až několika minut značnou část paměti a výkonu počítače. Obecně je systém s plným grafickým prostředím (ať už GNOME, nebo KDE) nepoužitelný pod 256MB RAM a i tato velikost je nedostatečná jak ukáže swap, bez problémů je až kapacita od 320MB. V dobách SUSE 9.x jsem používal KDE i na starších počítačích se 128MB a celek byl svižnější než nasazení OpenSUSE 10.2 na 320MB. U Novellu o neudržitelnosti tohoto stavu prý vědí a v současnosti probíhá přepsání celého kódu od základu. Musím říct, že se na to dost těším, protože ZMD výrazně degraduje jinak velmi dobrou distribuci až na samou hranici použitelnosti zejména pro starší hardware. K tomu se navíc přidává velmi mnoho problémů a chyb, z instalovaného systému samovolně vymizí subscribované kanály, nebo nelze provést aktualizaci kvúli konfliktu, kdy je vypsán jen číselný ID balíčku takže složitě zjišťujete kterého balíčku se to týká i když opakovaný update proběhne v pořádku apod. Podrobnosti o celé architektuře najdete v článku Understanding zmd - openSUSE.

V případě openSUSE nicméně je ještě částečně zachován starý systém správy v YaSTu částečně nezávislý na ZMD (pokud nepočítám synchronizaci). Nejlepší volbou je zatím při instalaci nevolit standartně vybraný profil "Sprava softwaru -> ZenWorks" a zrušit jeho zatržení v YaSTu. Uživatelé komerčních verzí SLES a SLED mají podstatně složitější situaci a ZMD se jen tak lehko nezbaví a není k tomu ani zvláštní důvod, pokud provozují plný systém ZEN Works pro správu. Pro izolované nasazení produktů bez infrastruktury od Novellu, tedy v korporátním prostředí, to ale zatím může být docela dost velký problém.

Autor: ulejm

Komentáře

JirkaZ odpověděl -

popisuje to, co se obecně člověk nedozví. K Vašemu závěru bych podotknul jen to, že pro "izolované nasazení" - pokud tím máte na mysli instalaci openSUSE na pracovní stanici - je nejlepší celý ZMD, ZENworks a související věci odstranit a používat buď zmíněný YAST, nebo (lépe) Smart.

Už se o tom na tomto portálu i jinde mluvilo víckrát a z osobní zkušenosti to můžu jen potvrdit a doporučit. Delší dobu je pro mě Smart téměř jediným prostředkem pro balíčkovací systém.

JirkaZ odpověděl -

vůbec takovéhle věci nemusíte řešit, když budete i na aktualizace používat Smart s korektně nastavenými repozitáři (kanály) nebo nakonec i ten YAST. Smart je ale lepší. Vše už tu bylo popsáno.

llipavsky odpověděl -

libzypp neni soucasti zmd ani yastu. Jedna se o knihovnu, kterou vyuziva jak ZMD, tak YaST. Je to videt tady.

Pokud pri instalaci OpenSUSE zrusite pri vyberu balicku ZENworks enterprise management (ci jak se to jmenuje), tak se vam nic ze ZMD nenainstaluje - cili pouze yast+libzypp. A jelikoz ZENworks nebude nainstalovan, tak k zadne synchronizaci zdroju s ZMD nedochazi.

Jinak pekne shrnuto ;-)

JirkaZ odpověděl -

jsou krásně vidět na tomto screenshotu (je kvůli výšce složený ze dvou). Vypíší se ve Smartu, pokud se pokusíte odstranit právě libzypp...