Am zehnten Juli endet planmäßig der Support für Ubuntu 24.10. Danach gibt es keine Sicherheitsupdates oder Fehlerbehebungen mehr. Wer das System weiter nutzt, bleibt ohne Schutz vor bekannten Schwachstellen. Canonical empfiehlt dringend ein Upgrade auf Ubuntu 25.04. Die neue Version trägt den Namen Plucky Puffin und wird noch bis Januar 2026 unterstützt. Danach folgt Ubuntu […]
Wenn Sie meinen vorigen Blogbeitrag über Hetzner-Cloud-Benchmarks gelesen haben, ist Ihnen vielleicht aufgefallen, dass ich Alma Linux 10 in einer Hetzner-Cloud-Instanz ausgeführt habe, um dort Geekbench-Tests auszuführen. Das war nicht so einfach: Hetzner bietet Alma Linux 10 noch nicht als Installations-Image an. (Update 3.7.2025: mittlerweile schon, sowohl AlmaLinux 10 als auch Rocky Linux 10)
Also habe ich eine neue Instanz zuerst mit Alma Linux 9 eingerichtet und danach mit Elevate ein Update auf Version 10 durchgeführt. Das ist erstaunlich unkompliziert gelungen, obwohl Version-10-Updates eigentlich noch im Beta-Test sind.
Update 10.7.2025: Version-10-Updates werden jetzt offiziell unterstützt (Quelle)
Was ist LEAPP, was ist Elevate?
RHEL und alle Klone durchlaufen über reguläre Updates alle Minor-Releases. Wenn Sie also Alma Linux 9.0 installiert haben, erhalten Sie durch die regelmäßige Installation von Updates nach und nach die Versionen 9.1, 9.2 usw. Ein Update auf die nächste Major-Version ist aber nicht vorgesehen.
Mit LEAPP hat Red Hat ein Framework geschaffen, um Major-Version-Updates für RHEL durchzuführen. LEAPP wurde sehr allgemeingültig konzipiert und kümmert sich um Pre-Upgrade-Kontrollen, Paketabhängigkeiten, den Workflow zwischen verschiedenen Stadien des Upgrades usw.
Elevate ist eine Community-Erweiterung zu LEAPP, die über das eigentliche Upgrade hinaus in manchen Fällen auch einen Wechsel der Paketquellen zwischen Alma Linux, CentOS, Oracle Linux und RockyLinux durchführen kann. Sie können mit Elevate beispielsweise zuerst von CentOS 7 zu RockyLinux 8 migrieren und dann weiter zu Rocky Linux 9 upgraden.
Mögliche Migrationspfade für »Elevate« (Stand: Juni 2026, Bildquelle: https://wiki.almalinux.org/elevate/ELevate-quickstart-guide.html)
Vorbereitungsarbeiten
Bevor Sie Elevate anwenden, müssen Sie ein vollständiges Backup durchführen und Ihren Rechner bzw. Ihre virtuelle Maschine neu starten:
dnf update
reboot
Danach richten Sie eine Paketquelle für Elevate ein und installieren das für Sie relevante Upgrade-Modul (für das Beispiel in diesem Artikel mit der Zieldistribution Alma Linux also leapp-data-almalinux).
dnf install -y http://repo.almalinux.org/elevate/elevate-release-latest-el$(rpm --eval %rhel).noarch.rpm
# für AlmaLinux
dnf install leapp-upgrade leapp-data-almalinux
# alternativ für Rocky Linux (etc.)
dnf install leapp-upgrade leapp-data-rocky
Als nächstes folgt ein Test, ob das gewünschte Upgrade (plus gegebenenfalls eine Migration zu einer anderen Distribution, hier nicht relevant) überhaupt möglich ist:
leapp preupgrade
leapp preupgrade erzeugt zwei Dateien: Einen umfassenden Bericht, der alle möglichen Probleme aufzählt, und eine answer-Datei, in die Sie gegebenenfalls Optionen eintragen müssen (z.B. mit leapp answer --section check_vdo.confirm=True). In meinem Fall — Upgrade einer Minimalinstallation von Alma Linux 9 auf 10, hat leapp preupgrade auf die folgenden Probleme hingewiesen, aber keine answer-Einträge verlangt.
High: veraltete Netzwerkkonfiguration in /etc/sysconfig/network-scripts
High: unbekannte Systemdateien (»Aktoren«)
High: unbekannte Pakete (hc-utils)
Medium: Berkeley DB (libdb) ist installiert, wird in RHEL 10 nicht mehr unterstützt
Low: unbekannten Paket-Repositories
cat /var/log/leapp/leapp-report.txt
Risk Factor: high (inhibitor)
Title: Legacy network configuration found
Summary: Network configuration files in legacy "ifcfg" format are present ...
- /etc/sysconfig/network-scripts/ifcfg-eth0
Related links:
- How to migrate the connection from ifcfg to NetworkManager keyfile plugin?:
https://access.redhat.com/solutions/7083803
- nmcli(1) manual, describes "connection migrate" sub-command.:
https://networkmanager.dev/docs/api/latest/nmcli.html
...
Remediation: [hint] Convert the configuration into NetworkManager native "keyfile" format.
----------------------------------------
Risk Factor: high
Title: Detected custom leapp actors or files.
Summary: We have detected installed custom actors or files on the system.
These can be provided e.g. by third party vendors ... This is allowed
and appreciated. However Red Hat is not responsible for any issues caused
by these custom leapp actors ...
The list of custom leapp actors and files:
- /usr/share/leapp-repository/repositories/system_upgrade/\
common/files/distro/almalinux/rpm-gpg/10/RPM-GPG-KEY-AlmaLinux-10
- /usr/share/leapp-repository/repositories/system_upgrade/\
common/files/rpm-gpg/10/RPM-GPG-KEY-AlmaLinux-10
...
Den vollständigen Report können Sie sich hier durchlesen.
Migration der Netzwerkkonfiguration
Wirklich kritisch war aus meiner Sicht nur die Netzwerkkonfiguration; die restlichen Hinweise und Empfehlungen habe ich ignoriert. Das Paket hc-utils (Hetzner Cloud Utilities) ist nur für Funktionen relevant, die in meinem Fall ohnedies nicht genutzt werden (siehe hier).
Auch die veraltete Netzwerkkonfiguration stammt vom Hetzner-Image für Alma Linux 9. Eine Umstellung auf eine *.nmconnection-Datei für den NetworkManager gelingt erstaunlich unkompliziert mit einem einzigen Kommando:
Mit einem weiteren Reboot habe ich sichergestellt, dass die Umstellung auch funktioniert.
Das Upgrade
leapp upgrade initiiert nun das Upgrade auf Alma Linux 10. Dabei werden seitenweise Logging-Ausgaben produziert (siehe den kompletten Output mit ca. 3150 Zeilen):
leapp upgrade
==> Processing phase `configuration_phase` ...
==> Processing phase `FactsCollection` ...
...
==> Processing phase `TargetTransactionFactsCollection`
Create custom repofile containing information about
repositories found in target OS installation ISO, if used.
Initializes a directory to be populated as a minimal environment
to run binaries from the target system.
AlmaLinux 10.0 - BaseOS 5.9 MB/s | 2.8 MB 00:00
AlmaLinux 10.0 - AppStream 11 MB/s | 5.6 MB 00:00
AlmaLinux 10.0 - CRB 5.0 MB/s | 2.2 MB 00:00
AlmaLinux 10.0 - HighAvailability 161 kB/s | 69 kB 00:00
AlmaLinux 10.0 - Extras 28 kB/s | 12 kB 00:00
AlmaLinux 10.0 - SAP 8.3 kB/s | 3.5 kB 00:00
AlmaLinux 10.0 - SAPHANA 35 kB/s | 15 kB 00:00
AlmaLinux 10.0 - RT 2.8 MB/s | 1.1 MB 00:00
AlmaLinux 10.0 - NFV 2.8 MB/s | 1.1 MB 00:00
Dependencies resolved.
...
Transaction Summary: Install 153 Packages
...
Complete!
==> Processing phase `TargetTransactionCheck`
...
Transaction Summary
Install 63 Packages
Upgrade 389 Packages
Remove 18 Packages
Downgrade 3 Packages
Transaction test succeeded.
Complete!
====> add_upgrade_boot_entry
Add new boot entry for Leapp provided initramfs.
A reboot is required to continue. Please reboot your system.
Debug output written to /var/log/leapp/leapp-upgrade.log
============================================================
REPORT OVERVIEW
============================================================
HIGH and MEDIUM severity reports:
1. Packages not signed by Red Hat found on the system
2. Detected custom leapp actors or files.
3. Berkeley DB (libdb) has been detected on your system
Reports summary:
Errors: 0
Inhibitors: 0
HIGH severity reports: 2
MEDIUM severity reports: 1
LOW severity reports: 2
INFO severity reports: 1
Before continuing, review the full report below for details about discovered
problems and possible remediation instructions:
A report has been generated at /var/log/leapp/leapp-report.txt
A report has been generated at /var/log/leapp/leapp-report.json
============================================================
END OF REPORT OVERVIEW
============================================================
Answerfile has been generated at /var/log/leapp/answerfile
Reboot the system to continue with the upgrade. This might take a while
depending on the system configuration.
Make sure you have console access to view the actual upgrade process.
Jetzt wird es unheimlich: Mit reboot starten Sie die nächste Phase des Upgrade-Prozesses, der im Blindflug erfolgt. Der Rechner bzw. die virtuelle Maschine wird während dieser Phase noch einmal neu gestartet. Wenn Sie nicht vor dem Rechner sitzen, sehen Sie weder, was passiert, noch haben Sie über eine SSH-Verbindung die Möglichkeit, einzugreifen.
reboot
Wenn alles gut geht, können Sie sich nach ein paar Minuten wieder einloggen. Bei mir hat es funktioniert:
Ich habe mit diesem Experiment erreicht, was ich haben wollte: eine funktionierende, minimale Alma-Linux-10-Installation in einer im Internet erreichbaren virtuellen Maschine. Ich kann damit experimentieren. Vermutlich wird Hetzner in ein paar Wochen Alma Linux 10 als reguläres Cloud-Installations-Image anbieten. Dann werde ich diese Installation vermutlich wieder abschalten.
In der Vergangenheit habe ich Elevate auch schon auf lokale virtuelle Maschinen mit (nicht besonders wichtigen) Testumgebungen angewendet, ebenfalls zu meiner Zufriedenheit.
Aber ich würde mich niemals trauen, für ein produktiv wichtiges System auf diese Weise ein Upgrade oder womöglich eine Migration auf eine andere Distribution durchzuführen — und schon gar nicht, wenn ich keinen physischen Zugriff auf die Installation habe. Es kann dabei so viel schief gehen! Es ist unklar, ob danach überhaupt eine Reparatur möglich ist, und wenn ja, wie lange diese dauern würde.
Vergessen Sie zuletzt nicht, dass das Upgrade von Alma Linux 9 auf Version 10 aktuell noch im Beta-Test ist. Bei meinem Minimalsystem hat es funktioniert, aber das ist keine Garantie, dass das bei Ihnen auch klappt!
Kurz und gut: Die Kombination aus LEAPP und Elevate bietet eine großartige Möglichkeit, Major Upgrades für RHEL und seine Klone durchzuführen. Das ist ideal für Entwicklungs- und Testsysteme. Aber wie bei jedem Linux-Distributions-Upgrade kann dabei viel schief gehen. Der sichere Weg für produktiv wichtige Installationen ist immer eine Neuinstallation! Sie können dann in aller Ruhe sämtliche Funktionen testen, zum Schluss die Daten migrieren und mit minimaler Downtime eine Umstellung durchführen.
Die nächste Version von Linux Mint steht in den Startlöchern. Mint 22.2 mit dem Codenamen Zara bringt eine besondere Neuerung. Eine eigene Anwendung namens Fingwit ermöglicht endlich Fingerabdruckerkennung. Mit Fingwit lässt sich der Rechner nicht nur entsperren. Auch der Sperrbildschirm, Sudo-Befehle und Adminrechte reagieren auf den Finger. Die App erkennt sogar automatisch, wann lieber das […]
Die zwei günstigsten Angebote in der Hetzner-Cloud sind Instanzen mit zwei CPU-Cores, 4 GB RAM und 40 GB Diskspace: Einmal mit virtuellen ARM-CPU-Cores (»CAX11«), einmal mit virtuellen x86-Cores (»CX22«). Der Preis ist identisch: 3,95 EUR/Monat inkl. USt (für D) plus ein Aufpreis von 0,50 EUR/Monat für eine IPv4-Adresse. Die naheliegende Frage ist: Welches Angebot gibt mehr Rechenleistung? Dieser Frage bin ich an einem verregneten Pfingstsonntag auf den Grund gegangen.
Ein »virtueller CPU-Core« heißt in diesem Zusammenhang, dass auf einem Server mehrere/viele virtuelle Maschinen laufen. Je nach Auslastung kann es sein, dass die für eine virtuelle Maschine vorgesehen CPU-Cores nicht vollständig verfügbar sind. Es gibt auch virtuelle Maschinen mit dezidierten Cores, die immer zur Verfügung stehen — aber die sind natürlich teurer.
Auswahl verschiedener Cloud-Instanzen
Testbedingungen
Für meine Tests habe ich zwei Cloud-Instanzen mit Alma Linux 9 eingerichtet, einmal mit zwei ARM-CPU-Cores (CAX11), einmal mit zwei x86-CPU-Cores (CX11). Außer tar und Geekbench habe ich keine weitere Software installiert. /proc/cpuinfo lieferte die folgenden Ergebnisse:
cat /proc/cpuinfo # CAX11 / ARM (Ampere)
processor : 0
BogoMIPS : 50.00
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm lrcpc dcpop asimddp
CPU implementer : 0x41
CPU architecture: 8
CPU variant : 0x3
CPU part : 0xd0c
CPU revision : 1
processor : 1
...
Geekbench-Ergebnisse
In beiden virtuellen Maschinen habe ich mit wget Geekbench heruntergeladen, mit tar xzf ausgepackt und dann dreimal ausgeführt. Die Ergebnisse:
CX11 / x86 / Alma Linux 9
Single Multi Core
------ -----------
698 1203
692 1207
642 1205
--------------------------
CAX11 / ARM / Alma Linux 9
Single Multi Core
------ -----------
1082 1979
1084 1982
1079 1965
Zuletzt wollte ich noch wissen, ob Alma Linux 10 bei gleicher Hardware mehr Speed liefert (schnellerer Kernel, bessere Optimierung/Kompilierung der Programme etc.). Diese Tests habe ich nur auf der ARM-Instanz durchgeführt.
CAX11 / ARM / Alma Linux 10
Single Multi Core
------ -----------
1078 1971
1069 1963
1077 1974
Zusammenfassung: Bei meinen Tests boten die CAX11-Instanzen bei gleichen Kosten fast 50% mehr Leistung. Alma Linux 9 versus 10 ergibt dagegen keinen messbaren Unterschied.
PS: Geekbench ist noch nicht im IPv6-Zeitalter angekommen. Ist ja auch wirklich eine ganz neue Technologie … Wenn Sie selbst Tests durchführen wollen, müssen Sie die Instanz mit einer IPv4-Adresse konfigurieren. Weder gelingt der Download (das lässt sich umgehen), noch kann ./geekbench6 danach die Ergebnisse hochladen.
Einschränkungen
Bitte überbewerten Sie die Ergebnisse nicht! Die Hetzner-Cloud-Seite gibt keinerlei Informationen darüber, auf welchem Server bzw. auf welcher CPU Ihre virtuellen Maschinen laufen werden. Hetzner hat mehrere Rechenzentren mit unzähligen Server, mit Glück oder Pech landet Ihre virtuelle Maschine auf einem anderen, besser oder schlechter ausgestatteten Server. Das hier präsentierte Ergebnis ist nur eine Momentaufnahme, kein professionell über Wochen durchgeführter Test!
Es erscheint mir unwahrscheinlich, dass zum Testzeitpunkt (Sonntag nachmittag) die Cloud-Server besonders stark ausgelastet waren, aber es ist natürlich denkbar, dass das Ergebnis durch die Aktivität anderer virtueller Maschinen beeinflusst wurde.
Geekbench ist definitiv nicht das Maß der Dinge für Server-Benchmarks. Aber Geekbench lässt sich leicht installieren und ausführen, außerdem sind die Ergebnisse mit Desktop-Hardware vergleichbar. Sagen wir so: Um die CPU-Performance zu vergleichen, sind die Tests aus meiner Sicht gut genug.
Zu guter Letzt habe ich ausschließlich die billigsten Cloud-Angebote verglichen (die bei meinen Anwendungen aber oft ausreichen). Es gibt viele weitere Varianten, z.B. »CPX11« (2 AMD-Cores, nur 2 GB RAM, 40 GB Disk).
Kurz und gut: Dieser Test besagt NICHT, dass ARM immer mehr Leistung als x86 bietet. Zum Zeitpunkt meiner Tests und bei den von mir gewählten Randbedingungen erscheint es aber so, also würden Sie bei preisgünstige Cloud-Instanzen mit ARM-CPUs aktuell mehr Leistung bekommen als bei Instanzen zum gleichen Preis mit x86-Hardware.
LibreOffice erhält mit Version 25.2.4 ein neues Update. Die Entwickler beheben 52 Fehler in der freien Bürosuite. Damit soll die Stabilität weiter verbessert werden. Die neue Version folgt rund fünf Wochen nach dem letzten Update. Nutzer berichten von weniger Abstürzen und spürbar flüssigerem Arbeiten. Wer bereits Version 25.2 nutzt, sollte bald aktualisieren. LibreOffice 25.2 erschien […]
Die mobile Version von Ubuntu bekommt ein neues Update. Die Community rund um die UBports Foundation hat OTA 9 veröffentlicht. Die neue Version basiert auf Ubuntu 20.04 LTS. Besonders erfreulich ist die verbesserte VoLTE Unterstützung. Auf mehreren Volla Geräten funktioniert die Telefonie über LTE nun direkt. Auf anderen Geräten bleibt sie jedoch experimentell. Auch Waydroid […]
Viele Android Nutzer wünschen sich mehr Kontrolle über ihre Daten. Genau das bietet /e/OS, ein alternatives Betriebssystem ohne Google Dienste. Die neue Version 3.0 hebt das Projekt nun auf ein neues Niveau. Entwickelt wird das System von der e Foundation in Zusammenarbeit mit Murena. Die Software läuft auf Murena Geräten und ausgewählten Smartphones anderer Hersteller. […]
Zwei neu entdeckte Schwachstellen gefährden aktuell bestimmte Linux-Distributionen. Die Sicherheitsforscher von Qualys haben Race Conditions in den Komponenten apport und systemd-coredump identifiziert. Sie wurden unter den CVE-Nummern CVE-2025-5054 und CVE-2025-4598 veröffentlicht und ermöglichen es lokalen Angreifern, auf Speicherabzüge privilegierter Prozesse zuzugreifen. CVE-2025-5054 betrifft die apport-Komponente, die bei Ubuntu zum Einsatz kommt – konkret Versionen bis […]
Mit Agama 15 veröffentlichen die (open)SUSE – Entwickler gleich zwei neue Versionen auf einmal – auch Agama 14 hatte längst das Licht der Welt erblickt, blieb aber ohne offiziellen Blogeintrag. Nun werden die Neuerungen beider Releases in einem Rutsch vorgestellt, und die haben es in sich. Besonders im Fokus stehen Verbesserungen der Benutzerfreundlichkeit. So wurde […]
Die GNOME-Entwickler haben mit Version 48.2 ein neues Wartungsupdate veröffentlicht. Es bringt gezielte Optimierungen für mehr Stabilität und Benutzerfreundlichkeit. Die Einstellungen-App zeigt jetzt mehrere GPU-Namen bei NVIDIA korrekt an. Zudem wurde die Passwort-Generierung überarbeitet und nutzt nun sicherere Wortlisten. Auch die Wiederherstellung maximierter Fenster auf dem richtigen Monitor funktioniert nun besser. Im Webbrowser Epiphany wurden […]
Die leichtgewichtige und vor allem in Containern als Grundlage dienende Distribution Alpine Linux frischt in ihrer neuen Version vor allem zahlreiche Pakete auf.
Die leichtgewichtige und vor allem in Containern als Grundlage dienende Distribution Alpine Linux frischt in ihrer neuen Version vor allem zahlreiche Pakete auf.
Der Linux Coffee Talk ist ein besonderes Format bei fosstopia, in dem wir die spannendsten Themen des vergangenen Monats Revue passieren lassen. Schnapp Dir einen Kaffee, Tee oder Dein Lieblingsgetränk, lehn Dich zurück und genieße die lockere Stimmung. In dieser Ausgabe werfen wir einen Blick auf die wichtigsten Entwicklungen im Mai 2025. Viel Spaß beim […]
Der Linux Coffee Talk ist ein besonderes Format bei fosstopia, in dem wir die spannendsten Themen des vergangenen Monats Revue passieren lassen. Schnapp Dir einen Kaffee, Tee oder Dein Lieblingsgetränk, lehn Dich zurück und genieße die lockere Stimmung. In dieser Ausgabe werfen wir einen Blick auf die wichtigsten Entwicklungen im Mai 2025.
Canonical hat eine große Änderung für Ubuntu angekündigt. Ab sofort wird es monatliche Schnappschüsse der Entwicklungsversion geben. Diese Maßnahme soll die Stabilität zukünftiger Releases verbessern. Die klassische Struktur mit halbjährlichen Releases und langfristigem LTS-Support bleibt unangetastet. Ziel der Neuerung ist es moderne Release-Techniken stärker zu nutzen. Während früher vor allem in den letzten Wochen vor […]
Die zweite Beta von KDE Plasma 6.4 ist da und richtet sich an Tester und Entwickler. Mit der neuen Testversion liefert das Team mehrere gezielte Fehlerbehebungen für zentrale Komponenten der Desktopumgebung. Besonders verbessert wurde die Unterstützung von Xwayland bei nicht-englischen Tastaturlayouts. Ein Fehler, der zu hängengebliebenen Tasten führen konnte, wurde beseitigt. Auch die Handhabung von […]
Mit einer Woche Abstand zur RHEL-10-Veröffentlichung bringt AlmaLinux OS 10 frischen Wind in die Enterprise-Linux-Welt. Die neue Version mit dem Spitznamen „Purple Lion“ setzt auf Kernel 6.12 und verspricht vollständige Kompatibilität mit Red Hat Enterprise Linux. Ein Highlight: Frame Pointers sind nun standardmäßig aktiviert. Das erlaubt bessere Systemanalyse in Echtzeit. Auch ältere Hardware profitiert, denn […]
Seit einigen Jahren ist CentOS kein produktionstauglicher RHEL-Klon mehr. Wer RHEL produktiv nutzen will, aber nicht dafür bezahlen kann, hat die Qual der Wahl: zwischen AlmaLinux, CentOS Stream (nicht für Langzeitnutzung), Oracle Linux, RHEL via Developer Subscription und Rocky Linux. Ich bin ein wenig zufällig im AlmaLinux-Lager gelandet und habe damit über mehrere Jahre, vor allem im Unterricht, ausgezeichnete Erfahrungen gemacht.
Nach diversen Tests mit der Beta-Version läuft AlmaLinux 10 jetzt nativ auf meinem Mini-PC (AMD 8745H), außerdem die aarch64-Variante in einer virtuellen Maschine auf meinem Mac. Dieser Artikel stellt die neue Version AlmaLinux 10 vor, die am 27. Mai 2025 freigegeben wurde, genau eine Woche nach dem Release von RHEL 10. Die meisten Informationen in diesem Artikel gelten auch für RHEL 10 sowie für die restlichen Klone. Oft beziehe ich mich daher im Text auf RHEL (Red Hat Enterprise Linux), also das zugrundeliegende Original. Es gibt aber auch ein paar feine Unterschiede zwischen dem Original und seinen Klonen.
AlmaLinux 10 mit Gnome Desktop
Ich habe vor, diesen Artikel in den nächsten Wochen zu aktualisieren, wenn ich mehr Erfahrungen mit AlmaLinux 10 gemacht habe und es zu Rocky Linux 10 und Oracle Linux 10 weitere Informationen gibt.
Update 8.6.2025: Der MySQL-Server ist per Default weiterhin offen wie ein Scheunentor.
Update 16.6.2025: Zu Rocky Linux 10 gibt es jetzt auch Release Notes.
Update 16.6.2025: Postfix und BDB vs LMDB
Update 27.6.2025: Oracle Linux 10 ist auch verfügbar, ich habe am Ende des Artikels Links zum Oracle-Blog und zu den Release Notes eingebaut
Update 3.7.2025: Im Hetzner-Cloud-Konfigurator können Sie jetzt auch AlmaLinux 10 und Rocky Linux 10 auswählen. Die Netzwerkkonfiguration erfolgt durch /etc/NetworkManager/system-connections/cloud-init-eth0.nmconnection (nicht mehr durch die veralteten Dateien in /etc/syconfig/network-scripts).
Red Hat hat mit RHEL 10 den X.org-Server aus den Paketquellen entfernt. RHEL setzt damit voll auf Wayland. (Mit XWayland gibt es für X-Client-Programme eine Kompatibilitätsschicht.) Weil RHEL und seine Klone zumeist im Server-Betrieb und ohne grafische Benutzeroberfläche laufen, ist der Abschied von X.org selten ein großes Problem. Einschränkungen können sich aber im Desktop-Betrieb ergeben, vor allem wenn statt Gnome ein anderes Desktop-System eingesetzt werden soll.
Eine Menge wichtiger Desktop-Programme sind aus den regulären Paketquellen verschwunden, unter anderem Gimp und LibreOffice. RHEL empfiehlt, die Programme bei Bedarf aus Flathub zu installieren. Davon abgesehen ist aber kein Wechsel hin zu Flatpaks zu bemerken. flatpak list ist nach einer Desktop-Installation leer.
In der Vergangenheit haben RHEL & Co. von wichtigen Software-Produkten parallel unterschiedliche Versionen ausgeliefert. Dabei setzte RHEL auf das Kommando dnf module. Beispielsweise stellte RHEL 9 Mitte 2025 die PHP-Versionen 8.1, 8.2 und 8.3 zur Auswahl (siehe dnf module list php).
Anscheinend sollen auch in RHEL 10 unterschiedliche Versionen (»AppStreams«) angeboten werden — allerdings nicht mehr in Form von dnf-Modulen. Wie der neue Mechanismus aussieht, habe ich nach dem Studium der Release Notes allerdings nicht verstanden.
Administration und Logging
Wie schon in den vergangenen Versionen setzt RHEL zur Administration auf Cockpit. Die Weboberfläche ist per Default aktiv, nicht durch eine Firewall geschützt und über Port 9090 erreichbar.
Zur Webadministration ist »Cockpit« auf Port 9090 vorgesehen
Bei einer Desktop-Installation sind standardmäßig rsyslog und das Journal installiert. rsyslog protokolliert wie eh und je in Textdateien in /var/log. Das Journal führt dagegen keine persistente Speicherung durch. Die Logging-Dateien landen in einem temporären Dateisystem in /run/log/journal und verschwinden mit jedem Reboot wieder. Wenn Sie ein dauerhaftes Journal wünschen, führen Sie die folgenden Kommandos aus:
Unbegreiflicherweise ist MySQL — jetzt in Version 8.4 — auch in RHEL 10 per Default so konfiguriert, dass jeder Benutzer mit mysql -u root ohne Passwort volle MySQL-Administrationsrechte erhält. Bei Ubuntu erhält per Default nur sudo mysql Admin-Rechte, und bei MariaDB (egal, ob unter Debian, Fedora, RHEL oder Ubuntu) gilt die gleiche Regel. Warum also nicht auch bei RHEL und MySQL?
Wie dem auch sei, das Problem ist nicht neu. Führen Sie also unmittelbar nach der Installation von mysql-server das Kommando mysql_secure_installation aus! Entscheidend ist dabei die Einstellung einen root-Passworts für MySQL.
sudo mysql_secure_installation
Would you like to setup VALIDATE PASSWORD component? y
There are three levels of password validation policy:
LOW Length >= 8
MEDIUM Length >= 8, numeric, mixed case, and special characters
STRONG Length >= 8, numeric, mixed case, special characters,
dictionary file
Please enter 0 = LOW, 1 = MEDIUM and 2 = STRONG: 1
Please set the password for root here.
New password: ************
Re-enter new password: ************
Disallow root login remotely? y
Remove test database and access to it? y
Reload privilege tables now? y
Postfix und BDB versus LMDB
RHEL 10 liefert den Mail-Server Postfix in der Version 3.8 aus. Bei früheren RHEL-Versionen hat Postfix Berkeley Datenbanken (BDB) zur Speicherung von Konfigurationstabellen verwendet. Mit RHEL 10 wird allerdings die libdbd-Bibliotheken aufgrund von Lizenzproblemen nicht mehr mitgeliefert. Postfix verwendet jetzt per Default LMDB-Datenbanken:
So weit, so gut. Ich bin beim Versuch, einen Postfix-Server einzurichten, allerdings über die Datei /etc/aliases gestolpert. Bisher was es notwendig, nach jeder Änderung in dieser Datei die entsprechende BDB-Datenbank aliases.db mit dem Kommando newaliases neu zu generieren. Genau dieser Hinweis steht auch in der von RHEL ausgelieferten Beispieldatei /etc/aliases. Und erstaunlicherweise funktioniert das Kommando auch unter RHEL 10. newaliases ist über fünf Links mit /usr/sbin/smtpctl aus dem Paket opensmtpd verbunden und scheint weiterhin BDB-Funktionen zu enthalten, Lizenzsorgen hin oder her.
Das Problem ist allerdings, dass Postfix /etc/aliases.db ignoriert und sich stattdessen darüber beklagt, dass es /etc/aliases.lmdb nicht gibt.
journalctl -u postfix
... postfix/smtpd[56492]: error: open database /etc/aliases.lmdb: No such file or directory
Ich habe eine Weile gebraucht, bis ich einen Weg gefunden habe, aliases.lmdb zu erzeugen. Das richtige Kommando, das newaliases ersetzt, sieht jetzt so aus:
postalias /etc/aliases
Virtualisierung
Red Hat enthält die üblichen qemu/kvm-Pakete als Basis für den Betrieb virtueller Maschinen. Die Steuerung kann wahlweise auf Kommandoebene (virsh) oder mit der Weboberfläche Cockpit erfolgen.
Das wesentlich komfortablere Programm virt-manager hat Red Hat schon vor Jahren als obsolet bezeichnet, und ich hatte Angst, das Programm wäre mit Version 10 endgültig verschwunden. Aber überraschenderweise gibt es das Paket weiterhin im CodeReady-Builder-Repository:
crb enable
dnf install virt-manager
virt-manager ist aus meiner Sicht die einfachste Oberfläche, um virtuelle Maschinen auf der Basis von QEMU/KVM zu verwalten. Red Hat empfiehlt stattdessen Cockpit (dnf install cockpit-machines), aber dieses Zusatzmodul zur Weboberfläche Cockpit hat mich bisher nicht überzeugen können. Für die Enterprise-Virtualisierung gibt es natürlich auch OpenShift und OpenStack, aber für kleine Lösungen schießen diese Angebote über das Ziel hinaus.
Bereits in RHEL 9 hat Red Hat die Unterstützung für Spice (Simple Protocol for Independent Computing Environments) eingestellt (siehe auch dieses Bugzilla-Ticket). Spice wurde/wird von virt-manager als bevorzugtes Protokoll zur Übertragung des grafischen Desktops verwendet. Die Alternative ist VNC.
Abweichend von RHEL wird Spice von AlmaLinux weiter unterstützt (siehe Release Notes).
EPEL (Extra Packages for Enterprise Linux)
Zu den ersten Aktionen in RHEL 10 oder einem Klon gehört die Aktivierung der EPEL-Paketquelle. In AlmaLinux gelingt das einfach mit dnf install epel-release. Es wird empfohlen, zusammen mit EPEL auch die gerade erwähnte CRB-Paketquelle zu aktivieren.
Die EPEL-10-Paketquelle ist mit schon gut gefüllt. dnf repository-packages epel list | wc -l meldet über 17.000 Pakete! Ein paar Pakete habe ich dennoch vermisst:
google-authenticator fehlt noch, ist aber in EPEL 10.1 für Fedora schon enthalten, wird also hoffentlich auch für RHEL10 & Klone bald verfügbar sein.
joe fehlt ebenfalls nicht mehr (Stand 3.7.2025). Ich installiere dieses Editor-Paket gerne, weil es jmacs zur Verfügung stellt, eine minimale Emacs-Variante. Ich bin vorerst auf mg umgestiegen, es entspricht meinen Ansprüchen ebenfalls. (Ich bin kein vi-Fan, und nano ist mir ein bisschen zu minimalistisch. Den »richtigen« Emacs brauche ich aber auch nicht, um zwei Zeilen in /etc/hosts zu ändern.)
AlmaLinux in der Hetzner-Cloud
Hetzner bietet mittlerweile vorkonfigurierte Cloud-Instanzen für AlmaLinux 10 und RockyLinux 10 an. Die einzige wesentliche Neuerung, die mir aufgefallen ist, betrifft die Netzwerkkonfiguration. Während Hetzner bis Version 9 auf die eigentlich dort schon veralteten Dateien in /etc/sysconfig/network-scripts gesetzt hat, kümmert sich jetzt eine NetworkManager-Datei um die Konfiguration. Beispiel:
cat /etc/NetworkManager/system-connections/cloud-init-eth0.nmconnection
# Generated by cloud-init. Changes will be lost.
[connection]
id=cloud-init eth0
uuid=1dd9a779-d327-56e1-8454-c65e2556c12c
autoconnect-priority=120
type=ethernet
[user]
org.freedesktop.NetworkManager.origin=cloud-init
[ethernet]
mac-address=96:00:04:6E:A0:A0
[ipv4]
method=auto
may-fail=false
[ipv6]
method=manual
may-fail=false
address1=2a01:4f8:1c17:53db::1/64
gateway=fe80::1
dns=2a01:4ff:ff00::add:1;2a01:4ff:ff00::add:2;
AlmaLinux versus Original (RHEL)
Im Wesentlichen verwendet AlmaLinux den gleichen Quellcode wie RHEL und ist zu diesem vollständig kompatibel. Es gibt aber ein paar feine Unterschiede:
Seit RHEL den Zugang zum Quellcodes für die Updates erschwert hat (siehe Ärger für Red-Hat-Klone und Red Hat und die Parasiten), greift AlmaLinux auch auf den Upstream-Quellcode einzelner Projekte zu, führt Bugfixes/Sicherheits-Updates zum Teil früher durch als RHEL und besteht nicht mehr auf eine vollständige Bit-für-Bit- und Bug-für-Bug-Kompatibilität. Im Detail ist diese Strategie und das Ausmaß der Kompatibilität hier dokumentiert.
Red Hat hat RHEL 10 für x86_v3 kompiliert, unterstützt damit nur relativ moderne Intel- und AMD-CPUs. Deswegen läuft RHEL 10 auf älteren Computern nicht mehr! Alma Linux macht es ebenso, bietet aber darüber hinaus eine v2-Variante an und unterstützt damit auch ältere Hardware. Die Mikroarchitektur-Unterschiede zwischen v2 und v3 sind z.B. in der Wikipedia sowie auf infotechys.com beschrieben. Das v2-Angebot umfasst auch die EPEL-Paketquelle.
Der Verzicht auf Bit-für-Bit-Kompatibilität gibt AlmaLinux die Möglichkeit, sich in einigen Details vom Original abzuheben. Das betrifft unter anderem die Unterstützung von Frame Pointers als Debugging-Hilfe sowie die fortgesetzte Unterstützung des Protokolls Spice,
AlmaLinux vs RockyLinux und Oracle Linux
In der Vergangenheit waren alle Klone praktisch gleich. Nun gut, Oracle hat immer einen eigenen »unbreakable« Kernel angeboten, aber davon abgesehen war das gesamte Paketangebot Bit für Bit kompatibel zum Original, kompiliert aus den gleichen Quellen. Die Extrapakete aus der EPEL-Quelle sind sowieso für das Original und seine Klone ident.
Seit Red Hat 2023 den Zugriff auf den Source-Code aller Updates eingeschränkt bzw. deutlich weniger unbequemer gemacht hat, haben sich AlmaLinux auf der einen und Rocky Linux und Oracle Linux auf der anderen Seite ein wenig auseinander entwickelt. AlmaLinux hat den Anspruch auf Bit-für-Bit-Kompatibilität aufgegeben (siehe oben). Rocky Linux und Oracle Linux beziehen den Quellcode für Updates hingegen nun aus anderen öffentlichen Quellen, unter anderem aus Cloud- und Container-Systemen (Quelle).
RHEL Developer
Für Entwickler macht Red Hat mit dem Red Hat Developer eigentlich ein attraktives Angebot. Nach einer Registrierung gibt es 16 freie Lizenzen für Tests und Entwicklungsarbeit. Ich habe einen entsprechenden Account, habe RHEL 10 installiert und registriert, bin aber dennoch nicht in der Lage, die Paketquellen zu aktivieren. Vielleicht bin ich zu blöd, vielleicht wird RHEL 10 noch nicht unterstützt (diesbezüglich fehlt klare Dokumentation) — ich weiß es nicht. Ich habe es ein paar Stunden probiert, und ich werde es in ein paar Wochen wieder versuchen. Vorerst fehlt mir dazu aber die Zeit und der Nerv.
Mozilla hat Thunderbird 139 veröffentlicht. Dabei handelt es sich um ein Update mit vielen kleinen Verbesserungen. Der beliebte Open Source Mailclient bietet nun präzisere Benachrichtigungseinstellungen, die sich individuell anpassen lassen. Besonders praktisch: E Mails lassen sich direkt in der Benachrichtigung löschen oder als gelesen markieren. Das spart Klicks und sorgt für mehr Effizienz im Alltag. […]
Mozilla hat Version 139 seines Browsers Firefox pünktlich im Zeitplan zum 27. Mai 2025 veröffentlicht. Das Update bringt keine spektakulären Änderungen, aber viele sinnvolle Verbesserungen für Nutzer und Entwickler. Für Anwender besonders interessant: Firefox unterstützt nun vollständige Übersetzungen auf Erweiterungsseiten. Auch eingefügte transparente PNG-Bilder werden korrekt dargestellt. Zusätzlich gibt es neue Optionen zur Gestaltung der […]
Nach einer kurzen Verzögerung durch einen späten Fehlerbericht ist Linux 6.15 offiziell erschienen. Ein Feature musste in letzter Minute deaktiviert werden. Trotzdem bringt die neue Version zahlreiche Verbesserungen im Speicher-, Datei- und Sicherheitssystem mit. Im Fokus stehen Optimierungen für Container, effizientere Speicherverwaltung und Inline-Verschlüsselung. Auch das Dateisystem Bcachefs wurde stark erweitert. Btrfs, Ext4 und F2FS […]
Stefan Wiehler hat einen Kernel-Treiber entwickelt, über den sich alte Telefone mit Wählscheibe unter Linux als Eingabegerät verwenden lassen. Notwendig ist dafür eine kleine Elektronikschaltung.
Seit vielen Jahren verwende ich Let’s Encrypt-Zertifikate für meine Webserver. Zum Ausstellen der Zertifikate habe ich in den Anfangszeiten das Kommando certbot genutzt. Weil die Installation dieses Python-Scripts aber oft Probleme bereitete, bin ich schon vor vielen Jahren auf das Shell-Script acme.sh umgestiegen (siehe https://github.com/acmesh-official/acme.sh).
Kürzlich bin ich auf einen Sonderfall gestoßen, bei dem acme.sh nicht auf Anhieb funktioniert. Die Kurzfassung: Ich verwende Apache als Proxy für eine REST-API, die in einem Docker-Container läuft. Bei der Zertifikatausstellung/-erneuerung ist Apache (der auf dem Rechner auch als regulärer Webserver läuft) im Weg; die REST-API liefert wiederum keine statischen Dateien aus. Die Domain-Verifizierung scheitert. Abhilfe schafft eine etwas umständliche Apache-Konfiguration.
Ausgangspunkt
Ausgangspunkt ist also ein »gewöhnlicher« Apache-Webserver. Dieser soll nun zusätzlich eine REST-API ausliefern, die in einem Docker-Container läuft (localhost:8880). Die erste Konfiguration sah ziemlich simpel aus:
Das Problem besteht darin, dass acme.sh zwar diverse Domain-Verifizierungsverfahren kennt, aber keines so richtig zu meiner Konfiguration passt:
acme.sh ... --webroot scheitert, weil die API eine reine API ist und keine statischen Dateien ausliefert.
acme.sh ... --standalone scheitert, weil der bereits laufende Webserver Port 80 blockiert.
acme.sh ... --apache scheitert mit could not resolve api.example.com.well-known.
Die Lösung
Die Lösung besteht darin, die Apache-Proxy-Konfiguration dahingehend zu ändern, dass zusätzlich in einem Verzeichnis statische Dateien ausgeliefert werden dürfen. Dazu habe ich das neue Verzeichnis /var/www/acme-challenge eingerichtet:
Danach habe ich die Konfigurationsdatei für Apache umgebaut, so dass Anfragen an api.example.com/.well-known/acme-challenge mit statischen Dateien aus dem Verzeichnis /var/www/acme-challenge/.well-known/acme-challenge bedient werden:
# Apache-Konfiguration wie bisher
<VirtualHost *:443>
ServerName api.example.com
# SSL
SSLEngine on
SSLCertificateFile /etc/acme-letsencrypt/api.example.com.pem
SSLCertificateKeyFile /etc/acme-letsencrypt/api.example.com.key
# Proxy: localhost:8880 <-> api.example.com
ProxyPreserveHost On
ProxyPass / http://localhost:8880/
ProxyPassReverse / http://localhost:8880/
# Logging Konfiguration ...
</VirtualHost>
# geändert: HTTP auf HTTPS umleiten, aber nicht
# für well-known-Verzeichnis
<VirtualHost *:80>
ServerName api.example.com
# Handle ACME challenges locally
Alias /.well-known/acme-challenge /var/www/acme-challenge/.well-known/acme-challenge
<Directory /var/www/acme-challenge/.well-known/acme-challenge>
Require all granted
</Directory>
# Redirect everything EXCEPT ACME challenges to HTTPS
RewriteEngine On
RewriteCond %{REQUEST_URI} !^/.well-known/acme-challenge/
RewriteRule ^(.*)$ https://api.example.com$1 [R=301,L]
</VirtualHost>
Nach diesen Vorbereitungsarbeiten und mit systemctl reload apache2 gelingt nun endlich das Zertifikaterstellen und -erneuern mit dem --webroot-Verfahren. Dabei richtet acme.sh vorübergehend die Datei /var/www/acme-challenge/.well-known/acme-challenge/xxx ein und testet dann via HTTP (Port 80), ob die Datei gelesen werden kann.
Eine noch elegantere Lösung besteht darin, den Docker-Container mit Traefik zu kombinieren (siehe https://traefik.io/traefik/). Bei korrekter Konfiguration kümmert sich Traefik um alles, nicht nur um die Proxy-Funktionen sondern sogar um das Zertifikatsmanagment. Aber diese Lösung kommt nur in Frage, wenn auf dem Host nicht schon (wie in meinem Fall) ein Webserver läuft, der die Ports 80 und 443 blockiert.
Wir schreiben das Jahr 2025. Die Frage, ob man Linux-Server mit oder ohne Swap-Partition betreiben sollte, spaltet die Linux-Gemeinschaft in einer Weise, wie wir es seit dem Editor War nicht mehr gesehen haben…
So könnte ein spannender Film für Sysadmins anfangen, oder? Ich möchte aber keinen Streit vom Zaun brechen, sondern bin an euren Erfahrungen und Gedanken interessiert. Daher freue ich mich, wenn ihr euch die Zeit nehmt, folgende Fragen in den Kommentaren zu diesem Beitrag oder in einem eigenen Blogpost zu beantworten.
Stellt ihr Linux-Server mit Swap-Partition bereit und wie begründet ihr eure Entscheidung?
Hat euch die Swap-Partition bei sehr hoher Speicherlast schon mal die Haut bzw. Daten gerettet?
War der Server während des Swapping noch administrierbar? Falls ja, welche Hardware wurde für die Swap-Partition genutzt?
Eine kleine Mastodon-Umfrage lieferte bisher folgendes Bild:
Schaue ich mir meine eigenen Server an, so ergibt sich ein gemischtes Bild:
Debian mit LAMP-Stack und Containern: 16 GB RAM & kein Swap
RHEL-KVM-Hypervisor 1: 32 GB RAM & 4 GB Swap
RHEL-KVM-Hypervisor 2: 128 GB RAM & kein Swap
RHEL-Container-Host (VM): 4 GB RAM & 4 GB Swap
Bis auf den Container-Host handelt es sich um Bare-Metal-Server.
Ich kann mich nicht daran erinnern, dass jemals einem dieser Systeme der Hauptspeicher ausgegangen ist oder der Swapspeicher genutzt worden wäre. Ich erinnere mich, zweimal Swapping auf Kunden-Servern beobachtet zu haben. Die Auswirkungen waren wie folgt.
Im ersten Fall kamen noch SCSI-Festplatten im RAID zum Einsatz. Die Leistung des Gesamtsystems verschlechterte sich durch das Swapping so stark, dass bereitgestellten Dienste praktisch nicht mehr verfügbar waren. Nutzer erhielten Zeitüberschreitungen ihrer Anfragen, Sitzungen brachen ab und das System war nicht mehr administrierbar. Am Ende wurde der Reset-Schalter gedrückt. Das Problem wurde schlussendlich durch eine Vergrößerung des Hauptspeichers gelöst.
Im zweiten Fall, an den ich mich erinnere, führte ein für die Nacht geplanter Task zu einem erhöhten Speicherverbrauch. Hier hat Swapping zunächst geholfen. Tasks liefen zwar länger, wurden aber erfolgreich beendet und verwendeter Hauptspeicher wurde anschließend wieder freigegeben. Hier entstand erst ein Problem, als der Speicherbedarf größer wurde und die Swap-Partition zu klein war. So kam es zum Auftritt des Out-of-Memory-Killer, der mit einer faszinierenden Genauigkeit immer genau den Prozess abgeräumt hat, den man als Sysadmin gern behalten hätte. Auch hier wurde das Problem letztendlich durch eine Erweiterung des Hauptspeichers gelöst.
Ich erinnere mich auch noch an die ein oder andere Anwendung mit einem Speicherleck. Hier hat vorhandener Swap-Speicher das Leid jedoch lediglich kurz verzögert. Das Problem wurde entweder durch einen Bugfix oder den Wechsel der Anwendung behoben.
Nun bin ich auf eure Antworten und Erfahrungsberichte gespannt.
Anmelden
Am zehnten Juli endet planmäßig der Support für Ubuntu 24.10. Danach gibt es keine Sicherheitsupdates oder Fehlerbehebungen mehr. Wer das System weiter nutzt, bleibt ohne Schutz vor bekannten Schwachstellen. Canonical empfiehlt dringend ein Upgrade auf Ubuntu 25.04. Die neue Version trägt den Namen Plucky Puffin und wird noch bis Januar 2026 unterstützt. Danach folgt Ubuntu […]
