Lässt sich Proxmox ohne Kommandozeile betreiben: die ehrliche Antwort

Die meisten, die das fragen, wollen eigentlich zwei verschiedene Dinge wissen: "kann ich das" und "fehlt mir dann etwas". Beide Antworten fallen besser aus als gedacht, aber dazwischen liegt eine wichtige Warnung.

Das Panel ist kein minderer Weg

Die verbreitete Annahme lautet, die Oberfläche sei eine vereinfachte Shell und die eigentliche Arbeit geschehe auf der Kommandozeile. Das stimmt nicht. Panel und Kommandozeile sprechen mit derselben Schnittstelle: der eigenen Programmierschnittstelle von Proxmox. Der Knopf, den du im Panel drückst, und der Befehl, den du ins Terminal tippst, gehen durch dieselbe Tür.

Die Arbeit aus dem Panel ist also keine "leichte Fassung". Es ist dieselbe Arbeit, von einer anderen Oberfläche aus.

Fast die gesamte tägliche Arbeit steckt schon im Panel

Maschinen anlegen, starten, stoppen, Momentaufnahmen machen, sichern, Speicher definieren, das Netz einrichten, Benutzer anlegen und Rechte vergeben, aktualisieren. All das gibt es in der Oberfläche, und für das meiste davon ist die Kommandozeile ohnehin langsamer.

Wo die Kommandozeile wirklich gebraucht wird

Diese Stellen sind wenige, aber nicht null, und Ehrlichkeit gebietet, das zu sagen. Sie fallen meist in drei Familien: wenn ein Bestandteil unerwartet kaputtgeht (Systemprotokolle lesen, sehen, warum ein Dienst nicht startet), wenn Arbeit in Menge anfällt (dieselbe Änderung auf hundert Maschinen anwenden), und wenn eine neue oder sehr spezielle Fähigkeit genutzt wird, die die Oberfläche noch nicht abdeckt.

Beachte, was diese drei gemeinsam haben: sie sind alle außergewöhnlich. Keine davon gehört zur täglichen Arbeit.

Die eigentliche Gefahr ist nicht das Nichtwissen

Das ist der wichtigste Satz dieses Eintrags: die Gefahr ist nicht, die Kommandozeile nicht zu kennen, sondern einen Befehl einzufügen, den du nicht verstehst.

Ein im Netz gefundener Befehl läuft auf deiner Maschine mit deinen Rechten, und niemand sieht sich das Ergebnis an. Dieses Wiki hat dafür zwei konkrete Beispiele: den Einzeiler, der den Abonnementhinweis stummschalten soll und in Wahrheit die gesamte Oberflächenbibliothek zerstört, und Compose-Dateien, die wie Konfiguration aussehen und dem Container die ganze Maschine geben können.

In beiden Fällen war das Problem nicht, dass die Person die Kommandozeile nicht kannte. Das Problem war, dass sie etwas ausführte, das sie nicht kannte. Wer die Kommandozeile nie anfasst, tappt in keine der beiden Fallen; wer sie halb kennt, tappt hinein.

Wenn du lernen willst, die richtige Reihenfolge

Wir sagen nicht, du sollst es meiden. Aber die Reihenfolge zählt: lerne zuerst die Befehle, die lesen, danach die, die schreiben. Befehle, die Status zeigen, Protokolle lesen und Listen ausgeben, machen nichts kaputt und lehren dich, wie das System denkt. Zu schreibenden Befehlen gehst du erst über, wenn du lesen kannst, was sie tun.

Und eine Regel: führe keinen Befehl, den du nicht verstehst, auf einer Maschine aus, die deine Arbeit trägt. Willst du ausprobieren, leg dir eine Maschine zum Ausprobieren an; sämtliche Sicherungs- und Rücksicherungseinträge in diesem Wiki sind genau dafür da.

Was Atlas tut

Atlas steht auf der Seite, tägliche Arbeit ins Panel zu holen, versucht also die obige Liste des "fast alles" zu erweitern. Dabei verbirgt es nichts: es sagt, was ein Vorgang tun wird, und bei Vorgängen ohne Rückweg sagt es das vor dem Vorgang.

Dieselbe Haltung zeigt sich an zwei direkt mit diesem Eintrag verbundenen Stellen. Installationsskripte und Compose-Dateien werden vor der Ausführung geprüft, und Zeilen, die die Containergrenze durchstoßen, werden dir gezeigt. Arbeiten, die Dateien anfassen, etwa das Stummschalten des Abonnementhinweises, geschehen im Produkt statt von Hand, und nach dem Schreiben wird die Datei zurückgelesen und geprüft.

Das Ziel ist also nicht, dir die Kommandozeile zu verbergen. Das Ziel ist, dass du nie einen Befehl einfügen musst, den du nicht verstehst.