RHEL 9 versus RHEL 10: praktische verschillen voor Linux-specialisten

RHEL 10 (uitgekomen mei 2025, codenaam "Coughlan") is geen incrementele update van RHEL 9 — het is op een aantal punten een bewuste breuk met oudere subsystemen. Voor wie dagelijks met RHEL werkt, of zich voorbereidt op RHCSA/RHCE, zijn een paar van die breuken direct relevant voor hoe je servers inricht en beheert. Dit artikel focust op wat in de praktijk daadwerkelijk anders werkt, niet op elke losse featurewijziging.

1. Hardware-eis: x86-64-v3 is nu verplicht

Dit is waarschijnlijk de meest onderschatte wijziging. RHEL 10 vereist een CPU die voldoet aan het x86-64-v3-microarchitectuurniveau — met name AVX2, BMI1/BMI2, FMA en MOVBE. RHEL 9 draaide nog op het bredere x86-64-v2-niveau.

Praktische impact: Oudere servers en VM's (grofweg vóór 2013, afhankelijk van de exacte CPU-generatie) kunnen RHEL 10 helemaal niet installeren — geen kwestie van performance, de installatie weigert simpelweg te starten. Controleer dit expliciet bij elk upgradetraject, vóórdat je tijd steekt in de rest van de voorbereiding.

cat /proc/cpuinfo | grep -o 'avx2|bmi1|bmi2|fma|movbe' | sort -u

2. Kernel: van 5.14 naar 6.12 LTS

Geen kleine puntversie-sprong, maar een overstap naar een nieuwere LTS-kernellijn, met verbeterde io_uring-ondersteuning, betere eBPF-mogelijkheden en bredere hardware-enablement. Voor de meeste dagelijkse beheertaken merk je dit niet direct, maar het is relevant als je met kernelmodules, eBPF-tooling, of zeer recente hardware werkt.

3. Netwerkconfiguratie: ifcfg-bestanden zijn weg

Dit raakt vrijwel elke ervaren RHEL-beheerder die nog gewend is aan het klassieke formaat. Het oude ifcfg-configuratieformaat (bestanden onder /etc/sysconfig/network-scripts/) wordt niet langer ondersteund. NetworkManager gebruikt nu uitsluitend zijn eigen keyfile-formaat.

# /etc/sysconfig/network-scripts/ifcfg-eth0nDEVICE=eth0nBOOTPROTO=staticnIPADDR=192.168.1.50nNETMASK=255.255.255.0nONBOOT=yes

nmcli connection add type ethernet con-name eth0 ifname eth0 \n  ipv4.addresses 192.168.1.50/24 \n  ipv4.method manual \n  connection.autoconnect yes

# /etc/NetworkManager/system-connections/eth0.nmconnectionn[connection]nid=eth0ntype=ethernetninterface-name=eth0nn[ipv4]naddress1=192.168.1.50/24nmethod=manual

Migratietip: Bestaande RHEL 9-servers met ifcfg-bestanden migreren niet automatisch bij een in-place upgrade naar RHEL 10 — controleer dit expliciet vóór een upgrade, en converteer waar nodig naar nmcli-commando's of keyfiles.

4. iptables: uit actief onderhoud

nftables is al sinds RHEL 8/9 het achterliggende mechanisme, maar RHEL 10 zet een volgende stap: iptables (inclusief de iptables-legacy-compatibiliteitslaag) valt buiten actief onderhoud. Voor wie nog scripts of firewall-regels op basis van iptables-commando's heeft, is dit het moment om definitief naar nft of firewalld te migreren.

iptables -L -n -vn# Vergelijk met de nftables-equivalent:nnft list ruleset

5. AppStream-modulariteit verwijderd: pakketinstallatie verandert

RHEL 9 gebruikte module streams om meerdere versies van bijvoorbeeld MariaDB, MySQL en PostgreSQL parallel aan te bieden. RHEL 10 heeft die modulariteit losgelaten — databases worden nu als gewone RPM-pakketten aangeboden, met de versie in de pakketnaam verwerkt.

dnf module enable postgresql:16ndnf install postgresql-server

dnf install postgresql16-server

Komt Red Hat later met een nieuwere PostgreSQL-versie voor RHEL 10, dan verschijnt die simpelweg als een nieuw pakket (bijvoorbeeld postgresql17-server) naast het bestaande, in plaats van als nieuwe modulestream.

6. Python: standaard 3.9 naar 3.12

De systeem-Python-versie springt van 3.9 (RHEL 9) naar 3.12 (RHEL 10) — relevant voor scripts en automatisering die op syntax of gedrag van een specifieke Python-versie leunen.

python3 --version

7. Podman 5 en uitsluitend cgroups v2

RHEL 10 draait op Podman 5, en cgroups v1-compatibiliteit is volledig verdwenen — alleen cgroups v2 wordt nog ondersteund. Voor de meeste moderne container-workloads (die al langer op v2 leunen) merk je hier weinig van, maar oudere, zelfgeschreven monitoring- of resource-beheer-scripts die specifiek v1-bestandspaden aanspreken, werken niet meer ongewijzigd.

8. Wayland-only (desktop-omgevingen)

Xorg is verwijderd ten gunste van uitsluitend Wayland. Voor pure serverbeheer zonder grafische omgeving is dit niet relevant, maar bij RHEL-desktopinstallaties (of servers met een grafische beheerinterface) is dit een aandachtspunt bij remote-desktop- of VNC-gebaseerde workflows die specifiek van Xorg afhankelijk waren.

9. Image mode: een nieuw, optioneel deploymentmodel

RHEL 10 introduceert image mode, gebaseerd op bootc: een manier om RHEL als een onveranderlijke (immutable) container-achtige image te beheren en te updaten, vergelijkbaar met hoe je container-images bouwt en versioneert. Dit is optioneel — de traditionele, pakketgebaseerde aanpak (dnf) blijft volledig beschikbaar en is voor de meeste bestaande omgevingen nog steeds de standaardkeuze.

Examentip (RHCSA/RHCE): Voor de huidige generatie examens (gebaseerd op RHEL 9) is dit nog geen examenstof — maar als Red Hat de examens naar RHEL 10 optrekt, verwacht dan vooral vragen over de ifcfg-naar-NetworkManager-overgang en de AppStream-modulariteit, aangezien dat de meest praktische, dagelijkse-beheer-relevante wijzigingen zijn.

10. DHCP-client: dhclient volledig verwijderd

Een wijziging die makkelijk over het hoofd wordt gezien: het dhcp-client-pakket (met daarin dhclient, de ISC DHCP-client) is volledig verwijderd uit RHEL 10 — niet alleen gedepreceerd zoals in RHEL 9.5+, maar daadwerkelijk niet meer beschikbaar. Reden: ISC onderhoudt de DHCP-client zelf niet langer upstream.

dnf install dhcp-clientnnmcli connection modify eth0 ipv4.dhcp=dhclient

# "dhcp=dhclient" is geen geldige optie meer — de interne client is de enige optiennmcli connection show eth0 | grep ipv4.dhcp

Voor DHCP-servers geldt hetzelfde principe: ISC DHCP is vervangen door Kea DHCP als de aanbevolen, meegeleverde oplossing.

11. Red Hat Lightspeed: een optionele AI-assistent op de command line

RHEL 9.6 en RHEL 10 introduceren een optionele, natuurlijke-taal command-line-assistent, aangedreven door Red Hat Lightspeed (met Google Gemini als onderliggend taalmodel). Je stelt een vraag in gewone taal; de assistent put uit RHEL-documentatie en Red Hat Knowledgebase-artikelen om te antwoorden.

dnf install command-line-assistantnc "help me uitzoeken waarom deze server traag opstart"

Realistische verwachting: De assistent heeft geen directe toegang tot de status van je eigen systeem — hij kan bijvoorbeeld niet zelf het vrije geheugen aflezen, maar vertelt je wél welk commando (zoals systemd-analyze) je daarvoor kunt gebruiken. Zie het als een doorzoekbare, natuurlijke-taal-ingang tot de Red Hat-documentatie, niet als een systeem dat je server zelf analyseert.

Wat juist níet is veranderd

Even belangrijk als de wijzigingen hierboven: een aantal kernonderdelen van RHEL-beheer is functioneel ongewijzigd, en die kennis blijft dus direct bruikbaar.

• LVM — Logical Volume Manager blijft de standaard opslagbenadering, met dezelfde commando's (pvcreate, vgcreate, lvcreate, lvextend, enz.). Geen wezenlijke functionele wijzigingen tussen RHEL 9 en RHEL 10 gevonden — een standaardinstallatie zet nog steeds root/home op als logical volumes binnen een volume group, zoals je dat al gewend bent.
• systemd — nog steeds het init-systeem en de manier waarop services beheerd worden (systemctl), geen fundamentele architectuurwijziging.
• SELinux — blijft actief en werkt volgens hetzelfde model; RHEL 10 brengt vooral verbeterde tooling eromheen, geen ander onderliggend concept.

Praktisch: Als je RHCSA/RHCE-kennis grotendeels uit LVM-, systemd- en SELinux-vaardigheden bestaat, blijft het grootste deel daarvan direct overdraagbaar naar RHEL 10 — de wijzigingen in dit artikel zitten vooral in netwerkconfiguratie en packaging, niet in deze kernonderdelen.

Bonus: een veelvoorkomende LVM-valkuil (geen RHEL 10-verschil, maar wel de moeite waard)

Loop je tegen een situatie aan waarin pvcreate of vgcreate een schijf weigert, terwijl die er volgens lsblk gewoon staat? De oorzaak is bijna altijd de LVM devices file — en dit is, in tegenstelling tot wat je zou verwachten, geen RHEL 10-wijziging: dit gedrag is al standaard actief sinds RHEL 9. LVM houdt sinds die versie een expliciete lijst bij van goedgekeurde apparaten in /etc/lvm/devices/system.devices, en negeert schijven die daar niet in staan — ook als ze verder prima zichtbaar zijn voor de kernel.

sudo lvmdevices --adddev /dev/sdXnsudo pvcreate /dev/sdX

# In /etc/lvm/lvm.conf, binnen de devices-sectie:nuse_devicesfile = 0

Waarom dit bestaat: Zonder devices file scant LVM bij het opstarten elk blockdevice op het systeem, wat op machines met veel schijven (of in geclusterde/SAN-omgevingen) onnodig lang kan duren en risico geeft dat LVM per ongeluk schijven van een ander systeem oppikt. De devices file maakt dat gedrag expliciet en voorspelbaar — de prijs is dat je een nieuwe schijf soms bewust moet "aanmelden" met lvmdevices vóórdat LVM het gebruikt.

Praktisch stappenplan bij een upgrade-overweging

1. Controleer CPU-compatibiliteit (x86-64-v3) op alle betrokken servers vóórdat je iets anders doet
2. Inventariseer welke servers nog ifcfg-bestanden gebruiken
3. Controleer scripts/automatisering op iptables-commando's en Python-versie-afhankelijkheden
4. Controleer welke module-stream-gebaseerde database-installaties er draaien
5. Test eerst op een niet-productie-omgeving — een in-place upgrade van RHEL 9 naar RHEL 10 raakt meerdere subsystemen tegelijk

Veelgestelde vragen

Kan ik gewoon in-place upgraden van RHEL 9 naar RHEL 10?

Technisch ondersteunt Red Hat een in-place upgradepad, maar gezien het aantal onderliggende wijzigingen (netwerkformaat, CPU-eis, packaging) is een zorgvuldige inventarisatie vooraf verstandiger dan blind te upgraden.

Werken oude ifcfg-bestanden nog als fallback?

Nee — dit is geen deprecatie met een genadeperiode, het formaat wordt niet meer ingelezen. Elke server die hier nog op leunt, moet vóór de upgrade naar NetworkManager-keyfiles of nmcli-commando's geconverteerd worden.