Wenn die Konfigurationsdatei einer Maschine kaputtgeht: wo die alte Fassung liegt

Jede virtuelle Maschine und jeder Container hat eine kleine Textdatei. Wie viele Kerne, wie viel Speicher, welche Platte, welches Netz: alles steht dort, in einer für Menschen lesbaren Form.

Was passiert, wenn diese Datei kaputtgeht, wo liegt die alte Fassung, und worauf müssen Sie achten, wenn Sie von Hand bearbeiten?

Zuerst die gute Nachricht: eine kaputte Datei betrifft nur ihre eigene Maschine

Jede Maschine hat ihre eigene Datei. Ein Tippfehler in einer bringt nicht das Panel zu Fall, stoppt nicht die anderen Maschinen, betrifft nicht den Server.

Das Symptom ist meist dies: diese Maschine erscheint nicht mehr in der Liste oder lässt sich nicht starten. Alles andere läuft normal weiter. Wissen Sie das, bevor Sie in Panik geraten, denn der erste Eindruck ist meist "das System ist kaputt", und das stimmt nicht.

Wie sie kaputtgeht

Bearbeiten von Hand. Das ist die häufigste Ursache. Ein Komma, ein Anführungszeichen, ein falsch geschriebener Schlüsselname.

Bearbeiten, während die Maschine läuft. Selbst wenn die Datei nicht kaputtgeht, passiert etwas Unerwartetes: Ihre Änderung greift beim nächsten Start, während Sie annehmen, sie sei sofort wirksam. Oder das System aktualisiert die Datei selbst und überschreibt, was Sie geschrieben haben.

Ein mittendrin abgebrochener Schreibvorgang. Der Strom fällt aus, die Platte läuft voll, der Prozess wird abgeschossen. Die Datei bleibt halbfertig.

Das dritte ist das hinterhältigste und verdient eine eigene Überschrift.

Eine halb geschriebene Datei ist schlimmer als gar keine

Fehlt eine Datei, ist das ein offensichtlicher Zustand. Ein Programm schaut nach, findet sie nicht, sagt "nicht da" und macht mit Standardwerten weiter. Dieser Zustand lässt sich leicht behandeln.

Eine halb geschriebene Datei ist anders. Sie sieht aus wie eine Datei. Das Programm prüft die Existenz, findet sie, vertraut ihr und versucht mit den unvollständigen Daten darin zu arbeiten. Der Ärger zeigt sich nicht beim Lesen, sondern danach.

Die Lösung ist einfach und gilt für jeden Schreibvorgang: überschreiben Sie die Datei nicht direkt. Schreiben Sie zuerst unter einen vorläufigen Namen, dann verschieben Sie an den Zielort. Ein Verschieben geschieht entweder vollständig oder gar nicht; ein Dazwischen gibt es nicht. So ist der Inhalt der Datei entweder der alte oder der neue, niemals die Hälfte.

Wenn Sie ein Skript schreiben, das Proxmox-Konfiguration anfasst, ist diese eine Gewohnheit mehr wert als der ganze übrige Code.

Die alte Fassung liegt an zwei Stellen

In der Sicherung. Die Sicherung einer Maschine trägt nicht nur die Platte, sondern auch die Konfigurationsdatei, wie sie in diesem Moment war. Stellen Sie die Sicherung wieder her, kommt auch die Konfiguration zurück. Die meisten denken bei einer Sicherung nur an Daten und merken nie, dass sie einen Rettungsweg in der Hand halten.

In der Momentaufnahme. Machen Sie eine Momentaufnahme, wird die Konfiguration dieses Augenblicks in einen benannten Abschnitt derselben Datei geschrieben. Die Datei trägt also einen Teil ihrer eigenen Geschichte in sich.

Aber diese beiden ersetzen einander nicht, und der Unterschied zählt: der Eintrag der Momentaufnahme liegt innerhalb derselben Datei. Wird die Datei selbst vernichtet, geht dieser Eintrag mit. Eine Sicherung liegt woanders. Der echte Rettungsweg ist die Sicherung; eine Momentaufnahme ist nur ein Punkt, zu dem Sie zurückkehren möchten.

Wenn Sie von Hand bearbeiten

Halten Sie die Maschine zuerst an.

Machen Sie vor dem Bearbeiten eine Kopie und legen Sie diese Kopie woandershin. Der Ort, an dem die Konfiguration liegt, wurde für Konfiguration entworfen; legen Sie dort keine Sicherungen ab.

Starten Sie die Maschine nach der Änderung und sehen Sie, dass sie wirklich funktioniert. Warten Sie nicht bis zum nächsten Neustart und vergessen Sie es nicht; eine vergessene halbfertige Bearbeitung kommt Monate später als Störung zurück, die niemand mit irgendetwas verbindet.

Die allgemeine Regel: "Datei fehlt" und "Datei kaputt" sind getrennte Zustände

Der Rettungsweg eines Programms wird meist mit dem Zustand "Datei fehlt" im Kopf geschrieben, weil einem der zuerst einfällt. Der Zustand "Datei ist da, aber ihr Inhalt ist kaputt" fällt einem nicht ein.

Dabei ist der zweite der wirklich gefährliche, genau weil er nicht bedacht wurde. Und die beiden sehen unterschiedlich aus: eine fehlende Datei trägt ein Kennzeichen, kaputter Inhalt nicht.

Was Atlas macht

Atlas führt ein paar eigene kleine Einstellungsdateien, und hier gibt es einiges ehrlich zu erzählen, denn alles davon wurde durch Messen gefunden.

Zwei Geschwisterdateien verhielten sich unterschiedlich. Die eine reparierte sich selbst, wenn ihre Datei beschädigt war: sie legte die kaputte beiseite und begann sauber. Die andere nicht: sie warf einen Fehler und blieb dabei, das heißt jene Funktion wurde dauerhaft unbrauchbar, ohne dass der Benutzer sie über das Produkt hätte richten können.

Die Ursache war genau die obige Regel: der Rettungszweig war für den Zustand "Datei fehlt" geschrieben. Ein Fehler wegen kaputten Inhalts trägt dieses Kennzeichen nicht, also griff der Zweig nicht und der Fehler entkam nach oben.

Die beiseitegelegten Kopien wurden nie aufgeräumt. Jedes Beschädigungsereignis hinterließ eine dauerhafte Datei, ohne Obergrenze. Auf einer laufenden Maschine gemessen: zwei davon lagen seit Monaten dort. Das ist dieselbe Regel wie anderswo in diesem Wiki: alles, was schreibt, braucht eine Decke.

Zwei Beiseitelegungen im selben Augenblick erzeugten denselben Namen, und die zweite Kopie überschrieb die erste, sodass eine kaputte Fassung stillschweigend verschwand.

Alles wurde korrigiert, und dem Beiseitelegen selbst wurde eine Regel gesetzt: es wirft unter keinen Umständen einen Fehler. Beiseitelegen ist ein Rettungsschritt, und ein Rettungsschritt darf nicht zu einer neuen Fehlerquelle werden. Dieser Satz sieht klein aus, aber jeder, der Rettungscode schreibt, sollte ihn sich an die Wand hängen.