Bevor Sie ein Community-Skript auf Ihrem Proxmox-Host ausführen: fünf Dinge zum Lesen

Community-Skripte sind wirklich gut. Sie tragen Wissen, das jemand mit verlorenen Abenden bezahlt hat, sie behandeln die unangenehmen Fälle, in die Sie um Mitternacht gelaufen wären, und für viele Aufgaben ist das Skript besser als das, was Sie selbst geschrieben hätten. Dieser Artikel ist kein Argument dagegen.

Es geht um eine bestimmte Lücke. Eine Paketinstallation und eine eingefügte Einzeilerinstallation sehen auf dem Bildschirm gleich alltäglich aus, und sie sind überhaupt nicht dasselbe.

Was ein Paket gibt und eine eingefügte Zeile nicht

Eine Signatur. Pakete sind signiert und die Signatur wird geprüft. Eine URL wird nur gegen Ihre Annahme geprüft, dass die URL stimmt.

Eine Version. Sie können sagen, welche Version Sie haben, und der Helfende auch. "Das Skript aus der Anleitung, vor ein paar Wochen" ist keine Version.

Einen Deinstallationsweg. Pakete merken sich, was sie abgelegt haben, und können es entfernen. Ein Skript legt oft an sechs Stellen Dateien ab und erinnert sich daran nicht.

Eine Beziehung zum Betreuer. Ändert ein Paket sein Verhalten, gibt es ein Änderungsprotokoll. Ein Skript kann sich unter derselben URL ändern, ohne dass es etwas zu lesen gäbe.

Nichts davon macht Skripte schlecht. Es macht sie zu einer anderen Art Sache, die eine andere Gewohnheit verdient.

Die fünf Dinge zum Lesen

Nicht das ganze Skript und nicht Zeile für Zeile. Diese fünf Antworten sind meist in einem Durchgang sichtbar.

① Was fasst es außerhalb seines eigenen Verzeichnisses an? Ein Skript, das nur unter seinen eigenen Ordner schreibt, ist leicht zu überblicken. Eines, das Dateien in Systemkonfigurationsverzeichnissen bearbeitet, nimmt Änderungen vor, die es überdauern.

② Fügt es ein Repository oder einen Schlüssel hinzu? Das ist in den meisten Skripten die folgenreichste Zeile und sie huscht in einer Sekunde vorbei. Eine Paketquelle hinzuzufügen heißt, dass jede künftige Aktualisierung auf dieser Maschine einer neuen Partei vertraut. Das kann völlig vernünftig sein und sollte eine Entscheidung sein, kein Nebeneffekt.

③ Berührt es Start, Kernel oder Netzwerk? Das sind die drei, die einen Host unerreichbar oder nicht startfähig machen können, und auf einem Hypervisor heißt das, alles darauf geht mit. Ein Skript, das eine Webanwendung installiert, hat in der Bootloader-Konfiguration nichts zu suchen, und wenn doch, lohnt es sich, das vorher zu verstehen.

④ Gibt es einen Rückweg? Suchen Sie nach einem Deinstallationsweg, ersatzweise nach einer Liste dessen, was es angelegt hat. Fehlt beides, ist Ihr Rückweg ein vorher erstellter Snapshot, was bedeutet, dass Sie einen erstellen müssen.

⑤ Was passiert beim zweiten Lauf? Viele Skripte sind für eine saubere Maschine geschrieben, und ein zweiter Lauf verdoppelt Einträge, setzt von Ihnen bearbeitete Konfiguration zurück oder bricht auf halbem Weg ab und hinterlässt einen Halbzustand. Sie werden es irgendwann zweimal laufen lassen, meist weil der erste Lauf gescheitert schien.

Speziell die eingefügte Einzeile

Das Muster, ein Skript zu holen und direkt in eine Shell zu leiten, hat eine Eigenschaft, die benannt gehört: Sie können nicht lesen, was Sie ausgeführt haben. Nicht "Sie haben nicht", Sie können nicht, denn es war nie eine Datei.

Es gibt auch eine feinere Variante. Das Skript im Browser zu lesen und den Hol-und-Leite-Befehl auszuführen sind zwei getrennte Anfragen. Nichts garantiert, dass beide dieselben Bytes lieferten.

Die Lösung kostet einen zusätzlichen Schritt. Datei herunterladen, hineinschauen, dann die lokale Kopie ausführen. Jetzt wissen Sie, was lief, können später exakt dasselbe erneut ausführen, und wenn etwas kaputtgeht, haben Sie den echten Text statt der Erinnerung an eine Webseite.

Ein Hypervisor ist kein Ort zum Ausprobieren

Das ist der Teil, der einen Proxmox-Host von einem Laptop trennt. Alles andere auf der Maschine hängt darunter. Ein Skript, das einen Laptop in einen seltsamen Zustand bringt, kostet Sie einen Abend; dasselbe Skript auf einem Host nimmt jede virtuelle Maschine mit.

Zwei Gewohnheiten machen fast alles davon sicher:

Führen Sie es zuerst in einer virtuellen Maschine aus, wenn es plausibel geht. Die meisten Skripte, die einen Dienst installieren, müssen gar nicht auf dem Host laufen. Das ist kein Behelf, das ist meist der richtige Ort.

Muss es wirklich auf dem Host laufen, vorher einen Snapshot. Nicht weil das Skript verdächtig wäre, sondern weil "ich probier es einfach" genau der Satz ist, der dem Bedarf nach einem Rückweg vorausgeht.

Was dieser Artikel nicht ist

Kein Grund, der Community zu misstrauen. Die geteilten Skripte gehören zum Besten in diesem Ökosystem, und die Autoren sind meist sorgfältiger als die, die sie ausführen.

Kein Grund, jede Zeile zu lesen. Fünf Fragen in einem Durchgang reichen, um die Art von Überraschung zu erwischen, die wirklich wehtut.

Was Atlas macht

Atlas legt vor Operationen, die den Hostzustand ändern, einen Snapshot an, sodass der Rückweg existiert, ohne dass Sie daran denken müssen. Das deckt Schritt vier der obigen Liste ab, also genau den, den man überspringt.

Das Prüfprotokoll hält fest, wer was wann woran mit welchem Ergebnis ausgeführt hat, und macht aus "letzten Dienstag hat sich etwas geändert" eine lesbare Antwort statt einer Ermittlung.

Die Ressourcenkette hilft eher beim Danach als bei der Entscheidung: verhält sich nach einer Installation etwas anders, zeigt die Karte, wie die Maschine jetzt tatsächlich aussieht, von den Gästen bis zu den physischen Platten.

Und wo Atlas selbst Software installiert, über den Anwendungskatalog, ist die Version festgelegt, die Quelle fix und vor Beginn wird ein Wiederherstellungspunkt genommen. Das ist ein bewusst schmaler, kuratierter Pfad und er ersetzt Community-Skripte nicht. Er ist schlicht dieselben fünf Fragen, im Voraus beantwortet für die Anwendungen, die er führt.