EPEL (Extra Packages for Enterprise Linux) ist das ergänzende Paket-Repository des Fedora-Projekts für Red Hat Enterprise Linux und damit kompatible Systeme, darunter AlmaLinux und Rocky Linux. Es enthält Programme, die in den eigenen Repositories der Distribution nicht enthalten sind, beispielsweise „htop“, „btop“, „ncdu“, „fail2ban“ oder „certbot“. Die EPEL-Pakete überschreiben die systemeigenen Pakete nicht, sondern ergänzen sie lediglich; daher lassen sie sich auf einem Server in der Regel problemlos aktivieren.

Wir haben die Schritte auf Systemen mit AlmaLinux 10.2 und 9.8 getestet. Führen Sie die Befehle als Root-Benutzer oder mit „sudo“ aus (siehe: Verwendung des Befehls „sudo“ mit Beispielen).

1. Installation von EPEL

AlmaLinux liefert das EPEL-Konfigurationspaket in seinem eigenen „extras“-Repository aus, sodass keine URL angegeben werden muss:

sudo dnf install epel-release

Am Ende der Installation zeigt das Paket folgende Meldung an:

Many EPEL packages require the CodeReady Builder (CRB) repository.
It is recommended that you run /usr/bin/crb enable to enable the CRB repository.

Sollte das „extras“-Repository aus irgendeinem Grund nicht verfügbar sein (beispielsweise bei einem minimalistischen Image), kann „epel-release“ auch direkt von der Fedora-Website installiert werden:

sudo dnf install https://dl.fedoraproject.org/pub/epel/epel-release-latest-10.noarch.rpm   # AlmaLinux 10
sudo dnf install https://dl.fedoraproject.org/pub/epel/epel-release-latest-9.noarch.rpm    # AlmaLinux 9

Der Test ergab eine neuere Version dieses Pakets (epel-release-10-8; im Repository „extras“ war es 10-6); die Repository-Einstellungen bleiben unverändert, die Aktualisierungen werden fortan von dnf verwaltet.

2. Aktivierung des CRB-Speichers

CRB (CodeReady Builder) ist eines der eigenen Repositorys von AlmaLinux, das Entwickler-Pakete enthält. Viele EPEL-Pakete basieren darauf, weshalb es zusammen mit EPEL aktiviert werden muss. Zu diesem Zweck installiert „epel-release“ auch ein kleines Hilfsprogramm:

sudo crb enable

Enabling CRB repo
CRB repo is enabled and named: crb

Der Status wird mit dem Befehl „sudo crb status“ angezeigt. Der Befehl „crb“ erfordert Root-Rechte; ohne „sudo“ wird die Fehlermeldung „Permission denied“ ausgegeben.

Im Test war CRB auf dem Cloud-Image von AlmaLinux 10 bereits standardmäßig aktiviert, auf AlmaLinux 9 hingegen nicht. Der Befehl „crb enable“ kann in beiden Fällen sicher ausgeführt werden: Ist das Repository bereits aktiv, werden keine Änderungen vorgenommen. Dasselbe Ergebnis erzielen Sie auch mit dem Befehl „dnf config-manager --set-enabled crb“.

3. Überprüfung

dnf repolist

In der Liste müssen die Repositories „epel“ und „crb“ aufgeführt sein. Unter AlmaLinux 9 wird zusätzlich ein Repository namens „epel-cisco-openh264“ hinzugefügt; dieses enthält den von Cisco portierten OpenH264-Videokodec, der auf dem Server jedoch keine Rolle spielt.

Die Größe des Repositorys wird durch den Befehl „dnf repolist -v epel“ angezeigt. Zum Zeitpunkt des Tests umfasste EPEL 10 etwa 23.900 und EPEL 9 etwa 26.500 Pakete.

4. Installation eines Pakets aus dem EPEL-Repository

Nach der Aktivierung von EPEL können Sie die Pakete genauso installieren wie die systemeigenen:

sudo dnf install htop ncdu btop

Bei der Installation des ersten EPEL-Pakets fragt „dnf“, ob der EPEL-Signaturschlüssel importiert werden soll (unter AlmaLinux 9: Userid : "Fedora (epel9) <epel@fedoraproject.org>"; der Schlüssel stammt aus der Datei /etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-9, die sich auf dem Rechner befindet); bestätigen Sie dies mit „y“. Zum Zeitpunkt des Tests waren beispielsweise folgende Versionen für AlmaLinux 10 verfügbar: „htop“ 3.3.0, „btop“ 1.4.7, „ncdu“ 1.22, „fail2ban“ 1.1.0, „certbot“ 4.2.0 und das dazugehörige „python3-certbot-nginx“.

Wir haben mehrere Artikel über nützliche EPEL-Pakete veröffentlicht: Installation und Verwendung von htop, Installation und Konfiguration von Fail2ban sowie Beantragung eines Let’s Encrypt-Zertifikats mit Certbot.

Welches Paket stammt aus dem EPEL-Repository?

dnf repository-packages epel list --installed

Kurz gesagt: dnf list --installed | grep @epel. Die letzte Spalte der Ausgabe (@epel) gibt die Quelle an:

btop.aarch64                        1.4.7-1.el10_2                         @epel
htop.aarch64                        3.3.0-5.el10_0                         @epel
ncdu.aarch64                        1.22-1.el10_1                          @epel

Für ein verfügbares Paket listet der Befehl „dnf info htop“ auf, aus welchem Repository es stammt (Repository : epel). Auf diese Weise können Sie mehrere Paketnamen gleichzeitig überprüfen:

dnf repoquery --repo epel --available eza btop nvtop

Es werden nur diejenigen angezeigt, die im EPEL enthalten sind: Im Test sind „btop“ und „nvtop“ enthalten, „eza“ hingegen nicht.

Pakete, die sich derzeit in der Testphase befinden

Das Repository „epel-testing“ enthält Updates, die für EPEL vorgesehen sind und sich noch in der Testphase befinden; es ist standardmäßig deaktiviert. Aktivieren Sie es auf einem Produktionsserver nicht dauerhaft; sollten Sie einen Fehlerbehebungs-Patch benötigen, können Sie es vorübergehend mit einem einzigen Befehl nutzen:

sudo dnf --enablerepo=epel-testing upgrade htop

Deaktivierung von EPEL

Wenn Sie den Cache nur vorübergehend deaktivieren möchten (beispielsweise zur Untersuchung einer Paketkollision), deaktivieren Sie den Cache und aktivieren Sie ihn bei Bedarf für einzelne Befehle:

sudo dnf config-manager --set-disabled epel
sudo dnf --enablerepo=epel install nvtop
sudo dnf config-manager --set-enabled epel

Im deaktivierten Zustand erhalten auch die EPEL-Pakete keine Updates. Endgültige Deinstallation:

sudo dnf remove epel-release

Dadurch werden lediglich die Repository-Einstellungen gelöscht. Die über EPEL installierten Programme verbleiben auf dem Rechner und funktionieren weiterhin, erhalten jedoch keine Updates mehr, was aus Sicherheitsgründen ein Risiko darstellt. Falls Sie diese Programme nicht benötigen, entfernen Sie sie bitte zuvor; die Liste finden Sie im Befehl des vorherigen Abschnitts.

Aktualisierungen

Die EPEL-Pakete werden zusammen mit den übrigen Paketen des Systems über den Befehl „dnf upgrade“ aktualisiert und sind ebenfalls von der automatischen Aktualisierung erfasst (siehe: Systemaktualisierung: dnf, apt und automatische Aktualisierungen).

EPEL wird von Fedora-Freiwilligen gepflegt und gehört nicht zu den von AlmaLinux unterstützten Paketen. Eine Aktualisierung eines EPEL-Pakets kann – wenn auch selten – zu Verhaltensänderungen führen; daher ist es wichtig, dass Sie nach einer Aktualisierung die Funktionsfähigkeit Ihrer Dienste überprüfen. Sollten Sie die Wartung des Servers lieber uns überlassen wollen, empfehlen wir Ihnen unseren Managed-VPS-Service; für den Eigenbetrieb können unsere KVM-VPS-Server auch mit AlmaLinux installiert werden.

Rocky Linux und Red Hat Enterprise Linux

Unter Rocky Linux lauten die Befehle identisch. Unter Red Hat Enterprise Linux ist „epel-release“ nicht in den Red Hat-Repositories enthalten: Dort muss es über die Fedora-Seite mittels URL installiert werden, und das CRB-Repository lässt sich mit dem Befehl „subscription-manager repos“ aktivieren.

Wenn Sie im nächsten Schritt eine neue PHP-Version oder ein neues Redist installieren möchten, beachten Sie bitte, dass das Remi-Repository auf EPEL basiert.