EPEL en CRB inschakelen op Rocky Linux en AlmaLinux

Waarom dnf het gewenste pakket niet kan vinden

EPEL en CRB zijn de twee repositories die een nieuwe Rocky Linux- of AlmaLinux-server niet standaard aanbiedt. Dit is de reden waarom dnf install htop op een nieuwe machine antwoordt met No match for argument: htop en vervolgens Error: Unable to find a match: htop. Er is niets defect en er is geen mirror offline. De basisdistributie levert bewust een kleine set pakketten, CRB is aanwezig maar uitgeschakeld, en EPEL is een afzonderlijke community-repository die u zelf moet toevoegen.

Op Ubuntu bevindt hetzelfde pakket zich in universe, en universe is op bijna elke cloud-image ingeschakeld, waardoor deze vraag nooit opkomt. De Red Hat-familie verdeelt haar pakketten anders en kiest standaard voor minder. De oplossing bestaat uit drie commando's. De rest van deze handleiding behandelt het deel dat niemand u in de eerste week vertelt: wat deze repositories beloven, wat ze niet beloven, en hoe u voorkomt dat een externe repository stilletjes uw basissysteem overneemt.

Hoe deze commando's zijn gecontroleerd. Onze testcontainers voor commando's draaien uitsluitend op Ubuntu, dus de dnf-commando's hieronder zijn niet op onze eigen testmachines uitgevoerd. Ze volgen de documentatie van Rocky Linux en AlmaLinux. Elke stap benoemt de output die u hoort te zien, dus controleer elke stap op uw eigen server in plaats van het hele blok in één keer te plakken.

Wat zijn BaseOS, AppStream en CRB?

BaseOS is het besturingssysteem zelf: de kernel, glibc, systemd en de kern van de userland. Versies in deze repository zijn bevroren voor de gehele levensduur van de major release; beveiligingsupdates worden naar deze bevroren versies geport. Een versienummer in BaseOS dat jaren oud lijkt, betekent niet dat het pakket ongepatcht is. Het is een gepatchte oude versie, wat precies het doel is van een enterprise-distributie.

AppStream bevat de software die u bovenop het systeem draait: webservers, databases, language runtimes, editors en monitoring-agents. In versie 8 werd een groot deel van AppStream geleverd als modules met alternatieve streams, waardoor dnf module list van belang was en u bijvoorbeeld één specifieke PHP-stream koos. Versie 9 heeft bijna alle modulariteit laten vallen, waardoor u op Rocky 9 en Alma 9 doorgaans één versie van een pakket krijgt zonder dat er eerst een module ingeschakeld hoeft te worden.

Extras staat standaard ingeschakeld en is zeer beperkt van omvang. Het bevat voornamelijk release-pakketten voor andere repositories, waar ook epel-release vandaan komt. Dit detail is de reden waarom u nooit een willekeurige URL hoeft te vertrouwen om EPEL op Rocky of Alma te installeren.

CRB is de CodeReady Builder-repository, die in versie 8 nog PowerTools werd genoemd. Deze bevat de ontwikkelkant van de distributie: development headers, statische libraries en de test- en documentatietools die pakketten nodig hebben tijdens het build-proces. Deze repository bevindt zich al op de mirror en staat standaard uitgeschakeld. Bij het product van Red Hat zelf heet dezelfde inhoud CodeReady Linux Builder; dit wordt meegeleverd met het abonnement, waarbij Red Hat aangeeft dat dit niet onder de support valt. Rocky en Alma nemen zowel de inhoud als de standaard uitgeschakelde status over.

Voor lezers die afkomstig zijn van Debian of Ubuntu: main combineert runtime-pakketten en -dev headers in één archief, waardoor er geen CRB ingeschakeld hoeft te worden. De meest vergelijkbare tegenhanger van EPEL is universe, dat door de community wordt onderhouden en geen supportgarantie van een leverancier biedt.

Wat EPEL is en wie erachter staat

EPEL staat voor Extra Packages for Enterprise Linux. Het is een Fedora-project: pakketten die in Fedora bestaan, worden opnieuw gebouwd voor de huidige enterprise-release. Ze worden onderhouden door de EPEL Special Interest Group, die grotendeels uit vrijwilligers van de Fedora-community bestaat. Red Hat host de build- en mirror-infrastructuur en enkele Red Hat-engineers onderhouden pakketten in de repository. Daar houdt de relatie op. EPEL is geen product van Red Hat. Er is geen ondersteuningscontract en geen SLA (service level agreement) verbonden aan een EPEL-pakket, noch op RHEL, noch op een rebuild.

Eén beleidsregel maakt het veilig om EPEL überhaupt in te schakelen: een EPEL-pakket mag nooit een pakket uit de basisdistributie vervangen. Als AppStream nginx levert, zal EPEL dat niet doen. Die regel wordt gehandhaafd door de mensen die EPEL-pakketten beoordelen, dus het is een garantie die uitsluitend voor EPEL geldt. Het beschermt u niet tegen andere bronnen die u later toevoegt.

De levensduurverwachting verschilt ook van de basisdistributie, en dit is waar men in het derde jaar vaak tegenaan loopt. De versie van een BaseOS-pakket is bevroren voor de volledige tienjarige levensduur van de major release. Een EPEL-beheerder committeert zich aan een veel kortere periode: ten minste één RHEL minor release of 13 maanden, afhankelijk van wat korter is. De meeste pakketten worden in de praktijk veel langer onderhouden. Sommige worden uitgefaseerd wanneer de beheerder stopt, en sommige springen naar een nieuwe major-versie midden in de levenscyclus van uw distributie, omdat EPEL Fedora volgt. Een routine-dnf upgrade kan er dus voor zorgen dat u een nieuwe major-versie van een EPEL-tool krijgt op een machine waarvan u dacht dat deze stabiel was, en een pakket waar u afhankelijk van bent kan stoppen met het ontvangen van updates zonder dat u daar een aankondiging van krijgt.

Nog een gevolg dat het waard is om te weten voordat u het inschakelt: EPEL wordt gebouwd tegen de nieuwste RHEL minor release. Als u een server op een oudere minor-versie houdt, door gebruik te maken van een bevroren mirror of een vendor point release-repository, kan een EPEL-pakket een basisbibliotheek vereisen die nieuwer is dan degene die u heeft. dnf rapporteert dit als een ontbrekende afhankelijkheid, en het lijkt op een mirror-probleem terwijl het in werkelijkheid een versie-verschil (version skew) is.

CRB inschakelen en EPEL installeren op Rocky of Alma

sudo dnf install -y dnf-plugins-core
sudo dnf config-manager --set-enabled crb
sudo dnf install -y epel-release
sudo dnf makecache
dnf repolist --enabled

dnf repolist --enabled zou nu baseos, appstream, extras, crb en epel moeten weergeven. Mogelijk ziet u ook een klein epel-cisco-openh264-item, dat epel-release toevoegt. Als crb ontbreekt in die lijst, is de inschakelstap niet verwerkt; de volgende sectie legt uit waarom.

Op Rocky 8 en Alma 8 heet de repository nog steeds PowerTools, dus het middelste commando wordt sudo dnf config-manager --set-enabled powertools. Repository-id's zijn hoofdlettergevoelig en oudere CentOS 8-documentatie spelt het als PowerTools met hoofdletters, wat niet zal matchen. Op AlmaLinux 10 is de CRB-repository standaard ingeschakeld vanaf versie 10.0 (gewijzigd in september 2025), dus daar hoeft u alleen de epel-release-stap uit te voeren.

epel-release is afkomstig van extras, dat al is ingeschakeld, dus er is geen URL om te vertrouwen en geen sleutel om handmatig te importeren. Het pakket schrijft /etc/yum.repos.d/epel.repo en installeert de EPEL-ondertekeningssleutel onder /etc/pki/rpm-gpg/. Bevestig gpgcheck=1 in dat bestand en negeer elke handleiding die u adviseert om een handtekeningfout te omzeilen met --nogpgcheck. Een mislukte handtekeningcontrole betekent dat het pakket niet is wat het beweert te zijn, of dat uw systeemklok onjuist is ingesteld.

Op Rocky installeert epel-release ook een kleine helper op /usr/bin/crb, waardoor sudo crb enable en crb status hetzelfde werk doen zonder de plugin. Controleer of u deze heeft met command -v crb voordat u erop vertrouwt, aangezien deze niet aanwezig is op elke branch van elke rebuild.

Om te bewijzen dat EPEL bereikbaar is in plaats van alleen vermeld, vraagt u om een pakket dat alleen in die repository voorkomt:

dnf repoquery --repo=epel htop

Dit toont de pakketnaam, versie en architectuur. Stilte betekent dat de repository is ingeschakeld maar niets retourneert, wat meestal een mirror- of metadataprobleem is in plaats van een configuratiefout; probeer in dat geval sudo dnf clean all && sudo dnf makecache.

Waarom dnf de melding 'no such command: config-manager' geeft

Dit is het eerste struikelblok voor veel gebruikers, en het komt precies voor bij de images die de meeste VPS-providers aanbieden.

No such command: config-manager. Please use /usr/bin/dnf --help
It could be a DNF plugin command, try: "dnf install 'dnf-command(config-manager)'"

config-manager is een plugin, geen ingebouwd dnf-subcommando. Het wordt geleverd in dnf-plugins-core, dat bij een volledige serverinstallatie automatisch wordt meegeïnstalleerd, maar bij minimale images, cloud-images en container-images wordt weggelaten. De suggestie van dnf zelf werkt omdat het pakket die virtuele functionaliteit declareert:

sudo dnf install -y 'dnf-command(config-manager)'

Plaats het tussen aanhalingstekens. De haakjes zijn shell-syntax; een versie zonder aanhalingstekens resulteert in een syntaxfout in plaats van een dnf-fout.

Als u de plugin niet kunt installeren omdat de benodigde repository is uitgeschakeld, bewerk dan handmatig het bestand. Zoek welk bestand de sectie bevat, open het en stel enabled=1 in onder [crb]:

grep -rl crb /etc/yum.repos.d/

Dit is precies wat config-manager doet, dus er gaat niets verloren door dit handmatig uit te voeren. dnf repolist --enabled bevestigt het resultaat.

Sommige EPEL-pakketten installeren niet voordat CRB is ingeschakeld

De tweede veelvoorkomende valkuil levert een foutmelding op die nooit naar CRB verwijst. Een EPEL-pakket dat linkt naar een bibliotheek die alleen in CRB wordt geleverd, faalt tijdens de afhankelijkheidsresolutie. Het bericht noemt hierbij de bibliotheek en het pakket dat deze vereist:

Error:
 Problem: conflicting requests
  - nothing provides libexample.so.0()(64bit) needed by examplepkg-1.4-2.el9.x86_64 from epel

De oorzaak is dat CRB is uitgeschakeld, waardoor dnf de enige repository die deze bibliotheek aanbiedt niet kan zien. Controleer de volgende twee zaken in deze volgorde:

dnf repolist --enabled
dnf --enablerepo=crb repoquery --whatprovides 'libexample.so.0()(64bit)'

Als het tweede commando een pakket noemt terwijl de standaard installatie nog steeds faalt, dan staat CRB uit. Dit type fout komt zo vaak voor dat AlmaLinux CRB in versie 10 standaard heeft ingeschakeld om dit specifiek te voorkomen. --enablerepo=crb werkt ook als een eenmalige vlag bij een enkele installatie, maar laat CRB permanent ingeschakeld als u EPEL gebruikt. Een volgende EPEL-update kan namelijk zonder waarschuwing vooraf een nieuwe CRB-afhankelijkheid vereisen.

Uit welke repository is dit pakket afkomstig?

Na een paar weken met vier ingeschakelde repositories is de relevante vraag niet langer wat er is geïnstalleerd, maar waar het vandaan komt.

dnf repolist --all
dnf info htop
dnf repoquery --installed --qf '%{from_repo} %{name}' | sort | uniq -c | sort -rn
dnf repository-packages epel list installed

dnf info op een geïnstalleerd pakket toont een From repo-regel. dnf list installed toont dezelfde informatie in de derde kolom met een @ ervoor; zo betekent @epel dat het pakket is geïnstalleerd vanuit EPEL, en @System betekent dat dnf niet weet waar het vandaan komt, wat meestal inhoudt dat iemand rpm -i heeft uitgevoerd op een gedownload bestand. De repoquery-regel geeft een telling per repository; dit is de snelste manier om te ontdekken dat een server die u heeft overgenomen veertig pakketten bevat uit een repository waar u nog nooit van heeft gehoord. Het laatste commando geeft een exacte lijst van wat één repository u heeft geleverd, en die inventarisatie heeft u nodig voordat u besluit deze te verwijderen.

De gewoonte in apt is apt-cache policy <package>, en de dnf en apt commando equivalenten zijn de eerste maand het waard om in een tweede tabblad open te houden, omdat de concepten goed overeenkomen, zelfs als de flags dat niet doen.

Hoe voorkom ik dat een externe repository een basispakket vervangt?

EPEL belooft dit niet te doen. Geen enkele andere repository biedt deze garantie. Een vendor-repository voor een database, een agent of een runtime-omgeving kan een eigen build van een bibliotheek leveren die ook door BaseOS wordt aangeboden. dnf zal deze installeren, omdat de standaardregel van dnf eenvoudig is: de hoogste versie wint, ongeacht de bron.

Twee instellingen doen het meeste werk en beide bevinden zich in het repository-bestand onder /etc/yum.repos.d/.

priority= bepaalt welke repository wint wanneer meerdere repositories hetzelfde pakket aanbieden. Lagere getallen winnen en de standaardwaarde is 99. Geef uw basis-repositories daarom een laag getal en elke externe repository een hoog getal. dnf kiest dan het basispakket, zelfs als de externe versie nieuwer is. Moderne dnf-versies regelen dit zelf, waardoor het afzonderlijke yum-plugin-priorities-pakket uit het CentOS 7-tijdperk niet langer nodig is.

includepkgs= is de krachtigere filteroptie. excludepkgs= blokkeert specifieke pakketten uit een repository, waarvoor u moet voorspellen wat deze zou kunnen leveren. includepkgs= draait dit om: deze repository mag uitsluitend deze namen leveren en niets anders. Een vendor-repository die alleen zijn eigen agent mag leveren, vereist slechts één regel.

[vendor-tools]
name=Vendor tools for EL9
baseurl=https://packages.example.com/el9/x86_64/
enabled=1
gpgcheck=1
gpgkey=https://packages.example.com/RPM-GPG-KEY-vendor
priority=90
includepkgs=vendor-agent,vendor-agent-plugins

Op versie 8 is er nog één instelling die u moet kennen. Een pakket uit een externe repository kan verborgen zijn wanneer een AppStream-module dezelfde naam levert, en module_hotfixes=1 in de sectie van die repository vertelt dnf om dit filteren te stoppen. Als een pakket zichtbaar is voor dnf repoquery maar niet wil installeren op een versie 8-systeem, is dit meestal de oorzaak. Versie 9 heeft bijna alle modules verwijderd, dus dit komt daar zelden voor.

Om één pakket vast te pinnen op één versie, installeert u python3-dnf-plugin-versionlock en gebruikt u sudo dnf versionlock add <package>. Dit is het equivalent van apt-mark hold. Let op één cruciaal verschil voor gebruikers die van Debian komen: in apt wint een hoger Pin-Priority-getal, in dnf wint een lager priority-getal.

Waarom het mengen van RHEL-gerelateerde repositories een server on-upgradebaar maakt

Rocky, Alma, CentOS Stream, Oracle Linux en RHEL liggen dicht genoeg bij elkaar om elkaars pakketten te installeren, maar ver genoeg uit elkaar om een systeem te creëren dat door niemand ondersteund kan worden.

Het mechanisme hierachter is versienummering. CentOS Stream 9 loopt vooruit op RHEL 9. Als u een Rocky 9-systeem naar een Stream-repository wijst, zelfs eenmalig of voor slechts één pakket, blijft u zitten met pakketten waarvan de versies hoger zijn dan wat Rocky ooit zal uitbrengen. Wanneer de volgende Rocky minor-release verschijnt, is de versie van dat pakket lager dan de uwe, waardoor dnf upgrade het pakket niet zal aanpassen. De machine draait nu een combinatie die door niemand is getest en blijft jarenlang in deze staat, terwijl u ervan uitgaat dat het systeem wordt gepatcht.

Het symptoom is dat dnf upgrade meldt dat er niets te doen is, terwijl sudo dnf distro-sync voorstelt om een lange lijst met pakketten te downgraden. distro-sync is het reparatiegereedschap: het dwingt elk geïnstalleerd pakket om overeen te komen met wat de ingeschakelde repositories daadwerkelijk aanbieden, inclusief downgrades. Schakel eerst de externe repository uit, voer het commando uit en lees de voorgestelde lijst door voordat u deze accepteert. De reparatie mislukt wanneer het oudere RPM-pakket niet langer op de mirror staat; op dat punt is het opnieuw opbouwen van de server vanaf een schone image sneller en veiliger dan het bevechten van de dependency solver.

Restanten uit het ELevate-tijdperk zijn de andere veelvoorkomende variant van dit probleem. ELevate is de migratietool van AlmaLinux, gebaseerd op Leapp, die wordt gebruikt om een CentOS 7-systeem te upgraden of om te converteren tussen rebuilds. Een overhaaste migratie laat EL7-repositorybestanden achter in /etc/yum.repos.d/ en laat EL7-pakketten geïnstalleerd staan. Zoek deze op met rpm -qa | grep el7. Elk van deze pakketten kan door geen enkele ingeschakelde repository worden bijgewerkt, en een latere Leapp-run zal ze rapporteren als pakketten die niet gemapt kunnen worden, wat een blokkade vormt voor de upgrade die u handmatig moet oplossen. Verwijder ze terwijl de server stabiel is, niet op de dag dat u de volgende grote upgrade moet uitvoeren.

Een vendor-repository die een AppStream-pakket overschaduwt, is de milde versie van hetzelfde probleem, en de includepkgs-regel hierboven is de oplossing. Container-tooling is het meest voorkomende geval, omdat containerd.io uit de eigen repository van Docker conflicteert met runc uit AppStream; één van beide moet dus verdwijnen. Maak een keuze, noteer de uitsluiting en volg een beproefde volgorde: de Docker installatie op Rocky Linux-handleiding beschrijft welke distributiepakketten u als eerste moet verwijderen.

De vertaling van apt naar dnf voor repositories

• /etc/apt/sources.list.d/*.sources wordt /etc/yum.repos.d/*.repo, waarbij één bestand meerdere [sections] kan bevatten, elk met een eigen id.
• add-apt-repository universe wordt dnf install epel-release, met het verschil dat universe zich nog steeds in het eigen archief van Ubuntu bevindt en EPEL een afzonderlijk project is.
• apt update heeft geen equivalent dat u moet onthouden. dnf ververst metadata volgens een eigen schema en dnf makecache dwingt dit nu af.
• apt-cache policy <pkg> wordt dnf info <pkg>, plus dnf list --showduplicates <pkg> om alle beschikbare versies te zien.
• apt-mark hold wordt dnf versionlock add, vanuit python3-dnf-plugin-versionlock.
• Pinning in /etc/apt/preferences.d/ wordt priority= in de repository-sectie, waarbij de getallen in omgekeerde volgorde werken.
• dpkg -S /path/to/file wordt rpm -qf /path/to/file.

Automatische updates worden eerder als concept dan als syntax overgedragen, aangezien er hier geen unattended-upgrades is. De timer, het configuratiebestand en de vraag of een herstart nodig is, worden behandeld in dnf-automatic op Rocky en Alma.

Houd de lijst met repositories kort

Schakel CRB in, installeer epel-release en noteer vervolgens wat u heeft gedaan en waarom, hetzij in uw configuratiebeheersysteem, hetzij in een tekstbestand op de server zelf. Deze aantekening is waardevoller dan het lijkt wanneer de server drie jaar oud is en iemand anders het beheer voert.

Zoek voordat u iets toevoegt. Voer dnf search uit, gevolgd door dnf info, en overweeg pas daarna een nieuwe repository. Een verrassend groot deel van de software waarvoor mensen EPEL inschakelen, is al aanwezig in AppStream. Systeemmonitoring is hiervan het duidelijkste voorbeeld, aangezien Performance Co-Pilot in de basisrepositories zit en geen externe partijen vereist. Elke extra repository is een extra partij die u op een dinsdag een pakket kan sturen, en elke toevoeging maakt de volgende grote upgrade complexer.

Als u nog steeds kiest tussen de twee distributies: deze gehele opzet is op beide identiek en epel-release gedraagt zich hetzelfde. De werkelijke verschillen liggen elders: de vergelijking tussen Rocky Linux en AlmaLinux behandelt de filosofie achter de rebuild, aangezien AlmaLinux zich nu richt op ABI-compatibiliteit (application binary interface) in plaats van een letterlijke rebuild regel voor regel.

FAQ

Hoe schakel ik EPEL in op Rocky Linux 9 of AlmaLinux 9?

Voer sudo dnf install -y dnf-plugins-core uit, gevolgd door sudo dnf config-manager --set-enabled crb en daarna sudo dnf install -y epel-release. Bevestig met dnf repolist --enabled; dit zou baseos, appstream, extras, crb en epel moeten weergeven. Schakel CRB in voordat u EPEL-pakketten installeert, omdat veel van deze pakketten afhankelijk zijn van bibliotheken die alleen door CRB worden geleverd. Op versie 8 is de repository-id powertools in plaats van crb.

Is het veilig om EPEL in te schakelen op een productieserver?

Het wordt op grote schaal gebruikt en is gebouwd op het beleid dat EPEL-pakketten nooit een pakket uit de basisdistributie vervangen. Het inschakelen ervan verandert dus niets aan wat BaseOS of AppStream u biedt. Het voorbehoud is de ondersteuning: EPEL is een Fedora-vrijwilligersproject zonder service level agreement, en een beheerder verbindt zich aan een pakket voor slechts één RHEL minor release of 13 maanden. Houd een inventaris bij met dnf repository-packages epel list installed en gebruik dnf versionlock voor elk EPEL-pakket waarvan een klantgerichte service afhankelijk is.

Waarom zegt dnf dat het commando config-manager niet bestaat?

Omdat config-manager een dnf-plugin is en geen ingebouwd commando, en minimale images of container-images worden geleverd zonder dnf-plugins-core. Het bericht zelf geeft de oplossing: sudo dnf install -y 'dnf-command(config-manager)', tussen aanhalingstekens zodat de shell de haakjes niet interpreteert. Als u nog niets kunt installeren, voer dan grep -rl crb /etc/yum.repos.d/ uit, open het bestand dat wordt genoemd en stel handmatig enabled=1 in onder de sectie [crb].

Wat is het verschil tussen CRB en PowerTools?

Dit is dezelfde repository onder twee verschillende namen. Versie 8 noemt het PowerTools met de id powertools, versie 9 en later noemen het CRB met de id crb, en het eigen product van Red Hat noemt de inhoud CodeReady Linux Builder. Het bevat development headers, statische bibliotheken en build-tools, en het is standaard uitgeschakeld op Rocky en op AlmaLinux 9. AlmaLinux 10 schakelt het standaard in vanaf 10.0, dus controleer dnf repolist --enabled voordat u daar het inschakelcommando uitvoert.

Hoe verwijder ik EPEL weer zonder dingen te verbreken?

Inventariseer eerst met dnf repository-packages epel list installed, omdat het verwijderen van alleen het pakket epel-release niets verwijdert dat vanuit EPEL is geïnstalleerd. Die pakketten blijven op de schijf staan, verliezen hun bron voor updates en ontvangen geen beveiligingspatches meer, zonder dat u hiervan een foutmelding krijgt. Beslis per pakket, verwijder of vervang de pakketten die u niet langer nodig heeft, en voer pas daarna sudo dnf remove epel-release uit. Als iets uit EPEL niets heeft vervangen en simpelweg weg moet, wist sudo dnf repository-packages epel remove de set in één transactie; lees de voorgestelde lijst dus zorgvuldig door voordat u deze bevestigt.