Hvis konfigurasjonsfilen til en maskin blir ødelagt: hvor den gamle versjonen ligger

Hver virtuelle maskin og hver container har en liten tekstfil. Hvor mange kjerner, hvor mye minne, hvilken disk, hvilket nett: alt står der, i en form et menneske kan lese.

Hva skjer om den filen blir ødelagt, hvor er den gamle versjonen, og hva må du passe på hvis du redigerer for hånd?

Først den gode nyheten: en ødelagt fil rammer bare sin egen maskin

Hver maskin har sin egen fil. En skrivefeil i én feller ikke panelet, stopper ikke de andre maskinene, rammer ikke tjeneren.

Symptomet er som regel dette: den maskinen slutter å vises i listen, eller nekter å starte. Alt annet fortsetter å virke normalt. Vit det før du får panikk, for førsteinntrykket er som regel "systemet er ødelagt", og det er det ikke.

Hvordan den blir ødelagt

Redigering for hånd. Dette er den vanligste årsaken. Et komma, et anførselstegn, et feilstavet nøkkelnavn.

Redigering mens maskinen kjører. Selv om filen ikke blir ødelagt, skjer noe du ikke ventet: endringen din trer i kraft ved neste oppstart mens du tror den gjaldt med en gang. Eller systemet oppdaterer filen selv og skriver over det du skrev.

En skriving avbrutt midtveis. Strømmen går, disken fylles, prosessen drepes. Filen blir halvferdig.

Den tredje er den lureste og fortjener sin egen overskrift.

En halvskrevet fil er verre enn ingen fil

Mangler en fil, er det en åpenbar tilstand. Et program ser etter, finner den ikke, sier "finnes ikke" og går videre med standardverdier. Den tilstanden håndteres lett.

En halvskrevet fil er ikke slik. Den ser ut som en fil. Programmet sjekker at den finnes, finner den, stoler på den, og prøver å arbeide med de ufullstendige dataene i den. Bråket dukker ikke opp ved lesingen, men etterpå.

Løsningen er enkel og gjelder enhver skriving: ikke skriv over filen direkte. Skriv først under et midlertidig navn, flytt den så på plass. En flytting skjer enten helt eller ikke i det hele tatt; noe midt imellom finnes ikke. Slik er filens innhold enten det gamle eller det nye, aldri halvparten.

Skriver du et skript som rører Proxmox-konfigurasjon, er den ene vanen verdt mer enn all den andre koden du kommer til å skrive.

Den gamle versjonen ligger to steder

Inne i sikkerhetskopien. Sikkerhetskopien av en maskin bærer ikke bare disken, men også konfigurasjonsfilen slik den var i det øyeblikket. Når du gjenoppretter kopien, kommer konfigurasjonen tilbake også. De fleste tenker på en sikkerhetskopi bare som data og oppdager aldri at de holder en redningsvei i hånden.

Inne i øyeblikksbildet. Når du tar et øyeblikksbilde, skrives konfigurasjonen fra det øyeblikket inn i en navngitt del av den samme filen. Filen bærer altså en del av sin egen historie i seg.

Men disse to erstatter ikke hverandre, og forskjellen betyr noe: øyeblikksbildets notat ligger inne i den samme filen. Ødelegges filen selv, følger notatet med. En sikkerhetskopi ligger et annet sted. Den ekte redningsveien er sikkerhetskopien; et øyeblikksbilde er bare et punkt du kanskje vil tilbake til.

Hvis du skal redigere for hånd

Stopp maskinen først.

Ta en kopi før du redigerer, og legg den kopien et annet sted. Stedet der konfigurasjonen bor ble laget for konfigurasjon; ikke legg igjen sikkerhetskopier der.

Start maskinen etter endringen og se at den faktisk virker. Ikke utsett det til neste omstart og glem det; en glemt halvferdig redigering kommer tilbake måneder senere som en feil ingen kobler til noe.

Den generelle regelen: "filen mangler" og "filen er ødelagt" er ulike tilstander

Redningsveien i et program skrives som regel med tilstanden "filen mangler" i tankene, fordi det er den som først faller en inn. Tilstanden "filen finnes, men innholdet er ødelagt" faller en ikke inn.

Likevel er den andre den virkelig farlige, nettopp fordi den ikke ble tenkt på. Og de to ser ulike ut: en manglende fil bærer et merke, ødelagt innhold gjør det ikke.

Hva Atlas gjør

Atlas holder noen egne små innstillingsfiler, og her er det flere ting å fortelle ærlig, for alt ble funnet ved å måle.

To søsterfiler oppførte seg ulikt. Den ene reparerte seg selv når filen var ødelagt: den la den ødelagte til side og begynte rent. Den andre gjorde det ikke: den kastet en feil og ble stående der, det vil si at den funksjonen ble varig ubrukelig uten at brukeren kunne rette den gjennom produktet.

Årsaken var nøyaktig regelen ovenfor: redningsgrenen var skrevet for tilstanden "filen mangler". En feil om ødelagt innhold bærer ikke det merket, så grenen fanget den ikke og feilen slapp oppover.

Kopiene som ble lagt til side ble aldri ryddet. Hver ødeleggelseshendelse etterlot en varig fil, uten tak på antallet. Målt på en maskin i drift: to av dem hadde ligget der i månedsvis. Det er den samme regelen som er skrevet andre steder i denne wikien: alt som skriver trenger et tak.

To sidelegginger i samme øyeblikk ga samme navn, og den andre kopien skrev over den første, slik at en ødelagt versjon forsvant i stillhet.

Alt ble rettet, og selve sidelegningen fikk én regel: den kaster aldri en feil, under ingen omstendighet. Sidelegning er et redningssteg, og et redningssteg må ikke bli en ny feilkilde. Den setningen ser liten ut, men det er den enhver som skriver redningskode burde henge på veggen.