Der Status von EPEL 8

EPEL steht für Extra Packages for Enterprise Linux und ist die wichtigste externe Paketquelle für RHEL- und CentOS-Anwender. EPEL hat deswegen eine so große Bedeutung, weil Red Hat traditionell viel weniger Pakete ausliefert/pflegt als beispielsweise Debian oder Ubuntu. RHEL/CentOS-Anwender, die darüberhinaus weitere Software-Pakete benötigen, richten deswegen zumeist die EPEL-Paketquelle ein.

Wer nach der Freigabe von Red Hat Enterprise Linux 8 (RHEL 8) sofort den Umstieg wagte, musste allerdings ohne EPEL auskommen. Weil Red Hat die Organisation seiner eigenen Pakete grundlegend verändert hat (Modularisierung durch das AppStream-Verfahren), muss auch das EPEL-Repository vollkommen neu organisiert werden — und das kostet Zeit.

Für early adopters bestand zwar grundsätzlich die Möglichkeit, einfach das alte EPEL-7-Repository einzurichten; wirklich praktikabel war das aber nicht, weil sich viele Pakete aufgrund unerfüllbarer Paketabhängigkeiten nicht installieren ließen. (Besonders betroffen waren Python-Pakete.)

Zuletzt aktualisiert am 17.12.2019.

EPEL-8-Rollout in mehreren Phasen

Mitte August wurde nun EPEL 8 offiziell freigegeben. Übertriebene Freude ist aber noch nicht angebracht. Wegen der bereits skizzierten Umstrukturierung ist das Paketangebot in EPEL 8 noch viel kleiner als in EPEL 7. Warum das so ist, hat der EPEL-Entwickler Stephen Smoogen bereits im Juli 2019 in seinem Blog skizziert. Demnach wird das EPEL-8-Rollout in mehreren Schritten erfolgen:

  • EPEL 8.0: Das aktuelle Release ist nur der erste Schritt, den Stephen Smoogen »EPEL 8.0« nennt. Es nutzt die Modularisierungsfunktionen von RHEL 8 noch nicht.
  • EPEL 8.1 wird ca. im November 2019 erwartet und wird möglicherweise parallel zu RHEL 8.1 freigegeben. Es soll RHEL-Module teilweise unterstützen.
  • Erst EPEL 8.2 (Zeitraum der Fertigstellung noch unklar) soll vollständig mit dem neuen Modulkonzept von RHEL 8 kompatibel sein.

EPEL 8.0 in der Praxis

Das Einrichten der EPEL-Paketquelle ist unverändert einfach:

yum install https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm

Hinter den Kulissen werden damit die Repository-Dateien /etc/yum.repos.d/epel*.repo eingerichtet. Anschließend können Sie sich mit yum einen Überblick über die aktuell verfügbaren Pakete verschaffen:

yum repository-packages epel list

Verfügbare Pakete
BackupPC.x86_64             4.3.1-2.el8     epel
BackupPC-XS.x86_64          0.59-3.el8      epel
CGSI-gSOAP.x86_64           1.3.11-7.el8    epel
CGSI-gSOAP-devel.x86_64     1.3.11-7.el8    epel
Field3D.x86_64              1.7.2-16.el8    epel
Field3D-devel.x86_64        1.7.2-16.el8    epel
Lmod.x86_64                 8.1.10-2.el8    epel
...

yum repository-packages epel list | wc -l

971

Update 19.12.2019: Mittlerweile ist die Paketanzahl auf 3680 angestiegen.

(Nur zum Vergleich: Unter CentOS 7 mit der EPEL-7-Paketquelle kommt yum repository-packages epel list | wc -l auf über 13.000 Pakete!)

Ob Sie mit EPEL 8 im aktuellen Zustand glücklich werden, hängt naturgemäß stark davon ab, welche Pakete Sie brauchen. Ich installiere üblicherweise als Erstes das Paket joe. Es enthält neben anderen Editoren den winzigen Emacs-Klon jmacs, mit dem ich bevorzugt Konfigurationsdateien verändere. (jmacs ist in seinen Grundkommandos zum Emacs kompatibel. Seine größten Vorteile sind ein blitzartiger Start und ein sparsamer Umgang mit Ressourcen.) Um es kurz zu machen: joe steht aktuell nicht zur Verfügung, eben sowenig wie jove (noch ein Emacs-Klon). Update 17.12.2019: joe steht jetzt zur Verfügung.

Auf meiner EPEL-Hitliste ganz oben steht des Weiteren fail2ban. Dieses Programm blockiert IP-Adressen, wenn von dort wiederholt fehlerhafte Login-Versuche erfolgen. fail2ban ist damit ein wichtiger Schutz vor Angreifern, die (SSH-)Passwörter durch systematisches Probieren erraten möchten. fail2ban ist erfreulicherweise bereits in EPEL 8.0 enthalten.

Dritter Testkandidat war certbot, um Let’s-Encrypt-Zertifikate einzurichten. Leider Fehlanzeige in EPEL 8.0 :-( Update 17.12.2019: Auch certbot ist jetzt verfügbar, hurra! Das Plugin zur Apache-Konfiguration (python-certbot-apache) fehlt allerdings. Sie können deswegen certbot nur ohne die Option --apache ausführen.

Quellen