EPEL und CRB auf Rocky Linux und AlmaLinux aktivieren

Warum dnf das gewünschte Paket nicht findet

EPEL und CRB sind die beiden Repositorys, die ein neu eingerichteter Rocky-Linux- oder AlmaLinux-Server nicht standardmäßig mitbringt. 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 befindet sich dasselbe Paket in universe. universe ist auf nahezu 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 Quellen. Die Lösung besteht aus drei Befehlen. Der restliche Teil dieses Leitfadens behandelt den Punkt, den Ihnen in der ersten Woche niemand erklärt: Welche Pakete diese Repositorys bereitstellen, welche 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 verwenden ausschließlich Ubuntu. Daher wurden die dnf-Befehle unten nicht auf unseren eigenen Testsystemen ausgeführt. Sie entsprechen 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 ändern sich während der Lebensdauer eines Major-Releases nur selten. Die meisten Korrekturen, einschließlich Sicherheitskorrekturen, werden in die bereits vorhandene Version zurückportiert. Gelegentlich aktualisiert ein Minor-Release jedoch eine zentrale Komponente auf eine neuere Upstream-Version. AlmaLinux 9.2 aktualisierte beispielsweise die SELinux-User-Space-Pakete auf Version 3.5. Eine Versionsnummer, die in BaseOS mehrere Jahre alt aussieht, gehört daher nicht zu einem ungepatchten Paket. 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, Sprachlaufzeiten, 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. Version 9 liefert die Standardversion jeder Anwendung als gewöhnliches Paket. Auf Rocky 9 und Alma 9 installiert ein einfaches dnf install daher diese Version, ohne dass Sie zuvor ein Modul aktivieren müssen. Alternative Versionen werden weiterhin als Modul-Streams bereitgestellt: RHEL 9 dokumentiert PHP 8.0 als gewöhnliches php-Paket sowie PHP 8.1 und 8.2 als php:8.1- und php:8.2-Streams. AlmaLinux 9.8 fügte neue Streams hinzu, beispielsweise MariaDB 11.8, PostgreSQL 18 und Ruby 4.0. Wenn Sie eine andere als die Standardversion benötigen, ist dnf module list unter Version 9 weiterhin relevant.

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 zufälligen URL vertrauen, um EPEL auf Rocky oder Alma zu installieren.

CRB ist das CodeReady-Builder-Repository und wird in Version 8 PowerTools genannt. Es enthält die Komponenten der Distribution für den Build-Prozess: 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 wird derselbe Inhalt CodeReady Linux Builder genannt. Er ist im Abonnement enthalten, und Red Hat gibt an, dass er nicht vom Support abgedeckt ist. Rocky und Alma übernehmen sowohl den Inhalt als auch die Deaktivierung als Standard.

Für Leser, die von Debian oder Ubuntu kommen: main kombiniert Laufzeitpakete und -dev-Header in einem Archiv. Deshalb gibt es dort kein CRB, das aktiviert werden muss. Das nächste Gegenstück zu EPEL ist universe. Es wird von der Community gepflegt und beinhaltet keine Zusage für Herstellersupport.

Was EPEL ist und wer dahintersteht

EPEL steht für Extra Packages for Enterprise Linux. Es ist ein Fedora-Projekt: Pakete, die in Fedora vorhanden sind, für das aktuelle Enterprise-Release neu gebaut und von der EPEL Special Interest Group gepflegt werden, die überwiegend aus Freiwilligen aus der Fedora-Community besteht. Red Hat hostet die Build- und Mirror-Infrastruktur, und einige Red-Hat-Engineers pflegen Pakete darin. Damit endet die Beziehung. EPEL ist kein Red-Hat-Produkt. Hinter einem EPEL-Paket steht weder auf RHEL noch auf einem Rebuild ein Supportvertrag und kein SLA (Service Level Agreement).

Eine Richtlinie macht es überhaupt sicher, EPEL zu aktivieren: Ein EPEL-Paket darf niemals ein Paket aus der Basisdistribution ersetzen. Wenn AppStream nginx ausliefert, wird EPEL das nicht tun. Diese Regel wird von den Personen durchgesetzt, die EPEL-Pakete prüfen. Sie ist daher nur eine 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 wird im dritten Jahr problematisch. Ein BaseOS-Paket behält seine Version während der gesamten zehnjährigen Lebensdauer des Major-Releases normalerweise bei. Fehlerbehebungen werden in diese Version zurückportiert, und nur gelegentlich erfolgt ein bewusstes Rebase. Ein EPEL-Maintainer verpflichtet sich zu einem deutlich kürzeren Zeitraum: Der Vorschlag zu den paketbasierten EPEL-Release-Laufzeiten formuliert dies als mindestens 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 ausgemustert, wenn der Maintainer die Pflege beendet. Andere wechseln mitten in der Lebensdauer Ihrer Distribution zu einer neuen Major-Version, weil EPEL Fedora folgt. Ein routinemäßiges dnf upgrade kann Ihnen daher auf einem vermeintlich stabilen System eine neue Major-Version eines EPEL-Tools installieren. Außerdem kann ein von Ihnen benötigtes Paket ohne Ankündigung, die Sie erreicht, keine Updates mehr erhalten. Eine neue Version wird in einem bereits laufenden Dienst ebenfalls nicht aktiv. needs-restarting zeigt Ihnen daher nach Abschluss der Transaktion, welche Prozesse noch die alte Binärdatei verwenden.

Eine weitere Folge sollten Sie kennen, bevor Sie EPEL aktivieren: EPEL wird nicht gegen das ältere Minor-Release gebaut, auf dem Sie einen Server möglicherweise festhalten. Die Fedora-EPEL-Richtlinie baut die führende EPEL-10-Minor-Version gegen CentOS Stream 10 und die nachfolgenden EPEL-10-Minor-Versionen gegen bestimmte RHEL-10-Minor-Releases. EPEL 8 und 9 haben eigene Zieldefinitionen. Wenn Sie einen Server mit einem eingefrorenen Mirror oder einem Repository eines Anbieters für ein bestimmtes Point-Release auf einem älteren Minor-Release halten, kann ein EPEL-Paket eine neuere Basisbibliothek voraussetzen als die bei Ihnen installierte. dnf meldet das als fehlende Abhängigkeit. Das sieht wie ein Mirror-Problem aus, ist aber tatsächlich ein Versionsabweichungsproblem.

CRB aktivieren und EPEL unter 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 anzeigen. 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.

Unter Rocky 8 und Alma 8 heißt das Repository weiterhin PowerTools. Der mittlere Befehl lautet dort daher sudo dnf config-manager --set-enabled powertools. Repository-IDs unterscheiden zwischen Groß- und Kleinschreibung. In älterer CentOS-8-Dokumentation wird es mit Großbuchstaben als PowerTools geschrieben. Diese Schreibweise stimmt nicht überein. Unter AlmaLinux 10 ist das CRB-Repository ab 10.0 standardmäßig aktiviert (geändert im September 2025). Dort müssen Sie daher nur den Schritt epel-release ausführen.

epel-release stammt aus extras, das bereits aktiviert ist. Sie müssen daher 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 einen Workaround mit --nogpgcheck empfehlen. Eine fehlschlagende Signaturprüfung bedeutet, dass das Paket nicht dem behaupteten Inhalt entspricht oder die Systemzeit falsch ist.

Unter Rocky installiert epel-release außerdem einen kleinen Helfer unter /usr/bin/crb. Damit erledigen sudo crb enable und crb status dieselbe Aufgabe ohne das Plugin. Prüfen Sie mit command -v crb, ob dieser Helfer vorhanden ist, bevor Sie sich darauf verlassen. Er ist nicht in jedem Zweig jedes Rebuilds enthalten.

Um nachzuweisen, dass EPEL erreichbar ist und nicht nur aufgelistet wird, fragen Sie das Repository nach einem Paket ab, das nur dort verfügbar ist:

dnf repoquery --repo=epel htop

Der Befehl gibt den Paketnamen, die Version und die 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 meldet: „no such command: config-manager“

Das ist das erste Problem, auf das viele stoßen. Es tritt genau bei den Images auf, die viele VPS-Provider 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. Minimal-Images, Cloud-Images und Container-Images enthalten es dagegen nicht. Der eigene Vorschlag von dnf funktioniert, weil das Paket diese virtuelle Fähigkeit deklariert:

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 daher mit einem Syntaxfehler und nicht mit einem dnf-Fehler fehl.

Wenn Sie das Plugin nicht installieren können, weil das benötigte Repository deaktiviert ist, bearbeiten Sie die Datei stattdessen direkt. 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. Durch die manuelle Änderung 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 gegen eine Bibliothek verlinkt ist, die ausschließlich in CRB bereitgestellt wird, schlägt bei der Abhängigkeitsauflösung fehl. Die Meldung nennt dabei 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 mit dieser Bibliothek 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, die einfache Installation aber weiterhin fehlschlägt, ist CRB deaktiviert. Diese Fehlerklasse tritt häufig genug auf, dass AlmaLinux CRB in Version 10 standardmäßig aktiviert hat, um sie zu verhindern. --enablerepo=crb funktioniert auch als einmaliges Flag bei einer einzelnen Installation. Lassen Sie CRB jedoch dauerhaft aktiviert, wenn Sie EPEL überhaupt verwenden, da das nächste 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 Repositories lautet die wichtige 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 @. Daher bedeutet @epel, dass das Paket aus EPEL installiert wurde. @System bedeutet, dass dnf nicht weiß, woher das Paket stammt. Das ist normalerweise der Fall, wenn jemand rpm -i für eine heruntergeladene Datei ausgeführt hat. Die Zeile repoquery enthält eine Anzahl 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, welche Pakete ein Repository bereitgestellt hat. Diese Bestandsaufnahme benötigen Sie, bevor Sie es entfernen.

Das entsprechende apt-Muster lautet apt-cache policy <package>. Die Entsprechungen der dnf- und apt-Befehle sollten Sie im ersten Monat in einem zweiten Tab geöffnet lassen, weil die Konzepte auch dann direkt vergleichbar sind, wenn die Flags unterschiedlich sind.

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

EPEL verspricht, dies nicht zu tun. Für kein anderes Repository gilt dieses Versprechen. 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 Herkunft.

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

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

includepkgs= ist die stärkere der Filteroptionen. 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

Unter Version 8 gibt es noch eine weitere wichtige Einstellung. Ein Paket aus einem Drittanbieter-Repository kann ausgeblendet werden, wenn ein AppStream-Modul denselben Namen bereitstellt. module_hotfixes=1 im Abschnitt dieses Repositorys weist dnf an, das Paket nicht zu filtern. Wenn ein Paket, das das Hersteller-Repository nachweislich führt, auf einem System mit Version 8 als nicht vorhanden gemeldet wird oder sich nicht installieren lässt, ist dies meist die Ursache: Das modulare Filtern macht das Paket für die meisten dnf-Befehle unsichtbar, statt einen Konflikt zu melden. Version 9 enthält zwar weniger Module, stellt aber weiterhin Modulstreams bereit. Daher kann dort derselbe Filter greifen, wenn ein Herstellerpaket denselben Namen wie ein Modulpaket trägt.

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

Warum das Mischen von RHEL-nahen Repositories einen Server nicht mehr upgradefähig macht

Rocky, Alma, CentOS Stream, Oracle Linux und RHEL sind ähnlich genug, dass sich ihre Pakete gegenseitig installieren lassen. Sie unterscheiden sich aber weit genug, dass daraus ein System entsteht, für das niemand Support leisten kann. Warum sie sich so ähnlich sind und warum Stream inzwischen vor RHEL statt parallel dazu liegt, beschreibt die Geschichte der Aufteilung von Red Hat Linux in Fedora und RHEL und die weitere Entwicklung von CentOS.

Der Mechanismus beruht auf Versionsnummern. CentOS Stream 9 liegt vor RHEL 9, und Red Hat beschreibt den Code von Stream als das, was zur nächsten Minor-Version von RHEL wird. Wenn Sie ein Rocky-9-System auch nur einmal und nur für ein Paket auf ein Stream-Repository verweisen, verwenden Sie anschließend Pakete, deren Versionen über den aktuell von Rocky ausgelieferten Versionen liegen. Eine spätere Rocky-Minor-Version kann aufholen. Es ist aber nicht garantiert, dass sie dieses Paket mit Ihrer Version oder einer höheren Version ausliefert. Bis dahin wird dnf upgrade es nicht anfassen. Das System verwendet nun eine Kombination, die niemand getestet hat. Dieser Zustand kann jahrelang unbemerkt bestehen bleiben, während Sie davon ausgehen, dass das System aktuell gepatcht ist.

Das typische Symptom ist, dass dnf upgrade meldet, es gebe nichts zu tun, während sudo dnf distro-sync das Downgrade einer langen Paketliste vorschlägt. distro-sync ist das Reparaturwerkzeug. Es erzwingt, dass jedes installierte Paket der Version entspricht, die von den aktivierten Repositories tatsächlich angeboten wird. Das schließt Downgrades ein. Deaktivieren Sie zuerst das fremde Repository. Führen Sie anschließend das Werkzeug aus. Lesen Sie die vorgeschlagene Liste, bevor Sie sie bestätigen. Die Reparatur schlägt fehl, wenn das ältere RPM nicht mehr auf dem Mirror vorhanden ist. In diesem Fall ist es schneller und sicherer, den Server aus einem sauberen Image neu aufzubauen, statt den Dependency Solver zu erzwingen.

Übrig gebliebene ELevate-Dateien sind eine weitere häufige Ausprägung dieses Problems. ELevate ist das auf Leapp basierende Migrationstool von AlmaLinux. Es dient dazu, ein CentOS-7-System weiterzuentwickeln oder zwischen Rebuilds zu wechseln. Eine überstürzte 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 nicht zugeordnet werden können. Dadurch blockieren sie das Upgrade und müssen manuell entfernt werden. Bereinigen Sie solche Überreste, solange der Server stabil läuft, nicht erst an dem Tag, an dem Sie das nächste Major-Upgrade benötigen.

Ein Vendor-Repository, das ein AppStream-Paket überschattet, ist die mildere Variante desselben Problems. Die oben genannte Zeile includepkgs behebt es. Container-Tools sind der häufigste Fall. containerd.io aus dem Repository von Docker steht im Konflikt mit runc aus AppStream, daher muss eines von beiden entfernt werden. Entscheiden Sie sich einmal, dokumentieren Sie den Ausschluss und halten Sie eine bewährte Reihenfolge ein: Die Anleitung zur Docker-Installation auf Rocky Linux beschreibt, welche Distributionspakete zuerst entfernt werden müssen.

Die Übersetzung von apt zu dnf für 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 Bestandteil des Ubuntu-eigenen Archivs ist, während EPEL ein separates Projekt ist.
• Für apt update gibt es kein entsprechendes Element, das Sie sich merken müssen. dnf aktualisiert die Metadaten nach einem eigenen Zeitplan. dnf makecache erzwingt die Aktualisierung sofort.
• apt-cache policy <pkg> wird zu dnf info <pkg>. Mit dnf list --showduplicates <pkg> sehen Sie zusätzlich jede verfügbare Version.
• apt-mark hold wird zu dnf versionlock add, ausgehend von python3-dnf-plugin-versionlock.
• Pinning in /etc/apt/preferences.d/ wird im Abschnitt für Paketquellen 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 als Konzept übertragen, nicht jedoch als Syntax, da es hier kein unattended-upgrades gibt. Der Timer, die Konfigurationsdatei und die Frage, ob ein Neustart durchgeführt werden soll, werden unter dnf-automatic unter Rocky und Alma behandelt.

Repository-Liste kurz halten

Aktivieren Sie CRB, installieren Sie epel-release und dokumentieren Sie anschließend, was Sie getan haben und warum. Halten Sie diese Informationen entweder in Ihrem Configuration Management oder in einer einfachen Datei auf dem Server fest. Diese Notiz ist wertvoller, 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. Ziehen Sie erst danach ein neues Repository in Betracht. 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 ist in den Basis-Repositories enthalten und benötigt keinerlei Drittanbieter-Repository. 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 dieser Aufbau bei beiden identisch, und epel-release verhält sich gleich. Die tatsächlichen Unterschiede liegen an anderer Stelle: der Vergleich von Rocky Linux und AlmaLinux beschreibt 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 und anschließend sudo dnf config-manager --set-enabled crb und sudo dnf install -y epel-release aus. Prüfen Sie das Ergebnis mit dnf repolist --enabled. Der Befehl sollte baseos, appstream, extras, crb und epel auflisten. Aktivieren Sie CRB, bevor Sie EPEL-Pakete installieren, da 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. Die Pakete folgen der Vorgabe, niemals ein Paket aus der Basisdistribution zu ersetzen. Die Aktivierung ändert daher nicht die Inhalte von BaseOS oder AppStream. Die Einschränkung betrifft den Support: EPEL ist ein freiwilliges Fedora-Projekt ohne Service-Level-Vereinbarung. Der Vorschlag zur Paketpflege von EPEL sieht vor, dass sich ein Maintainer für ein Paket bereits für eine einzige RHEL-Minor-Version oder 13 Monate verpflichten kann. Führen Sie mit dnf repository-packages epel list installed ein Inventar und 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 enthält 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 dort 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 bezeichnet es als PowerTools mit der ID powertools. Version 9 und höher verwendet die Bezeichnung CRB mit der ID crb. Red Hat bezeichnet diesen 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 dort daher dnf repolist --enabled, bevor Sie den Aktivierungsbefehl ausführen.

Wie entferne ich EPEL wieder, ohne Probleme zu verursachen?

Erstellen Sie zuerst mit dnf repository-packages epel list installed ein Inventar, da das alleinige Entfernen des Pakets epel-release keine aus EPEL installierten Pakete entfernt. Diese Pakete bleiben auf dem System, verlieren ihre Update-Quelle und erhalten keine Sicherheitsaktualisierungen mehr. Es wird kein Fehler angezeigt, der Sie darauf hinweist. Entscheiden Sie für jedes Paket einzeln, ob Sie es noch benötigen, und entfernen oder ersetzen Sie die nicht mehr benötigten Pakete. 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 gesamte Auswahl in einer Transaktion. Lesen Sie die vorgeschlagene Paketliste sorgfältig, bevor Sie den Vorgang bestätigen.