Unveränderliche Linux-Distributionen für Server erklärt

Was eine unveränderliche Linux-Distribution ist

Eine unveränderliche Linux-Distribution liefert das Betriebssystem als ein Image aus. Dadurch ersetzen Sie das System, statt es direkt zu aktualisieren. Es gibt kein apt upgrade, das Dateien unter /usr auf einem laufenden System neu schreibt. Sie erstellen ein neues Image oder laden eines herunter. Der Rechner legt es neben dem aktuell ausgeführten Image bereit. Beim nächsten Reboot wird festgelegt, welches Image aktiv ist. Das vorherige Image bleibt auf der Festplatte. Ein fehlerhaftes Update machen Sie daher durch einen Reboot rückgängig.

Der Begriff „unveränderlich“ ist übertrieben. Nichts hindert root physisch daran, auf die Festplatte zu schreiben. Diese Systeme binden die Systemverzeichnisse jedoch schreibgeschützt ein und ordnen sie dem Image zu. Persistente Daten liegen in /var. Maschinenspezifische Konfigurationen liegen in /etc. Alles unter /usr gehört zum Image. Deshalb enthalten zwei Server mit demselben Image-Tag identische Systemdateien.

Red Hat verwendet für die beiden Modelle die klarsten Bezeichnungen: Paketmodus und Imagemodus. Der Paketmodus besteht aus einem laufenden System und einem Paketmanager, der es verändert. Der Imagemodus besteht aus einem Build-Schritt an anderer Stelle, der ein Artefakt erzeugt, und einem Server, dessen einzige Aufgabe darin besteht, das von Ihnen angegebene Artefakt zu booten. Alles Folgende ergibt sich aus diesem einen Unterschied.

Warum ein schreibgeschütztes System auf einem Server wichtiger ist

Ein Server, der zwei Jahre lang betrieben wurde, hat eine nicht dokumentierte Historie. Ein make install aus einem hektischen Abend. Ein Drittanbieter-Repository, das für ein Paket hinzugefügt wurde. Eine Konfigurationsdatei, die während eines Ausfalls bearbeitet und nie wieder in das Configuration Management übernommen wurde. Dafür gibt es den Begriff Configuration Drift. Genau deshalb führt das Wiederaufbauen „desselben“ Servers anhand Ihrer Notizen so häufig zu einem System, das sich anders verhält. Die Notizen enthalten die Absicht. Die Festplatte enthält die tatsächliche Konfiguration.

Der Image-Modus beseitigt den Ort, an dem sich Drift ansammelt. /usr ist zur Laufzeit schreibgeschützt. Eine manuell durchgeführte Installation schlägt daher entweder unmittelbar fehl oder wird als Layer aufgezeichnet, den Sie mit einem Befehl auflisten können. Dadurch wird der Unterschied zwischen zwei Maschinen sichtbar, statt nur anhand historischer Spuren rekonstruiert werden zu müssen. Es handelt sich um dasselbe Problem, das eine reguläre Checkliste für die Linux-Serverwartung mit Disziplin angeht. Hier wird es stattdessen durch das Dateisystem gelöst.

Rollback bedeutet Neustart. Das ist die gesamte Grundlage.

Dieses Modell ist für genau den Fehler ausgelegt, den wir bereits dokumentieren: ein VPS, der nach einem Kernel-Update nicht bootet. Im Paketmodus führen Sie die Wiederherstellung über die Rescue-Konsole des Providers durch. Sie mounten den Datenträger, wechseln per chroot in das installierte System und entfernen ein Kernel-Paket manuell. Das funktioniert, weil der Bootloader ältere Kernel beibehält. Allerdings werden nur die Kernel auf diese Weise versioniert. Das glibc-Update und die systemd-Änderungen aus derselben Transaktion sind bereits angewendet. Kein einzelner Befehl setzt sie gemeinsam zurück.

Im Image-Modus ist die gesamte Einheit das System. Auf einem bootc-Host:

sudo bootc status
sudo bootc rollback
sudo systemctl reboot

bootc rollback stellt die Reihenfolge der Bootloader-Einträge auf den vorherigen Eintrag zurück. Dabei handelt es sich um das Image, das vor einer Stunde ausgeführt wurde, einschließlich Kernel und Userspace. Es wird nichts heruntergeladen und nichts neu erstellt, weil das alte Image weiterhin auf dem Datenträger vorhanden ist. Wenn Sie den weiter unten beschriebenen Timer für automatische Updates aktiviert haben, stoppen Sie ihn zuerst. Die bootc-Dokumentation warnt, dass ein Agent für automatisierte Upgrades den Rollback rückgängig machen kann.

Fedora CoreOS führt denselben Vorgang unter anderen Bezeichnungen aus:

sudo systemctl stop zincati.service
sudo rpm-ostree rollback -r

Stoppen Sie zuerst Zincati. Zincati ist der Agent, der einen Fedora-CoreOS-Rechner auf dem neuesten Release hält. Die gerade zurückgesetzte Deployment wird nicht erneut installiert. Zincati sucht jedoch weiterhin nach Updates und aktualisiert auf jedes neuere verfügbare Release. Führen Sie daher sudo systemctl disable --now zincati.service aus, wenn der Rechner bis zur Veröffentlichung einer Fehlerbehebung auf dem aktuellen Stand bleiben soll. -r führt einen Neustart durch, sobald der Rollback vorbereitet wurde. Damit eine vertrauenswürdige Deployment nicht durch die Garbage Collection entfernt wird:

sudo ostree admin pin 0
rpm-ostree status

rpm-ostree status listet die Deployments in der Reihenfolge auf, in der der Bootloader sie anbietet. Die laufende Deployment wird mit einem Punkt markiert. Auf der Deployment, die Sie festgehalten haben, wird Pinned: yes angezeigt.

Bei Talos genügt dafür ein API-Aufruf von Ihrer Workstation aus:

talosctl rollback --nodes 10.20.30.40

Flatcar verwaltet zwei /usr-Partitionen und wechselt zwischen ihnen. Jeder Slot enthält in der Partitionstabelle eine Priorität und einen Zähler für Bootversuche. Ein Slot, der nie erfolgreich bootet, verbraucht seine Versuche. Danach wählt der Bootloader den anderen Slot aus. Prüfen Sie, auf welchem Slot Sie sich befinden und ob er als fehlerfrei markiert wurde:

sudo cgpt show "$(rootdev -s /usr)" | grep successful=1

Ein fehlerfrei laufender Slot gibt eine Zeile aus, die tries=0 successful=1 enthält. Die Prioritätsnummer in derselben Zeile bestimmt nur die Rangfolge, nach der der Bootloader einen Slot bevorzugt. Daher kann dort auf einem vollständig fehlerfreien Rechner 1 oder 2 stehen. Wenn keine passende Zeile vorhanden ist, wurde der aktuelle Slot nie bestätigt. Das ist der Zustand zwischen einem Update und dem ersten erfolgreichen Boot.

Was ersetzt „ein Paket installieren“: bootc und eine Containerfile

bootc ist das Werkzeug, das dieses Muster verallgemeinert hat. Es beschreibt sich selbst als Werkzeug für transaktionale Betriebssystemaktualisierungen direkt im laufenden System unter Verwendung von OCI-Container-Images (Open Container Initiative) und ist ein CNCF-Sandbox-Projekt. Ihr Server wird zu einer Containerfile. Im August 2026 lautet das Fedora-Basis-Image quay.io/fedora/fedora-bootc:44 und die CentOS-Stream-Basis quay.io/centos-bootc/centos-bootc:stream10.

FROM quay.io/fedora/fedora-bootc:44
RUN dnf -y install nginx && dnf clean all
RUN systemctl enable nginx

Erstellen und pushen Sie sie wie jedes andere Image:

sudo podman build -t registry.example.com/edge/web:2026-08-19 .
sudo podman push registry.example.com/edge/web:2026-08-19

Anschließend auf dem Server:

sudo bootc upgrade --check
sudo bootc upgrade --apply

bootc upgrade fragt die Image-Quelle ab und stellt das neue Image für den nächsten Bootvorgang in die Warteschlange. --check meldet, ob ein Update verfügbar ist, und nimmt keine Änderungen vor. --apply startet das System mit diesem Image neu. bootc switch registry.example.com/edge/web:next weist den Rechner auf ein anderes Image und bewahrt dabei /etc und /var. So verschieben Sie einen Server zwischen Image-Streams, ohne ihn neu zu installieren.

Für unbeaufsichtigte Updates aktivieren Sie den Timer, den das Projekt ausliefert:

sudo systemctl enable --now bootc-fetch-apply-updates.timer

Das ist die Image-Mode-Entsprechung zu unbeaufsichtigten Upgrades unter Ubuntu und zu dnf-automatic unter Rocky und Alma. Der Unterschied liegt darin, was installiert wird. Ein Timer im Package Mode wendet die Versionen an, die das Repository in dieser Nacht bereitstellt. Die resultierende Zusammenstellung unterscheidet sich daher auf jedem Rechner geringfügig. Ein Timer im Image Mode wendet ein einzelnes Artefakt an, das Sie bereits an anderer Stelle gebootet haben.

Aus dieser Containerfile ergeben sich zwei Regeln für den Build. Schreibbare Daten gehören unter /var. Software, die unbedingt in ihr eigenes Installationsverzeichnis schreiben muss, benötigt daher entweder einen Symlink oder eine systemd-BindPaths=-Zeile, die beim Build hinzugefügt wird. Außerdem wird /etc beim Update als Drei-Wege-Merge zusammengeführt. Eine Datei, die Sie nie geändert haben, erhält dadurch die neue Version aus dem Image. Eine Datei, die Sie lokal bearbeitet haben, bleibt erhalten.

Wenn Sie ein Werkzeug für eine einzelne Debugging-Sitzung auf einem laufenden System benötigen:

sudo bootc usr-overlay
sudo dnf -y install strace

Dadurch wird unter /usr ein vorübergehendes, beschreibbares Overlay hinzugefügt. Beim nächsten Reboot wird es verworfen. Es dient zur Untersuchung eines Problems, nicht zu dessen Behebung. Auf diese Weise können Sie den Kernel nicht ändern. Alles, was Sie installieren, verschwindet beim Reboot absichtlich.

Fedora CoreOS: Einmal bereitgestellt, dauerhaft aktualisiert

Fedora CoreOS hat kein interaktives Installationsprogramm. Sie schreiben eine Butane-YAML-Datei, wandeln sie in Ignition-JSON um und übergeben sie der Maschine beim ersten Start:

podman run --interactive --rm quay.io/coreos/butane:release \
       --pretty --strict < your_config.bu > transpiled_config.ign

Ignition wird nur beim ersten Start in der Initramfs ausgeführt. Das ist der entscheidende Unterschied für alle, die von cloud-init kommen. Wenn die Konfiguration keinen SSH-Schlüssel enthält, startet die Maschine ohne Zugriffsmöglichkeit. Die einzige Lösung besteht dann darin, sie erneut von Grund auf bereitzustellen. Testen Sie die Konfiguration auf einer Wegwerfmaschine, bevor Sie sie auf einen wichtigen Server anwenden.

Installation auf einer Festplatte aus einer Live-Umgebung:

sudo coreos-installer install /dev/sda \
    --ignition-url https://example.com/example.ign

Updates werden standardmäßig automatisch installiert. Sie steuern den Zeitpunkt, nicht die grundsätzliche Ausführung. Legen Sie eine TOML-Datei unter /etc/zincati/config.d/55-updates-strategy.toml ab, die die periodische Strategie festlegt:

[updates]
strategy = "periodic"

Bei dieser Strategie fügen Sie pro Eintrag des Array of Tables ein Wartungsfenster hinzu. Jedes Fenster beginnt mit dem Namen updates.periodic.window als Kopfzeile in doppelten eckigen Klammern, gefolgt von drei Schlüsseln:

• days, eine Liste von Tagesnamen, beispielsweise "Sat" und "Sun".
• start_time, der Zeitpunkt, zu dem das Fenster beginnt, angegeben als "22:30".
• length_minutes, die Dauer des Fensters, beispielsweise 60.

Diese Zeitangaben sind UTC. Um Updates vollständig zu deaktivieren, führen Sie sudo systemctl disable --now zincati.service aus. Dann sind Sie selbst für den Patch-Zeitplan verantwortlich.

Package Layering ist als Ausweichlösung verfügbar:

sudo rpm-ostree install --allow-inactive vim
sudo systemctl reboot

Dadurch wird ein neues Deployment mit dem hinzugefügten Paket erstellt. Die Änderung wird erst nach dem Reboot wirksam. Die Folgen zeigen sich später. Ihr Layering wird auf jedes neue Basis-Image erneut angewendet. Wenn ein Paket am Tag eines Updates nicht mehr im Repository vorhanden ist, schlägt das Update fehl. Die Fedora-Dokumentation empfiehlt für umfangreichere Änderungen Container und für tatsächliche Änderungen am Betriebssystem ein bootc-Image.

Flatcar Container Linux: überhaupt kein Paketmanager

Flatcar ist die Fortsetzung von CoreOS Container Linux und die strengste der universell einsetzbaren Optionen. Es gibt keinen Paketmanager als Ausweichmöglichkeit. Alles, was Sie ausführen, ist ein Container. Für die Bereitstellung wird Ignition verwendet, wie bei Fedora CoreOS. Updates erfolgen über die beiden oben beschriebenen A/B-/usr-Partitionen. Gesteuert werden sie von update_engine. locksmithd legt fest, wann der Reboot erfolgt.

update_engine_client -status
update_engine_client -check_for_update

UPDATE_STATUS_UPDATED_NEED_REBOOT bedeutet, dass der passive Slot bereits das neue Image enthält und nur noch der Reboot aussteht. Die standardmäßige Reboot-Strategie ist reboot mit einer Verzögerung von fünf Minuten. Ein einzelner Produktions-VPS wird daher nach seinem eigenen Zeitplan neu gestartet, sofern Sie nichts anderes festlegen. Legen Sie ein Zeitfenster in /etc/flatcar/update.conf fest:

REBOOT_STRATEGY=reboot
LOCKSMITHD_REBOOT_WINDOW_START="Thu 04:00"
LOCKSMITHD_REBOOT_WINDOW_LENGTH=1h

REBOOT_STRATEGY=off überlässt den Reboot Ihnen. SERVER=disabled in derselben Datei beendet die Update-Prüfung vollständig. In einem Cluster begrenzt REBOOT_STRATEGY=etcd-lock zusammen mit locksmithctl set-max 4, wie viele Nodes gleichzeitig neu gestartet werden dürfen. Dadurch nimmt ein Update nie die gesamte Flotte gleichzeitig außer Betrieb.

Talos Linux: keine Shell, kein SSH, keine Konsole

Talos ist das spezialisierteste der vier Systeme und beschreibt seinen Zweck am klarsten. Es führt Kubernetes-Nodes aus. Es gibt keinen SSH-Daemon, keine Login-Shell und keinen Konsolen-Login. Die physische Konsole zeigt ein Dashboard zur Prüfung des Maschinenstatus, aber keine Login-Eingabeaufforderung. Jede Operation ist ein gRPC-API-Aufruf, den Sie mit talosctl von Ihrer Workstation aus gegen eine Maschinenkonfiguration ausführen, die Sie in git verwalten.

talosctl upgrade --nodes 10.20.30.40 \
  --image factory.talos.dev/metal-installer/376567988ad370138ad8b2698212367b8edcb69b5fd68c80be1f2ec7d603b4ba:v1.14.2

Seit Talos 1.14 wird das ghcr.io/siderolabs/installer-Image nicht mehr veröffentlicht. Installer-Images stammen stattdessen aus der Image Factory. Die lange ID in diesem Pfad ist das leere Schema für eine Maschine ohne Anpassungen. Verwenden Sie das Schema, mit dem Ihr Node installiert wurde, damit dessen Systemerweiterungen erhalten bleiben. Ersetzen Sie das Tag durch das Release, auf das Sie aktualisieren. Das Upgrade verwendet ein A-B-Schema, das den vorherigen Kernel und das vorherige OS-Image beibehält. Wenn das neue Image nicht bootet, führt Talos selbstständig ein Rollback durch. Dafür ist kein Eingriff erforderlich. Das Debugging funktioniert anders, weil es keine Login-Shell gibt: Auf dem System verwenden Sie talosctl logs und talosctl dmesg statt journalctl. Wenn Sie Tools auf dem Node benötigen, startet talosctl debug einen privilegierten Container aus einem von Ihnen angegebenen Image und öffnet darin dessen Shell. Beim Beenden wird der Container entfernt.

Wenn Ihre Workload nicht Kubernetes ist, ist Talos die falsche Lösung. Wenn sie Kubernetes ist, beseitigt Talos eine ganze Kategorie von Vorfällen, weil der Fall „Jemand hat sich auf einem Node angemeldet und etwas geändert“ nicht eintreten kann.

Was ein VPS-Mieter tatsächlich aufgibt

Ad-hoc-Installationen auf einem laufenden System. Das ist der wichtigste Punkt. sudo apt install htop um 2 Uhr während eines Vorfalls ist nicht verfügbar. Bei bootc erhalten Sie ein temporäres Overlay, das beim Reboot verschwindet. Bei Fedora CoreOS erhalten Sie ein geschichtetes Deployment, das einen Reboot erfordert. Bei Flatcar und Talos erhalten Sie nichts.

Eine Build-Pipeline, die zuvor nicht vorhanden war. Ein Paket hinzuzufügen bedeutet, ein Containerfile zu bearbeiten, das Image zu bauen, es in eine Registry zu pushen und die Server auszurollen. Wenn die Pipeline vorhanden ist, ist das kostengünstig. Wenn sie fehlt, ist ihr Aufbau echte Arbeit. Außerdem benötigen Sie eine Registry, die von den Servern aus erreichbar ist. Das ist entweder ein weiterer zu betreibender Dienst oder eine weitere Rechnung.

Kernel-Module. Der Kernel stammt aus dem Image. Daher bleibt ein gegen den laufenden Kernel kompiliertes Modul beim nächsten Update nicht erhalten. Out-of-Tree-Module und DKMS-Pakete (dynamic kernel module support) müssen gegen den Kernel dieses Images in das Image eingebaut werden. Alles, was ein Modul benötigt, das im Basis-Image nicht enthalten ist, wird dadurch zu einem Build-Problem statt zu einem Installationsproblem.

Agenten von Anbietern und Providern. Monitoring- und Backup-Agenten werden normalerweise als .deb oder .rpm mit einem Installationsskript bereitgestellt, das in /usr schreibt und eine Unit aktiviert. Auf einem schreibgeschützten System schlägt dieses Skript fehl. Einige Anbieter veröffentlichen einen Container oder dokumentieren eine Installation im Image-Modus. Viele tun dies nicht. Prüfen Sie das, bevor Sie sich festlegen. Eine Flotte, die Sie nicht überwachen können, ist schlechter als eine Flotte, deren Konfiguration abweicht.

Das Image selbst. Fast kein VPS-Control-Panel führt Fedora CoreOS, Flatcar oder Talos neben Ubuntu und Debian auf. Sie stellen den Datenträger selbst bereit. Das ist das Thema des nächsten Abschnitts.

Eine dieser Installationen auf einen gemieteten VPS bringen

Prüfen Sie zunächst zwei Punkte bei Ihrem Provider: Sie benötigen Out-of-Band-Konsolenzugriff, also VNC oder eine serielle Konsole, und Sie müssen ein Rettungssystem booten können. Ohne Konsole wird ein nicht wiederkehrender Server zu einem Support-Ticket statt zu einer Reparatur in fünf Minuten.

Wenn der Provider benutzerdefinierte Images akzeptiert, laden Sie das Raw- oder qcow2-Image des Anbieters hoch. Der Upload allein stellt jedoch noch keine Maschine bereit, bei der Sie sich anmelden können. Der core-Benutzer von Fedora CoreOS hat weder ein Standardpasswort noch einen SSH-Schlüssel. Sie müssen daher weiterhin eine Ignition-Konfiguration mit Ihrem Schlüssel bereitstellen oder auf einer Cloud-Plattform, die Afterburn unterstützt, einen Schlüssel über die eigene SSH-Key-Funktion des Providers hinterlegen. Andernfalls schreiben Sie das Laufwerk selbst aus dem Rettungssystem. Flatcar stellt dafür ein eigenständiges Script bereit, das unter jedem Linux-System ausgeführt werden kann:

curl -fsSLO https://raw.githubusercontent.com/flatcar/init/flatcar-master/bin/flatcar-install
chmod +x flatcar-install
sudo ./flatcar-install -d /dev/sda -i ignition.json

Führen Sie dieses Script aus dem Rettungssystem aus, niemals auf dem Server, den Sie ersetzen. Das Script partitioniert während der Ausführung das Zielgerät neu. Auf dem Gerät müssen mindestens 8 GB nutzbarer Speicherplatz vorhanden sein. Außerdem muss die Rettungsumgebung bash, bzip2 oder lbzip2, lsblk, wget, udevadm, gpg und gawk bereitstellen. Ihr ignition.json muss einen SSH-Schlüssel enthalten. Andernfalls können Sie sich beim installierten System nicht anmelden.

Fedora CoreOS funktioniert nach demselben Prinzip. Das Installationsprogramm wird als Container ausgeführt:

sudo podman run --pull=always --privileged --rm \
    -v /dev:/dev -v /run/udev:/run/udev -v .:/data -w /data \
    quay.io/coreos/coreos-installer:release \
    install /dev/vdb -i config.ign

Prüfen Sie den Gerätenamen mit lsblk, bevor Sie den Befehl ausführen. Wenn Sie auf das falsche Gerät schreiben, werden die darauf vorhandenen Daten zerstört. Es gibt keine Bestätigungsabfrage.

bootc bietet die einzige Möglichkeit, den Rettungsmodus zu überspringen, da es ein laufendes Linux-System direkt vor Ort konvertiert:

sudo podman run --rm --privileged -v /dev:/dev -v /var/lib/containers:/var/lib/containers -v /:/target \
             --pid=host --security-opt label=type:unconfined_t \
             quay.io/fedora/fedora-bootc:44 \
             bootc install to-existing-root

Lesen Sie vor der Ausführung die Dokumentation zum verwendeten Basis-Image. Testen Sie den Vorgang außerdem auf einem Server, den Sie problemlos verwerfen können. Nach dem Reboot läuft auf der Maschine das Image. Der zuvor installierte Paketsatz ist nicht mehr vorhanden.

Wer sollte einen unveränderlichen Server betreiben, und wer nicht

Das ist sinnvoll, wenn Ihre Server wie austauschbare Instanzen behandelt werden. Viele Maschinen werden aus einer Vorlage erstellt. Dazu gehören CI-Runner (Continuous Integration), die nur eine Stunde laufen, sowie k3s- oder Kubernetes-Nodes, die ersetzt statt repariert werden. Das gilt für alle Systeme, bei denen die Antwort auf einen defekten Server bereits lautet: „Löschen und einen neuen erstellen.“ Dieser Ansatz lohnt sich auch, wenn Sie einem Auditor nachweisen müssen, welche Software auf einer Maschine läuft. Die Antwort ist dann ein Image-Digest statt eine Paketliste.

Das ist nicht sinnvoll, wenn Sie einen manuell gepflegten VPS mit drei Diensten haben, Software bei Bedarf installieren und keine Build-Pipeline besitzen. Der Image-Modus beseitigt den Aufwand nicht. Er verlagert ihn vom Server in den Build und verursacht für diese Verlagerung zusätzlichen Aufwand durch eine Registry und eine Pipeline. Wenn Sie diesen Aufwand abbilden können, erhalten Sie identische Server, und ein Rollback besteht aus einem Reboot. Wenn nicht, fügen Sie einem bisher funktionierenden System zusätzliche Komponenten hinzu und erschweren die Arbeit um 2am.

Der unspektakuläre Mittelweg funktioniert weiterhin: eine normale Distribution mit automatischen Security-Updates sowie ein tatsächlich geübter Wiederaufbau. Die Auswahl dieser Basis ist eine eigene Entscheidung. Sie wird unter Auswahl des Betriebssystems für Ihren VPS behandelt. Der Image-Modus ist nur die jüngste Runde eines sehr alten Streits darüber, wie Software auf eine Maschine gelangen sollte. Die Geschichte der Linux-Distributionen besteht zu großen Teilen aus der Wiederholung dieses Streits.

FAQ

Ist eine unveränderliche Linux-Distribution wirklich unveränderlich?

Nein, und der Name sorgt für Verwirrung. root kann weiterhin auf die Festplatte schreiben. Tatsächlich wird /usr zur Laufzeit schreibgeschützt eingehängt und beim nächsten Image vollständig ersetzt, während /etc und /var schreibbar bleiben und Updates überstehen. Änderungen unter /usr werden entweder sofort abgewiesen oder beim nächsten Update verworfen. Praktisch bedeutet das, dass sich Systemverzeichnisse nur ändern, wenn sich das Image ändert.

Kann ich Fedora CoreOS oder Flatcar auf einem VPS ausführen, der diese Distributionen nicht anbietet?

In der Regel ja, wenn der Anbieter ein Rescue-System und Konsolenzugriff bereitstellt. Sie starten das Rescue-System, schreiben das Disk-Image der Distribution auf das Blockgerät und starten anschließend neu. Das flatcar-install-Skript von Flatcar erledigt dies aus jedem Linux-System heraus. Fedora CoreOS stellt dafür coreos-installer als Container bereit, den Sie auf dieselbe Weise ausführen können. Beide benötigen eine Ignition-Datei mit Ihrem SSH-Schlüssel, da es keine Passwortabfrage beim ersten Boot gibt, auf die Sie zurückgreifen könnten. Ohne Konsolenzugriff sollten Sie dies nicht versuchen: Wenn die Maschine nicht wieder startet, haben Sie keine Möglichkeit, den Fehler zu untersuchen.

Wie installiere ich ein Paket auf einem unveränderlichen Server?

Sie fügen es dem Image hinzu und führen ein erneutes Deployment durch. Bei bootc ist das eine RUN dnf -y install ...-Zeile im Containerfile, gefolgt von einem Rebuild, einem Push und anschließend sudo bootc upgrade --apply auf der Maschine. Unter Fedora CoreOS können Sie das Paket mit sudo rpm-ostree install als Layer hinzufügen und neu starten. Dafür wird das Paket bei jedem künftigen Update erneut angewendet. Unter Flatcar und Talos gibt es keinen Paketmanager. Die Antwort ist daher ein Container. Für ein einmaliges Debugging-Tool auf einem bootc-Host stellt sudo bootc usr-overlay ein schreibbares /usr bereit, das beim nächsten Reboot verschwindet.

Behebt der Image-Modus einen VPS, der nach einem Kernel-Update nicht mehr bootet?

Die Wiederherstellung wird dadurch von einer Aufgabe für die Rescue-Konsole zu einem Reboot. Das vorherige Image einschließlich Kernel und Userspace befindet sich weiterhin auf der Festplatte. Mit sudo bootc rollback oder sudo rpm-ostree rollback -r wechseln Sie darauf zurück. Talos und Flatcar führen außerdem automatisch ein Rollback durch, wenn der neue Slot nicht bootet. Ein Boot-Eintrag wird erst nach einem erfolgreichen Boot zum Standard. Nichts davon verhindert ein fehlerhaftes Update. Das Zurücksetzen wird dadurch jedoch einfach.

Welche unveränderliche Distribution sollte ich für einen Server auswählen?

Wählen Sie bootc, wenn Sie einen universell einsetzbaren Linux-Server möchten, den Sie wie ein Container-Image erstellen und auf einer bereits vorhandenen Maschine installieren können. Wählen Sie Fedora CoreOS, wenn Sie dieses Modell mit automatischer Erstellung und standardmäßig aktivierten automatischen Updates verwenden möchten. Wählen Sie Flatcar, wenn Sie einen minimalistischen Container-Host mit einem A/B-Updateverfahren und ohne Paketmanager möchten. Wählen Sie Talos nur, wenn die Maschine ein Kubernetes-Knoten ist, da Talos keine Login-Shell besitzt und nichts anderes ausführt.