Názory k článku CentOS je mrtev, ať žije CentOS Stream: distribuce předbíhající ve vývoji RHEL

Takže CentOS skončil. Většina důvodů, proč jej většina lidí používala tímto padá. Skvělá zpráva takhle na večer.

Není nad to nově nainstalovat nebo upgradovat v posledních měsících spoustu serverů na CentOS 8 a na to se dozvědět, že jim za rok nastává EOL. Děkuji pěkně, fakt.

Taky tomu nerozumím. Kdyby ukončili sedmičku zároveň s osmičkou, mělo by to jakýsi smysl, ale tohle je úlet.

Do pr.... Mam ho u sebe pro vyvoj a taky na jednom serveru.
Prestavam mit rad Red Hat, tohle je proste podraz...

Pro vývoj můžete použít RHEL Developer Subscription - https://developers.redhat.com/blog/2016/03/31/no-cost-rhel-developer-subscription-now-available/

Na server se možná bude týkat oznámené rozšíření nabídky RHELu zdarma.

Načo vyvíjať na niečom, kde to potom nemôžem používať v produkcii?

Debian, here I come.

Vdaka, toto je super informacia.

bude to zajímavé, Red Hat má cenovou politiku dost zběsilou, centos používáme převážně na dev/uat prostředí, pro virtualizaci, kde to Red Hat nemá dobře vyřešené a subscription je příliš drahé a neohebné. Pro Red Hat to byla prostě konkurence.

V produkci ale už druhým rokem na některých projektech testujeme Oracle linux, jeví se ve spoustě ohledech jako pěkná náhrada.

Pre server nevidim absolutne ziadny dovod nepouzivat Debian. Jedine kedy sa oplati RedHat je specificke nejake nove enterprise zelezo rozumej nejaka specialne pole s optickym pripojenim od nejakej 'obscurnej' firmy IBM. VTEDY ano, treba RedHat. Inac Debian, nikdy ziadny problem.
A na klientovi pouzivam Debian SID pripadne testing s rolujucimi balickami uplne bez problemov uz asi 10 rokov.

Kedysi mal APT taky neprijemny bug ktory nevedel spravne vyhodnotit zavislosti automatickych balickov ktore prechadzali cez rucne instalovane balicky ... takova blbost ... a od vtedy ako to zafixovali co je asi 3 roky sa clovek musi velmi snazit aby nainstaloval balicek s nefunkcnymi dependencies. Pouzivam stary dobry 'aptitude' a momentalne (tuk, tuk) 2-3 absolutne bezudrzbova zalezitost. Napriklad teraz mi v balikoch stoji uz asi 3 mesiace novy LibreOffice na chybajucich dependencies ale netlacim, pockam, vzdy pri update upozorni, dam ! - Accept a hotovo.

A ted si predstav, ze jsou mezi nami lide, kteri pouzivaji Arch. To musi byt docela adrenalin po dvou mesicich zavolat pacman -Syu. :D :D

Taky jsem jel na linuxove masine Debian Sida, ale pak jsem se na to vykaslal a presel na Ubuntu, oni v podstate jedou Sida.

debian zejména (ale obecně hlavně stable) má obrovský problém s fixováním bezpečnostním děr v balíčkách, na hromadu z nich nemá mainteinery a jsou ponechány bez dozoru. Např. debian buster, php 7.3 a CVE-2020-7070 z počátku letošního roku pořád není opraveno v stable a přitom lze zneužít z venku přes podvržené cookies.

To se u CentOS nestává v takové míře (teda pokud někdo nezačne používat epel). Mně politika CentOS s bezpečnostními aktualizacemi vždy více vyhovovala i za cenu zpoždění.

> Např. debian buster, php 7.3 a CVE-2020-7070 z počátku letošního roku pořád není opraveno v stable a přitom lze zneužít z venku přes podvržené cookies.

Jak se koukám, tak se koukám, ale tady to nevidím jako nahlášený bug: https://bugs.debian.org/cgi-bin/pkgreport.cgi?archive=0;dist=unstable;ordering=normal;repeatmerged=0;src=php7.3

A mimochodem CVE-2020-7070 bylo v upstreamu opravené v říjnu: https://www.php.net/ChangeLog-7.php#7.3.23, tak to nepřehánějte...

máš pravdu, CVE-2020-7070 jsem řešil někdy na konci jara, bylo na něj asi embargo, nedávno jsem na něj znovu narazil, že v debianu ještě není plně vyřešený.

Podle trackeru se čeká na další verze v upstreamu https://security-tracker.debian.org/tracker/CVE-2020-7070

Zrovna volit jako ukázku php nebyl dobrý nápad, to je zrovna balíček, který je v debianu aktivně spravovaný, díky že jsi to upřesnil.

Dovody by tu boli, napriklad SELinux, priznam sa ale ze neviem v akom stadiu je APP Armor a ci je to plnohodnotny ekvivalent.

Vyhody Debianu budu pravdepodobne plnohodnotny SystemD (v RHEL bol explicitne odstraneny systemd-networkd, atd) a BTRFS.

App Armor má daleko nižší granularitu toho na co se dají dělat pravidla. V SELinuxu to lze až na systémová volání. Tzn. jde s tím udělat víc, na druhou stranu daní za to je celková složitost pravidel a správy.

Ono to u SELinuxu vede k nešvaru, že admin pravidla moc nepromýšlí, ale povolí vše, o co si to řekne. Nikde jsem neviděl žádnou rešerši, co v praxi slouží lépe. SELinux je určitě vyspělejší, ale pokud ho málokdo používá, tak je možná méně k užitku, než AppArmor.

A nebude pak mozne stejne udelat to, co predtim CentOS, proste zkompilovat balicky ? Tzn. vytvorit dalsi CentOS ?

Tohle mi připadá jako hodně špatná zpráva. Hlavní výhoda CentOSu byla v tom, že umožňoval vyvíjet a testovat aplikace pro RHEL, a zárověn používat RHEL balíky třetích stran, aniž by člověk (jednotlivec, komunita atd) musel platit za drahý RHEL.

Zároveň řada výrobců enterprise sw podporovala svoje řešení i na CentOSu. RedHat na tom bude patrně finančně profitovat.

A ne úplně enterprise výrobci ho nezřídka i vyloženě doporučovali.

Např ABRA:
"Pro účely tohoto návodu byla vybrána distribuce CentOS. Na této distribuci taktéž probíhá testování každé nové verze SW ABRA. Pokud tedy zvolíte tuto distribuci, lze předpokládat nejvyšší kompatibilitu."

U nas je to opacne: (ne zrovna levnej) RHEL bezi na ~10 serverech pro vlastni vyvoj (i kvuli technicke podpore) a na tech zbyvajicich ~80 bezi pak CentOS. Tak sem zvedavej, co s tim ted udelaji, protoze korporat nema zrovna v oblibe nake experimentovani, pokud jde o OS pro servery...

Co s tím udělá Red Hat? Asi nic. Podle mě teď Red Hat a celé IBM cílí hlavně na hybridní cloudy a RHEL je teď podle mě pro ně jen podvozek pod OpenStack a hlavně pod OpenShift.

prave ze po OpenShift se hlavne pouziva CoreOS.
A tuto kombinaci RedHat tlaci co to jde..

Na vývoj aplikací pro RHEL můžete využít Developer Subscription, které je zdarma, vizte https://developers.redhat.com/blog/2016/03/31/no-cost-rhel-developer-subscription-now-available/

Na jaře pak podle Red Hatu budou ohlášeny další způsoby, jak získat RHEL zdarma nebo za velmi malé peníze.

Tohle, ale není typické nasazení CentOS. Celá myšlenka CentOS byla mít kvalitní stabilní systém s dlouhodobou podporu "zadarmo". A tak se také v drtivé většině instalací používá.

Ano ohlásí to až na jaře podle odezvy v komunitě.Je vidět, že nečekli moc pěknou odezvu.

Ufff... Ještěže jsem tak línej a zatím jsem zůstaval na CentOS 7. Holt asi pak na EOL zmigruji zpět na Ubuntu.

Zachovejte klid. Článek je trošinku zavádějící, pokusím se to vysvětlit.

Za prvé, nové funkce se přidávají do RHELu už léta. Platí pravidlo, že pokud nějaká novinka nerozbije stávající funkčnost, může se do RHELu přidat a děje se tak poměrně často (např. v 8.1 to byl eBPF). Některé kanály (například optional nebo desktop) dokonce podléhají tzv. "rebase" - nová verze programu (např. chrony, tuned v 8.1, nástroj pcp v 8.3 atd). Dokonce se některá funkčnost může odebrat, pakliže se jedná o Tech Preview (brtfs). Podle mého názoru je "zatímco RHEL v desetinkových verzích opravuje jen bezpečnostní a kritické technické chyby" nepřesné tvrzení stejně jako "Budou v něm tedy průběžně přibývat funkce a mohou se i měnit verze komponent" (tučně). Už se tak děje léta. Ano, většina věcí jsou opravy chyb ale nová funkcionalita se přidává, a to i do linuxového jádra. Pokud však dojde k jakékoli regresi, je to bug a musí se to opravit. A tohle se prosím v CentOS Stream nemění.

Za druhé, není to tak, že by se z CentOS Streamu stala Fedora. Ve článku je sice poznamenáno že CentOS Stream bude někde mezi Fedorou a RHELem, ale pak je uvedeno že se jedná o "testovací platforma". To je zavádějící, CentOS Stream bude daleko blíže RHELu a hodně vzdálen Fedoře. V odkazovaných materiálech je doslova napsáno že CentOS Stream "nebude BETA testovací" platformou RHELu. Jedná se spíše o upravu workflow, toho jak vývojáři pracují, než že by to výrazně pocítil uživatel. Když se opraví chyba, nejprve to bude provedeno v CentOS Stream, a teprve pak to zamíří do RHELu. Ale to neznamená, že se CentOS Stream "rozkope" do stavu kdy bude nepoužitelný. Chyby a vlastnosti, které jsou předmětem prací, jsou velmi pečlivě zvažovány a vybírány, a to se nemění.

A za třetí, ve článku není uvedena důležitá poznámka z Red Hat blogu (*): firma v první polovině příštího roku nabídne nový program předplatného (levněji nebo zdarma) pro open-source projekty a komunity. To by mohl být velmi zajímavý program vzhledem k tomu že doba podpory RHELu vždy byla a je delší než u CentOSu který dodržoval jen základní pětiletý cyklus: https://access.redhat.com/support/policy/updates/errata

Proto radím, nepanikařte, počkejte a vyzkoušejte si to. CentOS byla, je a bude kvalitní distribuce nejen pro server a nemyslím si že by tomu mělo být jinak.

(*) https://www.redhat.com/en/blog/centos-stream-building-innovative-future-enterprise-linux

Stále ale podle mě platí, že CentOS ztratí hlavní výhodu - kompatibilitu s RHEL. Ano, jasně, když vyvýjím pro RHEL, mám testovat na RHELu, ale nějak se zapomíná na komunitu okolo CentOS. Častokrát jsem spíše našel "How to do X in CentOS" než "How to do X in RHEL".

K tomu, že CentOS Stream nemá být Betou RHELu. Co tedy je když je před nejbližším patchem RHELu a pak je z něj RHEL? CentOS Stream se podlě mě stal tím, čemu se dlouhá léta šklebili posměváčci u Fedory :/ Uvidíme, jak se to vyvine...

Kompatibilita s RHELem se nijak neztrácí, alespoň pokud je myšlena binární kompatibilita.

> Častokrát jsem spíše našel "How to do X in CentOS" než "How to do X in RHEL".

Ano, protože obrovské množství obsahu je za "paywallem" access.redhat.com. Dá se tam ale dostat zřízením vývojářského účtu, který je (už dnes) zcela zdarma.

Ale no tak, vážně myslíte že nasrat komunitu je dobrej nápad? Chápu že lidi z RHELu budou tvrdit něco jiného než z těch zpráv vyplívá. Neb koho chleba jíš toho píseň zpívej.

Nás čekal přechod z centos 7/Rhel7 na osmičkové verze, Po těchto šílenostech se nejspíš začne řešit přechod na suse. Centos u nás slouží jako QA/UAT prostředí a na produkci která není kritycká. Jinak je na prod RHEL.. Tahle šílenost prostě dřív nebo později tohle celé rozkopne.

Takže to co se z toho IBM snaží vytřískat ( víc peněz z subscription), bude spíš kontra produktivní.

RHEL 8 jako první v historii obsahuje podporovaný upgrade (7->8), jsou tam omezení, ale žádná jiná verze to neměla zdokumentované a otestované. Dost dobře nechápu, co se snažíte říct. Každý major upgrade je bolestivý, co si budeme nalhávat, spíš bych doporučil reinstalaci a naplánování deploymentů tak, aby se maximáně využila dlouhá doba podpory.

Ano, pracuju pro Red Hat, ale to neznamená že moje názory nejsou objektivní. Kde přesně se dopouštím nějakých nepřesností? Já osobně vnímám změnu modelu k lepšímu protože většina mých CentOS serverů jsou testovací nebo nekritické instance, ale chápu že někomu může lépe vyhovovat starý model kdy CentOS vychází dlouhou dobu po RHELu, tím může být vnímán jako stabilnější.

K tomu "nasrat komunitu" asi není co říct, každá změna někoho asi "nasere". Jen jsem pár věcí upřesnil, každý ať si z toho vybere co chce.

"zatímco RHEL v desetinkových verzích opravuje jen bezpečnostní a kritické technické chyby"

Tímto jsou, myslím, myšleny opravy v rámci desetinkových verzí, tedy v z-streamu a tam se opravdu opravují jen zásadní a bezpečnostní chyby. Funkce se nepřidávají, verze se nemění. V rámci desetinkové verze tak má zákazník velmi stabilní a předvídatelný systém.

Mezi desetinkovými verzemi můžou být větší změny, přidávání nových funkcí, rebasy celých komponent.

CentOS má AFAIK Y-stream (změny mezi desetinkovými verzemi) a Z-stream spojený do jednoho aktualizačního streamu, takže jak vyjde nová desetinková verze RHELu a CentOS ty změny převezme, dostanou je uživatelé CentOSu automaticky v aktualizacích, takže ten velmi stabilní a předvídatelný systém mají jen po dobu mezi desetinkovými verzemi (6-9 měsíců), zatímco zákazníci jej můžou mít i několik let (desetinkové verze jsou podporované paralelně), nicméně v CentOS Streamu jim tam ty změny můžou přistávat kdykoliv, ne v těchto cyklech, což si myslím, že může být dokonce výhoda na desktopu (rychlejší přístup k novým ovladačům), ale chápu, že admini kritických serverů jsou při té představě nervózní.

Souhlasím, že je asi brzo dělat nějaké závěry. "Rolling release" hodně lidí vyděsí, protože si pod ním představí věcí jako Rawhide, ale CentOS Stream bude hodně testovaný a s malou deltou oproti stabilními RHELu. Navíc CentOS už je svým způsobem rolling release teď tím spojením Y a Z streamu, jen ty změny byly dávkované.

> desetinkových

Ano, máš pravdu že fakticky to má Petr napsané správně, ale já bych si dovolil to rozvést protože to není tak černobílé:

U RHELu se lze pro určité verze přihlásit ke streamu kde dojde ke "zmrazení", například je to 8.2. Mělo to různá marketingová jména a dneska se to tuším jmenuje EUS a SAP updates, ale technicky jde o to, že už mi půjdou delší dobu 8.2.z updaty takže bude celkově méně upgradů po dobu živostnosti serveru, což se hodí na drahé deploymenty kde upgrade něco stojí.

Toto CentOS nikdy neměl, bylo by to pro komunitu moc pracné. Takže ačkoli je tvrzení fakticky správně, uživatel CentOS se daných rebasů dočkal vždy (pakliže nevypnul updaty).

> CentOS má AFAIK Y-stream

Aha tak tady to přesně popisuješ. Jo, tohle jsem chtěl říct.

> "Rolling release" hodně lidí vyděsí

Souhlasím že tohle je marketingově trošku nezvládnuté. Pod tím pojmem si mnoho lidí představí Gentoo nebo Arch. A to je prosím naprosto jiná káva, živě si pamatuju rozbitý produkční emailový server na Gentoo který jsem po drobném upgrade opravoval týden. :-)

Možná tady lidi uklidňujete, ale ten způsob, jakým to bylo vyhlášeno v https://centos.org/distro-faq/ je jeden velký prostředníček ukázaný směrem k uživatelům, vývojářům i dobrovolníkům, cituji:

Q8: I need to build/test my packages for EPEL locally which I used CentOS for. CentOS Stream will have different ABI/API at times so my builds won’t work with that.
A: EPEL is part of the Fedora Project. We know they are looking into the cases where this happens and are working on a solution. Initial testing showed that only a few packages are affected. We encourage you to get involved there. The CentOS Project cannot and does not speak for Fedora: We encourage you to engage with the EPEL community instead.

(Přeloženo z korporátštiny: Je nám to jedno...)

Q9. EPEL 8 needs access to packages which are not shipped by RHEL but were made available by CentOS. How is this going to be solved?
A: EPEL is part of the Fedora Project. We know they are looking into the cases where this happens and are working on a solution. Initial testing showed that only a few packages are affected. We encourage you to get involved there.The CentOS Project cannot and does not speak for Fedora: you should instead engage with the EPEL community.

(Přeloženo z korporátštiny: Fakt je nám to jedno...)

Q12: I used CentOS for CI because I could not use RHEL developer licenses for this. CentOS Stream is aimed at the next generation when I need the last/current one. What is my alternative?
A: Red Hat is aware of these concerns and we encourage you to talk to them. If you’re testing for RHEL, RHEL is the best operating system to use. We also think that CentOS Stream has a place in your CI testing to help you be ready for the next RHEL.

(Přeloženo z korporátštiny: Kupte si RHEL...)

Q14: Can the CentOS community continue to develop/rebuild CentOS linux?
A: We will not be putting hardware, resources, or asking for volunteers to work towards that effort, nor will we allow the CentOS brand to be used for such a project, as we feel that it dilutes what we are trying to do with the refocus on CentOS Stream. That said, the code is open source and we wouldn’t try to stop anyone from choosing to use it or build their own packages from the code.

(Přeloženo z korporátštiny: Víš, co Sašo...)

Možná to nebude tak horké, jak to vypadá, ale ten způsob, jaký to bylo ohlášeno má teplotu zemského jádra.

Ano, způsob komunikace dost nešťastný. Což je škoda, protože z technického pohledu běžného uživatele CentOSu se v podstatě mění jen kadence aktualizací, což se dá řešit.

kadence aktualizací skončí freezem repa, takže se tím zvedne okno před opravou CVE. Jak to bude vypadat v praxi se uvidí, z prvotních informací spíše přemýšlím o přechodu než riskování jak se bude Stream chovat při aktualizacích.

Red Hat nasedl očividně na vlnu SaaS a poskytovat SW na on-premise není už jeho gró.

Pokud to dobře chápu, tak bezpečnostní chyby budou opravovány v normálním režimu, pokud není embargo. A drtivá většina CVE jsou normálně zveřejněné, nejedná se o tak závažné problémy (ale přesto by měly být trackovány a opraveny). Tudíž si troufám tvrdit, že tím že vývojáři Red Hatu dají opravy nejdřív do CentOSu a pak do RHELu se tím okno naopak průměrně zkrátí.

Stream lze zkoušet už dnes, byl představen před nedávnem: https://www.centos.org/centos-stream/ ale uvidíme jak budou nastaveny ty procesy.

Já bych to rozhodně tak horké neviděl. Ano, CentOS Stream bude obsahovat nějaké změny a nebudou jenom jednou za půl roku nebo rok. A to je tak asi celý rozdíl.

CentOS Stream bude obsahovat změny o něco dřív. Red Hat si je nebude schovávat pod pokličkou půl roku, ale budou uvolněny, jakmile na nich proběhne testování a vypadají ok. Ano, výjimečně bude možné, že se mezitím najde chyba, která se opraví dřív, než přistane v RHELu. Prakticky takových chyb má být minimum a cílem je zlepšit existující testování, aby nastávaly minimálně. Jedním z cílů je umožnit komunitě i zlepšení testování.

Jinak na CI se pořád dá Steam použít úplně v pohodě. Pokud to máte pro vlastní produkty, můžete být díky tomu připravení na nový RHEL, ještě, než vyjde. Navíc můžete jako komunita ne jenom kafrat, ale taky přispět do budoucího obrazu RHEL. Až to Red Hat vydá, je na diskuzi obvykle pozdě.

A EPEL prostě není RHEL. To znamená, že buď to má být v RHELu, nebo EPELu. To, že to není v RHEL ale je to v CentOS je speciální případ. Které se mají vyřešit systémově a přesunout buď do jednoho nebo do druhého. Určitě to neznamená polibte si šoš.

RHEL má jenom minimum balíků, které mění API. Neprovozuji to v produkci, ale mělo by vcelku jednoduše aktualizovat jenom security updaty, bez obyčejných bugfixů. Ano, jsou vyjímky, jednou je třeba bind9, kde ABI kompatibilita není garantována. Není jich moc.

Teplotu jádra mají často komentáře, které ne úplně správně chápou, jak to vlastně má být. Uznávám, ti, kdo chtěli přesnou kopii enterprise linuxu zdarma se cítí podvedeni. Vzhledem k tomu, že nenabízeli ani zpětnou vazbu ani peníze, asi se dají oželet.

Teď se hodně změn a nových featurů pozná z release notes u desetinkových verzí CentOS, jak chápu tak CentOS Stream nebude mít žádné release notes, takže zmizí jeden z dobrý zdrojů na co si dát pozor.

> Jinak na CI se pořád dá Steam použít úplně v pohodě.

Jsou tam jisté aspekty, které je třeba vyřešit. Například SELinux a kompilace balíků s politikami, což je problém který bude několik projektů muset řešit včetně toho našeho. Ale nic s čím bychom si neporadili.

> RHEL má jenom minimum balíků, které mění API. Neprovozuji to v produkci, ale mělo by vcelku jednoduše aktualizovat jenom security updaty, bez obyčejných bugfixů.

Nesouhlasím s "celkem jednoduše", CentOS erraty nezveřejňuje jako yum metadata. Ale s nějakým extra úsilím to jde.

> Teplotu jádra mají často komentáře...

Ondra má pravdu. Já bych to zbytečně nerozdmýchával, jakkoli můžeme chápat určité souvislosti a dobrý úmysl které nejsou veřejné, celkový obraz té zprávy, blogpostu a FAQ dokumentu je aktuálně špatný. Lze jen doufat, že to zodpovědní lidé upřesní a doplní další informace.

Stale je tu moznost komunitne spravit napr DarkHat a ist povodnou cestou. Ci? Tak zacinal aj CentOS. Uvidi sa , kto prezije.

Myslíte, že to bude mít i nějaký negativní dopad na Citrix Hypervisor ?

Takze z pouzivatelov CentOS sa stanu pokusni kralici Redhatu.

A hej tymto sa stratia vyhody, pre co sa CentOS pouziva a to stabilita aktualizacii.

...a pritom pro tu funkci "pokusneho kralika" tady uz je Fedora!

Tvl. Bezte uz s tema pokusnejma kralikama k sipku. To ze Fedora bere projekty rychlejc, nez ostatni, neznamena, ze jsme pokusni kralici.

Fedora ma vlastni QA testing. Samozrejme, ze se bugy objevuji, ale to je proste dan za to, ze pouzivame nejaktulnejsi software ze vsech std. distribuci.

Jinak jde o prekvapive stabilni platformu, s funkcnimi upgrady, notnou davkou inovativnich technologii a hlavne vsechny baliky v repozitari jsou aktivne udrzovane. Kdo muze tuhle rict?

Ja osobne neviem o nikom kto by prevadzkoval Fedoru na serveroch. Ako desktop distribucia je super, sam som ju roky pouzival, ale v enterprise sfere sa neda fungovat so systemom ktory ma bleeding edge verzie software v repozitaroch.

Z hladiska ludi ktori potrebuju mat prakticky nemenny system s bezpecnostnymi aktualizaciami a podporou tak 5-10 rokov je Fedora system pre "pokusne kraliky" rovnako ako akakolvek distribucia zamerana primarne na bleeding edge desktop.

To neznamena, ze je nieco zle s Fedorou, len je to uplne iny use case.

Inovativní ano, na druhou stranu neumí základní věci.
Jinak je to jen PR.

Ne, cílem je umožnit komunitě podílet se na budoucí verzi. Stream bude pořád obsahovat aktualizace, které prošly testováním. Pořád budou vcelku minimální, konzervativní.

CentOS se používá jako bezplatná verze RHELu. To zůstane. Jen se změní to, že to bude bezplatná verze nastávajícího RHELu namísto posledního RHELu. Pokud stabilitou chápete to, že častěji přijdou aktualizace, máte pravdu. Mám za to, že možnost neaktualizovat nové balíky zůstane, tak proč ta hysterie? Protože se změní výchozí konfigurace?

CentOS ... přestane být vhodný pro nasazení na serverech

Tohle je přehnané tvrzení, které si autor článku mohl odpustit.

Autor článku to má od lidí z Red Hatu, se kterými se o tom dost dlouho bavil. Navíc systém s proměnlivými verzemi skutečně nechcete používat na serveru. Jako problém to vidí i původní zakladatel CentOSu a už oznámil novou distribuci Rocky Linux.

Tak, tak. Co jiného také může Red Hat tvrdit, když hlavní motivací je "podojit" stávající uživatele CentOS, přechodem na RHEL.

Doufám, že to Greg jako před lety opět dotáhne a vytvoří klon a hlavně komunitu, která si bude pamatovat tohle Red Hatí bodnutí do zad.

O jaké komunitě to mluvíte? Co přesně tahle "komunita" nabízí? Myslíte stažení přesné kopie RHELu za nic?

Cílem není podojit uživatele, ale dát možnost komunitě účastnit se přípravy budoucího RHELu. Tedy nejen vzdálené Fedory, která se od RHELu liší celkem dost. Ano, vyčůránkům, co chtěli enterprise kvalitu za komunitní (rozumněj žádnou) podporu, to trochu kazí plány.

"Komunita" kolem Centosu nabízela prave Centos - ditribuci odvozenou od RHELu, která dávala možnost lidem a firmám co neměli na to platit za RHEL využívat systém bez podpory na své riziko. To že každý člen komunity přispíval jiným dílem, snad nemá cenu rozepisovat. A to jak fungovala synergie Centosu a RHELu take ne, to zde už udělali jiní a lépe

Co je a není cílem se uvidí.

Myslím si, že vetšina lidi z puvodní komunity Centosu o možnost
"účastnit se přípravy RHLEU" nestála, alespoň u mě osobně to tak třeba bylo. Na druhou stranu to třeba pro mě byla část motivace proč jít později pracovat pro Redhat.

> "Ano, vyčůránkům, co chtěli enterprise kvalitu za komunitní (rozumněj žádnou) podporu, to trochu kazí plány."

Tohle mi přijde jako zbytečné. Ano, lidem co Centos použivali kvuli tomu na čem stavěl, to kazí plány. Proč je ale nazýváte takto ? Protože neplatili za RHEL pokud jim stačil Centos ?

PS: Pro RedHat jsem pracoval 5 let, uz dva roky tam nejsem
PPS: Pokud pracujete pro RH, tak by to bylo dobré připsat do Vašeho příspěvku. Ale třeba se mýlím a nepracujete ...

Ne že by v tom co píšete, nebylo kousek pravdy, ale také je ve vašem příspěvku mnoho nepravdy. Zákazníci, kteří platí nemalé peníze za OpenStack, OpenShift, a vůbec celá infra je RHEL, a další RH produktech, také používají CentOS, a to docela dost, a právě kvůli testingu, vývoji, ale jistě také kvůli tomu, aby leckde ušetřili.

Tito zákazníci jsou jednak velmi dobré dojné krávy ale hlavně velkou referencí pro RH. Navíc jsou to zákazníci, kteří mají skill si ty RH produkty nějak naimplementovat a naintegrovat samostatně, jelikož RH nemá moc power & knowledge to do so. Ještě s RH podporou, kdy napíšu ticket, čekám, dostanu odpověď, odepíšu, změní se směna, vysvětluji vše znova i když je to popsáno výše.

No a nazývat tyto zákazníky vyčůránky, nebo nedat těmto zákazníkům vědět s předstihem o takovýchto změnách, není moc fér.

Takze neco vytvori z korporatu, korporat to od nej koupi, za par let potopi a jeho "resenim" je zacit tu samou cestu s tim samym korporatem?

Tomu rikam zlepseni se a pouceni se z historie :-D

Skvele, ze ten clovek (Gregory Kurtzer) zalozil Rocky Linux. Za rok me to zacne zajimat, to uz jen strhnu z vika notebooku nalepky co souvisi s RH, a doufam nejak hladce prejdu na tento OS.

A je tedy pro "vhodnost nasazení na serveru" důležitější:

1) konzervativní přijímání nových verzí balíčků
2) aby to nebyl rolling-release

...?

Ad 1), pokud to chápu správně, CentOS Stream bude pořád konzervativnější než třeba Ubuntu Server, ne?

Ad 2), třeba se časy mění, podívejte se na takové Windows :) (chápu, že Win pro desktop je něco jiného než Linux pro server...)

Je otázkou, jestli byl CentOS vůbec někdy vhodný pro nasazení na serverech. Přeci jen updaty jsou opožděné za RHELem, což může znamenat delší čekání na opravy bezpečnostních chyb.

Pro superpočítače se hodil. Superpočítače jsou za přístupovými servery, takže rychlost aktualizací tam není tak kritická jako u serverů připojených přímo na internet. Na současných TOP 500 má CenOS asi 20% - zdaleka nejvíc z linuxových distribucí (https://www.top500.org/statistics/list/).

Jak přesně na superpočítačích vadí CentOS Stream 8? Do aktualizací vás nikdo nenutí, že ne?

Navíc jádro distribuce je mezi minor updaty poměrně stabilní. Nic ze systémových knihoven nebude měnit API, stejně jako dosud. Když zpomalíte updaty, dostanete v podstatě původní CentOS 8.

ve většina případů se kritické zranitelnosti stejně opravují ad-hoc barigádou a až poté se záplatuje OS, málokdy je potřeba promptně dělat fix na OS.

Při používání minimální instalace jako základ pro javu těch balíčků zase tolik v OS není, takže ani CVE nejsou tak moc častá, aby to někomu přílši vadilo a zvyšovalo náklady.

Myslim ze bezny setup je CentOS na dev prostredi a RHEL na prod prostredi a pripada mi ze prave touto zmenou se development bude moct hezky pripravit na to co prijde do RHELu i kdyz zmeny jsou typicky male (ale ano, zalezi na perspektive). BTW vyslo FAQ:

https://www.redhat.com/en/blog/faq-centos-stream-updates

(Ano, jsem zamestnanec Red Hat-u a CentOS pouzivam na jednom hobby serveru ktery se ma tvarit jako produkcni)

Tohle je možná běžný přístup ve větších korporátech. Ve středních a malých firmách a hlavně v komunitě je CentOS i na produkčních serverch.

9. 12. 2020, 12:17 editováno autorem komentáře

i v těch korporátech je na produkčních serverech velice často. S nasazování dockerů, kubernetes a virtualizace RHEL nenabízí moc východisku a jen ti hodně velcí mají neomezené subscriptions.

Podle mne je to krok správným směrem. To zpoždění CentOSu mne na něm vždy odrazovalo.

Moc nechápu vyjádření jako „kudla do zad od RedHatu“. Pokud někdo bral CentOS jako „aktualizovaný RHEL, ale nemusím nic platit“, připadá mi takové jednání nefér od toho uživatele, ne od RedHatu. Pokud někdo požaduje stabilní RHEL, měl by ten požadavek vyjádřit penězi.

Pro ty koho to odrazovalo tu byl RHEL.

Jaké nefér jednání? Přesně kvůli tomu CentoOS vzniknul. Red Hat vydělavá na údržbě cizího kódu a díky svobodným licencím musí ten kód dávat zpět. Bez cizího kódu by Red Hat nebyl. Navíc komunita ten kód neustále vylepšuje s polu s Red Hatem.

Jaké nefér jednání? Přesně kvůli tomu CentoOS vzniknul.
To neříká nic o tom, zda to je nebo není v pořádku.

Red Hat vydělavá na údržbě cizího kódu a díky svobodným licencím musí ten kód dávat zpět. Bez cizího kódu by Red Hat nebyl. Navíc komunita ten kód neustále vylepšuje s polu s Red Hatem.
Na tom se přece nic nemění.

Jaké nefér jednání? Přesně kvůli tomu CentoOS vzniknul.
To neříká nic o tom, zda to je nebo není v pořádku.

Pokud vedete takovou úvahu, tak se musíte zamyslet i nad tím, z čeho RHEL vyšel - tedy ze spousty GPL'ed projektů. Imperativem GPL je, že přijmete cizí úsilí a světu to vrátíte formou výsledků Vaší práce.

Samozřejmě pak budeme hledat, kde je hranice mezi samotným softwarem, který je pod GPL, a kde už leží přidaná hodnota služeb RH (kterých se GPL netýká). Dlouho to fungovalo k všestranné spokojenosti. Nyní je s tím RH očividně už nespokojený, a tak dělá změny.

Fajn, CentOS se změní. Nic ale nebrání nikomu dalšímu vyvinout stejné úsilí a poskytnout to, co dříve CentOS. Nebude na tom nic nemorálního, bude to zase přesně v duchu GPL.

Je taky možné, že RH začne dělat obstrukce, odklánět vývoj a doplňovat RHEL o non-GPL části (těžko říct, jestli se jim vyplatí připravit se o široké publikum), nebo svoje úpravy zveřejňovat se zpožděním (což by byl postup chytré horákyně, ohýbání smyslu GPL).

Jakkoliv GPL nemám rád (je omezující tam, kde je to zbytečné a bezzubá tam, kde by bylo potřeba se bránit), rozhodně není nic nemorálního na původní podobě CentOS, ani na očekávání uživatelů, že nenastane takováto změna uprostřed životního cyklu.

Nemorální je to, že Red Hat ovládl komunitní projekt a pak ho úplně otočil. Tohle je ta sviňárna nejvyššího kalibru.

Vlamujete se do otevřených dveří. Na to, co RHEL dává zpět komunitě, se přece nic nemění. Mění se něco jiného. Doteď spousta lidí používala CentOS jako „kvalita RHELu, ale zadarmo“ – a mají bůhvíproč pocit, že něco takového mají nárok. A teď se (opět bůhvíproč) domnívají, že už nebudou dostávat tu nejvyšší kvalitu (a za tu kvalitu si přeci pl…, no vlastně neplatí).

Red Hat vydělavá na údržbě cizího kódu a díky svobodným licencím musí ten kód dávat zpět. Bez cizího kódu by Red Hat nebyl. Navíc komunita ten kód neustále vylepšuje s polu s Red Hatem.
Na tom se přece nic nemění.

Tvrdil někdo opak?

Tvrdil někdo opak?
Nevím. Právě mne zajímalo, jestli mělo nějaký smysl zjevné tvrzení, se kterým všichni souhlasí a které nevyvrací nic z dříve uvedeného. Ten komentář totiž vypadal skoro jako polemika.

A co třeba takový menší dedikovaný server pro klienty, kterým dělám www stránky a taktak si vydělá na měsíční provoz, který činí cca 4 000 Kč, když RHEL stojí kolem 20 000 Kč?

Na ten dáte CentOS Stream. Podle mne bude na takový server vhodnější, než CentOS.

Podle mne bude na takový server vhodnější, než CentOS.

Z čeho vycházíte?

Vycházím z toho, že bude častěji dostávat nejnovější aktualizace. Představa, že serverová distribuce má být velmi konzervativní, je podle mne přežitek, který způsobuje víc problémů, než kolik jich řeší. Všimněte si, že první argument, proč používat konetjnery, obvykle zní – můžete používat jaké verze knihoven a závislostí chcete, můžete používat ty verze, které máte ve vývoji. Což jiným slovy znamená – nemusíte čekat, až se potřebná verze konečně dostane do vaší distribuce.

A jinak většina uživatelů nepožaduje stabilní RHEL, ale CentOS. Což bylo přesně to co 15 let fungovalo, než Red Hat ovládl CentOS a otočil kolem ve svůj prospěch.

To je právě ono. Něco požadují, ale nenabízí nic za to. Nemůžete požadovat aby vám někdo dal něco zadarmo. Můžete o to akorát tak slušně poprosit, a když to nedostanete, můžete akorát poděkovat a jít dál. A nebo k tomu požadavku něco přihodíte, obvykle nějaké peníze. To je pak jiná.

Ale Redhat z toho niečo mal. Mindshare. Kopec ľudí, ktorí boli oboznámení s jeho systémom, pretože si ho mohli rozbehať "u seba" a prípadný zamestnávateľ ich už nemusel školiť. Kopec vypublikovaného know-how a how-to.

Toto všetko skončí. Aj pre tých, ktorí za RHEL platia priamo, sa prevádzka RHEL stane drahšou.

"Ale Redhat z toho niečo mal. Mindshare. Kopec ľudí, ktorí boli oboznámení s jeho systémom, pretože si ho mohli rozbehať "u seba" a prípadný zamestnávateľ ich už nemusel školiť. Kopec vypublikovaného know-how a how-to."

Co z tohoto nepůjde na CentOS Stream?

Nic z toho nekončí. Proč by si někdo nemohl u sebe rozběhnout CentOS Stream?

Ne to právě není ono. Kdyby se do toho Red Hat nevrtal, tak to funguje do teď a s novým klonem nejspíš bude dál. Tohle je jednostraná akce prospěšná pouze Red Hatu, komunita co používala CentOS z toho nic nemá.

Naprostá pravda, ale taky by se měl každý snažit dostát svým závazkům. Bylo by stejně slušné, kdyby CentOS nejprve dojel aktuální verze v původním režimu. Samozřejmě to nedělají, protože při čekání na v9 by se dost lidí připravilo na přechod z CentOS na něco nového. Takhle to nadávkují někam doprostřed osmičky a přesvědčí (ochočí) uživatele, že to je správná cesta.

Myslím, že to tak hrozné stejně nebude. Pokud to udělají s rozmyslem, tak minimálně z počátku budou proti RHEL jen o krůček napřed. Taky není vůbec vyloučené, že část této strategie později nepřevezme i RHEL.

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/

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.

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.

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.

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/

Král je mrtvev, ať žije Debian? Neee, dělám si legraci. Zkusím tedy CentOS Stream.

A co používáš? Něco půlročního? Nebo úplně rolling? (tam je pak v Debianu unstable)

Ale ten se vydává (vydával) ještě méně často než Debian. Nebo máš nové verze určitých aplikací ze speciálních repozitářů?

Aby todle hádání co provedlo RED neskočilo emigrací na Ubuntu, Archu nebo nedej bože SUSE.
To jsou jediná distra kam RED nešlápne nohou....

Tohle vypadá jako hezká příležitost pro openSUSE Leap, který bude od verze 15.3 mnohem blíže SLE, takže ještě více nabídne poptávanou stabilitu a dlouhodobou podporu. Děkujeme kolegům z RedHatu. :-)

No, nejsem si jistý, jestli oslovíte ty, kteří budou od CentOSu utíkat, protože už to není identická kopie komerční distribuce, něčím, co také není identická kopie komerční distribuce.

Ta idea CtLG (Closing the Leap Gap) je právě taková, že balíčky, které jsou ve SLE i Leapu, budou binárně identické (možná až na velmi málo výjimek). Prostě idea cílového stavu - a je snaha to tak mít už ve SLE15-SP3 a Leap 15.3 - je taková, že Leap bude z hlediska balíčků nadmnožina SLESu.

Ještě je tu https://www.abclinuxu.cz/zpravicky/konec-centosu-jak-jej-zname-dnes#60

Petice [EN]: https://www.change.org/p/centos-governing-board-do-not-destroy-centos-by-using-it-as-a-rhel-upstream

Tak já nebudu provokovat. :-) Je pravda, že openSUSE Leap (ani od brzké 15.3) není totéž, co CentoOS, tedy prakticky klon stávající superstabilní komerční distribuce. Leap je o maličký krok napřed, ale troufl bych si tvrdit, že Leap je aktálně nejblíže tomu, po čem touží uživatelé CentoSu. Leap 15.2 už je velmi blízko SLE 15 SP 2 a Leap 15.3 bude (minimálně v nejdůležitějších komponentech) totéž, co SLE 15 SP3, tak co víc si přát?

Já tím samozřejmě nehaním cestu CentoSu, jen upozorňuji, že tu je velmi dobrá a technicky pokročilá alternativa.

To zní jako úplně přesný popis CentOS Stream. Tedy je vidět, že SuSE došlo na velmi podobný princip jako konkurecne, tedy na tom asi něco bude. :)

Ta změna v openSUSE je ještě v procesu, ale openSUSE Leap 15.3 by měl mít stejné jádro a další důležité součásti jako SLE 15 SP 3. openSUSE má víc balíků, takže identické to nebude, ale podstatné součásti identické budou. Takže to dost možná bude lepší alternativa, než Centos Stream. :-)

Aneb jak se uprostřed týdne zdravě naštvat.

Jak už tady někdo psal, je to zdvihnutý prostředníček těm kdo CentOS používali v produkci. Nic proti rolling-release, ale to není zrovna vhodný na server. Na desktopu pokud mi to něco rozbije tak si to snadno opravím. Na serveru pokud se mi změní formát konfiguráku nějaké služby, tak to může být sakra průšvih.

Pro mě je to už druhý zdvihnutý prostředníček v řadě. Prvním bylo absolutní odstranění BtrFS z CentOS 8 a RHEL 8. A to bez toho, aby v době jeho odstranění měli plnohodnotnou náhradu. Stejné provedli teď - zařízneme CentOS, změny v licencování RHEL budou na jaře. Teď co?

No slovy klasika: Podveď mě jednou hanba tobě, podveď mě podruhé hanba mě. Tak čas se poohlédnou jinde.

Máte někdo tip na RPM based distribuci s dlouhou podporou (jako byl CentOS)? Dost uvažuju o návratu k openSUSE, i když mají kratší cyklus.

Debian based distribuce bohužel nemůžu, nevyhovuje mi DEB a nástroje kolem něj. Nepotřebuju aby mi apt v rámci aktualizace vypnul daemona na dynamické routování a pak se mě na konzoli zeptal zda chci nahradit konfigurák. To už se mi několikrát na Debianu stalo a není příjemné zjišťovat jak se tam dostanu abych stisknul jednu klávesu. Taky není úplně fajn když balíček sám rozhoduje jestli se nainstaluje/ak­tualizuje/odin­staluje podle návratové hodnoty.

už před rokem jsme započali u jednoho klienta migraci na Oracle linux (také zdarma) a zatím plní co je potřeba, jestli to je dlouhodobý cíl, těžko říct, je to Oracle.

Roky jsem trochu pokoukaval po CentOSu, obcas jsem ho nekam i nainstaloval, na par serverech jsme ho meli nejaky cas i v produkci, ale ted uz ho nastesti dlouho nemame nikde - to jsem fakt rad, ze to ted nemusime resit. Vzdycky jsem ho bral jako kvalitni stabilni LTS distribuci, coz byla spolecne s faktem, ze jde o vyvojovou verzi RHELu, jeho velka prednost a clovek by kvuli tomu zamhouril snad i oci ze dosahuje horsich vysledku v testech rychlosti, v porovnani s jinymi distrubucemi. Tohle je ale odklon uplne jinam a taky nejak nevidim smysl v tom, aby nekdo upgradoval CentOS 8 na CentOS Stream. To uz je fakt lepsi prejit rovnou rads na Debian, (mozna) Ubuntu, a nebo treba na nejaky BSD. Ale treba to i tak bude v budoucnu zajimava distribuce... A nebo se (je to dost pravdepodobny) dockame nejakyho forku a CentOS bude pokracovat. Ale trochu bych se precijen bal... Uz jak vidim fotku prazskeho metra v te pouzite fotce :))

V Canonicalu museli oslavovat...

Gratuluju Redhatu.

Sam jsem do jedne windows only firmy na specifickou zalezitost protlacil 20 Centos8 serveru s tim, ze vyhledove se prejde na RHEL, pokud bude potreba podpora vyrobce. A pres steering komisi jsem to protlacil prave argumenty LTS podpory a kompatibility prechodu na RHEL

Ted jsem za curaka.

No nic, projekt je v pocatku, jeste je cas switchnout na Ubuntu LTS, coz take udelam.

Telefonicky jsem s projektakem probiral noty, co budem zitra na steeringu rikat.

S timhle tam pudem:
Chovani Redhatu je velice neprofesionalni, zkraceni deklarovane podpory Centos8 je krajne nezvykla zalezitost.
Takto se v minulosti Redhat nechoval, tato zmena je zrejme.zapricinena akvizici IBM.
Navrhneme zmenu backend OS na Ubuntu LTS pri zachovani vsech ostatnich parametru projektu.
Tato situace je velice neprijemna, lec v pripade IBM standardni, Redhat zrejme ceka obdobny osut jako Lotus, Rational, Netcool, tedy vyzrani existujicich accountu, stagnace zpusobena zmatenym ci zadnym vyvojem, pak vysumeni do voidu.

Ono to může mít i prostší příčiny. Součástí podmínek prodeje bývá podmínka pro výplatu sjednané ceny, že nepoklesnou výkony firmy (resp. že splní určité ukazatele). Je taky klidně možné, že potřebují aspoň pár klientů z CentOS dostat do RH. Je to už hodně divoká spekulace, ale možné je i toto. (Pak by ale na vině nebylo IBM.)

To už je hodně divoká spekulace. Podmínky prodeje jsou totiž známé (dostali je určitě všichni akcionáři a SEC).

Ano, to je mozne, ze potrebujou nahonit nejake kvartalni cisla.

Kazdopadne ze stredne a dlouhodobe perspektivy to bude IMHO pro RH ztrata.

Ja osobne budu ve svych navrzich se RH pokud mozno vyhybat, z prosteho duvodu ztraty duveryhodnosti firmy.
Zkratit dlouhodobe deklarovanou podporu na polovinu, to trumfne i legendarni svinstvo Microsoftu se zariznutim silverlightu.

Proti nasazeni Streamu pri zachovani Centos8 deklarovane podpory, bych nerekl ani krles.
Takhle me RH dostal do situace, ze po dvou mesicich behu projektu, ktery bude trvat rok a pul, se dozvidam, ze ve dvou tretinach projektu RH svevolne ukoncuje deklarovanou podporu.

Tohle proste ne.
U me RH skoncil.

Kazdopadne ze stredne a dlouhodobe perspektivy to bude IMHO pro RH ztrata.

Taky si myslím, že ztratí konverzní cestu CentOS => RHEL. Znám případy, přesně jak popisujete, že zákazník nejdříve rozjede CentOS, a až je potřeba (nebo až situace dovolí), kupuje RHEL.

Druhý případ je, že firma má několik serverů s RHEL a podružné s CentOS. Ani ne tak kvůli úspoře, ale protože se to spravuje pod jedním know how. Tam samozřejmě část klientů koupí RHEL (ale nebude jich moc), část se smíří s CentOS Stream a část přejde ke konkurenci (ale k jaké?). Ta poslední skupina je nejzrádnější - protože klienti přijdou na to, že ve světě linuxu existuje víc možností, než RHEL.

Ano, je to krátkozraké, taky si myslím.

10. 12. 2020, 22:08 editováno autorem komentáře

Motáte trochu hrušky s jabkama.

RH sice zařízne CentOS 8 (=RHEL), ale stále bude nabízet kompatibilní produkt CentOS Stream 8 (=RHEL+0.1). Vzhledem k tomu, že i minor verze jsou až na vyjímky kompatibilní, ten rozdíl bude minimální.

Pokud máte ve firmě 20 serverů na jedinou záležitost, nejste zase tak drobný provozovatel. Pokud vás tenhle relativně drobný rozdíl natolik odrazuje, máte vždy možnost si zaplatit RHEL, nebo být jinde.

Nikdo vám nedává nůž na krk a neruší celou službu. Jenom možná nebude přesně taková, jakou jste si přál. Berte nebo nechte být.

Jako zaměstnanec Red Hatu (ale už mnoho let v úplně jiném oddělení) mám soukromý názor asi takovýto:

To oznámení o konci CentOSu je tragické a měli ho napsat jinak. Ale kdybyste si prošel veřejné informace tak například zjistíte, že "Updates for the CentOS Stream 8 distribution continue through the full RHEL support phase." Takže na době podpory se nic nemění.

Celá ta změna je jen o tom, kdy se do CentOSu dostanou RHEL aktualizace. Jestli po RHELu, nebo před ním. Bude to stejný kód, projde stejným testovacím procesem a bude udržovaný stejně dlouhou dobu.

Mimochodem, už CentOS 8 model byl jiný než u RHELu. Nevydával desetinkové verze jako to dělá RHEL (narozdíl od CentOSu 7).

Navíc ani RHEL nezaručuje stabilitu všeho, je několik úrovní garancí: https://access.redhat.com/articles/rhel8-abi-compatibility#Appendix

Ze strany Red Hatu ty balíčky taky typicky spravují ti samí lidé pro Fedoru, CentOS i RHEL. A ne, opravdu je pro CentOS stream schválně nebudeme víc rozbíjet. Testy jsou už dost automatizované a taky samozřejmě společné, proč bychom je psali dvakrát?

Finanční argument samozřejmě také existuje. Jak CentOS, tak CentOS Stream jsou _komunitní_ distribuce. Takže platíte svým časem místo penězi. Vezměte si třeba už jenom hlášení chyb. Kolegové se běžně zabývali hlášeními z CentOSu, i když striktně řečeno vlastně CentOS Red Hatem oficiálně podporován nebyl.

Do CentOS stream nové můžete i přispět (do RHELu to dost dobře nešlo a nejde). Kompletně kompatibilní CentOS by vlastních změn moc mít nemohl, takto dostane opravu dříve. A ta oprava projde stejným testovacím procesem, jako kdyby šla do RHELu. Koneckonců tam stejně skončí.

Jako vývojář Vám navíc řeknu jednu věc. Koho by bavilo dělat jenom klon, kam není jak přispět nebo něco vylepšit? Nejsme přece roboti...

Zapomeňte chvíli na zlé korporace a zamyslete se na tím, že spoustě vývojářů v Red Hatu na své práci záleží. Hodně z nás by raději odešlo, než se úplně zaprodat. Proto i po práci často pomáháme komunitě, pořádáme konference a podobně.

Ja pujdu zitra na steering a ti sedovlasi panove, co maji o distribucich matne poneti (jsou experty v jinem oboru) se me budou ptat.
Pame Youda, pred dvema mesici jste nam tu povidal bachorky, proc mame stavet na Centosu8, namisto woken, ktere mame vsude jinde.
Ze je to volna zjednodusena varianta RHEL bez podpory ekosystemu Satellite6, bez podpory vyrobce, jenom komunity, coz pro dany projekt nevadi a ze pozdeji se da prejit na enterprise verzi.
Nakecal jste nam, ze je v zajmu RH drzet Centos ve stavajicim modu, je to pro ne defacto marketingovy nastroj, kdo si na Centos zvykne, seamless switchne na placeny RHEL. A ted je tu jakysi Stream, muzem zapomenout, ze jako v pripade verze 7 proste nechame servery jak jsou, dokud bude trvat podpora, nic nas do upgradu nenuti. RH ma sice hromadu kecu, jak se nic nezmeni, ale verte firme, ktera svevolne zrusi deklarovanou podporu na.polovinu.

A ja jim odpovim ve stylu: "Plne chapu, ze ted vypadam jako naprosty curak, ale tim je nekdo jiny". Nabidnu jim v ramci stavajicich projektovych costu switch na jiny system, co ma ve svem nazvu LTS, konkretne Ubuntu.

A vubec nebudeme resit, jestli Ubuntu LTS ma stabilnejsi ABI nez Centos Stream. Valka slov, LTS vs Stream, hotovo, smytec.
A pokud to tak dopadne a oni sedovlasi panove ve steeringu mi zmenu povoli, budu stastny jak blecha. Ten projekt se pripravoval rok, nez se odladil RFP design a smlouva.

A cely Stream si spanembohem narvete do spic.

A ja osobne, jenom kvuli tototo extempore, budu RH nedoporucovat a hanit, kdokoliv se.me zepta.
Vy kurvite business me, ja to budu vracet.

Podobné pocity jsem zažil s Microsoftem - podobné veletoče udělali mockrát. Pak jsem přijal to, že garanci mám jedině se smlouvou v ruce, a tu jedině za peníze. Všechno ostatní je jen marketingová vata.

Nehájím RedHat za debilní rozhodnutí, chci jen říct to, že nosit kůži na trh za druhé se prostě nedá. Proti Windows můžete postavit jedině některý linux s komerční podporou, ale projedete to na ceně. Tu musíte odůvodnit. Postavit proti sobě systém, kde máte konkrétní dvoustrannou smlouvu proti komunitní variantě je lotynka a de facto profesní sebevražda.

Pokud to samé uděláte u Ubuntu a sázíte na komunitní verzi bez garancí, je to ještě navíc výraz nepoučitelnosti. Může se stát to samé, a Canonical je v horší kondici, než RedHat. Může se stát samé, obzvlášť poté, co CentOS snížil laťku trhu. Bacha na to.

Youda: Zákazníkům něco nakecáte (to jsou vaše vlastní slova); distribuci vybíráte podle toho, zda má „LTS“ v názvu a nijak nezkoumáte obsah; nerozhodujete se racionálně na základě informací, ale rozhodí vás to, že dojde ke změně, a vůbec nezkoumáte, v čem ta změna spočívá. Jestli někdo dá na vaše doporučení, je to jeho problém.

Ta komunikace okolo je prostě šílená.

Já třeba nechápu jednu věc - mám projekt, kde potřebuju sestavit RPM pro stávající RHEL, ale mám k dispozici jenom CentOS Stream. Jaká je garance ABI (i API) kompatibility mezi aktuálním RHEL a CentOS Stream?

A jak to bude s COPRem?

Ja jsem jenom hloupej kolemjdouci, ale neresi tohle prave developer licensing RHELu? Kdyz opravdu potrebuji testovat konkretni RHEL.

Z CentOS FAQ: "CentOS conforms fully with Red Hat, Inc's redistribution policies and aims to be functionally compatible with Red Hat Enterprise Linux."

Schválně jsem to hledal na wayback machine a ta garance se změnila z "aims to be 100% binary compatible" na "functionally compatible" už v roce 2014.

CentOS 7 vyšel v tom roce a až po této změně.

On totiž CentOS sice kompiloval stejné zdrojáky, ale nepoužíval nezbytně stejný toolchain a buildroot.

Takže mám skoro pocit, že se ve skutečnosti na garancích nic nemění.