Går det an å drifte Proxmox uten kommandolinje: det ærlige svaret

De fleste som stiller dette spørsmålet lurer egentlig på to forskjellige ting: "klarer jeg det" og "går jeg glipp av noe". Begge svarene er bedre enn man tror, men mellom dem ligger en viktig advarsel.

Panelet er ingen dårligere vei

Den vanlige antakelsen er at grensesnittet er et forenklet skall og at det virkelige arbeidet skjer på kommandolinjen. Slik er det ikke. Panelet og kommandolinjen snakker med det samme grensesnittet: Proxmox sitt eget programmeringsgrensesnitt. Knappen du trykker i panelet og kommandoen du skriver i terminalen går gjennom den samme døra.

Arbeidet fra panelet er altså ingen "lettversjon". Det er det samme arbeidet, fra en annen flate.

Nesten hele det daglige arbeidet ligger allerede i panelet

Opprette maskiner, starte dem, stoppe dem, ta øyeblikksbilder, ta sikkerhetskopier, definere lagring, ordne nettet, opprette brukere og gi rettigheter, oppdatere. Alt dette finnes i grensesnittet, og for det meste er kommandolinjen uansett tregere.

Der kommandolinjen virkelig trengs

De stedene er få, men ikke null, og ærlighet krever at man sier det. De faller som regel i tre familier: når en komponent ryker på en uventet måte (lese systemlogger, se hvorfor en tjeneste ikke starter), når arbeid skjer i mengde (bruke samme endring på hundre maskiner), og når man bruker en ny eller svært spesiell evne grensesnittet ennå ikke dekker.

Legg merke til hva de tre har til felles: de er alle utenom det vanlige. Ingen av dem hører til det daglige arbeidet.

Den virkelige faren er ikke det å ikke vite

Dette er den viktigste setningen i oppføringen: faren er ikke at du ikke kan kommandolinjen, men at du limer inn en kommando du ikke forstår.

En kommando du fant på nettet kjører på din maskin med dine rettigheter, og ingen ser på resultatet. Denne wikien har to konkrete eksempler: énlinjes kommandoen som skal tie abonnementsvarselet og som i virkeligheten ødelegger hele grensesnittbiblioteket, og compose-filer som ser ut som oppsett, men kan gi beholderen hele maskinen.

I ingen av tilfellene var problemet at personen ikke kunne kommandolinjen. Problemet var at vedkommende kjørte noe han ikke kjente. Den som aldri rører kommandolinjen går ikke i noen av fellene; den som kan den halvveis gjør det.

Vil du lære, da i riktig rekkefølge

Vi sier ikke at du skal unngå den. Men rekkefølgen teller: lær først kommandoene som leser, deretter de som skriver. Kommandoer som viser status, leser logger og lister opp ødelegger ingenting, og de lærer deg hvordan systemet tenker. Gå over til skrivende kommandoer først når du kan lese hva de gjør.

Og én regel: ikke kjør en kommando du ikke forstår på en maskin som bærer arbeidet ditt. Vil du prøve, opprett en maskin å prøve på; alle oppføringene om sikkerhetskopi og gjenoppretting i denne wikien finnes nettopp til det.

Hva Atlas gjør

Atlas står på den siden som flytter daglig arbeid inn i panelet, og prøver altså å utvide listen over "nesten alt" over. Men i det skjuler det ingenting: det sier hva en operasjon kommer til å gjøre, og for operasjoner uten vei tilbake sier det det før operasjonen.

Den samme holdningen finnes to steder som henger direkte sammen med denne oppføringen. Installasjonsskript og compose-filer granskes før de kjøres, og linjer som gjennomborer beholdergrensen blir vist for deg. Arbeid som rører filer, som å tie abonnementsvarselet, gjøres i produktet i stedet for for hånd, og etter skrivingen leses fila tilbake og kontrolleres.

Målet er altså ikke å skjule kommandolinjen for deg. Målet er at du aldri skal måtte lime inn en kommando du ikke forstår.