Går det att sköta Proxmox utan kommandorad: det ärliga svaret

De flesta som ställer den här frågan undrar egentligen två olika saker: "klarar jag det" och "missar jag något". Båda svaren är bättre än man tror, men däremellan finns en viktig varning.

Panelen är ingen sämre väg

Den vanliga föreställningen är att gränssnittet är ett förenklat skal och att det verkliga arbetet sker på kommandoraden. Så är det inte. Panelen och kommandoraden talar med samma gränssnitt: Proxmox eget programmeringsgränssnitt. Knappen du trycker på i panelen och kommandot du skriver i terminalen går genom samma dörr.

Arbetet från panelen är alltså ingen "lättversion". Det är samma arbete, från en annan yta.

Nästan hela det dagliga arbetet finns redan i panelen

Skapa maskiner, starta dem, stoppa dem, ta ögonblicksbilder, ta säkerhetskopior, definiera lagring, ordna nätet, skapa användare och ge rättigheter, uppdatera. Allt detta finns i gränssnittet, och för det mesta är kommandoraden ändå långsammare.

Där kommandoraden verkligen behövs

De ställena är få men inte noll, och ärlighet kräver att man säger det. De faller oftast i tre familjer: när en komponent går sönder på ett oväntat sätt (läsa systemloggar, se varför en tjänst inte startar), när arbete sker i mängd (tillämpa samma ändring på hundra maskiner), och när man använder en ny eller mycket särskild förmåga som gränssnittet ännu inte täcker.

Lägg märke till vad de tre har gemensamt: de är alla utöver det vanliga. Ingen av dem hör till det dagliga arbetet.

Den verkliga faran är inte okunskapen

Det här är den viktigaste meningen i posten: faran är inte att du inte kan kommandoraden, utan att du klistrar in ett kommando du inte förstår.

Ett kommando du hittat på nätet körs på din maskin med dina rättigheter, och ingen tittar på resultatet. Den här wikin har två konkreta exempel: enradskommandot som ska tysta abonnemangsnotisen och som i själva verket förstör hela gränssnittsbiblioteket, och compose-filer som ser ut som konfiguration men kan ge behållaren hela maskinen.

I inget av fallen var problemet att personen inte kunde kommandoraden. Problemet var att hen körde något hen inte kände till. Den som aldrig rör kommandoraden går inte i någon av fällorna; den som kan den till hälften gör det.

Vill du lära dig, då i rätt ordning

Vi säger inte att du ska undvika den. Men ordningen spelar roll: lär dig först de kommandon som läser, sedan de som skriver. Kommandon som visar status, läser loggar och listar saker förstör ingenting, och de lär dig hur systemet tänker. Gå över till skrivande kommandon först när du kan läsa vad de gör.

Och en regel: kör inte ett kommando du inte förstår på en maskin som bär ditt arbete. Vill du pröva, skapa en maskin att pröva på; alla poster om säkerhetskopiering och återställning i den här wikin finns just för det.

Vad Atlas gör

Atlas står på den sida som flyttar dagligt arbete in i panelen, och försöker alltså bredda listan över "nästan allt" ovan. Men i det döljer det ingenting: det säger vad en åtgärd kommer att göra, och för åtgärder utan väg tillbaka säger det det före åtgärden.

Samma hållning syns på två ställen som hör direkt ihop med den här posten. Installationsskript och compose-filer granskas innan de körs, och rader som genomborrar behållargränsen visas för dig. Arbete som rör filer, som att tysta abonnemangsnotisen, görs i produkten i stället för för hand, och efter skrivningen läses filen tillbaka och kontrolleras.

Målet är alltså inte att dölja kommandoraden för dig. Målet är att du aldrig ska behöva klistra in ett kommando du inte förstår.