Vlákno názorů k článku CentOS je mrtev, ať žije CentOS Stream: distribuce předbíhající ve vývoji RHEL od lzap - Pokud vás stejně jako mě znepokojují častější aktualizace...

  • Článek je starý, nové názory již nelze přidávat.
  • 9. 12. 2020 13:25

    lzap

    Pokud vás stejně jako mě znepokojují častější aktualizace v CentOS Stream oproti tradičnímu CentOSu, mám tip na řešení.

    Aktualizovat produkční servery přímo z mirrorů CentOSu není dobrý nápad, existují postupy a nástroje, jak aktualizace provádět více kontrolovaně. Typicky se repositáře synchronizují (zrcadlí) na vlastní server ke kterému se klienti připojují. Na tomto serveru lze aktualizace různě třídit a filtrovat.

    K tomuto účelu existuje projekt Pulp, který umí repositáře synchronizovat (ručně, podle plánu). Uživatelé často nevytvoří jen hloupé zrcadlo celého OS, ale udělají řetěz repositářů: upstream -> test -> preprod -> prod. Tím získávají možnost nejprve aktualizace nahrubo otestovat (test) a pak v předprodukčním prostředí ověřit, že nic nerozbijí.

    Pulp nabízí také správu tzv. errat. Errata v Red Hat světě je v podstatě takový dokument, který popisuje určitou opravu chyby (nebo novou vlastnost) a obsahuje seznam balíků, které jsou nutné k aplikaci. Red Hat tyto informace dává k dispozici pro RHEL tak, že jsou dostupné přímo v dnf/yumu, projekt CentOS je pak zveřejňuje na mailing listu (integrace s dnf/yumem není z důvodů nedostatečné kapacity lidské síly a zdrojů). Existuje však skript, pomocí kterého lze erraty natáhnout z centos listu do Pulpu a pak s nimi pracovat.

    Pulp má pouze API a CLI klienta, pokud pracujete ve větším týmu, určitě se hodí webové rozhraní s dalšími možnostmi jako je RABL, Kerberos/LDAP/MSAD případně abstraktní vrstva nad repositáři kdy se pracuje s tzv. Lifecycle Environments a Content Views které umožnují vytvářet skupiny serverů/klientů u kterých chcete například počkat na určité verzi po delší dobu a podobně. Celý workflow může být poměrně složitý.

    Podobných výsledků lze docílit obyčejnými nástroji jako je rsync případně createrepo, ale myslím že ať už Pulp, nebo Foreman s pluginem Katello jsou skvělou volbou. Mimochodem, oba projekty podporují i repositáře jiných distribucí, jmenovitě Debian, Ubuntu a Suse, takže pokud by vás něco podobného zaujalo, projekty se neomezují jen na Red Hat.

    Foreman s pluginem Katello je však relativně komplikovaný deployment, má komponenty v Ruby, Pythonu i Javě, potřebujete dedikovaný virtuální stroj s hodně paměti i velkým diskem a dokumentace by taky potřebovala vylepšit. Proto tohle zvažujte až od určitého počtu serverů, určitě se asi nemá cenu trápit kvůli desítkám serverů.

    Na projektu Foreman pracuju, věnuju se ale instalacím OS přes síť, což je jedna z dalších vlastností které Foreman může nabídnout. Věci týkající se repositářů neznám do hloubky, ale máme spoustu spokojených uživatelů a svělou komunitu. Projekt je také prodáván jako komerční řešení: Red Hat Satellite a ATIX, lze objednat konzultace u několika dalších firem. Píšu to proto, že je možné si stáhnout a pročíst dokumentaci u jednoho z projektů a vše co se dozvíte bude fungovat i u volně dostupné verze.

    https://theforeman.org/
    https://theforeman.org/plugins/katello/
    https://docs.theforeman.org/
    https://access.redhat.com/documentation/en-US/Red_Hat_Satellite/6.8/
    http://cefs.steve-meier.de/

  • 9. 12. 2020 14:29

    FactChecker

    Máte v popisu práce dělat Red Hatu i damage control?

    Ale jinak perfektní informativní příspěvek! Díky za něj.

  • 9. 12. 2020 19:02

    lzap

    Zbytečně to polarizujete. "To že pracuju pro Red Hat jsem měl napsat předem..." a "Damage control v popisu práce". Ono je potřeba chápat, že sice pracuju pro Red Hat, ale zároveň jsem členem Fedory a po večerech spravuju pár balíků, účastním se meetingů a volím ve volbách. U CentOSu jsem jen uživatel, ale komunitu pasivně sleduju.

    A samozřejmě mě jako uživatele CentOSu mrzí, že tahle nešikovná komunikace poškodila vztahy. CentOS Stream tak jak ho chápu je hlavně změna workflow, pro toho co pozorně své systémy patchuje to může vést dokonce k rychlejším updatům. A "Franta Procházka" z "Horní Dolní" co má doma CentOS na NASu si toho vůbec nevšimne. Nicméně mělo to být komunikováno podstatně lépe, zejména užití pojmu Rolling Release média dost rozmázla a porovnávají CentOS Stream s Gentoo/Arch Linuxem, což je samozřejmě srovnávání jablek a hrušek. A oheň je na střeše.

    Patch management myslím bude důležitější než kdy jindy. Proto ten příspěvek. Nic za tím nehledejte, nikoho nebráním. Byla by škoda kdyby uživatelé opouštěli CentOS jen kvůli tomuhle, správně patchovat se musí i ten Debian.

  • 9. 12. 2020 22:24

    FactChecker

    Tohle beru. Mimochodem byl jsem aktivně u zrodu CentOS a jsem také členem Fedory s pár balíky a vlastním software.

    Asi se ale rozcházíme v pohledu na motiv té změny. Vy za tím vidíte změnu workflow a já zas urážku principů na kterých stál CentOS a jeho zneužití jen k prospěchu Red Hatu.

  • 11. 12. 2020 9:14

    Vláďa Smitka

    Jen bych doplnil, že v odkazu zmíněný Steve Meier nedává k dispozici jen zdroje pro postavení vlastního repa (tak jsem to dříve řešil), ale má i přímo repozitář, který errata doplní a není potřeba nic dalšího řešit. Pro přístup ho stačí sledovat na Patreonu za $1 měsíčně. Psal jsem o tom https://smitka.me/2019/01/02/enhance-your-centos-security-for-1-a-month-with-autoupdates/