Die Überschrift sagt eigentlich schon alles: Ich habe seit sechs Wochen keine Updates mehr für meine CentOS-8-Systeme erhalten. (Ich beziehe mich dabei auf die zwei wichtigsten Paketquellen, Base und AppStream, jeweils für die Architektur x86_64.) Sicherheitstechnisch ist das sub-optimal, gelinde formuliert.

Update 23.12.2019: CR-Paketquelle aktivieren (siehe unten)

Update 15.1.2020: CentOS 8.1 (in der CentOS-Nomenklatur »CentOS 8.1 [1911]«) ist fertig. Wer CentOS 8 installiert hat, bekommt nun endlich — nach 10 Wochen — wieder Updates.

Update 16.6.2020: Erneut fast sieben Wochen keine Updates. Zeitverlauf:

• RHEL 8.2: 21.4.2020
• Oracle Linux 8, Update 2: 6.5.2020
• CentOS Linux 8 (2004): 15.6.2020

---

Konkret bedeutet das für einige ausgewählte Pakete (Stand 13.12.2019, jeweils nach yum update):

Paket              in RHEL 8           in CentOS 8
---------          ------------------  --------------
firefox            68.3.0              68.2.0
httpd              2.4.37-16           2.4.37-12
kernel             4.18.0-147          4.18.0-80
NetworkManager     1.20.0              1.14.0
openssh-server     8.0p1               7.8p1 
php                7.2.11-4            7.2.11-1

Red Hat hat seit dem 30.10.2019 diverse kritische Sicherheitslücken gestopft (Quelle). Betroffen sind unter anderem Firefox und PHP. CentOS-8-Anwender stehen diesbezüglich im Regen.

Ursache des Problems ist wohl die Umstellung auf CentOS 8.1, deren Ende nicht absehbar ist (Quelle). Red Hat hat ja Anfang November Version 8.1 vorgestellt, CentOS konnte diesen Versionssprung bisher nicht nachvollziehen.

Angesichts dieser Verzögerungen stellt sich aber die Frage, ob man CentOS noch als kostenlose RHEL-Alternative empfehlen kann. Im jetzigen Zustand offenbar nicht — es geht einfach nicht an, dass wichtige Sicherheits-Updates wochenlang ausbleiben.

Continuous-Release-Paketquelle (Update 23.12.2019 + 27.12.2019)

CentOS sieht eine Continuous-Release-Paketquelle (kurz CR) vor. Diese soll speziell in der Übergangszeit zwischen Minor Releases weniger gut getestete Pakete enthalten und so einerseits eine frühzeitige Testmöglichkeit bieten, andererseits aber auch einen Weg, kritische Updates ohne die Wartezeit auf das nächste Release zu erhalten. Hier ist die offizielle Beschreibung des CR-Repositories.

Die Datei /etc/yum.repos.d/CentOS-CR.repo enthält darüberhinaus den folgenden Hinweis, den ich hier wörtlich zitiere:

# CentOS-CR.repo
#
# The Continuous Release ( CR )  repository contains rpms that are due in the next
# release for a specific CentOS Version ( eg. next release in CentOS-8 ); these rpms
# are far less tested, with no integration checking or update path testing having
# taken place. They are still built from the upstream sources, but might not map
# to an exact upstream distro release.
#
# These packages are made available soon after they are built, for people willing
# to test their environments, provide feedback on content for the next release, and
# for people looking for early-access to next release content.
#
# The CR repo is shipped in a disabled state by default; its important that users
# understand the implications of turning this on.
#
# NOTE: We do not use a mirrorlist for the CR repos, to ensure content is available
#       to everyone as soon as possible, and not need to wait for the external
#       mirror network to seed first. However, many local mirrors will carry CR repos
#       and if desired you can use one of these local mirrors by editing the baseurl
#       line in the repo config below.

Die Aktivierung der Paketquelle ist simpel:

yum-config-manager --enable cr

In der Folge berücksichtigt yum update auch die CR-Paketquelle.

Der praktische Nutzen war zum Zeitpunkt meines ersten Tests (23.12.2019) allerdings vernachlässigbar. Die CR-Paketquelle für CentOS 8 war leer :-(

Bei einem zweiten Test am 27.12. sah die Sache schon ein wenig besser aus, allerdings trat nun ein Konflikt bei den glibc-Paketen auf.

Angesichts des explizit experimentellen Charakters der CR-Quelle ist das grundsätzlich OK. Mit der Option --nobest war es immerhin möglich, einen Großteil der Updates durchzuführen. Meine CentOS-Testinstallation ist damit wieder halbwegs am aktuellen Stand.

Am Grundproblem ändert aber auch die CR-Quelle nichts: CentOS 8 hat mittlerweile seit 8 Wochen (Stand 27.12.) keine offiziellen Updates und ist im aktuellen Zustand für den Produktionseinsatz ungeeignet. Und dieses Urteil lässt sich frühestens revidieren, wenn das Update auf Version 8.2 irgendwann im Sommer oder Herbst 2020 besser verläuft.

Quellen

• Base-Pakete, geordnet nach letzter Änderung: http://mirror.centos.org/centos/8/BaseOS/x86_64/os/Packages/?C=M;O=D
• AppStream-Pakete, geordnet nach letzter Änderung: http://mirror.centos.org/centos/8/AppStream/x86_64/os/Packages/?C=M;O=D
• https://wiki.centos.org/About/Building_8.x
• https://access.redhat.com/security/security-updates/#/
• https://www.redhat.com/en/blog/whats-new-rhel-81-kernel-patching-more-insights-and-right-time
• https://wiki.centos.org/AdditionalResources/Repositories/CR
• https://lists.centos.org/pipermail/centos/2019-December/thread.html

15.1.2020. Ein kleiner Hoffnungsschimmer, dass in Zukunft alles wieder gut ist :-)

• https://blog.centos.org/2020/01/update-state-of-centos-linux-8-and-centos-stream