Innan du kör ett community-skript på din Proxmox-värd: fem saker att läsa

Community-skript är verkligen bra. De bär kunskap som någon betalat för med bortkastade kvällar, de tar hand om de otrevliga fallen du hade gått på vid midnatt, och för många uppgifter är skriptet bättre än det du själv hade skrivit. Den här artikeln argumenterar inte mot dem.

Den handlar om ett bestämt glapp. En paketinstallation och ett inklistrat enradsskript ser lika vardagliga ut på skärmen, och de är inte alls samma sak.

Vad ett paket ger som en inklistrad rad inte gör

En signatur. Paket är signerade och signaturen kontrolleras. En adress kontrolleras bara mot ditt antagande att adressen stämmer.

En version. Du kan säga vilken version du har, och den som hjälper dig också. "Skriptet från readme, för några veckor sedan" är ingen version.

En avinstallationsväg. Paket registrerar vad de lagt dit och kan ta bort det. Ett skript lägger ofta filer på sex ställen och minns inte att det gjort det.

En relation till en underhållare. När ett pakets beteende ändras finns en ändringslogg. Ett skript kan ändras under samma adress utan att lämna något att läsa.

Inget av detta gör skript dåliga. Det gör dem till en annan sorts sak som förtjänar en annan vana.

De fem sakerna att läsa

Inte hela skriptet, och inte rad för rad. De här fem svaren syns oftast i en genomläsning.

① Vad rör det utanför sin egen katalog? Ett skript som bara skriver under sin egen mapp är lätt att överblicka. Ett som ändrar filer i systemets konfigurationskataloger gör ändringar som överlever det självt.

② Lägger det till ett repository eller en nyckel? Det är den rad med tyngst följder i de flesta skript och den passerar på en sekund. Att lägga till en paketkälla betyder att varje framtida uppdatering på den maskinen litar på en ny part. Det kan vara helt rimligt och bör vara ett beslut, inte en sidoeffekt.

③ Rör det start, kärna eller nätverk? Det är de tre som kan lämna en värd onåbar eller ostartbar, och på en hypervisor betyder det att allt ovanpå följer med. Ett skript som installerar en webbapplikation har inget i startladdarens konfiguration att göra, och gör det ändå det är det värt att förstå innan det körs.

④ Finns en väg tillbaka? Leta efter en avinstallationsrutin eller åtminstone en lista över vad det skapat. Saknas båda är din väg tillbaka en snapshot tagen innan, vilket betyder att du måste ta en.

⑤ Vad händer om det körs två gånger? Många skript är skrivna för en ren maskin, och ett andra varv dubblerar poster, nollställer konfiguration du ändrat, eller havererar halvvägs och lämnar ett halvt tillstånd. Du kommer att köra det två gånger någon gång, oftast för att första varvet såg ut att misslyckas.

Den inklistrade raden, specifikt

Mönstret att hämta ett skript och skicka det rakt in i ett skal har en egenskap värd att namnge: du kan inte läsa det du körde. Inte "du gjorde det inte", du kan inte, för det var aldrig en fil.

Det finns också en finare variant. Att läsa skriptet i webbläsaren och att köra hämta-och-skicka-kommandot är två skilda förfrågningar. Ingenting garanterar att de gav samma byte.

Lösningen kostar ett extra steg. Ladda ner filen, titta på den, kör sedan den lokala kopian. Nu vet du vad som kördes, du kan köra exakt samma sak senare, och om något går sönder har du den faktiska texten i stället för minnet av en webbsida.

En hypervisor är ingen plats att prova på

Det här skiljer en Proxmox-värd från en bärbar dator. Allt annat på maskinen ligger under den. Ett skript som lämnar en bärbar i ett konstigt läge kostar dig en kväll; samma skript på en värd tar med sig varenda virtuell maskin.

Två vanor gör nästan allt detta säkert:

Kör det först i en virtuell maskin om det rimligen går. De flesta skript som installerar en tjänst behöver inte alls ligga på värden. Det är ingen krångelväg, det är oftast rätt plats.

Måste det verkligen köras på värden, snapshot först. Inte för att skriptet är misstänkt, utan för att "jag testar bara" är precis den mening som föregår behovet av en väg tillbaka.

Vad den här artikeln inte är

Inget skäl att misstro gemenskapen. De delade skripten hör till det bästa i det här ekosystemet, och de som skriver dem är oftast mer noggranna än de som kör dem.

Inget skäl att läsa varje rad. Fem frågor i en genomläsning räcker för att fånga den sorts överraskning som faktiskt gör ont.

Vad Atlas gör

Atlas tar en snapshot före operationer som ändrar värdens tillstånd, så vägen tillbaka finns utan att du behöver komma ihåg att skapa den. Det täcker steg fyra i listan ovan, alltså det man hoppar över.

Revisionsloggen antecknar vem som körde vad, när, på vad och med vilket resultat, vilket gör "något ändrades i tisdags" till ett läsbart svar i stället för en utredning.

Resurskedjan hjälper mer efteråt än vid beslutet: beter sig något annorlunda efter en installation visar kartan hur maskinen faktiskt ser ut nu, från gästerna ner till de fysiska diskarna.

Och där Atlas själv installerar programvara, via applikationskatalogen, är versionen fastlåst, källan fast och en återställningspunkt tas innan installationen börjar. Det är en medvetet smal och kurerad väg och den ersätter inte community-skript. Det är helt enkelt samma fem frågor, besvarade i förväg för de applikationer den bär.