Rocky Linux und AlmaLinux: EPEL und CRB aktivieren

Warum dnf das gewünschte Paket nicht findet

EPEL und CRB sind die beiden Repositorys, die ein frisch installiertes Rocky-Linux- oder AlmaLinux-System nicht standardmäßig bereitstellt. Deshalb antwortet dnf install htop auf einem neuen System mit No match for argument: htop und anschließend mit Error: Unable to find a match: htop. Es ist nichts defekt, und kein Mirror ist ausgefallen. Die Basisdistribution liefert absichtlich nur eine kleine Auswahl an Paketen. CRB ist vorhanden, aber deaktiviert. EPEL ist ein separates Community-Repository, das Sie hinzufügen müssen.

Unter Ubuntu liegt dasselbe Paket in universe. universe ist auf fast jedem Cloud-Image aktiviert, daher stellt sich diese Frage dort nicht. Die Red-Hat-Familie teilt ihre Pakete anders auf und aktiviert standardmäßig weniger Repositorys. Die Lösung besteht aus drei Befehlen. Der Rest dieses Leitfadens behandelt den Teil, den Ihnen in der ersten Woche niemand erklärt: was diese Repositorys bereitstellen, was sie nicht bereitstellen und wie Sie verhindern, dass ein Repository eines Drittanbieters unbemerkt Ihr Basissystem übernimmt.

So wurden diese Befehle geprüft. Unsere Container für Befehlstests führen ausschließlich Ubuntu aus. Daher wurden die dnf-Befehle unten nicht auf unseren eigenen Testsystemen ausgeführt. Sie basieren auf der Dokumentation von Rocky Linux und AlmaLinux. Jeder Schritt nennt die erwartete Ausgabe. Prüfen Sie daher jeden Schritt auf Ihrem eigenen Server, statt den gesamten Block auf einmal einzufügen.

Was sind BaseOS, AppStream und CRB?

BaseOS ist das Betriebssystem selbst: der Kernel, glibc, systemd und die grundlegenden Userland-Komponenten. Die Versionen bleiben während der gesamten Hauptversion unverändert. Sicherheitskorrekturen werden in diese eingefrorenen Versionen zurückportiert. Eine Versionsnummer, die in BaseOS mehrere Jahre alt aussieht, bedeutet nicht, dass das Paket ungepatcht ist. Es handelt sich um eine gepatchte alte Version. Genau das ist der Zweck einer Enterprise-Distribution.

AppStream enthält die Komponenten, die Sie darauf ausführen: Webserver, Datenbanken, Laufzeitumgebungen für Programmiersprachen, Editoren und Monitoring-Agenten. In Version 8 wurde ein großer Teil von AppStream als Module mit alternativen Streams bereitgestellt. Deshalb war dnf module list relevant, und Sie wählten beispielsweise einen PHP-Stream aus. Version 9 hat die Modularität nahezu vollständig abgeschafft. Auf Rocky 9 und Alma 9 erhalten Sie daher normalerweise eine Version der jeweiligen Komponente, ohne zuerst ein Modul aktivieren zu müssen.

Extras ist standardmäßig aktiviert und sehr klein. Es enthält hauptsächlich Release-Pakete für andere Repositorys. Von dort stammt auch epel-release selbst. Deshalb müssen Sie niemals einer beliebigen URL vertrauen, um EPEL auf Rocky oder Alma zu installieren.

CRB ist das Repository CodeReady Builder und wird in Version 8 PowerTools genannt. Es enthält die Komponenten für die Erstellung von Paketen: Entwicklungs-Header, statische Bibliotheken sowie Test- und Dokumentationswerkzeuge, die Pakete beim Erstellen benötigen. Das Repository ist bereits auf dem Mirror vorhanden, aber standardmäßig deaktiviert. Im eigenen Produkt von Red Hat heißt derselbe Inhalt CodeReady Linux Builder. Er ist im Abonnement enthalten, und Red Hat erklärt, dass er nicht vom Support abgedeckt ist. Rocky und Alma übernehmen sowohl den Inhalt als auch die standardmäßige Deaktivierung.

Für Leser, die von Debian oder Ubuntu kommen: main enthält Laufzeitpakete und -dev-Header in einem gemeinsamen Archiv. Deshalb müssen Sie dort kein CRB aktivieren. Das nächste Gegenstück zu EPEL ist universe. Es wird von der Community gepflegt und beinhaltet keine Zusage des Herstellers für Support.

Was EPEL ist und wer dahintersteht

EPEL steht für Extra Packages for Enterprise Linux. EPEL ist ein Fedora-Projekt: Pakete aus Fedora werden für das aktuelle Enterprise-Release neu gebaut und von der EPEL Special Interest Group gepflegt, die größtenteils aus Freiwilligen aus der Fedora-Community besteht. Red Hat hostet die Build- und Mirror-Infrastruktur, und einige Red-Hat-Entwickler pflegen Pakete in EPEL. Damit endet die Verbindung. EPEL ist kein Red-Hat-Produkt. Für ein EPEL-Paket gibt es weder einen Supportvertrag noch ein SLA (Service Level Agreement), weder auf RHEL noch auf einem Rebuild.

Eine Richtlinie macht es überhaupt sicher, EPEL zu aktivieren: Ein EPEL-Paket darf niemals ein Paket aus der Basisdistribution ersetzen. Wenn AppStream nginx ausliefert, tut EPEL das nicht. Diese Regel wird von den Personen durchgesetzt, die EPEL-Pakete prüfen. Sie gilt daher nur als Zusage für EPEL. Vor allem schützt sie Sie nicht vor anderen Quellen, die Sie später hinzufügen.

Auch die Zusage zur Lebensdauer unterscheidet sich von der der Basisdistribution. Das zeigt sich häufig im dritten Jahr. Die Version eines BaseOS-Pakets bleibt während der gesamten zehnjährigen Lebensdauer eines Major-Releases unverändert. Ein EPEL-Maintainer verpflichtet sich zu einem deutlich kürzeren Zeitraum: mindestens für ein RHEL-Minor-Release oder 13 Monate, je nachdem, welcher Zeitraum kürzer ist. In der Praxis werden die meisten Pakete deutlich länger gepflegt. Einige werden eingestellt, wenn der Maintainer das Projekt verlässt. Andere wechseln während der Lebensdauer Ihrer Distribution zu einer neuen Major-Version, weil EPEL Fedora folgt. Daher kann ein routinemäßiges dnf upgrade auf einem System, das Sie für stabil hielten, eine neue Major-Version eines EPEL-Tools installieren. Außerdem kann ein Paket, von dem Sie abhängen, ohne eine für Sie sichtbare Ankündigung keine Updates mehr erhalten.

Vor der Aktivierung sollten Sie noch eine weitere Folge kennen: EPEL wird gegen das neueste RHEL-Minor-Release gebaut. Wenn Sie einen Server auf einem älteren Minor-Release halten und dafür einen eingefrorenen Mirror oder ein Repository eines Anbieters für ein bestimmtes Point-Release verwenden, kann ein EPEL-Paket eine neuere Basisbibliothek voraussetzen als die auf Ihrem System vorhandene. dnf meldet das als fehlende Abhängigkeit. Das sieht wie ein Mirror-Problem aus, ist aber tatsächlich ein Versionsabweichungsproblem.

CRB aktivieren und EPEL auf Rocky oder Alma installieren

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 sollte jetzt baseos, appstream, extras, crb und epel auflisten. Möglicherweise sehen Sie außerdem einen kleinen epel-cisco-openh264-Eintrag, den epel-release hinzufügt. Fehlt crb in dieser Liste, wurde der Aktivierungsschritt nicht übernommen. Im nächsten Abschnitt wird erklärt, warum.

Auf Rocky 8 und Alma 8 heißt das Repository weiterhin PowerTools. Daher lautet der mittlere Befehl sudo dnf config-manager --set-enabled powertools. Repository-IDs berücksichtigen Groß- und Kleinschreibung. In älterer Dokumentation zu CentOS 8 wird PowerTools mit Großbuchstaben geschrieben. Das stimmt nicht überein. Unter AlmaLinux 10 ist das CRB-Repository ab 10.0 standardmäßig aktiviert. Diese Änderung erfolgte im September 2025. Dort müssen Sie daher nur den Schritt epel-release ausführen.

epel-release stammt aus extras, das bereits aktiviert ist. Daher müssen Sie keiner URL vertrauen und keinen Schlüssel manuell importieren. Das Paket schreibt /etc/yum.repos.d/epel.repo und installiert den EPEL-Signaturschlüssel unter /etc/pki/rpm-gpg/. Bestätigen Sie gpgcheck=1 in dieser Datei. Ignorieren Sie Anleitungen, die bei einem Signaturfehler eine Umgehung mit --nogpgcheck empfehlen. Eine fehlgeschlagene Signaturprüfung bedeutet, dass das Paket nicht dem erwarteten Inhalt entspricht oder dass die Systemzeit falsch ist.

Auf Rocky installiert epel-release außerdem ein kleines Hilfsprogramm unter /usr/bin/crb. Daher erfüllen sudo crb enable und crb status dieselbe Aufgabe ohne das Plugin. Prüfen Sie mit command -v crb, ob es vorhanden ist, bevor Sie sich darauf verlassen. Es ist nicht in jedem Zweig jedes Rebuilds enthalten.

Um zu bestätigen, dass EPEL erreichbar ist und nicht nur aufgelistet wird, fragen Sie dort ein Paket ab, das ausschließlich dieses Repository enthält:

dnf repoquery --repo=epel htop

Der Befehl gibt Paketname, Version und Architektur aus. Keine Ausgabe bedeutet, dass das Repository aktiviert ist, aber keine Ergebnisse liefert. Meist liegt dann ein Mirror- oder Metadatenproblem vor und kein Konfigurationsfehler. Versuchen Sie anschließend sudo dnf clean all && sudo dnf makecache.

Warum dnf „no such command: config-manager“ meldet

Das ist der erste Punkt, an dem viele hängen bleiben. Das passiert genau bei den Images, die die meisten VPS-Anbieter bereitstellen.

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 ist ein Plugin und kein integrierter dnf-Unterbefehl. Es wird mit dnf-plugins-core bereitgestellt. Eine vollständige Serverinstallation installiert dieses Paket normalerweise mit. Minimale Images, Cloud-Images und Container-Images enthalten es dagegen nicht. Der eigene Vorschlag von dnf funktioniert, weil das Paket diese virtuelle Funktion bereitstellt:

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

Setzen Sie den Befehl in Anführungszeichen. Die Klammern sind Shell-Syntax. Eine Version ohne Anführungszeichen schlägt deshalb mit einem Syntaxfehler fehl und nicht mit einem dnf-Fehler.

Wenn Sie das Plugin nicht installieren können, weil das benötigte Repository deaktiviert ist, bearbeiten Sie stattdessen die Datei. Ermitteln Sie, welche Datei den Abschnitt enthält, öffnen Sie sie und setzen Sie enabled=1 unter [crb]:

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

Genau das schreibt config-manager. Wenn Sie die Einstellung manuell vornehmen, geht daher nichts verloren. dnf repolist --enabled bestätigt das Ergebnis.

Einige EPEL-Pakete lassen sich erst installieren, wenn CRB aktiviert ist

Die zweite häufige Falle führt zu einem Fehler, in dem CRB nicht erwähnt wird. Ein EPEL-Paket, das mit einer Bibliothek verknüpft ist, die nur in CRB bereitgestellt wird, scheitert bei der Abhängigkeitsauflösung. Die Meldung nennt die Bibliothek und das Paket, das sie benötigt:

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

Die Ursache ist, dass CRB deaktiviert ist. Daher kann dnf das einzige Repository, das diese Bibliothek bereitstellt, nicht durchsuchen. Prüfen Sie die beiden Punkte in dieser Reihenfolge:

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

Wenn der zweite Befehl ein Paket nennt, während die einfache Installation weiterhin fehlschlägt, ist CRB deaktiviert. Dieser Fehlertyp tritt häufig genug auf, dass AlmaLinux CRB in Version 10 standardmäßig aktiviert hat, um ihn zu verhindern. --enablerepo=crb funktioniert bei einer einzelnen Installation ebenfalls als einmalig verwendete Option. Wenn Sie EPEL verwenden, sollten Sie CRB jedoch dauerhaft aktiviert lassen, da ein späteres EPEL-Update ohne vorherige Warnung eine neue CRB-Abhängigkeit einführen kann.

Aus welchem Repository stammt dieses Paket?

Nach einigen Wochen mit vier aktivierten Repositorys lautet die nützliche Frage nicht mehr, was installiert ist, sondern woher es stammt.

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 für ein installiertes Paket gibt eine Zeile mit From repo aus. dnf list installed zeigt dieselben Informationen in der dritten Spalte mit einem vorangestellten @ an. Daher bedeutet @epel, dass das Paket aus EPEL installiert wurde. @System bedeutet, dass dnf nicht weiß, woher das Paket stammt. Das heißt normalerweise, dass jemand rpm -i für eine heruntergeladene Datei ausgeführt hat. Die Zeile repoquery enthält die Anzahl der Pakete pro Repository. Damit erkennen Sie am schnellsten, dass ein übernommener Server vierzig Pakete aus einem Repository enthält, von dem Sie noch nie gehört haben. Der letzte Befehl listet genau auf, was ein Repository bereitgestellt hat. Diese Bestandsaufnahme benötigen Sie, bevor Sie das Repository entfernen.

Die entsprechende apt-Gewohnheit lautet apt-cache policy <package>. Die Befehlsentsprechungen von dnf und apt sollten Sie im ersten Monat in einem zweiten Tab geöffnet lassen, weil sich die Konzepte sauber übertragen lassen, auch wenn die Flags nicht identisch sind.

Wie verhindere ich, dass ein Drittanbieter-Repository ein Basispaket ersetzt?

EPEL verspricht, dies nicht zu tun. Für kein anderes Repository gilt das. Ein Hersteller-Repository für eine Datenbank, einen Agenten oder eine Laufzeitumgebung kann einen eigenen Build einer Bibliothek bereitstellen, die auch BaseOS anbietet. dnf installiert diesen Build, weil die Standardregel von dnf einfach ist: Die höchste Version gewinnt, unabhängig von ihrer Quelle.

Zwei Einstellungen erledigen den größten Teil der Arbeit. Beide befinden sich in der Repository-Datei unter /etc/yum.repos.d/.

priority= legt fest, welches Repository gewinnt, wenn mehrere Repositorys denselben Paketnamen enthalten. Niedrigere Werte gewinnen. Der Standardwert ist 99. Geben Sie Ihren Basis-Repositorys daher einen niedrigen Wert und jedem Drittanbieter-Repository einen hohen Wert. dnf verwendet dann das Basispaket, selbst wenn die Version des Drittanbieters neuer ist. Moderne dnf-Versionen erledigen dies selbst. Das separate yum-plugin-priorities-Paket aus der Zeit von CentOS 7 ist daher nicht mehr Teil der Lösung.

includepkgs= ist die stärkere Filteroption. excludepkgs= blockiert benannte Pakete aus einem Repository. Dafür müssen Sie vorhersehen, welche Pakete es möglicherweise bereitstellt. includepkgs= kehrt dieses Verhalten um: Dieses Repository darf diese Namen bereitstellen und nichts anderes. Ein Hersteller-Repository, das ausschließlich den eigenen Agenten bereitstellen soll, benötigt dafür nur eine Zeile.

[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

Für Version 8 gibt es eine weitere wichtige Einstellung. Ein Paket aus einem Drittanbieter-Repository kann ausgeblendet werden, wenn ein AppStream-Modul denselben Namen bereitstellt. module_hotfixes=1 in diesem Repository-Abschnitt weist dnf an, die Filterung dieses Pakets zu beenden. Wenn ein Paket für dnf repoquery sichtbar ist, sich auf einem System mit Version 8 aber nicht installieren lässt, ist das normalerweise der Grund. Version 9 hat fast alle Module entfernt. Dort tritt dieses Problem daher nur selten auf.

Um ein Paket auf eine bestimmte Version festzulegen, installieren Sie python3-dnf-plugin-versionlock und verwenden Sie sudo dnf versionlock add <package>. Das entspricht apt-mark hold. Beachten Sie eine Umkehrung, die Nutzer von Debian häufig verwirrt: In apt gewinnt ein höherer Pin-Priority-Wert. In dnf gewinnt ein niedrigerer priority-Wert.

Warum das Mischen von RHEL-nahen Repositorys einen Server nicht mehr aktualisierbar macht

Rocky, Alma, CentOS Stream, Oracle Linux und RHEL sind ähnlich genug, dass sich ihre Pakete gegenseitig installieren lassen. Sie unterscheiden sich aber genug, dass am Ende ein System entsteht, das niemand mehr unterstützen kann.

Der Mechanismus beruht auf Versionsnummern. CentOS Stream 9 liegt vor RHEL 9. Wenn Sie ein Rocky-9-System auch nur einmal oder für ein einzelnes Paket auf ein Stream-Repository verweisen, bleiben Pakete mit Versionen zurück, die Rocky niemals ausliefern wird. Sobald das nächste Rocky-Minor-Release erscheint, ist dessen Version dieses Pakets niedriger als Ihre installierte Version. Daher wird dnf upgrade das Paket nicht anfassen. Das System verwendet dann eine Kombination, die niemand getestet hat. Dieser Zustand bleibt möglicherweise jahrelang unbemerkt bestehen, während Sie davon ausgehen, dass das System gepatcht ist.

Das typische Symptom ist, dass dnf upgrade keine ausstehenden Aktualisierungen meldet, während sudo dnf distro-sync vorschlägt, eine lange Liste von Paketen herunterzustufen. distro-sync ist das Reparaturwerkzeug. Es erzwingt, dass jedes installierte Paket zu den tatsächlich von den aktivierten Repositorys angebotenen Versionen passt, einschließlich Downgrades. Deaktivieren Sie zuerst das fremde Repository. Führen Sie anschließend das Werkzeug aus und prüfen Sie die vorgeschlagene Liste, bevor Sie sie bestätigen. Die Reparatur schlägt fehl, wenn das ältere RPM nicht mehr auf dem Mirror verfügbar ist. Dann ist es schneller und sicherer, den Server aus einem sauberen Image neu aufzubauen, als den Dependency Solver zu bekämpfen.

ELevate-Überreste sind eine weitere häufige Variante dieses Problems. ELevate ist das auf Leapp basierende Migrationstool von AlmaLinux. Es wird verwendet, um ein CentOS-7-System weiterzuentwickeln oder zwischen Rebuilds zu konvertieren. Eine überhastete Migration hinterlässt EL7-Repository-Dateien in /etc/yum.repos.d/ und weiterhin installierte EL7-Pakete. Finden Sie diese mit rpm -qa | grep el7. Jedes dieser Pakete kann von keinem aktivierten Repository aktualisiert werden. Bei einem späteren Leapp-Lauf werden sie als Pakete gemeldet, die keinem Zielpaket zugeordnet werden können. Dadurch werden sie zu einer Upgrade-Blockade, die Sie manuell beseitigen müssen. Entfernen Sie diese Überreste, solange der Server stabil läuft, nicht an dem Tag, an dem Sie das nächste Major-Upgrade benötigen.

Ein Vendor-Repository, das ein AppStream-Paket überschreibt, ist die mildere Variante derselben Krankheit. Die oben gezeigte includepkgs-Zeile behebt sie. Container-Werkzeuge sind der häufigste Fall, weil containerd.io aus dem eigenen Repository von Docker mit runc aus AppStream kollidiert. Eines der beiden Pakete muss daher entfernt werden. Treffen Sie die Entscheidung einmal, dokumentieren Sie den Ausschluss und halten Sie eine bewährte Reihenfolge ein: Die Anleitung Docker-Installation unter Rocky Linux beschreibt, welche Distributionspakete zuerst entfernt werden müssen.

Die Übersetzung von apt zu dnf bei Paketquellen

• /etc/apt/sources.list.d/*.sources wird zu /etc/yum.repos.d/*.repo. Eine Datei kann mehrere [sections] enthalten, jeweils mit einer eigenen ID.
• add-apt-repository universe wird zu dnf install epel-release. Der Unterschied besteht darin, dass universe weiterhin im eigenen Ubuntu-Archiv liegt, während EPEL ein separates Projekt ist.
• Für apt update gibt es kein entsprechendes Gegenstück. dnf aktualisiert die Metadaten nach einem eigenen Zeitplan, und dnf makecache erzwingt die Aktualisierung sofort.
• apt-cache policy <pkg> wird zu dnf info <pkg>. Mit dnf list --showduplicates <pkg> werden zusätzlich alle verfügbaren Versionen angezeigt.
• apt-mark hold wird zu dnf versionlock add aus python3-dnf-plugin-versionlock.
• Das Pinning in /etc/apt/preferences.d/ wird im Repository-Abschnitt zu priority=. Die Zahlen laufen dabei in umgekehrter Richtung.
• dpkg -S /path/to/file wird zu rpm -qf /path/to/file.

Automatische Updates lassen sich eher als Konzept denn als Syntax übertragen, da es hier kein unattended-upgrades gibt. Der Timer, die Konfigurationsdatei und die Frage, ob ein Neustart durchgeführt werden soll, werden in dnf-automatic unter Rocky und Alma behandelt.

Repositoryliste kurz halten

Aktivieren Sie CRB, installieren Sie epel-release und dokumentieren Sie anschließend, was Sie getan haben und warum. Verwenden Sie dafür entweder Ihr Configuration Management oder eine einfache Datei auf dem Server. Diese Notiz ist wichtiger, als es zunächst klingt, wenn der Server drei Jahre alt ist und von jemand anderem verwaltet wird.

Suchen Sie, bevor Sie ein Repository hinzufügen. Führen Sie dnf search und anschließend dnf info aus. Erst danach sollten Sie ein neues Repository in Betracht ziehen. Ein überraschend großer Teil der Pakete, für die EPEL aktiviert wird, ist bereits in AppStream enthalten. Die Systemüberwachung ist das deutlichste Beispiel: Performance Co-Pilot wird in den Basis-Repositories bereitgestellt und benötigt keinerlei Repository eines Drittanbieters. Jedes zusätzliche Repository ist eine weitere Stelle, die Ihnen an einem Dienstag ein Paket bereitstellen kann. Außerdem erschwert jedes zusätzliche Repository das nächste Major-Upgrade.

Wenn Sie noch zwischen den beiden Distributionen wählen, ist diese gesamte Struktur bei beiden gleich. Auch epel-release verhält sich identisch. Die tatsächlichen Unterschiede liegen an anderer Stelle: der Vergleich zwischen Rocky Linux und AlmaLinux behandelt die jeweilige Rebuild-Philosophie. AlmaLinux zielt inzwischen auf ABI-Kompatibilität (application binary interface) statt auf einen zeilengetreuen Rebuild.

FAQ

Wie aktiviere ich EPEL unter Rocky Linux 9 oder AlmaLinux 9?

Führen Sie sudo dnf install -y dnf-plugins-core, anschließend sudo dnf config-manager --set-enabled crb und danach sudo dnf install -y epel-release aus. Bestätigen Sie die Aktivierung mit dnf repolist --enabled. Dabei sollten baseos, appstream, extras, crb und epel aufgelistet werden. Aktivieren Sie CRB, bevor Sie EPEL-Pakete installieren, weil viele davon Bibliotheken benötigen, die nur CRB bereitstellt. In Version 8 lautet die Repository-ID powertools statt crb.

Ist es sicher, EPEL auf einem Produktivserver zu aktivieren?

EPEL wird häufig eingesetzt und basiert auf der Richtlinie, dass EPEL-Pakete niemals ein Paket aus der Basisdistribution ersetzen. Durch die Aktivierung ändert sich daher nicht, welche Pakete Ihnen BaseOS oder AppStream bereitstellen. Der Vorbehalt betrifft den Support: EPEL ist ein von Freiwilligen betreutes Fedora-Projekt ohne Service-Level-Agreement. Außerdem verpflichtet sich ein Maintainer unter Umständen nur für ein RHEL-Minor-Release oder 13 Monate zur Pflege eines Pakets. Führen Sie mit dnf repository-packages epel list installed eine Bestandsaufnahme durch. Verwenden Sie dnf versionlock für jedes EPEL-Paket, von dem ein kundenorientierter Dienst abhängt.

Warum meldet dnf no such command: config-manager?

Weil config-manager ein dnf-Plugin und kein integrierter Befehl ist. Minimale Images oder Container-Images werden ohne dnf-plugins-core ausgeliefert. Die Meldung nennt bereits die Lösung: sudo dnf install -y 'dnf-command(config-manager)'. Setzen Sie den Ausdruck in Anführungszeichen, damit die Shell die Klammern nicht interpretiert. Wenn Sie noch nichts installieren können, führen Sie grep -rl crb /etc/yum.repos.d/ aus, öffnen Sie die darin genannte Datei und setzen Sie enabled=1 im Abschnitt [crb] manuell.

Was ist der Unterschied zwischen CRB und PowerTools?

Es handelt sich unter zwei Namen um dasselbe Repository. Version 8 nennt es PowerTools mit der ID powertools. Version 9 und höher verwenden die Bezeichnung CRB mit der ID crb. Red Hat bezeichnet denselben Inhalt als CodeReady Linux Builder. Das Repository enthält Entwicklungs-Header, statische Bibliotheken und Werkzeuge für die Build-Zeit. Unter Rocky und AlmaLinux 9 ist es standardmäßig deaktiviert. AlmaLinux 10 aktiviert es ab 10.0 standardmäßig. Prüfen Sie daher mit dnf repolist --enabled den Status, bevor Sie dort den Aktivierungsbefehl ausführen.

Wie entferne ich EPEL wieder, ohne Probleme zu verursachen?

Erstellen Sie zuerst mit dnf repository-packages epel list installed eine Bestandsaufnahme. Das alleinige Entfernen des Pakets epel-release entfernt keine aus EPEL installierten Pakete. Diese Pakete bleiben auf dem System, verlieren ihre Update-Quelle und erhalten ohne Fehlermeldung keine Sicherheitsaktualisierungen mehr. Entscheiden Sie für jedes Paket einzeln, ob Sie es noch benötigen. Entfernen oder ersetzen Sie nicht mehr benötigte Pakete und führen Sie erst danach sudo dnf remove epel-release aus. Wenn ein EPEL-Paket nichts ersetzt und vollständig entfernt werden soll, entfernt sudo dnf repository-packages epel remove die betreffende Paketmenge in einer Transaktion. Lesen Sie die vorgeschlagene Liste daher sorgfältig, bevor Sie die Aktion bestätigen.