Der Befehl, der den Abonnementhinweis entfernt: der häufigste Einzeiler, der leiseste Schaden

Das Erste, was nach der Installation alle treffen, ist der Abonnementhinweis, und die erste Lösung, die alle finden, ist ein einzeiliger Befehl. Die verbreitete Fassung dieses Befehls wurde gemessen: sie kann die gesamte Oberflächenbibliothek zerstören.

AtlasPVE ·

Dieser Eintrag beantwortet

  • proxmox abonnementhinweis entfernen
  • proxmox no valid subscription
  • proxmox post install script
  • proxmox was nach der installation tun
  • proxmox nag entfernen

Du hast Proxmox installiert, dich angemeldet, und der Abonnementhinweis erschien. Er stört, denn er kommt bei jeder Anmeldung wieder. Du suchst und findest einen einzeiligen Befehl. Er scheint zu funktionieren.

Dieser Artikel handelt von diesem Befehl, doch sein eigentliches Thema ist nicht der Befehl: die leisen Kosten davon, etwas einzufügen, das man nicht versteht.

Der gemessene Fehler

Im weit verbreiteten Einzeiler steckt ein echter Mangel, und der Mangel ist fein.

In den einfachen regulären Ausdrücken klassischer Textwerkzeuge ist ein mit Rückstrich geschriebener senkrechter Strich kein gewöhnliches Zeichen, sondern der Alternativoperator. Die Bedingung im Oberflächencode enthält zwei senkrechte Striche, und wenn der Befehl sie so maskiert, entsteht zwischen zwei Alternativoperatoren eine leere Alternative.

Eine leere Alternative passt an jeder Stelle der Datei. Zusammen mit "alle ersetzen" ausgeführt, streut der Ausdruck die Änderung über die gesamte Datei.

Das ist keine Vermutung. Es wurde an einer Kopie der echten Datei gemessen: 26458 von 26458 Zeilen änderten sich, und die Zahl der false in der Datei stieg von 558 auf 26458. Der Administrator, der diesen Befehl ausführte, hätte die gesamte Oberflächenbibliothek von Proxmox zerstört.

Dazu kommt ein zweites Problem: die anvisierte Bedingung steht nicht in einer Zeile, Proxmox verteilt sie auf sechs. Ein zeilenweise arbeitendes Werkzeug hätte sie ohnehin nie richtig treffen können.

Warum es niemandem auffiel

Weil der Schaden leise ist. Der Befehl meldet keinen Fehler, nichts leuchtet rot auf. Die Oberfläche kann eine Weile weiterlaufen, der Ärger zeigt sich später, und in dem Moment verbindet niemand ihn mit "dem Befehl, den ich letzte Woche eingefügt habe".

Die allgemeine Lehre daraus: "bei allen läuft es" ist kein Beweis. Meist ist es nur der Beweis, dass niemand hingesehen hat.

Vier Regeln für jede Änderung dieser Art

Jeder Vorgang, der eine Systemdatei berührt, muss diese vier tragen, gleich wer ihn ausführt.

Die Sicherung wird einmal genommen und nie überschrieben. Sie bei jedem Lauf zu erneuern, heißt beim zweiten Lauf den kaputten Zustand zu sichern.

Das Ziel ist eng. Hat sich der anvisierte Text wirklich geändert, wird der Vorgang nicht ausgeführt. Das Nächstliegende auf Verdacht zu ändern, ist schlimmer, als gar nichts zu ändern.

Nach dem Schreiben wird zurückgelesen. Erscheint das erwartete Ergebnis nicht, wird die Sicherung wiederhergestellt. Dass ein Schreibvorgang keinen Fehler meldet, heißt nicht, dass er das Richtige geschrieben hat.

Eine Markierung wird hinterlassen. Die Frage "ist diese Datei gepatcht" muss durch das Vorhandensein eines Zeichens beantwortet werden, nicht durch Raten.

Der Fall, an den niemand denkt: wenn die Sicherung schon kaputt ist

Selbst wenn du alle vier befolgst, bleibt eine Lücke. Was, wenn ein anderes Werkzeug die Datei früher zerstört hat und du die Sicherung danach genommen hast?

Dann bringt die Rücknahme die kaputte Datei zurück, und du glaubst, du hättest es behoben. Deshalb muss auch die Rücknahme überprüft werden: kam das Original wirklich zurück, oder war die Sicherung selbst schon gepatcht?

Das ist ein Beispiel für die Frage, die man beim Arbeiten mit einer installierten Maschine ständig stellen muss: nicht was auf einer sauberen Installation passiert, sondern was auf einer Maschine passiert, die einen alten Zustand trägt?

Was Atlas tut

Atlas erledigt diese Arbeit im Produkt statt durch das Einfügen eines Befehls und wendet alle vier obigen Regeln an.

Die Sicherung wird einmal genommen und nicht überschrieben. Das Ziel ist eng: ein Muster, das bei Leerraum nachgiebig, sonst aber wortgetreu ist, sodass es weiter greift, wenn Proxmox die Formatierung ändert, aber wenn sich die Bedingung selbst geändert hat, wird nichts getan. Nach dem Schreiben wird die Datei zurückgelesen und überprüft; erscheint das erwartete Ergebnis nicht, wird die Sicherung wiederhergestellt. Und der eingesetzte Text trägt eine Markierung, sodass die Frage "ist es gepatcht" mit Gewissheit beantwortet wird.

Auf der Rücknahmeseite wird auch der letzte Fall oben behandelt: nach dem Wiederherstellen der Sicherung wird geprüft, ob das Original wirklich zurückkam, und ist das nicht so, wird es klar gesagt.

Der eine Satz, den dieser Artikel wirklich sagen will, lautet: die Aufgabe ist nicht schwer, aber der Unterschied zwischen richtig gemacht und scheinbar funktionierend führt über das Messen.

Quellen

Die eigene Dokumentation von Proxmox. Auf Englisch, und sie hat in dieser Sache das letzte Wort.

Verwandte Einträge

Wie sieht das in Atlas aus?

Zur Produktseite