Kan man drive Proxmox uden kommandolinje: det ærlige svar

De fleste, der stiller dette spørgsmål, vil egentlig vide to forskellige ting: "kan jeg det" og "går jeg glip af noget". Begge svar falder bedre ud end antaget, men imellem dem ligger en vigtig advarsel.

Panelet er ingen ringere vej

Den udbredte antagelse er, at grænsefladen er en forenklet skal, og at det rigtige arbejde sker på kommandolinjen. Sådan er det ikke. Panelet og kommandolinjen taler med den samme grænseflade: Proxmox' egen programmeringsgrænseflade. Den knap, du trykker på i panelet, og den kommando, du skriver i terminalen, går gennem den samme dør.

Arbejdet fra panelet er altså ingen "letudgave". Det er det samme arbejde, fra en anden flade.

Næsten hele det daglige arbejde ligger allerede i panelet

Oprette maskiner, starte dem, stoppe dem, tage øjebliksbilleder, tage sikkerhedskopier, definere lagring, ordne nettet, oprette brugere og give rettigheder, opdatere. Alt dette findes i grænsefladen, og for det meste er kommandolinjen alligevel langsommere.

Hvor kommandolinjen virkelig er nødvendig

De steder er få, men ikke nul, og ærlighed kræver, at man siger det. De falder som regel i tre familier: når en komponent går i stykker på en uventet måde (læse systemlogge, se hvorfor en tjeneste ikke starter), når der arbejdes i mængde (anvende den samme ændring på hundrede maskiner), og når man bruger en ny eller meget særlig evne, grænsefladen endnu ikke dækker.

Læg mærke til, hvad de tre har til fælles: de er alle ud over det sædvanlige. Ingen af dem hører til det daglige arbejde.

Den virkelige fare er ikke det ikke at vide

Dette er den vigtigste sætning i artiklen: faren er ikke, at du ikke kan kommandolinjen, men at du indsætter en kommando, du ikke forstår.

En kommando, du har fundet på nettet, kører på din maskine med dine rettigheder, og ingen kigger på resultatet. Denne wiki har to konkrete eksempler: énlinjekommandoen, der skulle tie abonnementsbeskeden, og som i virkeligheden ødelægger hele grænsefladebiblioteket, og compose-filer, der ligner opsætning, men kan give beholderen hele maskinen.

I ingen af tilfældene var problemet, at personen ikke kunne kommandolinjen. Problemet var, at vedkommende kørte noget, han ikke kendte. Den, der aldrig rører kommandolinjen, går i ingen af fælderne; den, der kan den halvt, gør.

Vil du lære det, så i den rigtige rækkefølge

Vi siger ikke, at du skal undgå den. Men rækkefølgen tæller: lær først de kommandoer, der læser, dernæst dem, der skriver. Kommandoer, der viser status, læser logge og lister ting, ødelægger intet, og de lærer dig, hvordan systemet tænker. Gå først over til skrivende kommandoer, når du kan læse, hvad de gør.

Og én regel: kør ikke en kommando, du ikke forstår, på en maskine, der bærer dit arbejde. Vil du prøve, så opret en maskine at prøve på; alle artikler om sikkerhedskopi og gendannelse i denne wiki findes netop til det.

Hvad Atlas gør

Atlas står på den side, der flytter dagligt arbejde ind i panelet, og forsøger altså at udvide listen over "næsten alt" ovenfor. Men i det skjuler det intet: det siger, hvad en handling vil gøre, og ved handlinger uden vej tilbage siger det det før handlingen.

Den samme holdning findes to steder, der hænger direkte sammen med denne artikel. Installationsscripts og compose-filer gennemgås, før de kører, og linjer, der gennemborer beholdergrænsen, bliver vist for dig. Arbejde, der rører filer, som at tie abonnementsbeskeden, gøres i produktet i stedet for i hånden, og efter skrivningen læses filen tilbage og kontrolleres.

Målet er altså ikke at skjule kommandolinjen for dig. Målet er, at du aldrig skal være nødt til at indsætte en kommando, du ikke forstår.