CentOS-alternatieven in 2026: AlmaLinux vs Rocky Linux (en hoe je migreert)

CentOS is dood: dit is de korte versie

CentOS Linux is stopgezet. CentOS 8 werd voortijdig afgekapt en bereikte op 31 december 2021 end-of-life; CentOS 7 bereikte op 30 juni 2024 end-of-life. Een van beide vandaag draaien betekent geen security-updates. En CentOS Stream is niet de vervanging die de meeste mensen willen: sinds de omslag in 2020 zit het upstream van Red Hat Enterprise Linux (een rolling preview van de volgende RHEL, geen downstream stable rebuild ervan).

De twee echte opvolgers zijn AlmaLinux en Rocky Linux. Beide zijn gratis, beide zijn RHEL-compatibel, beide zijn legitieme vervangers voor CentOS Linux. Hier is het op voorwaarden gebaseerde antwoord dat deze gids onderbouwt:

• Kies AlmaLinux als je een hostingstack draait (cPanel, CloudLinux), snellere security-patches wilt, of een distributie nodig hebt met een eigen FIPS 140-3-validatie.
• Kies Rocky Linux als je specifiek strikte 1:1 binaire pariteit met RHEL nodig hebt, bug-voor-bug, omdat een leverancier of een interne certificering de identieke build eist.
• Kies RHEL zelf als compliance een betaalde support-SLA en vendor-certificering vereist, en je het abonnement kunt dragen.
• Kies niet voor CentOS Stream als stabiele productiebasis. Het is uitstekend om vooruit te kijken naar RHEL en voor development; het is geen vast point-release-doel.

De rest van dit artikel legt uit waarom, en (want dat is het deel dat elke andere gids overslaat) precies hoe je migreert, met de faalpunten benoemd.

Wat er nu echt verschilt: ABI vs 1:1 binair

Vóór juni 2023 deden de twee projecten hetzelfde: de door Red Hat gepubliceerde RHEL-bronnen herbouwen tot een gratis, identieke distributie. Toen beperkte Red Hat de distributie van RHEL-bronbestanden tot zijn klantenportaal, waardoor CentOS Stream de enige publieke bron overbleef. AlmaLinux en Rocky reageerden verschillend, en dat verschil is de hele beslissing.

Rocky Linux koos ervoor om 1:1 te blijven. Het bouwt nog altijd vanuit de exacte RHEL source-RPM's, verkregen via routes waarvoor je Red Hats abonnementsvoorwaarden niet hoeft te accepteren. In Rocky's eigen woorden uit Keeping Open Source Open: de ene route is "het gebruik van UBI-containerimages die op RHEL zijn gebaseerd," een andere is "pay-per-use publieke cloud-instances… iedereen kan RHEL-images in de cloud opstarten en zo de broncode voor alle pakketten en errata verkrijgen," allemaal "zonder onze toewijding aan open source software te compromitteren of ToS- of EULA-beperkingen te accepteren." Het resultaat is een distributie die is ontworpen om bug-voor-bug identiek te zijn aan RHEL.

AlmaLinux koos in plaats daarvan voor ABI-compatibiliteit. In plaats van byte-identieke pakketten na te jagen, liet AlmaLinux het 1:1-doel los en bouwt het nu vooral vanuit CentOS Stream, gericht op Application Binary Interface-compatibiliteit: "software die op RHEL draait, draait hetzelfde op AlmaLinux." In hun eigen voetnoot betekent ABI-compatibiliteit "eraan werken om te garanderen dat applicaties die zijn gebouwd om op RHEL (of RHEL-klonen) te draaien, zonder problemen op AlmaLinux kunnen draaien." Doordat het vanuit Stream bouwt in plaats van te wachten op uitgebrachte RHEL-bronnen, kan AlmaLinux bovendien sommige fixes vóór de downstream-cadans uitbrengen.

Wat verandert "ABI-compatibel versus 1:1 binair" nu eigenlijk voor een draaiende server? Minder dan het debat doet vermoeden, op drie specifieke plekken:

• RPM's van derden en ISV's: Geen praktisch verschil. Beide voldoen aan de RHEL-ABI, dus alles wat voor RHEL is gebouwd (een vendor-agent, een database-RPM, een monitoringpakket) installeert en draait op beide. Dit is het geval dat voor bijna iedereen telt, en het is geen probleem.
• Kernelmodules (kmods): Beide volgen de RHEL-kernel en zijn kABI, dus vooraf gebouwde out-of-tree modules laden doorgaans op beide. Het theoretische voordeel is voor Rocky: een byte-identieke kernel is een sterkere garantie voor een binaire kmod dan een ABI-garantie. In de praktijk onderhoudt AlmaLinux kABI-pariteit en is er geen gedocumenteerde, reproduceerbare breuk. Zie dit als Rocky's positionering, niet als een waargenomen fout bij AlmaLinux.
• FIPS 140-3: Dit is de ene plek waar de splitsing materieel zichtbaar is. AlmaLinux heeft zijn eigen FIPS 140-3-validatie: de cryptografische modules van AlmaLinux 9.2 zijn gevalideerd (gefinancierd en ingediend door CloudLinux), met latere releases die door NIST's pipeline vorderen. Rocky Linux heeft geen eigen NIST-gevalideerd certificaat; de modules hebben op NIST's Modules-in-Process-lijst gestaan, en FIPS-compliance voor Rocky wordt commercieel aangeboden door CIQ/TuxCare. De crypto-code is bij beide functioneel gelijk aan die van RHEL; het verschil is het certificaat, en als je een inkoopvereiste hebt die "FIPS 140-3 gevalideerd" verplicht stelt, is dat onderscheid het hele verhaal.

Nog een as achter de twee projecten: wie ze financiert en bestuurt. AlmaLinux wordt gesteund door CloudLinux, een founding platinum sponsor die zich vastlegt op zo'n $1M/year, en wordt beheerd door de non-profit AlmaLinux OS Foundation. Rocky Linux wordt gerund door de Rocky Enterprise Software Foundation (RESF), met commerciële support van CIQ. Geen van beide gaat ergens heen; beide leveren al jaren op schema. Dit is niet meer het drama dat het in 2023 was.

CentOS Stream: nuttig, maar geen productiebasis

Het loont om precies te zijn over Stream, want de naam misleidt mensen. Red Hat ontwikkelt RHEL nu in CentOS Stream: Stream wordt "continu geleverd" en "loopt net voor op de ontwikkeling van RHEL." Dat betekent dat Stream wijzigingen ontvangt voordat ze in een uitgebrachte RHEL point release terechtkomen, het tegenovergestelde van het oude CentOS Linux, dat achter RHEL aanliep.

Stream is echt goed voor twee dingen: vooruitkijken naar wat er in de volgende RHEL aankomt, en CI/development tegen de RHEL die er over een paar maanden zal zijn. Het past slecht als vaste productiebasis, omdat het een rolling target is zonder stabiele point releases om aan vast te pinnen. Is je eerste gedachte "CentOS Stream is de natuurlijke voortzetting van CentOS," stel die dan bij; de voortzetting die je zoekt is AlmaLinux of Rocky. Voor context over waar dit alles staat naast Ubuntu en Debian, zie onze hub-gids over het kiezen van een Linux-distributie voor een dedicated server.

Naast elkaar: de dimensies waar je echt op beslist

Twee rijen daarin verdienen extra aandacht omdat ze recent zijn veranderd en echte gevallen beslissen:

cPanel liet Rocky Linux vallen in versie 134. Sinds cPanel & WHM versie 134 (uitgebracht in januari 2026) kun je een Rocky Linux-server niet meer upgraden naar de huidige cPanel; de ondersteunde OS-lijst is AlmaLinux 8/9/10, CloudLinux 8/9/10 en Ubuntu 24.04 LTS, en cPanel raadt expliciet aan om Rocky-servers naar AlmaLinux te converteren. Draai je cPanel, dan beslecht dit alleen al de AlmaLinux-versus-Rocky-vraag. (Controleer dit bij de actuele release notes van cPanel voordat je actie onderneemt; dit is recent en verandert snel.)

Rocky verklaart de vorige minor end-of-life zodra een nieuwe verschijnt. In tegenstelling tot RHEL's Extended Update Support is Rocky's beleid dat zodra, zeg, 9.7 uitkomt, 9.6 meteen end-of-life is. Moet je op een specifieke minor blijven voor een langere kwalificatieperiode, dan is dat een punt in het voordeel van RHEL, niet van Rocky.

Het oordeel, zonder slag om de arm

Elke andere vergelijking eindigt met "beide zijn uitstekend, het hangt ervan af." Hier is de versie die daadwerkelijk een keuze maakt:

• Draai je cPanel of een CloudLinux-stack? → AlmaLinux. cPanel liet Rocky vallen, CloudLinux is het bedrijf achter Alma, en het CloudLinux/Immunify/hardened-kernel-ecosysteem is eromheen gebouwd. Dit is niet eens close.
• Wil je de nieuwste security-patches op een gratis EL? → AlmaLinux. Doordat het vanuit Stream bouwt, kan het sommige fixes vóór de strikte downstream-cadans uitbrengen.
• Heb je een gevalideerde FIPS 140-3-module nodig op een gratis distributie? → AlmaLinux, dat een eigen certificaat heeft. Rocky heeft daar een commerciële add-on voor nodig.
• Heb je een vendor- of interne regel die byte-identieke RHEL-builds eist? → Rocky Linux. Eist een certificering letterlijk "dezelfde binary als RHEL," dan is Rocky's 1:1-model het veilige antwoord.
• Gebonden aan compliance voor een ondersteund, gecertificeerd OS met een SLA? → RHEL, en neem het abonnement erbij. Met onze RHEL dedicated servers breng je je eigen entitlement mee.

Voor de meeste mensen die CentOS in 2026 verlaten, zeker iedereen in hosting, is de pragmatische standaardkeuze AlmaLinux. Rocky is de juiste keuze voor de smallere eis "ik heb bit-voor-bit RHEL nodig." Beide verslaan het blijven hangen op een end-of-life CentOS met een oneindige marge, want "geen security-updates" is geen strategie.

Van CentOS migreren, stap voor stap

Er zijn twee heel verschillende situaties, en ze door elkaar halen is waar mensen zich bezeren:

1. Je zit op CentOS 8 (of een andere EL8/EL9-rebuild) en wilt zijwaarts overstappen naar Rocky of Alma op dezelfde major-versie. Dit is een goed ondersteunde, gescripte in-place conversie.
2. Je zit op CentOS 7 en moet een major-versie oversteken (7 → 8 → 9). Dit is een Leapp-gebaseerde upgrade, die echt lastiger is en je een muur van pre-flight inhibitors voor de voeten werpt. Die muur is de echte inhoud. Elke omgeving stuit erop.

De onderstaande commando's zijn de echte tools, flags en repositories. De getoonde console-output is representatief voor wat elke tool afdrukt, om de vorm van een run te illustreren. Vervang dit door je eigen hostnames en verwacht je eigen pakketaantallen. Draai dit altijd eerst tegen een snapshot of een wegwerpkloon, nooit tegen een productiemachine die je niet kunt terugdraaien.

Voordat je iets aanraakt: de pre-flight checklist

Hetzelfde voor alle drie de paden:

• Maak een volledige snapshot of image-level backup. Deze conversies zijn effectief eenrichtingsverkeer; er is geen schoon "undo"-script. Je rollbackplan is de snapshot (zie hieronder).
• Inventariseer repositories van derden (dnf repolist / yum repolist). EPEL is prima; vendor-repo's (een database, een monitoring-agent, een paneel) kunnen pakketten vastzetten die de conversie tegenwerken. Noteer ze.
• Lijst out-of-tree kernelmodules op (lsmod, DKMS-pakketten): storage/NIC-drivers, ZFS, proprietary agents. Dit zijn de gebruikelijke breekpunten.
• Leg je paneel/control-plane vast (cPanel, Plesk, CloudPanel) en controleer de ondersteunde-OS-matrix voor het doel voordat je begint.
• Bevestig vrije schijfruimte voor een volledige her-download van pakketten en de swap, en dat de machine de doel-repo's kan bereiken.

Pad A: CentOS/EL8 of EL9 → Rocky Linux (migrate2rocky)

Rocky levert migrate2rocky in de rocky-tools-repository. Er zijn twee scripts: migrate2rocky.sh converteert een EL8-systeem naar Rocky 8, en migrate2rocky9.sh converteert EL9 naar Rocky 9. Haal het script op dat bij jouw major-versie past en draai het met -r om de conversie uit te voeren:

# On an EL8 system (CentOS 8 / other EL8 rebuild)
curl -O https://raw.githubusercontent.com/rocky-linux/rocky-tools/main/migrate2rocky/migrate2rocky.sh
chmod +x migrate2rocky.sh
sudo ./migrate2rocky.sh -r

Het script verwijdert de identiteitspakketten van de oude distro, installeert de Rocky release- en GPG-pakketten, wijst elke repo naar Rocky, en herinstalleert het basissysteem vanaf Rocky-mirrors. Een gepubliceerde CentOS 8 → Rocky 8 walkthrough legt de vorm van een echte run vast; hij brengt elke repo in kaart, somt de CentOS-pakketten op die worden verwisseld voor Rocky-equivalenten (centos-linux-release → rocky-release, centos-gpg-keys → rocky-gpg-keys, centos-linux-repos → rocky-repos), en eindigt op Complete! / Done, please reboot your system. Representatieve output:

migrate2rocky - Begin logging at Tue Jul  7 09:14:02 2026.

Removing dnf modules that are not compatible with Rocky Linux...
Identifying repositories to be replaced...
Determining repository names for Rocky Linux...
Repository baseos matched by repository id baseos.
Repository appstream matched by repository id appstream.
Removing distribution packages: centos-linux-release centos-gpg-keys ...
Installing Rocky Linux release package: rocky-release rocky-gpg-keys ...
Switching old release to Rocky Linux release.
Distro-syncing to Rocky Linux ...
...
Complete!
Done, please reboot your system.

Herstart, en bevestig dat je op Rocky bent uitgekomen:

$ cat /etc/redhat-release
Rocky Linux release 8.10 (Green Obsidian)
$ rpm -q rocky-release
rocky-release-8.10-1.5.el8.noarch

Twee waarschuwingen voordat je dit draait op iets waar je om geeft. CIQ, het bedrijf achter Rocky, waarschuwt dat custom-gecompileerde kernelmodules kunnen zorgen voor fouten "die je machine onbruikbaar kunnen achterlaten," dus test dit eerst in een lab; en op een UEFI-machine moet je bij de eerste herstart mogelijk de Rocky-bootoptie handmatig kiezen in GRUB. Er is geen betrouwbare gepubliceerde doorlooptijd voor de conversie; het is een pakketwissel plus een distro-sync, begrensd door download- en dnf-tijd, doorgaans minuten tot tientallen minuten op een bescheiden machine. Neem de tijd op van je eigen snapshot-run om een cijfer te krijgen dat je kunt vertrouwen.

Pad B: CentOS/EL8 of EL9 → AlmaLinux (almalinux-deploy)

AlmaLinux levert almalinux-deploy, één script dat een EL-systeem van dezelfde major (8.4+, 9 of 10) converteert naar AlmaLinux. Het draait eerst een pre-flight compatibiliteitscheck, wisselt dan release-pakketten en herinstalleert vanaf AlmaLinux-repo's:

curl -O https://raw.githubusercontent.com/AlmaLinux/almalinux-deploy/master/almalinux-deploy.sh
sudo bash almalinux-deploy.sh

De statusregels die het almalinux-deploy.sh-script print (elk gevolgd door OK of ERROR) verlopen ongeveer in deze volgorde:

Check root privileges                                               OK
Check Secure Boot disabled                                          OK
Check centos-8.x86_64 is supported                                  OK
Your OS is supported
Download the AlmaLinux GPG public key                               OK
Install almalinux-release package                                   OK
Run dnf distro-sync -y                                               OK
Enabled AlmaLinux repositories that were before the migration       OK
Migration to AlmaLinux is completed

Herstart en verifieer:

$ cat /etc/almalinux-release
AlmaLinux release 8.10 (Cerulean Leopard)

De AlmaLinux-migratiegids stelt de vereisten: de bron moet EL 8.4 of nieuwer zijn, Secure Boot uitgeschakeld (de regel Check Secure Boot disabled is precies waar het script stopt als dat niet zo is), een bootpartitie met ruimte voor drie kernels, en (zoals altijd) eerst een gemaakte snapshot.

Pad C: CentOS 7 → 8 → 9 (ELevate, en de inhibitor-muur)

CentOS 7 is het lastige geval, en het is waar eerlijkheid een nuttige gids onderscheidt van een commando-dump. Je kunt CentOS 7 niet direct naar een versie-9-distributie springen. AlmaLinux' eigen ELevate-gids is expliciet: Leapp voert stapsgewijze upgrades uit, dus het pad is 7 → 8, dan 8 → 9 (en daarna 9 → 10 als je de nieuwste wilt). Elke sprong is een aparte Leapp-run met zijn eigen pre-flight.

ELevate is de Leapp-gebaseerde tooling van het AlmaLinux-project die Red Hats Leapp uitbreidt naar cross-distro, cross-major upgrades. De 7 → 8-run ziet er zo uit:

# Install ELevate + the AlmaLinux migration data
sudo yum install -y http://repo.almalinux.org/elevate/elevate-release-latest-el7.noarch.rpm
sudo yum install -y leapp-upgrade leapp-data-almalinux

# Pre-flight analysis — this is the important part
sudo leapp preupgrade

leapp preupgrade upgradet niets. Het analyseert het systeem en schrijft een rapport naar /var/log/leapp/leapp-report.txt met daarin inhibitors: blokkerende problemen die je moet oplossen voordat Leapp verdergaat. Op een echte CentOS 7-machine kun je er meerdere verwachten, en steeds hetzelfde handjevol keert terug in verslag na verslag. Dit zijn de problemen die mensen daadwerkelijk tegenkomen, geciteerd uit echte rapporten, met de gedocumenteerde fix:

• Verwijderde kernel-drivers. "Detected loaded kernel drivers which have been removed in RHEL 8. Upgrade cannot proceed." De gebruikelijke boosdoeners zijn pata_acpi en floppy (plus de mpt* SCSI-drivers op VMware-guests); unload ze met modprobe -r pata_acpi floppy en draai opnieuw. (Valentin S, Vander Host)
• Het pam_pkcs11-antwoord. "Missing required answers in the answer file" voor remove_pam_pkcs11_module_check.confirm. Leapp laat je dit expliciet bevestigen: leapp answer --section remove_pam_pkcs11_module_check.confirm=True. (CIQ KB)
• Root-login via SSH. "Possible problems with remote login using root account": zet PermitRootLogin yes in /etc/ssh/sshd_config zodat je jezelf na de upgrade niet buitensluit. (Bigstep)
• Een kapotte repo van derden. Slechte vendor-repo-metadata kan de pre-upgrade helemaal stilleggen; één account liep tegen een ModelViolationError aan die werd herleid tot de PostgreSQL PGDG-repo in /etc/yum.repos.d/. Schakel twijfelachtige repo's uit voordat je begint. (ApisCP)

De 8 → 9-sprong voegt dan twee toe die je bij 7 → 8 nog niet zag: "Current x86-64 microarchitecture is unsupported in RHEL9" (fix het CPU-type van de VM: zet het op host of een v2-capabel model op de hypervisor) en "Detected RPMs with RSA/SHA1 signature" (oude pakketten van derden ondertekend met SHA-1). (Vander Host)

Werk het rapport door, los elke inhibitor op, en draai leapp preupgrade opnieuw totdat het schoon terugkomt. Dan pas:

sudo leapp upgrade
sudo reboot   # boots into the upgrade initramfs, applies the transaction, reboots again

Begroot de tijd: de eigenlijke Leapp-upgrade duurt ruwweg 5 tot 10 minuten plus drie herstarts van ~5 minuten (naar de upgrade-initramfs, naar de SELinux-relabel, naar het echte OS), en één CentOS 7-hostingpaneelaccount zette de hele exercise op bijna een uur inclusief opschoning voor en na de upgrade.

Nadat 7 → 8 is geslaagd en het systeem gezond is, herhaal je het ELevate-proces voor 8 → 9. Stapel de sprongen niet zonder de machine ertussenin te verifiëren.

Het rollbackplan (test het voordat je het nodig hebt)

Er is geen betrouwbaar script dat een geconverteerd systeem terugmigreert. Je rollback is de snapshot die je in de pre-flight-stap hebt gemaakt:

1. Maak voordat je begint een volledige VM-snapshot of block-level image van de boot- en datavolumes.
2. Draai de migratie op die machine.
3. Als het mislukt of de machine zich misdraagt, herstel de snapshot; je bent precies terug waar je begon.

Op een hypervisor is dit een rechtermuisklik en een paar minuten; op bare metal betekent het een image van vóór de migratie die je opnieuw kunt uitrollen. Het punt is hetzelfde: draai deze conversies nooit zonder een geteste hersteloptie. Zowel AlmaLinux' migratiegids als CIQ zijn expliciet dat er geen ingebouwde "undo" is (de snapshot is de rollback), en de forums hebben de waarschuwende verhalen die daarbij passen, waaronder een operator die midden in ELevate "vrijwel gebrickt" achterbleef met alleen een verse herinstallatie als terugvaloptie. De "fix forward"-optie bij een mislukte cross-major upgrade kan een lange nacht worden.

Wat er kapotgaat (de eerlijkheidssectie)

De conversies zelf zijn betrouwbaar; de schade zit vrijwel altijd in de dingen die aan het basissysteem vastgeschroefd zijn. Dit zijn echte, gedocumenteerde faalpunten, gehaald uit de issue-trackers en forums van de tools:

• Een verouderde kernelmodule van derden breekt de pre-flight. Eén migrate2rocky-run brak af met een kapotte RPM-database doordat een oude el7 kmod-kvdo-module met zichzelf conflicteerde, eindigend in "Error: Check discovered 95 problem(s)". Ruim out-of-tree modules op en herstel de RPM-database voordat je converteert.
• cPanel/paneel-afhankelijkheidsconflicten tijdens distro-sync. Het converteren van een cPanel-machine naar AlmaLinux liep tegen libstdc++-devel-...el8.alma-versus-stockbibliotheek-conflicten aan die de dnf distro-sync deden mislukken; de workaround was opnieuw draaien met --allowerasing/--skip-broken. Erger nog, een Leapp 8 → 9-upgrade op een cPanel-host wiste alle WHM/cPanel-pakketten bij herstart. Controleer eerst de ondersteunde-OS-matrix van je paneel voor het doel.
• EFI/GRUB valt terug op een grub-prompt na conversie. Een UEFI-machine kwam na migrate2rocky uit bij een kale grub-prompt; de fix was grub2-mkconfig --output=/boot/efi/EFI/rocky/grub.cfg, en Secure Boot moet uitgeschakeld zijn voordat je begint.
• Een verdwaalde Stream-only repo blijft hangen. Na het migreren naar AlmaLinux overleefde een CentOS-Stream-only epel-next-release-pakket en veroorzaakte conflicten totdat het werd verwijderd met dnf remove epel-next-release.
• Configuratiedrift na een major-upgrade. Leapp neemt configuratie mee, maar niet perfect. Verwacht dat je sshd_config, firewalld en SELinux moet reconciliëren (dat tijdens de upgrade terugvalt naar permissive, dus zet het terug naar enforcing), plus elke service waarvan de standaardinstellingen tussen de majors zijn veranderd.

Validatie na de migratie

Welk pad je ook nam, verifieer voordat je het afgerond noemt:

# Confirm the OS identity
cat /etc/os-release

# Any packages still from the old distro? (should be empty/none)
rpm -qa | grep -Ei 'centos' 

# Reconcile everything against the new repos
sudo dnf distro-sync -y

# Repos point where you expect
dnf repolist

# Core services are up
systemctl --failed

dnf distro-sync is de belangrijke: het lijnt elk geïnstalleerd pakket uit met de versie van de doeldistributie, en ruimt alles op wat de conversie tussen twee releases liet hangen. Migreerde je een RHEL-machine (in plaats van CentOS) naar een rebuild, draai dan ook subscription-manager unregister / remove en verwijder subscription-manager zodat het systeem stopt met proberen te praten met Red Hat. Rond af met nog een herstart en het bevestigen van services, en schakel daarna eventuele repo's van derden die je in de pre-flight had uitgeschakeld weer in.

Veelgestelde vragen

Is CentOS Stream veilig voor productie?

Het is stabiel genoeg om te draaien, maar het is een rolling distributie die upstream van RHEL gepositioneerd is, zonder vaste point releases om aan vast te pinnen. Voor de meeste productieomgevingen die een voorspelbaar, gepatcht point-release-doel willen, is AlmaLinux of Rocky de betere keuze. Stream blinkt uit in het vooruitkijken naar RHEL en voor CI/development tegen wat RHEL gaat worden.

Kan ik CentOS 7 rechtstreeks migreren naar AlmaLinux 9 of 10?

Nee. Leapp/ELevate doet één major-versie per run, dus het pad is CentOS 7 → 8, dan 8 → 9, dan 9 → 10: elk een aparte, geverifieerde stap. Er is geen ondersteunde directe sprong van 7 naar een versie-9- of versie-10-distributie. Op veel CentOS 7-omgevingen is een verse versie-9/10-machine uitrollen en data overzetten minder werk dan drie aaneengeschakelde in-place upgrades.

Is AlmaLinux nog steeds 1:1 met RHEL?

Nee, en dat is bewust. Sinds 2023 richt AlmaLinux zich op ABI-compatibiliteit (applicaties gebouwd voor RHEL draaien ongewijzigd op AlmaLinux) in plaats van byte-voor-byte identieke pakketten. Rocky Linux is degene die nog steeds strikte 1:1 binaire pariteit nastreeft. Voor het draaien van software van derden is de ABI-garantie wat telt, en die houdt stand.

AlmaLinux vs Rocky Linux: is de een sneller?

Nee. Beide zijn herbouwd uit dezelfde upstream-bronnen met dezelfde kernel, dus er is geen reproduceerbaar prestatieverschil. Phoronix' EL10-benchmarks laten zien dat AlmaLinux, Rocky en RHEL over tientallen tests heen vrijwel gelijk presteren. Kies op basis van compatibiliteitsmodel, ecosysteem, patch-cadans en FIPS, niet op doorvoersnelheid.

Ondersteunt cPanel Rocky Linux nog?

Niet in de huidige versies. cPanel & WHM liet de ondersteuning voor Rocky Linux vallen in versie 134; de ondersteunde lijst is AlmaLinux, CloudLinux en Ubuntu 24.04. Draai je cPanel, dan is AlmaLinux het migratiedoel. (Controleer dit bij de actuele release notes van cPanel, want dit is recent veranderd.)

Sla de migratie over: deploy vers op Serverside

De schoonste CentOS-exit is vaak helemaal geen in-place conversie; het is een verse machine op de opvolger die je hebt gekozen, met je data en configuratie overgezet. Elke dedicated server van Serverside installeert AlmaLinux en Rocky Linux (en RHEL, bring-your-own-subscription) op bare metal binnen een minuut, zodat je het doel kunt opzetten, je stack kunt valideren, en op je eigen schema kunt overschakelen in plaats van een productiehost te gokken op een eenrichtings-upgrade.

De hardware is identiek welke je ook kiest, en altijd-actieve DDoS-mitigatie op ons ASN 55285-netwerk staat voor de machine, ongeacht de distributie. Weeg je de RHEL-familie nog af tegen Ubuntu of Debian, begin dan met onze Linux-distributiegids; heb je eenmaal gekozen, dan installeren onze CentOS-opvolger dedicated servers AlmaLinux of Rocky voorgeïnstalleerd, en nemen onze RHEL dedicated servers je eigen entitlement mee.