CentOS gaat zich op Stream-releases en niet meer op rebuilds van RHEL richten

Ontwikkelaars van CentOS richten zich voortaan op CentOS Stream, de software die als een preview van Red Hat Enterprise Linux te beschouwen is. CentOS Linux 8 is de laatste rebuild van Red Hat Enterprise Linux.

Red Hat ziet CentOS, oftewel Community ENTerprise Operating System, als een platform voor aan de ene kant innovatie en aan de andere kant stabiliteit. De focus op Stream moet eraan bijdragen dat de diverse groep grootzakelijke gebruikers de software snel in productieomgevingen kan integreren. Dat meldt Red Hat, dat daaraan toevoegt dat Facebook al besturingssystemen op basis van CentOS Stream voor zijn servers gebruikt en ook Intel achter de strategiewijziging staat.

Die wijziging maakt dat CentoS niet langer rebuilds van Red Hat Enterprise Linux omvat. Het project gaat zich volledig richten op het leveren van een upstream ontwikkelplatform van RHEL en dus juist vooroplopen op de stabiele releases van die Linux-distro.

Red Hat kondigde CentOS Stream in september vorig jaar aan en ziet voldoende aanleiding nu al zijn interne projecten hierop te richten. Volgens het bedrijf is Stream de toekomst van Linux voor de enterprisemarkt en klanten zouden er direct de richting van RHEL mee kunnen beïnvloeden.

Red Hat benadrukt dat CentOS niet te beschouwen is als bètaplatform voor RHEL en dat de verwachting is dat de software juist minder bugs gaat bevatten omdat deze eerder fixes en functies krijgt. De stap betekent dat CentOS Linux 8, de rebuild van RHEL 8, eind 2021 stopt. Red Hat houdt vast aan de ondersteuningscyclus van CentOS Linux .

Door Olaf van Miltenburg

Nieuwscoördinator

08-12-2020 • 16:44

96 Linkedin

Reacties (96)

Wijzig sortering
Zou de oorzaak zijn dat veel mensen gewoon centos gebruiken ipv rhel ?
Want om nou voor iedere server 350 euro te gaan uitgeven terwijl je ook centos kan draaien...
Doe je paar servers wel rhel zodat je supportvragen kan stellen indien nodig. (al is forum vaak net zo handig)
Lijkt me eerder dat CentOS de test- en playground voor RHEL wordt. Waar het tot op heden een community build van RHEL is.
Fedora is tot nu toe het 'bleeding edge' test OS van RHEL.
Wat eerder de reden is lijkt me de (door tweakers gemiste) Augustus aankondiging van IBM om op te splitsen, waarin CentOS waarschijnlijk een plek krijgt in de nieuw op te richten afsplitsing.
https://arstechnica.com/i...anies-by-the-end-of-2021/
De focus bij IBM gaat dus nog meer richting IBM Cloud De traditionele IT lijkt richting de af te splitsen 'NewCorp' (naam nog later in te vullen) te gaan met oa de onderdelen RHEL/CentIOS/Fedora etc.
De vraag die bij mij rijst is wel: wat blijft er van RH/CentOS/Fedora als besturingssysteem over?

[Reactie gewijzigd door michielRB op 8 december 2020 20:52]

Hoe ik het begrepen heb bij een presentatie van enkele IBM engineers is dat ze hun applicaties gaan ombouwen naar openshift.
Zo kunnen ze hun applicaties in de cloud draaien MAAR ook lokaal bij klanten. Persoonlijk denk ik een dikke win win.
Lijkt me wel dat IBM met de overname van redhat goed bezig is.
Ik zie die binnen enkele jaren wel boomen.
Het kan ook zo zijn dat die support een zekere aansprakelijkheid of veiligheid betekent die RHEL levert, wat het voor bedrijven interessanter maakt de betaalde variant te draaien. Denk daarbij vooral aan het uitbrengen van patches voor beveiligingsissues.

Voor heel wat bedrijven is het problematisch om een version upgrade te plannen en zingen ze het liever wat langer uit met een oudere version op het juiste patchlevel. Als die ondersteuning een paar jaar langer is, dan investeert minder vaak naar een nieuwe major OS version te moeten upgraden voor de laatste security patches zich snel terug.
Ja maar daarin verschilde centos en rhel niet dus, liepen gewoon gelijk kwa updates. (naja bijna gelijk, centos kwam soms wat later met updates omdat ze moesten rebuilden)
Het enige verschil is dat bij issues met Cent os je first/third party uurtje factuurtje support hebt o.b.v. beschikbaar terwijl je bij Red Hat volledige support hebt

Verschilt per omgeving of dat nuttig is. In de omgeving waar ik werkt is het nut nihil (2000 systemen en op OS niveau niet heel veel complexiteit)
Ja en dus krijg je mensen die dan zeg 99 systemen lekker met centos draaien en 1 met rhel, dan kan je supportvragen via dat ene systeem stellen.
Zoiets hadden wij in het verleden ook, inmiddels draaien alle servers gewoon centos want support heb je toch eigenlijk niet nodig/vaak sneller om het zelf op te lossen.
Dat is met alle “verzekeringen” zo. Tot je cruciale systeem eruit ligt en je het zelf niet kan oplossen. Dan is die 24x7 hotline plots erg handig.
Mijn ervaring met duurbetaalde support is dat ze het bij echt complexe issues vaak zelf ook niet weten.

Dan beter inzetten op een systeem voor snelle re-deployment.
In de hoek van Microsoft/Cisco/HP/Dell is dat zeker zo ja...

Ik vond RedHat qua support en eigenlijk ook qua opleidingen altijd een positieve uitzondering hierin.
Goh ik was ooit linux admin in een klein bedrijf en dan ben je toch blij met redhat support.
Nu zit ik in een groot bedrijf , ook met redhat support, waar het veel minder nodig is omdat je hier met een pak skilled linux engineers zit.
Hangt dus wel veel af van je interne engineers denk ik.
Wij draaien op het gros van onze (web)servers debian. Dat is vrij stabiel en wordt een redelijke tijd ondersteund.

We hebben een aantal oudere applicaties draaien, die niet zo makkelijk te upgraden zijn, of waar er geen interesse is om die te upgraden. Voor dat soort applicaties hebben we wat CentOS servers in de lucht omdat dat nog erg lang (security) support blijft leveren voor oude software.
RHEL8 komt ook met stream. Dus daar zal wel weinig aan veranderen. De core blijft gewoon echt long-term en met name de onwtikkeltools in de streams waardoor je redelijk bij kan blijven met nieuwe ontwikkelingen.

Ik moet zeggen dat streams en de dnf modules voor mij wel even wennen zijn. Maar goed dat was systemd ook 😁
Voor grote(re) organisaties zijn dat niet per se de kosten meer. Als je alle problemen iedere keer moet reproduceren op een andere machine, dan maakt dat de support niet altijd makkelijker. Als je tot je nek in de shit staat, wil je wel heel graag een nummer hebben wat je kan bellen. Dan kan je ook makkelijker uitleggen aan de klant dat je alles uit de kast trekt om een probleem op te lossen.

Ik snap het helemaal dat je als MKB niet zit te wachten op die licentiekosten, maar als grote instantie is het wel ontzettend praktisch.
Grote staat los van complexiteit. 1000e nodes die na een whipe / Ansible playbookje weer draaien zijn iets anders dan 100nodes met elk een stukje custom (vaak legacy) software
In die zin staat grootte juist vaak niet los van complexiteit, bijna in alle echt grote omgevingen is automation veel beter ingericht dan in kleinere. De kosten van bepaalde tools en de bijbehorende kennis worden relatief ook lager naarmate de omgevingen groter worden.
Ik hoef bij mijn klanten niet aan te komen met een oplossing die niet back-to-back gesupport is. Als se er achter komen dat ik zo'n kostenbesparende truc zou uithalen is het einde verhaal en misschien wel een rechtzaak. Als je daar op gaat besparen ben je hobbyist en niet serieus bezig.
Dat is een overdreven reactie.
Het is puur een afweging van kosten en in-house knowledge.

Ik ken genoeg serieuze productie systemen die perfect op CentOS draaien.

Ik heb (als hobby) er zelf ook 2 draaien en die zijn super stabiel.

Ik ga trouwens die ene eens proberen te upgraden van CentOS7 naar Stream, wat officieel niet kan.
Dat is natuurlijk afhankelijk voor het doel dat ingezet wordt. Als jij een een standaard server er tussen nodig die bv alleen log bestanden verzameld. Is het per definitie niet noodzakelijk om een duur betaalde server neer te zetten. Om dan wel in lijn van rhel te blijven zou je centos voor deze doeleinde kunnen inzetten.
Sorry maar echt hele grote cloud platformen draaien op niet gesupporte software, dat zijn volgens jou dan allemaal amateurs ? Tsja, meestal zijn dat wel de bedrijven die de nieuwe generatie technologie creeeren en bepalen.
Doe je paar servers wel rhel zodat je supportvragen kan stellen indien nodig. (al is forum vaak net zo handig)
Maar ergens moeten de engineers die hieraan sleutelen toch ook gewoon eten aan het einde van de dag?
Trouwens de hudige centos 8 is ook al een soort stream ? :

]# cat /etc/redhat-release
CentOS Stream release 8

]# rpm -qa |grep release
elrepo-release-8.2-1.el8.elrepo.noarch
epel-release-8-8.el8.noarch
centos-stream-release-8.4-1.el8.noarch

Maakt het niet echt duidelijk dus waar ze nou precies mee stoppen straks.
Ja, en nee. Er zijn twee varianten van CentOS te downloaden. CentOS Linux, en CentOS Stream. Mijn servers, waarvan een deel vandaag geüpdatet is naar 8.3, vermeldt namelijk niets over stream:

]# cat /etc/redhat-release
CentOS Linux release 8.3.2011

]# rpm -qa| grep release
centos-linux-release-8.3-1.2011.el8.noarch

CentOS Linux komt op ten duur te vervallen, en dan blijft enkel CentOS Stream over.
Ok ik vermoed dat ik die servers geupdate heb naar streem ivm updates die later kwamen.
Niet helemaal duidelijk dat ik toen dus ook overstapte op andere 'release'
Of je hebt iets geïnstalleerd met een DNF module, dan krijg je automagisch stream support e.d
Kennelijk heb je ooit eens het centos-release-stream package geïnstalleerd. In de FAQ staat dat dat de manier is om een machine om te katten van 'gewone' CentOS naar de Stream variant:

https://centos.org/distro...allation-to-centos-stream
ik dacht eigenlijk dat fedora hier voor in het leven was geroepen. maar ik zit er dan totaal naast natuurlijk
Fedora is toch meer een desktop georienteerde distributie? Centos/RHEL voor servers.
Fedora word gebruikt als een speeltuin voor nieuwe features en technologie dat later mogelijk in RHEL/CentOS beland. CentOS en RHEL zijn beide gebaseerd op Fedora.

Fedora heeft ook een server variant die het zelfde bleeding-edge en experimentele release model volgt.

CentOS Stream zal het stukken voorzichtiger doen, iets dat in CentOS stream beland zal vrijwel zeker binnen een korte tijd ook in RHEL verschijnen.

[Reactie gewijzigd door Omega op 8 december 2020 17:01]

Een beetje het Debian model dus als ik het zo goed begrijp. Stable, testing en sid/unstable.
Niet echt.

Debian unstable loopt altijd achter met security updates en word nauwelijks getest. En in Debian unstable zie je alleen maar software updates, er worden zelden grote veranderingen aan de standaard configuratie aangebracht. Mensen vonden het al schokkend dat Debian 10 Wayland ging gebruiken als standaard display server voor GNOME, Wayland is wel stabiel maar het heeft een aantal bugs en mist wat functionaliteit.

Debian testing is een staging distro, de software daar in staat op het punt om in stable te belanden.

In elke release van Fedora worden er grote veranderingen aangebracht aan de standaard configuratie van de distro zolang het de stabiliteit van de distro niet aantast. Bijvoorbeeld, Fedora 33 is van plan om PulseAudio en Jack te vervangen met Pipewire. Met Debian moet je niet verbaast zijn als ze over 10 jaar nog steeds op PulseAudio en Jack zitten. Je ziet in Debian testing en unstable eigelijk niks gebeuren dat niet uiteindelijk in een stabiele release van Debian verschijnt.

Daarnaast heeft Fedora ook aparte experimentele releases zoals Fedora Silverblue en Fedora CoreOS dat eigelijk al uiterst geschikt is als daily driver/productie.

Fedora is een professioneel product en zo word het ook behandeld door de developers. Er zijn developers en systeembeheerders zoals ik die Fedora dagelijks gebruiken, wij gebruiken het omdat het zowel stabiel en up-to-date is. Stabiliteit staat bij Fedora voorop, en ze hebben ook de mensen en kennis om dit als haalbaar doel te hebben met een semi-rolling release distro.

[Reactie gewijzigd door Omega op 8 december 2020 18:02]

? Sid krijgt gewoon security updates, loopt maximaal 6 uur achter, gezien die repos elke 6 uur updaten. Vergeet niet dat Debian Sid nog steeds de basis is voor Ubuntu en bijna alle distro's in Debian's stamboom. Volgens mij ben je in de war met Debian experimental.

Ze hadden vrij vlot na Fedora's introductie van Systemd, dit ook geïntroduceerd in Sid/testing, ondanks tegenstribbelingen uit de community. Ze gaan best goed mee, alleen een beetje conservatief kat uit de boom kijken, maar dat is ook de kracht van Debian en de community zit grotendeels bij Debian vanwege de gegarandeerde stabiliteit. Debian stable kan je tussen de major releases door zonder omkijken gescript updaten. Zelfs dist-upgrades zijn vrij kopzorgloos. Die ervaring is voor mij bij Ubuntu en Fedora toch echt heel anders :)

RHEL = Stable, CentOS = testing en Fedora = Sid. Het lijkt hier in ieder geval heel sterk op.

Bij een rolling release staat stabiliteit nooit voorop, dat kan niet :) Anders is het geen rolling release, beetje tegenstrijdig. ~2 jaar heb ik Fedora gebruikt, ik heb het echt geprobeerd (het is een prima distro), maar ik zal het (net als Ubuntu) zelf nooit inzetten als server OS en velen met mij. Zegt genoeg over de focus op stabiliteit. Stabiliteit is meer dan het niet krijgen van kernel panics.

Debian Sid is ook prima bruikbaar als daily driver, jarenlang gedaan als desktop en hobby/dev servers. Maar ik zal het niet op een productie server gebruiken. Maar je kan doorgaans ook prima testing/sid packages gebruiken op je stable Debian. Dus het is eigenlijk nooit nodig.

[Reactie gewijzigd door batjes op 8 december 2020 18:24]

Dat klopt niet, de repos worden elke 6 uur geüpdate, dat betekent niet dat er beveiligings-updates in zitten. Debian unstable heeft niet als bedoeling dat jij die draait als daily driver, het is puur voor testing. Als u de regel onder die leest waarin staat dat de repos elke 6 uur word geüpdate staat er het volgende:
Sid exclusively gets security updates through its package maintainers. The Debian Security Team only maintains security updates for the current "stable" release.
De sprong naar Systemd was ook niet bepaald snel, dat was 4 jaar na de release van Systemd en Fedora draaide Systemd al 3 jaar op het punt dat het in Debain stable belande. En grote veranderingen zoals dit zie je in Debian niet vaak.

De grootste veranderingen van Debian 9 op 10 waren dat Apparmor standaard word enabled en dat Iptables was vervangen met Nftables. Debian heeft er 2 jaar over gedaan om 2 redelijk kleine veranderingen door te voegen. In die zelfde tijdspan(+/- een paar maandjes) heeft Fedora 4 releases gehad allemaal met een redelijk grote lijst aan changes.

Als wij RHEL, CentOS en Fedora met elkaar vergelijken krijgen we dit;
stable = RHEL, CentOS.
Testing = ~
sid = ~

Het release model van Fedora valt niet te vergelijken met de Debian releases, en eigenlijk met vrijwel geen ander besturingssysteem. Het is stabiel maar tegelijk een testing ground voor nieuwe (maar ook oude) technologie van Red Hat en andere partijen.

Fedora is een semi-rolling release. Belangrijke software met een grote impact zoals de Linux kernel, webbrowser en MESA word up-to-date gehouden met de nieuwste releases, en tegelijk worden de minder belangrijke pakketje zoals de grafische interface en de meeste programma's alleen geüpdate bij de Fedora point releases die elke 6 maanden zijn.

Mijn ervaring met Debian unstable is het zelf als die met Fedora Rawhide, bugs, kapotte installaties.

Nooit software mixen tussen verschillende releases van een distro. De package manager zal meer installeren dan alleen de software die jij aanroept, hij zal ook proberen verschillende packages te updaten. Dit kan lijden tot package conflicts en software die niet meer werkt ivm. incompatibiliteit met een dependencies uit de andere release.
Dat systemd er tig jaar over deed om in stable te komen komt omdat debian niet heel vaak een stable brengt. Waar Ubuntu elke 6 maand met een release komt duurt dat bij debian 1-4 jaar.
Unstable krijgt nieuwe software, dat schuift na een paar dagen tot weken door naar testing en stable krijgt alleen security updates en bij een pointrelease bugfixes. Als testing uiteindelijk klaar is om de nieuwe stable te worden gaat de hele zooi op slot en mogen er alleen nog bugfixes en security fixes gedaan worden.
Verder is er nog experimental, waar boel getest wordt dat vaak nog te prematuur is om het in unstable en testing los te laten.
Bij een rolling release staat stabiliteit nooit voorop, dat kan niet :) Anders is het geen rolling release, beetje tegenstrijdig.
Bij openSUSE hebben we ook twee versies Leap als fixed point en Tumbleweed als rolling release. Voor Leap wordt expres niet de stabiele versie genoemd aangezien ze allebei! stabiel zijn.

Daarnaast wordt Tumbleweed met openQA voor iedere release snapshot (zeg maar iedere dag/2 dagen) volledig automatisch getest met alle packages onderling.

Met Tumbleweed wordt niet zomaar iedere package blind geupgrade. Bijvoorbeeld op Gnome 3.38 heb ik 2 maanden gewacht. Eerst wachten ze tot 3.38.1 uitkomt, maar daar zaten nog problemen in met een aantal andere packages die opgelost moesten worden. Toen 3.38.2 uitkwam duurde het overigens wel maar een paar dagen voordat ik dat draaide.

Zie ook deze link van 1 van de developers van SUSE/openSUSE
https://rootco.de/2020-02-10-regular-releases-are-wrong/

[Reactie gewijzigd door hsb85 op 9 december 2020 10:12]

Uit de faq ook :
Q15: How does CentOS Stream differ from Fedora ELN?
A: CentOS Stream is focused on the next RHEL minor release. This means we are improving and influencing the shipping releases of RHEL. Fedora ELN is a testing area for changes that may occur in the next major release of RHEL.The CentOS Project cannot and does not speak for Fedora. We encourage you to speak with them directly.
Maar dan heb je dus straks centos stream 8, die dus zeg nieuwe functies 'test' die in rhel 8.4 komen
Maar krijg je ook nog een rhel 8.4 beta, voor mensen die willen beta testen.
En fedora voor mensen die willen testen wat er in rhel9 komt.
Misschien is dat het wel: Fedora is te veel de desktop kant op gegaan.

En dat CentOS zich redelijk tot de server-kant richt waar RedHat misschien wel meer tussen in zit, al moet ik eerlijk zeggen dat ik deze distributies niet meer zo actief volg.

CentOS is volgens mij ooit ontstaan als de open-source versie van RedHat en dat ze daarmee dus expliciet achter RedHat aan liep. Maar ik kan mij goed voorstellen dat CentOS meer en meer een eigen pad gaat lopen. Het is immers niet met handen en voeten aan RedHat gebonden.

UPDATE: Blijkbaar zit CentOS vaster aan RedHat dan ik op mijn netvlies had. RedHat blijkt (al jaren) eigenaar te zijn.

TOEVOEGING: Misschien is het artikel hier boven bij Tweakers niet helemaal compleet of helemaal duidelijk. Zelf heb ik in ieder geval een paar stappen gemist. Volgens www.centos.org bieden ze al een tijdje 2 varianten: CentOS Linux en CentOS Stream. En vanaf volgend jaar krijgt CentOS Stream de voorkeursbehandeling, waar dat tot nu toe CentOS Linux was.

[Reactie gewijzigd door beerse op 8 december 2020 18:25]

zover ik weet is CentOS in handen van Redhat sinds 2014 volgens dit artikel nieuws: Red Hat neemt CentOS-project over

het kan zijn dat er tussentijds wijzigingen zijn geweest, als iemand dat weet correct me please
CentOS is vorig jaar gekocht door RedHat, net voor de IBM deal. Ze zijn dus geeen community-OS meer, maar gewoon betaald.
Fedora is al heel lang geleden, al ruim voor de overname van CentOS meer desktop georienteerd geraakt, er is juist sinds enige tijd weer een server editie van te krijgen. Maar uiteraard wel bleeding edge, net als de desktop variant.
Dat was ook precies mijn gedachte, maar fedora is nog veel verder upstream dan CentOS gaat worden denk ik.

Plus niet alles van fedora komt in RHEL en dat zou bij CentOS wel moeten waarschijnlijk..
En wat betekend dit voor de End of LIFE datum van ergens 2029 die oorspronkelijk voor CentOS 8 stond?
Updates for the CentOS Linux 8 distribution continue until the end of 2021; users can choose to switch over directly to CentOS Stream 8
CentOS 7 blijft wel gewoon bestaan tot juni 2024 ;
Updates for the CentOS Linux 7 distribution continue as before until the end of support for RHEL7.
Dan is het dilemma dus om nu dan nieuwe servers toch maar te deployen met CentOS 7 en rustig verder kijken voor na 2024 of nu toch kiezen voor CentOS 8; maar dan weet je dus niet wat er gaat gebeuren met de stabiliteit en betrouwbaarheid van die versie. Helaas is een heel ander OS ook niet altijd te doen, denk aan sommige control panels die CentOS vereisen. :X Het is altijd lastig met gratis opensource producten, maar RHEL sloopt op deze wijze CentOS/waar het voor staat en alles wat de community al die jaren voor RedHat heeft gedaan. Ik denk dat sommige hier toch een beetje brandend gevoel in hun derrière van gaan krijgen.
Mua, CentOS 8 Stream is de standaard CentOS 8 met een extra optie: DNF modules (streams). Verder zijn ze identiek. Je hoeft op 8 Stream de streams niet te gebruiken, dan heb je dus feitelijk gewoon CentOS 8.

Je kunt dus straks een CentOS 8 Stream bak inrichten, en zonder dat je daar moeite voor hoeft te doen is het toch CentOS 8.

Ik hoop dat dit duidelijk is.
Helaas is dat niet zo; dit gaat niet over het opt-in concept Application Streams, maar over CentOS Stream. Die twee hebben verwarrende naamgeving maar niets met elkaar te maken. CentOS Stream is een WIP van de volgende minor release. Als reguliere CentOS/RHEL op 8.3 zitten dan is Stream alvast een WIP van 8.4, en dat stukje is "rolling release", dus de fixes en changes komen dag bij dag binnen gecombineerd met de security releases tot ze het stabiel genoeg vinden om het als RHEL 8.4 uit te brengen. Dan gaat Stream gelijk over in een testtuin voor 8.5.

Stream veranderd niets dat niet in 8.x veranderd, dus grote softwareversies zoals de kernel en binary compatibility blijven min of meer gelijk (Fedora is de testtuin voor majors als 9.0), maar het is wel degelijk een WIP met bepaalde bugfixes en changes die eerst uitgetest moeten worden en soms teruggedraaid kunnen worden. Zie bijvoorbeel de RHEL 8.3 release notes. Admins die door die notes kijken en zoiets hebben van "doe ik later wel" kunnen RHEL 8.2 nog tot mid-2022 met security updates gebruiken, of zelfs tot 2024 als je ~$8k/jaar/server voor de SAP extended-support package erbij tikt. Dit was met CentOS al zeer beperkt mogelijk omdat ze alleen ondersteuning gaven voor de nieuwste minor, maar nu moet je dus zelfs op de feiten voorop gaan lopen.
Dan heb ik hier een vreemde configuratie draaien denk ik. Ik heb 2 CentOS 8 machines, eentje Stream en de andere non-Stream. Beide machines zijn qua files en structuur 100% gelijk, op 3 files na in /etc/yum.repos.d/

[Reactie gewijzigd door sfranken op 9 december 2020 04:15]

Dat gaat dus veranderen en een pad van CentOS naar RHEL wordt dan ook sterk bemoeilijkt. Ik denk dat je het probleem en de impact voor productieservers waar stabiliteit bittere noodzaak is sterk onderschat. ;( Maar gelukkig is het met C7 nog tot 2024 uit te zingen. Balen van C8 deployments, maar dat zij zo. De community gaat CentOS forken en dan komt het hopelijk helemaal goed en hebben we weer een LTS-versie. :)
Als stabiliteit écht zo'n "bittere noodzaak" is is een licentie RHEL peanuts, zeker in de zakelijke wereld. Ik zie het probleem om eerlijk te zijn niet zo
Dat merk ik ja :P Dit is naar mijn mening een absurde suggestie om een heel scala aan redenen en juist hetgeen wat we absoluut NIET zouden moeten doen om dit wangedrag en misbruik van community werk te belonen...

Maar goed, laat maar zitten; het heeft ook geen zin. :) Er komen ruim op tijd forks uit om niet met dit probleem te maken te krijgen in een productieomgeving, hopelijk kost het RHEL verschrikkelijk veel klanten gezien ze nu laten zien volledig onbetrouwbaar te zijn en klaar. De community overleeft het wel, daar heb ik alle vertrouwen in, RHEL komt wel in lastiger vaarwater.

Ik hoop in ieder geval dat je voor je (nieuwe) productiemachines niet gaat inzetten op CentOS 8, want dan ga je vroeg of laat écht gezeik krijgen. Dat zie je nu misschien niet, maar ik hoop oprecht dat je het niet “the hard way” gaat ervaren en er goed over nadenkt. :) Bèta’s draaien we liever niet in productie met een reden en onthoud ook: je zal ook geen aansluiting meer hebben op RHEL als je normaliter gewend bent zo over te kunnen gaan of cross-platform te ontwikkelen... Dat wordt nu allemaal kapot gemaakt.
Ik heb de luxe geen CentOS machines in productie te draaien. Dat is allemaal RHEL hier. Ik heb alleen CentOS thuis draaien, op machines waar stabiliteit geen bittere noodzaak is.

Ik denk dat Red Hat meer op de plank heeft liggen. Een bedrijf wat al 20 jaar (om en nabij) zaken doet weet écht wel wat de community wil, denkt, én doet. Dit verhaal krijgt nog een staart(je)
Maar daar stopt support volgend jaar voor, dan EOL'd het hele zooitje op CentOS 7 na.
Nee hoor, CentOS 8 Stream heeft gewoon support, alleen de non-Stream variant gaat EOL. Nogmaals: Stream en non-Stream zijn nu 99% gelijk, en na de EOL ook nog. Alleen de focus is anders.
Voor nu. Wat ik me afvraag wat gebeurd er met bijvoorbeeld een PHP. De default is nu geloof ik 7.2 bij CentOS 8. Wordt die straks zomaar vervangen voor een 7.3? Idem met een MySQL, gaan we dan ineens van 8 naar 9 als die uitkomt.

Ik heb het idee dat Stream nu hetzelfde is als Ubuntu 20.04 LTS draaien, om vervolgens te upgraden naar 20.10, daarna 21.04 etc. Met als gevolg dat je steeds server software zoals Apache, Postfix e.d. vervangt met de laatste grote release, i.p.v. dat je in dezelfde minor version blijft.
Je hebt de keuze. Je kunt streams vastzetten op de versie die je wilt per stream. Ik verwacht niet dat de CentOS developers daaraan gaan sleutelen, want dat is een concept wat Red Hat voor RHEL 8.4 (en later) steeds meer wil gaan toepassen.
Wat een hele goede optie is is je eigen yum repo bouwen en vullen met specifieke packages uit externe repo's, in jou geval bijvoorbeeld Remi voor PHP...

Ik vraag me ook af of dit hele stream gedoe straks niet gewoon op te lossen is door een slimme yum/dnf plugin... Wat in een bepaalde RHEL versie released wordt staat ook al in de CentOS Stream repo, je wil dus gecontroleerd achter kunnen lopen. Daarvoor heb je feitelijk de informatie nodig welke packages RHEL in de repo heeft staan. Je zou met die info zelfs de juiste packages kunnen syncen naar een eigen yum repo, feitelijk dus een repo die alleen de packages bevat die in RHEL ook zijn gereleased en die gebruiken voor het updaten van je servers. Zullen vast wat haken en ogen aan zitten maar is niet onhaalbaar lijkt me.

Ik ga dit eens onderzoeken voor onszelf, hebben nu toch bijna 300 CentOS vm's draaien die daar de vruchten van plukken. Op een gegeven moment zal het grootste deel wel vervangen worden door containers maar voorlopig nog even niet.
Op https://wiki.centos.org/About/Product geven ze voor CentOS 8 toch ook echt december 2021 aan nu. Ik vind dit vrij bizar. Afgelopen zomer druk bezig geweest met installatiescripts voor 8 en weken bezig geweest met de migratie van websites. Juist voor CentOS 8 gekozen vanwege de lange support. Stond op het punt het in te gaan zetten voor een nieuwe mailserver.

Nu maar even goed inlezen wat het nu werkelijk betekend om te upgraden naar Stream. Voor nu bij nieuwe servers dan toch maar weer voor Ubuntu LTS kiezen dan.
Ik ben al even over naar Ubuntu LTS. Voornaamste reden is dat debian / ubuntu het meest gebruikt worden bij diverse user setups. Bijvoorbeeld home assistant.
Andere reden is hun push naar buildah and podman ipv docker.
Ik maak al vanaf 2007 gebruik van Ubuntu. Altijd een fijn OS gevonden voor servers. Maar een maximale leeftijd van 5 jaar bij LTS (was dit vroeger niet 4 jaar?) tegenover de 10 van CentOS deed mij doen beslissen over te gaan op CentOS 8... Gewoon omdat ik niet iedere 4-5 jaar wil migreren :-). Gezien de geschiedenis van CentOS had ik dit niet zien aankomen.

Gelukkig gaat het nog maar om één CentOS server in productie, maar had net mijn installatie- en configuratiescripts klaar. Ik ga nu komend jaar deze weer ombatterijen voor Ubuntu LTS, maar had me deze tijd graag bespaard.

Ik hoop in ieder geval dat CentOS 8 Stream stabiel en betrouwbaar genoeg zal zijn voor servers, dan kan ik deze ene server hopelijk laten voor wat het is.
Idem dito, afgelopen 3 maanden 8 servers omgegooid naar CentOS juist vanwege die EOL.
Kan dus weer opnieuw beginnen.
Zelfde probleem overigens bij Slackware. Versie-15 staat al 3 jaar op hold! Versie-14 is nog wel ondersteund, maar de default OpenSSL/MySQL is toch wel echt achterhaald aan het worden.
Ubuntu heb ik op desktop draaien, maar mijn gevoel zegt nee voor servers (enkel voor Odoo).
Denk dan toch maar richting Debian weer te gaan.
Maar bij Debian duurt LTS maar 4 jaar en bij Ubuntu 5. Als ik rondkijk is er nog OpenSuse, maar die doet zo te zien maar 3 jaar. En om nu wéér een nieuwe distributie te leren. Heb gelukkig sinds 2007 ervaring met Ubuntu server, dus om volgend jaar Ubuntu 20.04 de lucht in te gooien zal niet zo’n probleem worden. Het migreren van websites en webapplicaties zit ik echter totaal niet op te wachten... Voor nu laat ik ‘t mooi draaien tot en met de zomer en onderneem ik dan wel actie om afscheid te nemen van CentOS 8.

Ik stond ook op het punt een CentOS 8 mailserver op te zetten die dus ook zo lang mee moest gaan. Blij dat ik het te druk had en er niet aan toe kwam.
Zou Centos ook niet teveel de hete adem voelen van andere Rhel gebaseerde os’s zoals Amazonlinux en Oracle Linux?

Persoonlijk ben ik zeker voorstander van deze centos heroriëntatie.

[Reactie gewijzigd door dayofdead op 8 december 2020 17:04]

Meer andersom. Amazon en Oracle Linux zijn in feite gewoon Red Hat Enterprise Linux maar dan van een andere software boer. Cent OS is de gratis versie van RHEL, maar Amazon en Oracle kunnen natuurlijk ook doen wat Cent OS doet.

Fedora staat hier los van: Fedora is meer voor de desktop, en het is de technische speeltuin van Red Hat. Nieuwe technieken komen eerste in Fedora terecht, vaak zelfs eerder dan in Arch en Debian Sid.
Kans bestaat nu dat gebruikers van CentOS juist overstappen op Oracle want die doen precies wat CentOS doet (/binnenkort deed)

Zie ook meteen de 3 comments op blog van centos ;
https://blog.centos.org/2020/12/future-is-centos-stream/
This is dumb. The entire premise and the only reason anyone uses CentOS is because it's rebuilt RHEL. Congratulations on undermining that, nitwits.
I guess my argument "Use CentOS, not Ubuntu if you want most stable production" is out of the window now. Ubuntu it is then from now on.
Against my better judgement... *looks at Oracle Enterprise Linux*
Je moet er maar zin in hebben om Oracle in huis te halen. Die hebben bij mij niet zo'n hele beste en betrouwbare naam. In 2018 heb ik nog een enorme berg JRE's mogen vervangen door OpenJDK ivm licensing issues.

Het zou mij persoonlijk niet verbazen als er een nieuwe naam komt die het oude werk van CentOS gaat oppakken, alles wat nodig is beschikbaar.
Misschien weer tao linux, die is ooit ook samen gegaan met centos.
Ik heb jaren tao gedraaid en toen dus overgestapt op centos.
Dat komt er inderdaad en we moeten ook even met een schuin oog kijken naar Fermilab en CERN mbt Scientific Linux rebooten.
Ik was al bang dat zoiets zou gaan gebeuren nadat Redhat het CentOS project had over genomen. Baal er wel van nu ik net al mijn persoonlijke VPSen en mijn Nas thuis over heb naar CentOS8, gelukkig is er nog 8 jaar support met CentOS8. Ik zie wel tegen die tijd wat de alternatieven RHEL clones zijn, ik heb geen zin om voor een RHEL subscriptie te betalen voor mijn persoonlijke systemen omdat ik geen support nodig heb.

Ben eigenlijk wel benieuwd wat ScientificLinux nu gaat doen want die gingen juist over naar CentOS om daar aan mee te helpen, hoop een beetje dat er nu een bericht komt dat ze nu toch nog verder gaan met ScientificLinux en anders is het hopen dat SpringdaleLinux met een versie 8 komt. Dan is er nog OracleLinux maar daar ik zal er alles aan doen op Oracle producten voor persoonlijk gebruik te vermijden. Mochten er over 8 jaar geen alternatieve RHEL clones zijn waar ik naar toe kan migreren dan zal ik waarschijnlijk over gaan naar Debian of zo, maar ik draai toch liever RHEL clones voor mijn persoonlijke systemen.

[Reactie gewijzigd door Hydranet op 8 december 2020 20:19]

Nou nee, het gewone CentOS 8 wordt nog maar ondersteund tot eind 2021. Zie https://wiki.centos.org/About/Product
Bedankt! Had het laatste deel van het artikel niet goed gelezen.

[Reactie gewijzigd door Hydranet op 8 december 2020 20:47]

Je kunt gewoon om naar Stream zonder al teveel moeite.
Ja dat weet ik, ik wil alleen geen beta tester zijn voor RHEL want dat word CentOS stream maar het word niet zo letterlijk gezegd. Ik gebruik CentOS omdat ik binary compatible systeem wil niet omdat ik upstream van RHEL wil zitten.

[Reactie gewijzigd door Hydranet op 11 december 2020 00:24]

Ik begrijp je gevoel volledig. Ik ben actief bij een op CentOS (nu nog 7) gebaseerde distro: NethServer. Dit nieuws is ook in onze community redelijk aan het indalen. En we zijn wel degelijk ons aan het beraden hoe de toekomst van het project er uit moet gaan zien. Er zijn nu zo verschrikkelijk veel vragen en onzekerheden.
Er is (gelukkig) wel aandacht voor de SIG's
Ik hoop dat er van daar uit nog wat aan de 'traditionele' server OS gedaan wordt zodat er toch nog op fysiek ijzer (of als VM) een server geïnstalleerd kan worden.
SpringdaleLinux is ook een RHEL clone en ze hebben ook gewoon een versie 8 ;)

[Reactie gewijzigd door Hydranet op 9 december 2020 10:55]

gelukkig is er nog 8 jaar support met CentOS8
Support voor de niet-stream versie van CentOS 8 stopt eind 2021.

[Reactie gewijzigd door Locke_ op 8 december 2020 23:27]

Iemand anders wijste mij er al op, ik had het laatste deel van het artikel niet goed gelezen. Ook bedankt voor de reactie dat ik het verkeerd had gezien.
Gregory Kurtzer, de originele oprichter van CentOS, had een oproepje gedaan om een fork te gaan maken. Binnen een paar uur hebben zoveel mensen zich gemeld, dat het zo te zien gaat gebeuren. En dat kan vast helemaal af zijn in 2021. Dat is al heel positief nieuws. <3 de FOSS-community.
Lees ook al iets over een naam voor wat het waard is: rocky linux.
CenTwo zou een betere naam zijn :)
De stap betekent dat CentOS Linux 8, de rebuild van RHEL 8, eind 2021 stopt.
Fijn als je net een aantal maanden geleden een nieuwe DirectAdmin VPS hebt opgezet op CentOS 8 (die eerst pas EOL ging in 2029), omdat CentOS 6 EOL ging ... :(
CentOS Stream wordt gewoon een onstabiele bende ...
Ik heb door vertraging bij een leverancier eigenlijk dikke mazzel bij een project. Een vlootje van 40 nieuwe servers had 2 weken geleden binnen moeten komen, die zouden allemaal voorzien zijn van C8 en binnen een paar dagen (na function tests) in productie genomen zijn. Nu komen ze pas overmorgen binnen en denk ik dat de C7 scripts van stal gehaald worden. Dan is er tenminste 3 met uitloop tot maximaal 4 jaar de tijd om rustig af te wachten wat de ontwikkelingen zijn en wat er tegen die tijd beschikbaar is als vervanger.
Volgens mij klopt de laatste zin niet - CentOS 8 was normaalgesproken pas EOL per 31 mei 2029, en dit wordt nu vervroegd naar eind volgend jaar. Dat betekent ook dat de mensen die overgeschakeld zijn nu o zoek moeten naar óf een andere distro, of mee moeten gaan in dit stream-verhaal.

Voor een aantal van mijn klanten draai ik managed hosting op basis van cPanel, en cPanel werkt uitsluitend op CentOS 7. Aangezien support eindig is voor CentOS 7 ben ik wel heel benieuwd hoe zij hier mee om zullen gaan. `

Edit: jaartal.

[Reactie gewijzigd door las3r op 9 december 2020 16:59]

2029*

cPanel heeft een paar weken terug een beta uitgebracht die werkt met CentOS 8 en ze hebben de complete SQL-integratie herschreven voor 8. Dus die zullen niet blij zijn.
Want ? Dat zou niet werken dan op CentOS 8 Stream ?

Ik denk dat cPanel, Plesk, DirectAdmin gewoon prima overweg kunnen met Stream... Voor bepaalde software waar meer controle over nodig is werden toch al eigen packages of builds gemaakt.

CloudLinux zou nog wel eens lastiger kunnen zijn, die hebben nu al af en toe moeite met bij blijven binnen het huidige systeem.
Het cliënteel van cPanel wil over het algemeen stabiele systemen met hele lange (LTS) support in plaats van bleeding edge beta software in hun productieomgeving.
Ik neem aan dat de afkorting "REHL" eigenlijk RHEL moet zijn?
Kan je beter hier melden: Spel- en tikfoutjes - en dus *geen* andere foutjes - deel 45.
Maar na 2 uur is het nog niet aangepast.

Op dit item kan niet meer gereageerd worden.


Google Pixel 7 Sony WH-1000XM5 Apple iPhone 14 Samsung Galaxy Watch5, 44mm Sonic Frontiers Samsung Galaxy Z Fold4 Insta360 X3 Nintendo Switch Lite

Tweakers is samen met Hardware Info, AutoTrack, Gaspedaal.nl, Nationale Vacaturebank, Intermediair en Independer onderdeel van DPG Media B.V.
Alle rechten voorbehouden © 1998 - 2022 Hosting door True

Tweakers maakt gebruik van cookies

Tweakers plaatst functionele en analytische cookies voor het functioneren van de website en het verbeteren van de website-ervaring. Deze cookies zijn noodzakelijk. Om op Tweakers relevantere advertenties te tonen en om ingesloten content van derden te tonen (bijvoorbeeld video's), vragen we je toestemming. Via ingesloten content kunnen derde partijen diensten leveren en verbeteren, bezoekersstatistieken bijhouden, gepersonaliseerde content tonen, gerichte advertenties tonen en gebruikersprofielen opbouwen. Hiervoor worden apparaatgegevens, IP-adres, geolocatie en surfgedrag vastgelegd.

Meer informatie vind je in ons cookiebeleid.

Sluiten

Toestemming beheren

Hieronder kun je per doeleinde of partij toestemming geven of intrekken. Meer informatie vind je in ons cookiebeleid.

Functioneel en analytisch

Deze cookies zijn noodzakelijk voor het functioneren van de website en het verbeteren van de website-ervaring. Klik op het informatie-icoon voor meer informatie. Meer details

janee

    Relevantere advertenties

    Dit beperkt het aantal keer dat dezelfde advertentie getoond wordt (frequency capping) en maakt het mogelijk om binnen Tweakers contextuele advertenties te tonen op basis van pagina's die je hebt bezocht. Meer details

    Tweakers genereert een willekeurige unieke code als identifier. Deze data wordt niet gedeeld met adverteerders of andere derde partijen en je kunt niet buiten Tweakers gevolgd worden. Indien je bent ingelogd, wordt deze identifier gekoppeld aan je account. Indien je niet bent ingelogd, wordt deze identifier gekoppeld aan je sessie die maximaal 4 maanden actief blijft. Je kunt deze toestemming te allen tijde intrekken.

    Ingesloten content van derden

    Deze cookies kunnen door derde partijen geplaatst worden via ingesloten content. Klik op het informatie-icoon voor meer informatie over de verwerkingsdoeleinden. Meer details

    janee