Kun je Proxmox beheren zonder opdrachtregel: het eerlijke antwoord

De meesten die dit vragen willen eigenlijk twee verschillende dingen weten: "kan ik het" en "mis ik dan iets". Beide antwoorden vallen beter uit dan gedacht, maar er zit een belangrijke waarschuwing tussen.

Het paneel is geen mindere weg

De gangbare aanname is dat de interface een vereenvoudigde shell is en dat het echte werk op de opdrachtregel gebeurt. Dat klopt niet. Het paneel en de opdrachtregel praten met dezelfde interface: de eigen programmeerinterface van Proxmox. De knop die je in het paneel indrukt en de opdracht die je in de terminal typt gaan door dezelfde deur.

Het werk vanuit het paneel is dus geen "lichte versie". Het is hetzelfde werk, vanaf een ander oppervlak.

Bijna al het dagelijkse werk zit al in het paneel

Machines aanmaken, starten, stoppen, momentopnamen maken, back-uppen, opslag definiëren, het netwerk inrichten, gebruikers aanmaken en rechten geven, bijwerken. Dat alles zit in de interface, en voor het meeste is de opdrachtregel sowieso trager.

Waar de opdrachtregel echt nodig is

Die plekken zijn er weinig maar niet nul, en eerlijkheid gebiedt dat te zeggen. Ze vallen meestal in drie families: als een onderdeel op een onverwachte manier stukgaat (systeemlogboeken lezen, zien waarom een dienst niet start), als er in bulk gewerkt wordt (dezelfde wijziging op honderd machines toepassen), en als een nieuwe of heel specifieke mogelijkheid wordt gebruikt die de interface nog niet dekt.

Let op wat die drie gemeen hebben: ze zijn allemaal buitengewoon. Geen ervan hoort bij het dagelijkse werk.

Het echte gevaar is niet het niet-weten

Dit is de belangrijkste zin van dit artikel: het gevaar is niet dat je de opdrachtregel niet kent, maar dat je een opdracht plakt die je niet begrijpt.

Een op internet gevonden opdracht draait op jouw machine met jouw rechten, en niemand kijkt naar de uitkomst. Deze wiki heeft er twee concrete voorbeelden van: de eenregelige opdracht die de abonnementsmelding zou dempen en in werkelijkheid de hele interfacebibliotheek sloopt, en compose-bestanden die eruitzien als configuratie terwijl ze de container de hele machine kunnen geven.

In geen van beide gevallen was het probleem dat de persoon de opdrachtregel niet kende. Het probleem was dat hij iets uitvoerde dat hij niet kende. Wie de opdrachtregel nooit aanraakt trapt in geen van beide vallen; wie hem half kent wel.

Wil je het leren, dan de juiste volgorde

We zeggen niet dat je het moet mijden. Maar de volgorde telt: leer eerst de opdrachten die lezen, daarna die schrijven. Opdrachten die status tonen, logboeken lezen en dingen opsommen breken niets, en ze leren je hoe het systeem denkt. Ga pas over op schrijvende opdrachten als je kunt lezen wat ze doen.

En één regel: voer een opdracht die je niet begrijpt niet uit op een machine die je werk draagt. Wil je proberen, maak dan een machine om op te proberen; alle back-up- en herstelartikelen in deze wiki bestaan precies daarvoor.

Wat Atlas doet

Atlas staat aan de kant van het dagelijkse werk naar het paneel halen, en probeert dus de lijst van "bijna alles" hierboven te verbreden. Maar daarbij verbergt het niets: het zegt wat een bewerking gaat doen, en bij bewerkingen zonder weg terug zegt het dat vóór de bewerking.

Dezelfde houding komt terug op twee plekken die direct met dit artikel te maken hebben. Installatiescripts en compose-bestanden worden onderzocht voordat ze draaien, en regels die de containergrens doorboren worden je getoond. Werk dat bestanden aanraakt, zoals het dempen van de abonnementsmelding, gebeurt in het product in plaats van met de hand, en na het schrijven wordt het bestand teruggelezen en gecontroleerd.

Het doel is dus niet om de opdrachtregel voor je te verbergen. Het doel is dat je nooit een opdracht hoeft te plakken die je niet begrijpt.