Zuletzt aktualisiert: 17.09.2026 · Lesezeit: 11-13 Minuten
Ein In-Place-Upgrade mit Leapp hebt ein RHEL-System auf die nächste Hauptversion, ohne es neu aufzusetzen. Was auf einem einzelnen Server ein Nachmittag ist, wird bei fünfzig Hosts schnell zum Projekt, wenn man es nicht automatisiert. Dieser Artikel zeigt, wie weit Leapp auf RHEL-Derivaten wie AlmaLinux und Rocky heute wirklich ist, was mit Software aus Fremd-Repositories passiert und was die Foreman-Integration foreman_leapp einer ganzen Flotte abnimmt.
Das Wichtigste in 30 Sekunden
- Ein In-Place-Upgrade mit Leapp erspart die Neuinstallation. Das funktioniert nativ oder über das Projekt ELevate, je nach Distribution und Upgrade-Pfad unterschiedlich weit.
- Rocky Linux ist dafür das Beispiel: 8 → 9 vollständig unterstützt, 9 → 10 mangels Migrationsdaten aktuell nicht möglich.
- Ein Rollback gibt es nicht – Snapshot oder Backup vor dem Upgrade sind Pflicht, nicht optional.
- Ob Fremdsoftware das Upgrade mitmacht, hängt vom Hersteller-Repository ab, nicht von Leapp selbst.
- foreman_leapp macht aus dem Preupgrade eine Flottenabfrage über eine Host-Collection, statt SSH auf jeden Host einzeln.
- Beim Install-Schritt blockiert das mitgelieferte Foreman-Template aktuell noch alle Nicht-RHEL-Derivate, der Rest der Integration funktioniert bereits.
Die Uhr läuft: EOL-Termine im EL-Umfeld
Irgendwann trifft es jede Flotte: Das Betriebssystem fällt aus dem Support. Die naheliegende Antwort ist eine Neuinstallation. Bei einem Server ist das ein Nachmittag. Bei fünfzig Servern mit gewachsenen Konfigurationen, Anwendungsverantwortlichen und Wartungsfenstern wird daraus ein Projekt, das ein halbes Jahr bindet.
Die Alternative ist das In-Place-Upgrade: das laufende System auf die nächste Hauptversion heben, ohne es neu aufzusetzen. Das Werkzeug dafür heißt Leapp und für Foreman gibt es das Plugin foreman_leapp, das die Läufe als Remote-Execution-Jobs ausführt. Mein Kollege Dirk hat Leapp hier im Blog 2022 schon einmal vorgestellt, damals für den Weg RHEL 8 → 9. Seitdem hat sich einiges getan, vor allem außerhalb von RHEL.
In meinem Projekt habe ich mir beides angesehen, erst Leapp von Hand, dann die Foreman-Integration. In diesem Artikel geht es um die Dinge, die so nicht in der Doku stehen: wann Leapp nativ läuft und wann man ELevate braucht, was mit Software aus Fremd-Repositories passiert, was Foreman einem abnimmt und wo die Integration bei gemischten Flotten heute noch hakt.
Zuerst der Blick auf den Kalender, denn der entscheidet über die Dringlichkeit. Stand September 2026:
| Version | Support-Ende | Verbleibende Zeit | Handlungsbedarf |
|---|---|---|---|
| CentOS Stream 8 | 31.05.2024 | abgelaufen | Upgrade überfällig, es kommen keine Updates mehr |
| RHEL 7 | 30.06.2024 | abgelaufen | Upgrade überfällig, Updates nur noch über kostenpflichtiges ELS |
| CentOS Stream 9 | 31.05.2027 | unter neun Monate | Upgrade jetzt planen |
| RHEL 9: Ende Full Support | 31.05.2027 | unter neun Monate | kein Upgrade nötig, danach Maintenance Support bis 2032 |
| RHEL 8 / AlmaLinux 8 / Rocky 8 | 31.05.2029 | knapp drei Jahre | Upgrade in diesem Zeitraum einplanen |
| RHEL 9 / AlmaLinux 9 / Rocky 9 | 31.05.2032 | knapp sechs Jahre | kein akuter Handlungsbedarf |
Zwei Zeilen verdienen besondere Aufmerksamkeit. Am engsten wird es bei CentOS Stream 9. Stream kennt keine Maintenance-Phase mit verlängerten Sicherheitsupdates, nach dem 31.05.2027 kommt schlicht nichts mehr. Wer heute Stream 9 betreibt, hat also keine neun Monate mehr und der Weg führt von 9 nach 10, nicht von 8 nach 9.
Bei EL 8 klingt 2029 dagegen nach viel Zeit. Das täuscht, sobald jedes einzelne Upgrade ein Wartungsfenster, eine Abstimmung und einen Rückfallplan braucht. Wer 200 Hosts in Zehnergruppen durch den Change-Prozess schiebt, rechnet nicht in Wochen.
Was Leapp macht
Ein Leapp-Lauf besteht aus drei Schritten:
Der letzte Schritt ist mehr als ein Reboot. Das System startet in ein vorbereitetes initramfs, führt dort die Transaktion durch, für die es nicht laufen darf, und bootet danach selbstständig ein zweites Mal in die neue Hauptversion. Dazwischen ist die Maschine eine ganze Weile nicht erreichbar, was bei der Automatisierung gleich noch eine Rolle spielt. Und bevor der erste Befehl fällt, sollte klar sein: Ein Rollback gibt es nicht. Snapshot oder Backup sind hier nicht die Vorsichtsmaßnahme, sondern die einzige Ausstiegsoption.
Der eigentliche Grund, warum Leapp in der Praxis funktioniert, ist preupgrade. Der Schritt prüft Hardware, Pakete, Konfiguration und Plattenplatz und schreibt einen Report nach /var/log/leapp/. Findet er etwas, das das Upgrade zerlegen würde, setzt er einen Inhibitor und bricht ab, bevor irgendetwas verändert wurde.
Bei meinem ersten Lauf, AlmaLinux 8.10 mit minimaler Installation und nichts Exotischem darauf, kamen gleich vier Inhibitoren zusammen:
AllowZoneDrifting in der Firewalld-Konfiguration, das es in EL9 nicht mehr gibt; ein fehlendes Prüfwerkzeug für VDO-Volumes; ein Kernel, der zwar installiert, aber noch nicht gebootet war; und der per Passwort erlaubte Root-Login.
Der Report liefert zu jedem Finding die passende Remediation gleich mit, alle vier waren in Minuten erledigt. Wissen will man sie trotzdem vor dem Reboot.
Genau das ist der Unterschied zum Upgrade „über den Paketmanager“, wie man es früher versucht hat: Die Probleme liegen vorher auf dem Tisch, und zwar aus einem Lauf, der nichts verändert. Deshalb kann man ihn beliebig oft wiederholen, auch über die ganze Flotte hinweg.
Nativ oder über ELevate?
Lange lief Leapp nur auf RHEL. Für die Derivate ist ELevate eingesprungen, ein Projekt von AlmaLinux, das Leapp und die Migrationsdaten für die Klone bereitstellt. Inzwischen sind die Patches upstream angekommen. Wie viel davon in den nativen Repositories einer Distribution landet, unterscheidet sich aber von Distribution zu Distribution und sogar von Upgrade-Pfad zu Upgrade-Pfad. Für den Weg 9 → 10 sah es bei mir so aus:
| Distribution | Actors (leapp-upgrade) | Migrationsdaten (leapp-data-*) |
|---|---|---|
| RHEL | nativ (subscription-manager) | im Paket enthalten |
| CentOS Stream | nativ (AppStream) | im Paket enthalten |
| AlmaLinux | über ELevate | über ELevate |
| Rocky | über ELevate | für 9 → 10 nicht verfügbar |
Auf CentOS Stream 9 bekomme ich mit einem schlichten dnf install leapp-upgrade das Paket leapp-upgrade-el9toel10-0.24.0-3.el9 aus dem AppStream, ohne dass jemals ein elevate-release das System anfasst. Auf AlmaLinux schlägt derselbe Befehl fehl, dort übernimmt ELevate.
Bei Rocky ist auf diesem Pfad vorerst Schluss. ELevate liefert leapp-data-rocky für el7 und el8 aus, für el9 nicht, weder im stabilen Repository noch im testing-Zweig. Die Actors für 9 → 10 sind vorhanden, die Migrationsdaten für ein Ziel Rocky 10 nicht, und Leapp bricht mit „Could not determine the target version for the in-place upgrade“ ab. Von einem Rocky 9 aus führen die ELevate-Pfade derzeit nur nach AlmaLinux 10, AlmaLinux Kitten 10 oder CentOS Stream 10. Für 8 → 9 dagegen ist Rocky vollständig versorgt.
Für jede Form von Automatisierung ist das der wichtigste Punkt: Man sollte sich weder auf einen Weg festlegen noch fest verdrahten, welche Distribution welchen Weg nimmt. Sobald AlmaLinux die Pakete nativ ausliefert, wäre diese Verdrahtung falsch, und dasselbe gilt, sobald ELevate die Rocky-Daten für el9 nachliefert. Dabei geht es nicht nur um das Wie, sondern auch um das Ob, denn dieselbe Distribution kann auf einem Pfad vollständig unterstützt sein und auf dem nächsten überhaupt nicht.
Software aus Fremd-Repositories
Ein sauberes System zu upgraden ist die einfache Übung. Interessant wird es mit Software, die nicht aus den Distributions-Repositories kommt. Ich habe mir dafür drei Kandidaten auf ein AlmaLinux 9 gelegt und jeden davon aus demselben Snapshot heraus auf 10 gehoben. Herausgekommen sind drei verschiedene Ergebnisse.
Docker CE lief einfach durch. Leapp erwähnte es im Report mit keinem Wort, nach dem Reboot lief Docker als el10-Paket weiter. Verantwortlich dafür ist der vendors.d-Mechanismus: ELevate bringt für Docker eine fertige Migrationskarte mit (/etc/leapp/files/vendors.d/docker-ce_map.json). Wo es eine solche Karte gibt, muss man selbst nichts tun.
Der Zabbix Agent blieb auf el9 stehen. Leapp markierte die Pakete als „not signed by distribution vendor“ mit Risk Factor HIGH, setzte aber keinen Inhibitor. Das Upgrade lief durch und Zabbix danach auch, eben nur weiterhin in der el9-Version. Die Ursache lag nicht bei Leapp: Zabbix hatte zum Testzeitpunkt keinen Paket-Zweig für die Zielversion, und ohne Repository beim Hersteller gibt es nichts zu migrieren.
Dieses Beispiel hat sich zwischen Test und Veröffentlichung selbst überholt, repo.zabbix.com/zabbix/7.0/alma/10/ existiert inzwischen. Für die Praxis macht das den Fall eher interessanter: Ob eine Fremdkomponente ein Upgrade mitmacht, ist keine Eigenschaft des Werkzeugs, sondern ein Zeitpunkt im Release-Kalender eines Dritten.
Grafana lag dazwischen, ohne vendors.d-Karte, aber mit einem Repository, das el10 längst bedient. Hier muss man selbst eingreifen, und hier steckt auch die Falle: --enablerepo grafana allein reicht nicht. Leapp arbeitet im Target Userspace mit einer eigenen Repository-Konfiguration, und was in /etc/yum.repos.d/ steht, wird dorthin nicht übernommen. Das Repository muss Leapp separat bekannt gemacht werden:
Danach läuft leapp preupgrade --enablerepo grafana-leapp sauber durch, und Grafana kommt als el10-Paket auf der anderen Seite an. Zwei Details dazu, die mich Zeit gekostet haben:
Diese Datei nur ergänzen, niemals überschreiben. Auf AlmaLinux gehört
leapp_upgrade_repositories.repozum Paketleapp-data-almalinuxund enthält die Basis-Repositories des Zielsystems. Ein>statt>>nimmt dem Upgrade die Grundlage.
Eine eigene Repo-ID vergeben (ich hänge
-leappan) und einebaseurlverwenden, die nicht von$releaseverabhängt. Bei gleicher ID wie das System-Repo quittiert Leapp das mit dem Inhibitor „a YUM/DNF repository defined multiple times“.
Für die Planung heißt das: Für jede Fremdsoftware ist genau eine Frage zu klären, nämlich ob es beim Hersteller einen Zweig für die Zielversion gibt. Wenn ja, ist der Rest Konfiguration. Wenn nein, ist es kein Leapp-Thema mehr, sondern eines für die Planung. Diese Recherche macht man einmal für die Flotte und nicht einmal pro Host.
Upgrade-Pfad für deine Flotte klären?
Wir prüfen, welche Systeme sauber durchlaufen, wo Fremdsoftware im Weg steht und wie sich das Upgrade über Foreman automatisieren lässt.
Consulting kostenlos anfragen →
Was die Foreman-Integration abnimmt
So weit die Kommandozeile. Für eine Flotte will man das nicht dreißig Mal per SSH machen, und genau hier setzt foreman_leapp an. Installiert wird es mit foreman-installer --enable-foreman-plugin-leapp, danach ändert sich vor allem die Arbeitsweise.
Aus dem Preupgrade wird eine Flottenabfrage: ein Job über eine Host-Collection oder eine Suchabfrage, dreißig Reports. Weil leapp preupgrade nichts verändert, kann man ihn auch ein Jahr vor dem geplanten Upgrade laufen lassen, als Bestandsaufnahme, bevor überhaupt ein Wartungsfenster verhandelt ist.
Die Reports werden dabei deutlich lesbarer. Das Plugin fängt die JSON-Ausgabe ab und rendert sie als Tabelle in einem eigenen Tab der Job-Invocation, mit Findings, Severity und Remediation pro Host. Die Remediations lassen sich direkt aus dem Report heraus auswählen und als eigener Job ausführen, auf Wunsch mit angehängtem neuem Preupgrade-Lauf. Die Schleife aus Prüfen, Beheben und Nachprüfen läuft damit komplett in der Oberfläche.
Auch die Inventarisierung bleibt ehrlich: Nach dem Reboot meldet der Host neue Facts, und Foreman zeigt ihn ohne weiteres Zutun als EL 10. Dazu kommt die Nachvollziehbarkeit. Jede Job-Invocation ist protokolliert, und bei einem Vorgang ohne Rollback ist das kein Overhead, sondern der Unterschied zwischen „das System ist seit gestern anders“ und einer nachlesbaren Historie. Praktisch ist außerdem die Rollentrennung: Den harmlosen Preupgrade kann man deutlich breiter delegieren als das Upgrade selbst.
Ein Detail aus dem Testlauf, das man kennen sollte: Der Upgrade-Job ist ein Ansible-Playbook, und dessen command-Modul bricht den Play bei einem Fehler von selbst ab. Auf einem AlmaLinux mit vier offenen Inhibitoren beendete sich leapp upgrade mit Exit-Code 1, der nachfolgende Reboot-Task lief daraufhin gar nicht mehr, und die Maschine blieb unberührt. Ein Upgrade, das Leapp verweigert, hinterlässt also kein halb angefasstes System.
Leapp löst damit das Upgrade eines einzelnen Systems, Foreman das einer ganzen Flotte.
Wo die Integration an ihre Grenze stößt
Das gilt mit einer Einschränkung, und die trifft ausgerechnet die Systeme, die laut Kalender oben am dringendsten dran sind. Mein erster Versuch mit dem mitgelieferten Template „Install Leapp“ scheiterte an zwei Zeilen:
In Foreman haben alle EL-Derivate dieselbe family = Redhat, aber einen anderen name. Die erste Zeile lässt damit ausschließlich echtes RHEL durch und blockiert AlmaLinux, Rocky und CentOS Stream, obwohl Leapp dort längst funktioniert. Die zweite Zeile kannte die 9 nicht.
Die zweite Hälfte hat sich während meines Projekts erledigt. Mit dem Foreman-Issue #39587 ist supported_versions = [7, 8, 9] upstream gelandet und seit foreman_leapp 4.1.2 draußen. Die erste Hälfte steht unverändert, jedes Derivat läuft weiterhin in den fail-Task.
Wichtig ist dabei: Betroffen ist nur der Install-Schritt. Preupgrade, Report-Auswertung, Remediation-Schleife und Upgrade funktionieren auf einem AlmaLinux genauso wie auf einem RHEL, sobald Leapp erst einmal installiert ist. Es fehlt also kein Feature, sondern eine Fallunterscheidung. Bis upstream nachzieht, bleibt auf Derivaten genau ein Schritt Handarbeit, der Rest der Integration steht bereit.
Fazit: Der Weg hängt vom Zielsystem ab
Leapp ist deutlich weiter, als sein Ruf in der Derivate-Welt vermuten lässt. Wie weit genau, hängt an der Distribution und am Upgrade-Pfad, und es ändert sich laufend. Rocky ist dafür das beste Beispiel: auf 8 → 9 vollständig unterstützt, auf 9 → 10 mangels Migrationsdaten überhaupt nicht. Wer das automatisiert, sollte die Frage deshalb dem Zielsystem stellen, statt sie fest zu verdrahten. Das gilt übrigens auch für die Bewertung des Werkzeugs selbst, denn die Hälfte meiner Kritik am Install-Template war einen Monat später schon behoben.
Der kritische Pfad liegt meist nicht beim Betriebssystem, sondern bei der Fremdsoftware und der Frage, ob sie für die Zielversion überhaupt schon ausgeliefert wird. Das ist eine Recherche von zehn Minuten pro Paket, und sie gehört an den Anfang der Planung.
Vor allem aber kostet die Vorbereitung nichts. leapp preupgrade verändert nichts und lässt sich über Foreman wie eine beliebige Abfrage über die ganze Flotte ausrollen. Wer heute einmal durchläuft, weiß in ein bis zwei Stunden, welche Systeme sauber durchgehen, welche Inhibitoren immer wieder auftauchen und wo Fremdsoftware im Weg steht. Diese Liste wird nicht besser, wenn man sie erst im Frühjahr 2027 erstellt. CentOS Stream 9 läuft am 31.05.2027 aus, EL 8 zwei Jahre später, und bis dahin will jedes Wartungsfenster einzeln verhandelt sein.
Wer tiefer einsteigen will: der ELevate-Quickstart-Guide im AlmaLinux-Wiki und, für den RHEL-Weg, Upgrading from RHEL 9 to RHEL 10.
Und wer den Sprung nicht selbst planen möchte: Wir unterstützen dich beratend und im Betrieb, von der Bestandsaufnahme über die Upgrade-Planung bis zum Aufbau der passenden Foreman-Infrastruktur.
