Die Einstellung des Git-Repos mit den RHEL-Quellen (siehe auch Ärger für Red-Hat-Klone) hat im Netz erwartungsgemäß für hitzige Diskussionen gesorgt. Ein wenig irritiert haben mich die Kommentare auf lwn.net, eigentlich der seriösesten Linux-News-Quelle: Dort wurden AlmaLinux, Rocky Linux und speziell Oracle von manchen Autoren als »Parasiten« bezeichnet.

Nun ist es unbestritten, dass die Zusammenstellung einer Distribution wie RHEL mit richtig viel Arbeit verbunden ist. Noch viel mehr Mühe bereitet es, das Software-Angebot über 10 Jahre zu warten und auch bei veralteter Software Sicherheits-Patches rückzuportieren. (Python 2.7 ist ein klassisches Beispiel.)

Wenn nun die RHEL-Klone die Quellen einfach kopieren und daraus ein kostenloses Produkt machen (oder, wie im Falle von Oracle, wahlweise kostenlos oder kostenpflichtig mit Support), ist das noch fair? Ist die Bezeichnung »Parasiten« womöglich zutreffend?

Anmerkung: Dieser Artikel wurde zwischen 23.6. und 24.6.2023 mehrfach aktualisiert.

Open Source ist keine Einbahnstrasse

ABER: Linux ist Open-Source-Software. Und das gilt nicht nur für den Kernel, das gilt auch für alle weitere Komponenten: Apache, NGINX, PHP, PostgreSQL, Samba, Postfix, Java, die Bash, der C-Compiler, Python, GRUB usw. Ich könnte hier vermutlich 1000 Open-Source-Komponenten aufzählen, die in RHEL zum Einsatz kommen. Ja, Red Hat arbeitet intensiv an manchen Open-Source-Projekten mit (dem Kernel, systemd, Gnome usw.) und unterstützt viele weitere finanziell. Von anderen Projekten profitiert es, ohne etwas zurückzugeben.

Dazu noch eine Anmerkung aus meiner beruflichen Praxis: Red Hat hat mit Podman ein Konkurrenzprodukt zu Docker geschaffen. Beide Programme stehen unter Open-Source-Lizenzen, beide halten sich an den öffentlichen OCI-Standard und beide funktionieren großartig. In der Presse genießt Docker aber einen zweifelhaften Ruf, weil es versucht, Geld zu verdienen. (Gerade c’t und iX bzw. einige Heise-Autoren sind sehr Docker-kritisch eingestellt.) Übersehen wird dabei: Die Firma Docker betreibt — mit beträchtlichem finanziellem Aufwand — den Docker Hub, die weltweit größte Quelle von Container-Images. Red Hat betreibt zwar auch Registries für ein paar eigene Software-Projekte, aber davon abgesehen gilt: Wer Podman anwendet, bezieht in aller Regel die Images vom Docker Hub (also von docker.io) und verursacht so weitere Kosten für Docker. Red Hat und Podman sind hier also Nutznießer einer Infrastruktur, die von einer anderen Firma geschaffen wurde. (Und ja, das ist Open Source. Das bessere Angebot wird sich langfristig durchsetzen.)

Das Open-Source-Modell funktioniert dann am besten, wenn Einsatz/Aufwand und Nutzen einigermaßen fair verteilt sind. Das Linux-Ökosystem als Ganzes profitiert von erfolgreichen Open-Source-Firmen, und Red Hat war ohne Zweifel die erfolgreichste. (Seit 2018 ist Red Hat Teil von IBM.) Red Hat wiederum profitiert vom riesigen Angebot exzellent gewarteter Open-Source-Software.

Wenn nun umgekehrt kleine Entwickler, Organisationen ohne riesige Finanzmittel, Schulen usw. RHEL-kompatible Software über den Umweg von AlmaLinux, Rocky Linux und Co. kostenfrei nutzen dürfen, erscheint mir das fair. Wiederum profitieren alle, letztlich sogar Red Hat bzw. IBM, weil ihre Software von vielen Anwendern genutzt und getestet wird, weil Studenten die Administration von RHEL-kompatiblen Systemen lernen (und nicht etwas die von Debian oder Ubuntu) usw.

Ohne Not in den Shit Storm

Der Schritt von Red Hat, die Quellen zu RHEL (soweit es GPL-technisch überhaupt möglich ist) zu kappen, wäre verständlich, wenn man sich um die finanzielle Stabilität von Red Hat Sorgen machen müsste. Aber soweit man den Finanzberichten trauen kann, ist das nicht der Fall. IBM hat 2018 Red Hat für 34 Mrd. Dollar gekauft. Damals machte Red Hat 2,9 Mrd Dollar Umsatz und 259 Mil. Dollar Gewinn (Quelle). Seither werden keine eigenen Red-Hat-Zahlen mehr veröffentlicht, aber die Red-Hat-Sparte innerhalb von IBM hat sich offenbar prächtig weiterentwickelt (Quelle). Red Hat kämpft also nicht um sein finanzielles Überleben. Eher ist es wohl die Gier (IBMs?), aus einem gut gehenden Geschäft noch mehr rauszuholen. Auch wenn dabei die Fairness auf der Strecke bleibt.

Und eines muss man schon sagen: Das Timing ist bösartig, ein freundlicheres Wort fällt mir nicht ein. Sowohl die Kommunikation über das CentOS-Ende (Ende 2020) als auch der Stopp der Veröffentlichung der RHEL-Quellen unter git.centos.org (Juni 2023) erfolgte jeweils äußerst kurzfristig mitten im Release-Zyklus. Es ist beabsichtigt, die Anwender von (damals) CentOS und (heute) AlmaLinux, Rocky Linux, Oracle Linux ganz bewusst zu verunsichern und vor den Kopf zu stoßen.

fosspost.org hat die Aktion Red Hat als Schuss ins Knie bezeichnet. Mir erscheint diese Einschätzung zutreffend. Ansible-Entwickler Jeff Geerling fragt: »Are you dumb?« und überlegt, ob er sich überhaupt noch die Mühe machen soll, RHEL zu unterstützen (also z.B. Fehlermeldungen zu bearbeiten, die sich auf RHEL beziehen).

Als Red Hat das CentOS-Projekt in seiner bisherigen Form stoppte, hatte ich Sorgen um die freie Verfügbarkeit von RHEL-Klonen. Dann erlebte das Konzept in Form von AlmaLinux und Rocky Linux eine Wiedergeburt und funktioniert heute besser denn je. Womöglich wird sich dieses Spiel wiederholen. An den Regeln der GNU Public Licence geht auch für Red Hat/IBM kein Weg vorbei. Sicher ist aber schon jetzt: Red Hat (IBM) verliert in der Open-Source-Community gerade massiv Reputation und Gunst.

Quellen/Links

• https://www.redhat.com/en/blog/furthering-evolution-centos-stream
• https://almalinux.org/blog/impact-of-rhel-changes/
• https://rockylinux.org/news/2023-06-22-press-release
• https://lwn.net/Articles/935918/

Reaktionen

• https://www.jeffgeerling.com/blog/2023/dear-red-hat-are-you-dumb
• https://twitter.com/geerlingguy/status/1671930926949974036?s=58&t=yMJdHyGwnXVT_13bSmcayA (Twitter-Diskussion zum obigen Blog-Beitrag)
• https://fosspost.org/red-hat-is-shooting-itself-in-the-foot-again/
• https://www.heise.de/meinung/Kommentar-Erst-verteufeln-dann-selber-so-machen-Red-Hats-idiotischer-Murks-9204529.html

»Parasiten«-Diskussion

• https://lwn.net/Articles/935592
• https://www.infoworld.com/article/3697733/chatgpt-s-parasitic-machine.html
• https://twitter.com/scstonewall/status/1672047372287737863?s=58&t=yMJdHyGwnXVT_13bSmcayA

Finanzielle Daten zu Red Hat

• https://de.wikipedia.org/wiki/Red_Hat
• https://www.manager-magazin.de/digitales/it/warum-ibm-34-milliarden-fuer-red-hat-zahlt-a-1235731.html
• https://www.lightreading.com/service-provider-cloud/red-hat-is-bright-spot-in-dreary-ibm-picture/d/d-id/777592
• https://www.sdxcentral.com/articles/news/red-hat-fuels-ibm-hybrid-cloud-revenue-growth/2023/04/

Red Hat Enterprise Linux (RHEL) besteht aus Open-Source-Code, der öffentlich zugänglich ist. Diesen Umstand nutzen AlmaLinux, Oracle Linux, Rocky Linux und einige weitere Distributionen, um zu RHEL kompatible Distributionen anzubieten. Es ist verständlich, dass dies Red Hat (oder noch mehr IBM?) ein Dorn im Auge ist. Die Klons funktionieren so gut wie das Original, und wer keinen Support braucht oder mit externen Support-Angeboten das Auslangen findet, kann sich viel Geld für Lizenzen sparen.

Nachdem Red Hat schon 2020 das CentOS-Projekt (quasi einen Red-Hat-eigener RHEL-Klon) beendet hat und durch das für den Produktivbetrieb weniger attraktive CentOS Stream ersetzt hat, hat die Firma Ende Juni verkündet, den öffentlichen Zugang auf die RHEL-Quellen unter https://git.centos.org zu beenden. Den RHEL-Quellcode erhalten dann möglicherweise nur noch zahlende Kunden. Das Ganze wurde in bestem Marketing-Sprech als Aufwertung des CentOS-Stream-Projekts verkündet. Die zentrale Aussage lautet: CentOS Stream will now be the sole repository for public RHEL-related source code releases.

Aktuell ist noch unklar, was das für AlmaLinux, Rocky Linux & Co. bedeutet. Grundsätzlich könnten die hinter den Projekt stehenden Organisationen einfach ein RHEL-Abo abschließen. Die Frage ist aber, in welcher Form der Zugang auf den Quellcode dann erfolgt (über SRPM-Pakete?), und wie flott diese Pakete aktualisiert werden. Letztlich könnte die ganze Aktion darauf hinauslaufen, die natürlich weitgehend automatisierten Build-Prozesse der Klone zu behindern oder zu verzögern.

Eine weitere Frage ist, ob irgendwelche EULA-Regeln die Verwendung dieses Codes zum Nachbau anderer Distributionen verbieten können. Das erscheint mir — ohne juristisches Wissen — eher unwahrscheinlich. Es galt immer und es gilt weiterhin die GNU Public License.

Es bleibt also spannend. AlmaLinux verkündet auf Twitter: Don’t panic. Wahrscheinlich eine gute Idee.

Quellen/Links

• https://www.redhat.com/en/blog/furthering-evolution-centos-stream
• https://lwn.net/Articles/935592/
• https://twitter.com/AlmaLinux/status/1671556693308604417
• https://www.gnu.org/licenses
• https://kofler.info/nachruf-auf-centos

Ausgewählte Artikel und Updates nach Erscheinen meines Blog-Artikels

• https://almalinux.org/blog/impact-of-rhel-changes/
• https://www.heise.de/news/Red-Hat-vernagelt-Zugang-zu-oeffentlichen-Repositories-Problem-fuer-Klone-9194940.html
• https://rockylinux.org/news/2023-06-22-press-release
• https://rockylinux.org/news/brave-new-world-path-forward/
• https://www.theregister.com/2023/06/23/red_hat_centos_move/
• https://www.redhat.com/en/blog/red-hats-commitment-open-source-response-gitcentosorg-changes
• https://www.theregister.com/2023/06/28/rocky_linux_rhel_ripples/
• https://rockylinux.org/news/keeping-open-source-open/
• https://www.heise.de/meinung/Kommentar-Erst-verteufeln-dann-selber-so-machen-Red-Hats-idiotischer-Murks-9204529.html
• https://www.heise.de/news/Open-Source-Linux-Distributor-Red-Hat-veraergert-die-Community-9209799.html
• https://www.zdnet.com/article/oracle-takes-on-red-hat-in-linux-code-fight/
• https://www.heise.de/news/SUSE-forkt-RHEL-9212790.html
• https://curius.de/2023/07/die-enterprise-linux-welt-sortiert-sich-neu/
• https://almalinux.org/blog/future-of-almalinux/
• https://lowendbox.com/blog/seismic-industry-shift-is-rhel-about-to-vanish-from-the-web-hosting-landscape
• https://www.zdnet.com/article/almalinux-discovers-working-with-red-hat-isnt-easy
• https://arstechnica.com/information-technology/2023/07/almalinux-says-red-hat-source-changes-wont-kill-its-rhel-compatible-distro/
• https://www.zdnet.com/article/oracle-suse-and-ciq-go-after-red-hat-with-the-open-enterprise-linux-association
• https://fossforce.com/2023/08/the-almalinux-dilemma-when-upstream-suddenly-disappears/

Sie wollen WordPress auf einem Server mit RHEL 9 oder einem Klon installieren? Diese Anleitung fasst alle erforderlichen Schritte zusammen. Dabei gehe ich davon aus, dass Sie über eine minimale Installation auf einem Root-Server oder in einer virtuellen Maschine verfügen. Ich habe meine Tests mit AlmaLinux 9 in einer Hetzner-Cloud-Instanz durchgeführt.

DNS-Einträge

Nachdem Sie Ihren Server in Betrieb genommen und sich mit SSH eingeloggt haben, ermitteln Sie die IP-Adressen, unter denen der Server nach außen hin erreichbar ist. Beachten Sie, dass das an sich nützliche Kommando hostname -I nicht in jedem Fall zielführend ist. Wenn Ihre virtuelle Maschine als EC2-Instanz in der Amazon Cloud (AWS) läuft, liefert das Kommando eine Adresse in einem privaten Netzwerk. Diese Adresse gilt aber nur AWS-intern! Sie müssen in der AWS-Konsole ergründen, welche IP-Adresse nach außen gilt.

Ich gehe hier davon aus, dass Ihre WordPress-Installation unter den Adressen example.com und www.example.com zugänglich sein soll und dass Sie IPv4 und IPv6 unterstützen. Dann müssen Sie für Ihre Domain example.com vier DNS-Einträge definieren. Naturgemäß müssen Sie die Beispiel-IP-Adressen durch Ihre echten IP-Adressen ersetzen. Normalerweise dauert es eine Weile (fünf Minuten bis hin zu mehreren Stunden), bis diese DNS-Änderungen wirksam werden.

Typ    Name      Zieladresse
-----  -------   -------------------
A       @        1.2.3.4
A       www      1.2.3.4
AAAA    @        2345:1234:1234::1
AAAA    www      2345:1234:1234::1

Software-Installation

Auf Ihrem Server müssen Sie nun einen Webserver, einen Datenbank-Server sowie PHP installieren. Ich gehe hier davon aus, dass Sie Apache und MySQL verwenden. Statt Apache wäre natürlich auch NGINX denkbar, statt MySQL auch MariaDB. (Beachten Sie aber, dass die mit RHEL 9 uralte MariaDB-Versionen ausgeliefert werden. Wenn Sie MariaDB einsetzen möchten, sollten Sie den Datenbank-Server aus dem Repository von MariaDB installieren, siehe https://mariadb.org/download/?t=repo-config.)

dnf install epel-release httpd mod_ssl mysql-server
dnf module install php:8.1
dnf install php-mysqlnd

Mit systemctl starten Sie den Web- und Datenbank-Server:

systemctl enable --now httpd   
systemctl enable --now mysqld

Firewall

Falls Sie auf einem Root-Server arbeiten, müssen Sie die Firewall für die Protokolle HTTP und HTTPS (also Port 80 und 443) freischalten:

firewall-cmd --permanent --zone=public --add-service=http
firewall-cmd --permanent --zone=public --add-service=https
firewall-cmd --reload

Bei Cloud-Instanzen entfällt dieser Schritt normalerweise: Die meisten Cloud-Anbieter haben in ihren Instanzen die RHEL-interne Firewall deaktiviert und verwenden stattdessen Firewalls auf Cloud-Ebene, die über die Web-Oberfläche des Cloud-Systems konfiguriert werden muss.

Apache ausprobieren

Um zu testen, dass Ihre Website im Internet zugänglich ist, schreiben Sie »Hello World« in eine Datei im Webverzeichnis /var/www/html:

echo "Hello World" > /var/www/html/index.html

Nun öffnen Sie im Webbrowser auf Ihrem Notebook die Adresse www.example.com oder example.com. Statt »Hello World« wird der Webbrowser eine Sicherheitswarnung anzeigen, weil Ihr Server noch über kein richtiges Zertifikat verfügt. Das ist ein gutes Zeichen: Der Web-Server an sich funktioniert. Ihr Webbrowser erkennt, dass Ihr Server HTTPS unterstützt und will dieses verwenden.

Let’s-Encrypt-Zertifikat für HTTPS einrichten

Es gibt verschiedene Tools, um Zertifikate von Let’s Encrypt zu installieren. Meiner Ansicht nach funktioniert acme.sh am besten. Zur Installation führen Sie die folgenden Kommandos aus:

dnf install tar socat
curl https://get.acme.sh -o acme-setup
less acme-setup                             (kurze Kontrolle)
sh acme-setup email=admin@example.com

An die E-Mail-Adresse werden Warnungen verschickt, sollte in Zukunft die automatische Erneuerung von Zertifikaten nicht funktionieren. Damit Sie das frisch installierte Script verwenden können, müssen Sie sich aus- und neu einloggen. Jetzt fordern Sie das gewünschte Zertifikat an, wobei Sie natürlich example.com wieder durch Ihren tatsächlichen Hostnamen ersetzen:

acme.sh --issue -d --server letsencrypt example.com -d www.example.com -w /var/www/html

  Your cert is in
    /root/.acme.sh/example.com/example.com.cer 
  ...

acme.sh speichert das Zertifikat also vorerst in Ihrem Heimatverzeichnis. Sie könnten die Zertifikatsdateien einfach in das /etc-Verzeichnis kopieren, aber das wäre keine gute Idee: Das Zertifikat muss regelmäßig erneuert werden, und acme.sh muss wissen, wohin die neuen Zertifikate dann kopiert werden müssen. Daher weisen Sie acme.sh an, die Zertifikate in das Verzeichnis /etc/mycert zu kopieren:

mkdir /etc/mycert

acme.sh --install-cert -d example.com \
  --cert-file      /etc/mycert/example.com.cert \
  --key-file       /etc/mycert/example.com.key \
  --fullchain-file /etc/mycert/example.com.fullchain

acme.sh merkt sich den Installationsort und berücksichtigt ihn in Zukunft automatisch bei Updates der Zertifikate. Für diese Updates ist das Kommando acme.sh --cron zuständig, das automatisch einmal täglich durch /var/spool/cron/root ausgeführt wird.

Die Zertifikatsdateien sind nun im /etc-Verzeichnis, aber Apache weiß noch nichts davon. Sie müssen also in der Webserver-Konfiguration angeben, wo sich die Verzeichnisse befinden. Dazu verändern Sie zwei Zeilen in ssl.conf:

# in /etc/httpd./conf.d/ssl.conf zwei Zeilen ändern
SSLCertificateFile    /etc/mycert/example.com.fullchain
SSLCertificateKeyFile /etc/mycert/example.com.key

Jetzt starten Sie Apache neu:

systemctl restart httpd

Danach versuchen Sie nochmals, die Seite example.com im Webbrowser zu öffnen. Jetzt sollte alles klappen, d.h. »Hello World« wird verschlüsselt vom Webserver zum Webbrowser übertragen und der Webbrowser ist mit dem Zertifikat zufrieden.

MySQL absichern

Unbegreiflicherweise ist die MySQL-Installation von RHEL 9 und all seinen Klonen offen wie ein Scheunentor. Jeder Benutzer, der sich auf dem Linux-System anmelden kann, erhält mit mysql -u root ohne Passwort Root-Rechte für MySQL. Abhilfe schafft das Kommando mysql_secure_installation. Die folgenden Zeilen fassen stark gekürzt die wichtigsten Eingaben zusammen:

mysql_secure_installation 

Would you like to setup VALIDATE PASSWORD  component?      n

New password:          xxxxxx
Re-enter new password: xxxxxx

Remove anonymous users?                 y
Disallow root login remotely?           y
Remove test database and access to it?  y
Reload privilege tables now?            y

MySQL-Datenbank einrichten

WordPress braucht eine Datenbank, in der Ihre Einstellungen, den HTML-Code Ihrer Blog-Beiträge, die Kommentare anderer Benutzer usw. speichern kann. Diese Datenbank sowie ein Datenbank-Nutzer, der darauf zugreifen darf, wird jetzt eingerichtet. Ich habe für die Datenbank und den Benutzer jeweils den Namen wp verwendet, aber natürlich sind Sie bei der Namenswahl frei.

mysql -u root -p
Password: xxxxxxx   (gleiches Passwort wie bei mysql_secure_installation)

mysql> CREATE DATABASE wp;
mysql> CREATE USER wp@localhost IDENTIFIED BY 'strengGeheim';
mysql> GRANT ALL ON wp.* TO wp@localhost; 
mysql> exit

WordPress-Dateien installieren

WordPress steht nicht als Paket zur Verfügung, sondern muss manuell installiert werden. Dazu laden Sie die Dateien herunter, packen Sie aus und weisen Ihnen die richtigen Zugriffsrechte samt SELinux-Kontext zu.

cd /var/www/html
rm index.html
wget https://de.wordpress.org/latest-de_DE.tar.gz
tar xzf latest-de_DE.tar.gz
chown -R apache wordpress
chcon -R system_u:object_r:httpd_sys_content_rw_t:s0 wordpress
rm latest-de_DE.tar.gz

Mit der Installation der WordPress-Dateien in /var/www/html/wordpress soll dieses Verzeichnis der Startpunkt für die Dateien in Apache sein. Daher mussdie Variable DocumentRoot von /var/www/html auf /var/www/html/wordpress umgestellt werden. Bei der Gelegenheit können Sie auch gleich den Server-Namen einstellen:

# in /etc/httpd/conf/httpd.conf zwei Zeilen ändern
DocumentRoot "/var/www/html/wordpress"
ServerName example.com

Damit die Einstellungen wirksam werden, ist das folgende Kommando notwendig:

systemctl reload httpd

WordPress konfigurieren

Damit ist es endlich soweit. Sie können nun mit der WordPress-Konfiguration beginnen. Dazu öffnen Sie die Seite example.com/wp-admin/setup-config.php. Im ersten Schritt müssen Sie den Namen der Datenbank, den Datenbank-User sowie dessen Passwort angeben.

Im nächsten Schritt legen Sie den Namen Ihrer Website sowie einen Benutzernamen und ein Passwort für die WordPress-Administration fest. Mit diesen Daten können Sie sich danach bei Ihrer neuen Seite anmelden und die mit Inhalten füllen.

Fine Tuning

Wenn alles funktioniert, sollten Sie sich noch um die folgenden Details kümmern:

• SSH absichern (z.B. mit Fail2Ban)
• Paket-Updates automatisieren (Paket dnf-automatic)
• automatische Umleitung HTTP -> HTTPS sowie Optimierung der HTTPS-Optionen (siehe https://ssl-config.mozilla.org)
• Backup-System einrichten

In diesem Artikel möchte ich einen Blick auf die Linux Distributionen AlmaLinux und Rocky Linux werfen und sie ihrem Upstream-Projekt Red Hat Enterprise Linux (RHEL) gegenüber stellen. Dabei interessieren mich insbesondere die folgenden Punkte:

1. Wer betreibt das Projekt bzw. steht hinter dem Projekt?
2. Wie finanziert sich das Projekt? Gibt es ein funktionierendes Geschäftsmodell?
3. Welchen Eindruck hinterlässt die Dokumentation?
4. Wie lange wird ein Major-Release unterstützt?
5. Wie viele Tage liegen zwischen einem RHEL-Release und den Releases der beiden Projekte?
6. Wie handhaben die Projekte Sicherheits-Updates?

Aus Gründen der Transparenz weise ich darauf hin, dass ich Mitglied der Red Hat Accelerators Community und System-Administrator diverser RHEL-Server bin. Dieser Text gibt ausschließlich meine persönlichen Ansichten und nicht die von Red Hat oder die meines Arbeitgebers wieder. Zwar können diese in einzelnen Punkten übereinstimmen, müssen es aber nicht.

Was haben beide Projekte gemeinsam?

Sowohl AlmaLinux als auch Rocky Linux sind nach eigener Aussage:

• Produktionsreife Betriebssysteme
• Binärkompatibel zu RHEL
• Werden aus den RHEL-Quelltexten übersetzt
• Für den Nutzer kostenlos
• Bieten 10 Jahre Unterstützung für ein Major-Release

Auch Red Hat bietet 10 Jahre Support auf seine RHEL-Major-Releases (Login erforderlich), an die sich eine Extended Life Phase anschließen kann. Selbstverständlich ist auch RHEL nach eigener Aussage reif für den produktiven Einsatz. Im Unterschied zu AlmaLinux und Rocky Linux kann RHEL jedoch nur zusammen mit einer kostenpflichtigen Subskription sinnvoll betrieben werden. Je nach Größe der Umgebung und Anzahl RHEL-Instanzen können hier beträchtliche Kosten anfallen.

Wer steht hinter den Distributionen?

Bei AlmaLinux handelt es sich um ein Community-Projekt, welches von der Firma CloudLinux Inc. gestartet wurde, welche das Projekt auch mit 1 Mio. USD pro Jahr unterstützt. Entwickelt und gesteuert wird das Projekt durch die Community, zu deren Unterstützung die gemeinnützige AlmaLinux OS Foundation gegründet wurde.

Neben der jährlichen Zuwendung von CloudLinux finanziert sich das Projekt durch diverse Sponsoren.

Die Firma CloudLinux Inc. verfügt selbst über mehr als 10 Jahre Erfahrung in der Pflege eines RHEL-Klons sowie den Betrieb der dazu notwendigen Infrastruktur. Nach eigener Aussage möchte CloudLinux Inc. durch die Unterstützung des Projekts den eigenen Bekanntheitsgrad steigern und hofft auf neue Kunden für das kommerzielle CloudLinux OS und KernelCare.

RHEL wird von der Firma Red Hat entwickelt, welches eines der weltweit erfolgreichsten Open Source Unternehmen ist. Haupteinnahmequelle des Unternehmens ist der Vertrieb von Subskriptionen für RHEL und weitere Produkte aus dem Portfolio. Eine Subskription berechtigt zum Bezug von Software-Aktualisierungen und umfasst kommerziellen Support.

Rocky Linux ist ein Community-Projekt, welches vom CentOS-Mitbegründer Gregory Kurtzer gegründet wurde. Das Projekt verfolgt die gleichen Ziele wie das ursprüngliche CentOS, welches zugunsten von CentOS Stream aufgegeben wurde.

Ähnlich wie AlmaLinux finanziert sich das Projekt durch verschiedene Sponsoren. Wie die Webseite Linuxnews am 16. Mai 2022 berichtete, konnte sich Rocky Linux eine Finanzierung in Höhe von 26 Mio. USD von Google sichern.

Hilfe, Unterstützung und Dokumentation

Wie oben bereits beschrieben haben alle Distributionen ein Unterstützungszeitraum von 10 Jahren. Das heißt, dass ein Major-Release wie AlmaLinux/RHEL/Rocky Linux 8 für einen Zeitraum von 10 Jahren Aktualisierungen in Form von Bug-/Security-Fixes und ausgewählter Verbesserungen erhält. AlmaLinux und Rocky Linux profitieren hier von der Vorarbeit, welche Red Hat für RHEL geleistet hat.

Hilfe für individuelle Probleme, Sorgen, Nöte und Anträge erhält man bei AlmaLinux und Rocky Linux in Foren, Chats und auf Mailinglisten. Darüber hinaus kann man kommerziellen Support für AlmaLinux bei TuxCare einkaufen. Rocky Linux listet CIQ und OpenLogic by Perforce als Support-Anbieter. Red Hat unterhält mit der Red Hat Customer Portal Community ebenfalls einen Bereich mit Disussions-Forum. Darüber hinaus bietet Red Hat im Rahmen seiner Subskriptionen Support direkt vom Hersteller.

Für alle drei Distributionen gibt es also sowohl freie/kostenlose Support-Angebote, als auch kommerzielle Support-Verträge, entweder direkt vom Hersteller oder durch Drittanbieter.

Ob man kommerziellen Support benötigt oder der Community-Support ausreicht, hängt von verschiedenen Faktoren wie z.B. den eigenen Fähigkeiten und nicht zuletzt von der eigenen Risikofreudigkeit ab. Ich persönlich habe die Erfahrung gemacht, dass in Enterprise- bzw. Provider-Umgebungen Probleme auftreten können, die im Hobbykeller, im Verein oder im SoHo ausbleiben und völlig unbekannt sind. In diesen Fällen darf man sich nicht wundern, wenn sich in den Community-Foren niemand findet, der helfen kann. Hier kann ein kommerzieller Support vorteilhaft sein, der auf diese Umgebungen ausgerichtet ist und über mehr Erfahrung in diesem Bereich verfügt.

Ich persönlich bin mit dem Red Hat Support für RHEL zufrieden. Er hat mir schon einige Male bei Problemen und Fragestellungen geholfen, wo ich im Forum vermutlich ohne Antwort geblieben wäre. Die Support-Qualität bei AlmaLinux und Rocky Linux kann ich mangels Erfahrung nicht beurteilen.

Softwareunterstützung

Alle drei betrachteten Distributionen sind zueinander binärkompatibel. Das bedeutet, dass Anwendungen, die unter RHEL ausgeführt werden können, in aller Regel auch unter AlmaLinux und Rocky Linux ausgeführt werden können und umgekehrt.

Software-Hersteller führen in ihren Systemvoraussetzungen häufig unterstützte Betriebssysteme auf. Hier finden sich manchmal nur die kommerziellen Enterprise-Betriebssysteme wie RHEL oder SuSE Linux Enterprise Server (SLES). In solch einem Fall kann es passieren, dass der Software-Hersteller den Support ablehnt, wenn man seine Anwendung auf einem RHEL-Klon ausführt statt auf dem Original. Evtl. verlangt der Hersteller auch nur, dass das Problem unter einem offiziell unterstützten Betriebssystem nachgestellt wird. Dieser Punkte sollte bei der Auswahl einer Distribution mit bedacht werden.

Dokumentation

Red Hat bietet für RHEL eine ausführliche Produkt-Dokumentation und eine umfassende Wissensdatenbank. Zwar ist auch hier nicht alles perfekt, doch hat man dies auch schon deutlich schlechter gesehen. Um die Dokumentation kontinuierlich zu verbessern, bietet Red Hat allen Kunden und Nutzern die Möglichkeit, Dokumentations-Feedback direkt in der Dokumentation zu geben. Aus eigener Erfahrung kann ich berichten, dass gefundene Fehler meist innerhalb weniger Tage behoben werden.

Bei AlmaLinux habe in hinsichtlich Dokumentation auf den ersten Blick nur ein Wiki gefunden, welches auf mich hinsichtlich Gliederung und Umfang einen enttäuschenden Eindruck macht.

Rocky Linux hat ebenfalls ein Wiki und einen gesonderten Bereich für Dokumentation. Auch hier lässt mich die Gliederung etwas verstört und hilflos zurück. Zwar finden sich auf den ersten Blick mehr Anleitungen als bei AlmaLinux, an die RHEL-Dokumentation reicht sie jedoch keinesfalls heran.

Die schwache bis mangelhafte Dokumentation bei AlmaLinux bzw. Rocky Linux mag nicht so sehr ins Gewicht fallen, da man in vielen Fällen einfach die RHEL-Doku zurate ziehen kann. Auch hier profitieren die beiden Projekte wieder von der Vorarbeit des Originals.

Release-Zyklen

Seit RHEL 8 hat sich Red Hat feste Release-Zyklen auferlegt, welche alle 6 Monate ein Minor- bzw. Point-Release und alle 3 Jahre ein Major-Release vorsehen. Da AlmaLinux und Rocky Linux als Downstream-Projekte aus den RHEL-Quelltexten gebaut werden, erscheinen deren Releases stets nach der Veröffentlichung eines RHEL-Release. Die folgende Tabelle gibt einen kleinen Überblick, wann welche Distribution ein Minor-Release veröffentlicht hat.

Release	AlmaLinux	RHEL	Rocky Linux
8.4	2021-05-26	2021-05-18	2021-06-21
8.5	2021-11-12	2021-11-09	2021-11-15
8.6	2022-05-12	2022-05-10	2022-05-16
9 beta	2022-04-19	2021-11-03	N/A
9.0 GA	2022-05-26	2022-05-18	2022-07-14

Bisher folgen die Releases von AlmaLinux und Rocky Linux in der Regel wenige Tage auf das RHEL-Release. Beim Major-Release 9 hing RockyLinux ca. 1,5 Monate hinterher.

Bereitstellung von Sicherheits-Updates

Alle drei Projekte stellen Produkt-Errata im Internet bereit:

• AlmaLinux Product Errata – https://errata.almalinux.org/
• Red Hat Product Errata – https://access.redhat.com/errata
• Rocky Linux Product Errata – https://errata.rockylinux.org/

Dabei werden Errata in Bugfix-, Enhancement- und Security-Advisory unterschieden.

Während Bugs und fehlende Funktionalität störend und ärgerlich sein können, stellt die schnelle Verfügbarkeit von Sicherheits-Updates einen kritischen Faktor dar, um Sicherheitslücken zeitnah schließen zu können. Nach Aussage von AlmaLinux werden Errata bei AlmaLinux und Rocky Linux mit einem Geschäftstag Verzögerung in Bezug auf das RHEL-Errata-Release veröffentlicht. Ob beide Projekte dies durchhalten können, werde ich in der Zukunft stichprobenartig kontrollieren.

Mein Open-Source-Projekt Ansible: Patch-Management für Red Hat Systeme nutzt die Red Hat Security Advisories, um sogenannte Patch-Sets zu definieren, welche zu bestimmten Stichtagen installiert werden. Es ist darauf angewiesen, dass Errata-Informationen als Meta-Informationen in den Paket-Repositorien verfügbar sind. Bei CentOS fehlten diese, sodass mein Patch-Management für CentOS nicht nutzbar ist.

Daher bin ich sehr erfreut, dass AlmaLinux und Rocky Linux diese Meta-Informationen ebenfalls in ihren Repositorien bereitstellen. Prinzipiell sollte mein Patch-Management auch mit diesen beiden Distributionen funktionieren. Ein Test steht jedoch noch aus.

Zusammenfassung

Mit AlmaLinux und Rocky Linux gibt es zwei von einer Gemeinschaft entwickelte binärkompatible RHEL-Klone, welche von unterschiedlichen Unternehmen unterstützt und gesponsort werden. Erste Unternehmen bieten kommerziellen Support für diese Distributionen an.

Mir fällt positiv auf, dass beide Projekte in ihren Repos Errata-Informationen wie z.B. ALSA oder RLSA bereitstellen. Dies erleichtert die gezielte Installation von sicherheitsrelevanten Aktualisierungen. Hier bieten beide Projekte mehr, als es CentOS in der Vergangenheit tat.

Die Dokumentation scheint bei beiden Projekten keine große Rolle zu spielen. Ich empfinde sie als unübersichtlich und lückenhaft. Hier kann man jedoch vermutlich auf die Dokumentation des Originals (RHEL) zurückgreifen, welche sich mit sehr geringer Transferleistung auch für AlmaLinux und Rocky Linux nutzen lässt.

Auf den ersten Blick scheint es sich sowohl bei AlmaLinux als auch bei Rocky Linux um zwei solide Distributionen für alle jene zu handeln, die sich RHEL nicht leisten können oder wollen.

Vergleichsweise kurze drei Jahre dauerte es von RHEL 8 bis RHEL 9: Vor ca. zwei Wochen präsentierte Red Hat die neueste Version von Red Hat Enterprise Linux. Diese Linux-Distribution wird in den nächsten Jahren als Referenz für den kommerziellen Linux-Einsatz gelten.

Das Rennen, wer als erster einen RHEL9-Klon fertigstellen kann, hat AlmaLinux gewonnen. AlmaLinux zählt neben Rocky Linux und Oracle Linux zu den drei wichtigsten CentOS-Nachfolgern. (Zur Erinnerung: CentOS, der in der Vergangenheit populärste RHEL-Klon, wurde von Red Hat Ende 2021 eingestellt. CentOS Stream, ein neues Angebot von Red Hat, hat eine andere Zielgruppe als das originale CentOS.)

Nur 9 Tage nach dem RHEL-Release steht AlmaLinux 9 für dieselben vier CPU-Architekturen wie das Original zur Auswahl: x86_64, aarch64, ppc64le und s390. Zusätzlich zu den »gewöhnlichen« Installations-ISO-Images gibt es Live-Images, die neben Gnome auch die (von Red Hat nicht offiziell unterstützten) Desktop-Systeme KDE und Xfce enthalten. AlmaLinux gibt es auch in Form von Docker-Images, zur Installation für den Raspberry Pi, zur Installation im Windows Subsystem for Linux (WSL) sowie für diverse Cloud-Plattformen. Dass AlmaLinux diese riesige Software-Palette wenige Tage nach dem RHEL-Release anbieten kann, ist beeindruckend.

Dieser Blog-Beitrag wirft einen ersten Blick auf AlmaLinux 9 für x86-64-CPUs.

Installation und Betrieb

An der Installation von RHEL bzw. AlmaLinux hat sich im Vergleich zu Version 8 praktisch nichts verändert. Das Installationsprogramm funktioniert unverändert. Unübersichtlich wie eh und je ist die Partitionierung der Datenträger (falls erforderlich). Alle anderen Schritte sind schnell und intuitiv erledigt.

Für die Konfiguration von RHEL bzw. AlmaLinux gewinnt Cockpit weiterhin an Bedeutung. Die Webkonsole muss mit systemctl enable --now cockpit.socket aktiviert werden und kann dann über Port 9090 im Webbrowser verwendet werden.

Für nicht offizielle Zusatzpakete ist EPEL weiterhin die erste Wahl. Die Paketquelle wird unter AlmaLinux einfach mit dnf install epel-release aktiviert.

Versionsnummern

Wie üblich steht bei RHEL 9 und damit auch bei allen Klonen Stabilität vor Aktualität. Im Vergleich zu Version 8 ist der Software-Stack aber doch deutlich aktueller. Das AppStream-Konzept wird von wichtigen Programmiersprachen und Server-Paketen in Zukunft auch neuere Versionen zur Auswahl stellen.

Basis             Desktop             Programmierung   Server
---------------   ------------------  --------------   --------------
Kernel     5.14   Gnome          40   bash       5.1   Apache     2.4
glibc      2.34   Firefox ESR    91   gcc       11.2   CUPS       2.3
X-Server   1.20   Gimp         2.10   git       2.31   MySQL      8.0
Wayland    1.19   LibreOffice   7.1   Java        11   OpenSSH    8.7
Mesa       21.3   Thunderbird    91   PHP        8.0   qemu/KVM   6.2
Systemd     250                       Podman     4.0   Postfix    3.5
NetworkMan 1.36                       Python     3.9   Samba     4.15
GRUB       2.06 

Technische Neuerungen

Abseits der Versions-Updates gibt es in RHEL9 verblüffend wenig »echte« Neuerungen.

• Firewall: Die Firewall-Funktionen verwenden nun nft als neues Fundament. In der Praxis ändert das vorerst wenig, iptables steht als kompatibles Kommando weiterhin zur Verfügung. Die Release Notes warnen allerdings davor, die in iptables-nft enthaltenen Kommandos einzusetzen. Die Kompatibilitätsschicht wird nicht weiterentwickelt, neue Firewall-Scripts sollen nativ nft verwenden.

• Netzwerkkonfiguration: Das traditionsreiche Verzeichnis /etc/sysconfig/network-scripts ist jetzt leer. Standardmäßig erfolgt die Konfiguration der Schnittstellen nun direkt durch Dateien im Verzeichnis /etc/NetworkManager/system-connections. (Das NetworkManager-Plugin ifcfg-rh zur Verarbeitung von Konfigurationsdateien in network-scripts steht aber weiterhin zur Verfügung und funktioniert unverändert. Es befindet sich im Paket NetworkManager. Details siehe man nm-settings-ifcfg-rh sowie man NetworkManager.conf.)

• Core Scheduling: Mit Core Scheduling besteht die Möglichkeit, einer Gruppe von Prozessen eine CPU-Core zuzuweisen. Das kann aus Sicherheits- oder Performance-Gründen zweckmäßig sein. Mehr Details sind hier beschrieben.

• Grafiksystem: Schon RHEL 8 setzte standardmäßig auf Wayland. Neu ist, dass X.org in den Release Notes nun als deprecated bezeichnet wird. Offensichtlich sollen die X.org-Pakete in zukünftigen RHEL-Versionen entfernt werden. Für die X-Kompatibilität ist Xwayland zuständig.

• Virtualisierung: Wie schon in RHEL 8 ist virt-manager als deprecated markiert. Das Paket steht aber weiterhin zur Verfügung. Längerfristig soll virt-manager durch Cockpit ersetzt werden.

• Podman: Red Hat setzt anstelle von Docker weiter auf die Eigenentwicklung Podman. RHEL/AlmaLinux 9 enthält die erst im Februar 2022 vorgestellte Version 4.0 von Podman.

Fazit

RHEL 9 ist, was die technischen Neuerungen betrifft, ein eher unspektakuläres RHEL-Release.

Erfreulich entwickelt hat sich das Angebot der RHEL-Klone: Vor zwei Jahren hatte ich befürchtet, ohne CentOS würde ein riesiges Loch in der RHEL-Welt entstehen. Stattdessen gibt es nun mit Rocky Linux und AlmaLinux zwei neue, sehr aktive und offenbar gut finanzierte Angebote. Zusammen mit Oracle Linux und einigen weiteren Anbietern ist das Klon-Angebot breiter denn je.

Es ist schwer, unter den Klonen einen eindeutigen Favoriten zu erkennen. Seit 18 Monaten sticht Alma Linux aber durch besonders schnelle Reaktionszeiten hervor — d.h. die Wartezeiten nach offiziellen RHEL-Releases beträgt jeweils nur wenige Tage. Insgesamt ist es beruhigend zu sehen, dass es nicht ein Angebot gibt, sondern eine gesunde Konkurrenz zwischen mehreren Anbietern (samt Scripts, die einen unkomplizierten Wechsel ermöglichen).

Quellen/Links

• AlmaLinux 9 Now Available (Blog von AlmaLinux)
• AlmaLinux 9 Relase Notes
• AlmaLinux 9 ISO Downloads
• AlmaLinux 9 Live Medien (inkl. KDE und Xfce)
• AlmaLinux 9 für den Raspberry Pi
• AlmaLinux 9 für WSL
• AlmaLinux 9 für Docker
• Wikipedia-Seite zu Alma Linux (mit Release-Zeiten)

Red Hat Enterprise Linux 9

• Hot Off the Presses: Red Hat Enterprise Linux 9 (Red Hat Blog)
• RHEL 9 Release Notes
• RHEL 9 Documentation
• RHEL 9 Deprecated Functionality
• Core Scheduling
• Podman 4 Release Notes
• Bericht bei heise.de
• Bericht bei theregister.co.uk

Sonstiges

• Nachruf auf CentOS
• EPEL 9 Release