Hvis en maskines konfigurationsfil går i stykker: hvor den gamle udgave ligger

Hver virtuel maskine og hver container har en lille tekstfil. Hvor mange kerner, hvor meget hukommelse, hvilken disk, hvilket net: det står alt sammen der, i en form et menneske kan læse.

Hvad sker der, hvis den fil går i stykker, hvor er den gamle udgave, og hvad skal du passe på, hvis du redigerer i hånden?

Først den gode nyhed: en ødelagt fil rammer kun sin egen maskine

Hver maskine har sin egen fil. En tastefejl i én vælter ikke panelet, stopper ikke de andre maskiner, rammer ikke serveren.

Symptomet er som regel dette: den maskine holder op med at optræde på listen, eller nægter at starte. Alt andet bliver ved med at fungere normalt. Vid det, før du går i panik, for førstehåndsindtrykket er som regel "systemet er gået i stykker", og det er det ikke.

Hvordan den går i stykker

Redigering i hånden. Det er den hyppigste årsag. Et komma, et anførselstegn, et forkert stavet nøglenavn.

Redigering mens maskinen kører. Selv hvis filen ikke går i stykker, sker der noget uventet: din ændring træder i kraft ved næste start, mens du tror, den gjaldt med det samme. Eller systemet opdaterer selv filen og skriver hen over det, du skrev.

En skrivning afbrudt midtvejs. Strømmen går, disken fyldes, processen dræbes. Filen bliver halvfærdig.

Den tredje er den lumskeste og fortjener sin egen overskrift.

En halvskrevet fil er værre end slet ingen fil

Mangler en fil, er det en åbenlys tilstand. Et program kigger, finder den ikke, siger "findes ikke" og fortsætter med standardværdier. Den tilstand håndteres let.

En halvskrevet fil er ikke sådan. Den ligner en fil. Programmet tjekker, at den findes, finder den, stoler på den og prøver at arbejde med de ufuldstændige data i den. Balladen viser sig ikke ved læsningen, men bagefter.

Løsningen er enkel og gælder enhver skrivning: skriv ikke hen over filen direkte. Skriv først under et midlertidigt navn, og flyt den så på plads. En flytning sker enten helt eller slet ikke; der er ingen mellemtilstand. Så er filens indhold enten det gamle eller det nye, aldrig halvdelen.

Skriver du et script, der rører ved Proxmox-konfiguration, er den ene vane mere værd end al den øvrige kode, du kommer til at skrive.

Den gamle udgave ligger to steder

Inde i sikkerhedskopien. En maskines sikkerhedskopi bærer ikke kun disken, men også konfigurationsfilen, som den var i det øjeblik. Når du gendanner kopien, kommer konfigurationen også tilbage. De fleste tænker på en sikkerhedskopi som kun data og opdager aldrig, at de har en redningsvej i hånden.

Inde i øjebliksbilledet. Når du tager et øjebliksbillede, skrives konfigurationen fra det øjeblik ind i et navngivet afsnit af den samme fil. Filen bærer altså en del af sin egen historie i sig.

Men de to erstatter ikke hinanden, og forskellen betyder noget: øjebliksbilledets notat ligger inde i den samme fil. Ødelægges filen selv, følger notatet med. En sikkerhedskopi ligger et andet sted. Den rigtige redningsvej er sikkerhedskopien; et øjebliksbillede er blot et punkt, du måske vil tilbage til.

Hvis du skal redigere i hånden

Stop maskinen først.

Tag en kopi, før du redigerer, og læg den kopi et andet sted. Stedet, hvor konfigurationen bor, blev lavet til konfiguration; efterlad ikke sikkerhedskopier der.

Start maskinen efter ændringen, og se, at den faktisk virker. Udskyd det ikke til næste genstart og glem det; en glemt halvfærdig redigering kommer måneder senere tilbage som en fejl, ingen kobler til noget.

Den generelle regel: "filen mangler" og "filen er i stykker" er forskellige tilstande

Et programs redningsvej skrives som regel med tilstanden "filen mangler" i tankerne, fordi det er den, man først kommer i tanke om. Tilstanden "filen er der, men indholdet er i stykker" kommer man ikke i tanke om.

Alligevel er den anden den virkelig farlige, netop fordi der ikke blev tænkt på den. Og de to ser forskellige ud: en manglende fil bærer et mærke, ødelagt indhold gør ikke.

Hvad Atlas gør

Atlas holder nogle få egne små indstillingsfiler, og her er der flere ting at fortælle ærligt, for det hele blev fundet ved at måle.

To søskendefiler opførte sig forskelligt. Den ene reparerede sig selv, når dens fil var beskadiget: den lagde den ødelagte til side og begyndte rent. Den anden gjorde det ikke: den kastede en fejl og blev stående der, hvilket betød, at den funktion blev varigt ubrugelig, uden at brugeren kunne rette den via produktet.

Årsagen var præcis reglen ovenfor: redningsgrenen var skrevet til tilstanden "filen mangler". En fejl om ødelagt indhold bærer ikke det mærke, så grenen fangede den ikke, og fejlen slap opad.

De fraskilte kopier blev aldrig ryddet op. Hver beskadigelseshændelse efterlod en varig fil, uden loft over antallet. Målt på en maskine i drift: to af dem havde ligget der i månedsvis. Det er den samme regel, som står andre steder i denne wiki: alt, der skriver, har brug for et loft.

To fraskillelser i det samme øjeblik gav det samme navn, og den anden kopi skrev hen over den første, så en ødelagt udgave forsvandt i stilhed.

Alt blev rettet, og selve fraskillelsen fik én regel: den kaster aldrig en fejl, under ingen omstændigheder. Fraskillelse er et redningstrin, og et redningstrin må ikke blive en ny fejlkilde. Den sætning ser lille ud, men det er den, enhver, der skriver redningskode, burde hænge på væggen.