Om en maskins konfigurationsfil går sönder: var den gamla versionen finns

Varje virtuell maskin och varje container har en liten textfil. Hur många kärnor, hur mycket minne, vilken disk, vilket nät: allt står där, i en form en människa kan läsa.

Vad händer om den filen går sönder, var finns den gamla versionen, och vad ska du se upp med om du redigerar för hand?

Först de goda nyheterna: en trasig fil påverkar bara sin egen maskin

Varje maskin har sin egen fil. Ett skrivfel i en fäller inte panelen, stoppar inte de andra maskinerna, påverkar inte servern.

Symptomet är oftast detta: den maskinen slutar synas i listan, eller vägrar starta. Allt annat fortsätter fungera som vanligt. Vet det innan du får panik, för det första intrycket är oftast "systemet är trasigt" och så är det inte.

Hur den går sönder

Redigering för hand. Det är den vanligaste orsaken. Ett kommatecken, ett citattecken, ett felstavat nyckelnamn.

Redigering medan maskinen körs. Även om filen inte går sönder händer något du inte väntade dig: din ändring får verkan vid nästa start medan du tror att den gällde direkt. Eller så uppdaterar systemet filen själv och skriver över det du skrev.

En skrivning avbruten på mitten. Strömmen går, disken fylls, processen dödas. Filen blir halvfärdig.

Den tredje är den listigaste och förtjänar en egen rubrik.

En halvskriven fil är värre än ingen fil alls

Saknas en fil är det ett uppenbart tillstånd. Ett program tittar, hittar den inte, säger "finns inte" och fortsätter med standardvärden. Det tillståndet hanteras lätt.

En halvskriven fil är inte så. Den ser ut som en fil. Programmet kontrollerar att den finns, hittar den, litar på den och försöker arbeta med de ofullständiga data den innehåller. Bekymret visar sig inte vid läsningen, utan efteråt.

Lösningen är enkel och gäller varje skrivning: skriv inte över filen direkt. Skriv först under ett tillfälligt namn, flytta sedan på plats. En flytt sker antingen helt eller inte alls; något däremellan finns inte. Så är filens innehåll antingen det gamla eller det nya, aldrig hälften.

Skriver du ett skript som rör Proxmox konfiguration är den enda vanan värd mer än all övrig kod du kommer skriva.

Den gamla versionen finns på två ställen

Inuti säkerhetskopian. En maskins säkerhetskopia bär inte bara disken utan också konfigurationsfilen som den var i det ögonblicket. När du återställer kopian kommer konfigurationen tillbaka också. De flesta tänker på en säkerhetskopia bara som data och inser aldrig att de håller en återställningsväg i handen.

Inuti ögonblicksbilden. När du tar en ögonblicksbild skrivs konfigurationen i det ögonblicket in i ett namngivet avsnitt av samma fil. Filen bär alltså en del av sin egen historia inom sig.

Men dessa två ersätter inte varandra, och skillnaden spelar roll: ögonblicksbildens anteckning ligger inuti samma fil. Förstörs filen själv följer den anteckningen med. En säkerhetskopia ligger någon annanstans. Den verkliga återställningsvägen är säkerhetskopian; en ögonblicksbild är bara en punkt du kanske vill återvända till.

Om du ska redigera för hand

Stoppa maskinen först.

Ta en kopia innan du redigerar, och lägg den kopian någon annanstans. Platsen där konfigurationen bor konstruerades för konfiguration; lämna inte säkerhetskopior där.

Starta maskinen efter ändringen och se att den verkligen fungerar. Skjut inte upp det till nästa omstart och glöm bort det; en glömd halvfärdig redigering kommer tillbaka månader senare som ett fel ingen kopplar till någonting.

Den allmänna regeln: "filen saknas" och "filen är trasig" är skilda tillstånd

Ett programs återställningsväg skrivs oftast med tillståndet "filen saknas" i tankarna, för det är det som först dyker upp. Tillståndet "filen finns men innehållet är trasigt" dyker inte upp.

Ändå är det andra det verkligt farliga, just för att det inte tänktes på. Och de två ser olika ut: en saknad fil bär en markering, trasigt innehåll gör det inte.

Vad Atlas gör

Atlas håller några egna små inställningsfiler, och här finns flera saker att berätta ärligt, för allt hittades genom mätning.

Två syskonfiler betedde sig olika. Den ena reparerade sig själv när dess fil var skadad: den lade den trasiga åt sidan och började rent. Den andra gjorde inte det: den kastade ett fel och stannade där, vilket betyder att den funktionen blev permanent oanvändbar utan något sätt för användaren att rätta den via produkten.

Orsaken var precis regeln ovan: återställningsgrenen var skriven för tillståndet "filen saknas". Ett fel om trasigt innehåll bär inte den markeringen, så grenen fångade det inte och felet slapp uppåt.

De undanlagda kopiorna städades aldrig. Varje skadehändelse lämnade en bestående fil, utan tak för antalet. Uppmätt på en maskin i drift: två av dem hade legat där i månader. Det är samma regel som skrivits på annat håll i den här wikin: allt som skriver behöver ett tak.

Två undanläggningar i samma ögonblick gav samma namn och den andra kopian skrev över den första, så att en trasig version försvann i tysthet.

Allt rättades, och på själva undanläggningen sattes en regel: den kastar aldrig ett fel, under inga omständigheter. Undanläggning är ett återställningssteg, och ett återställningssteg får inte bli en ny felkälla. Den meningen ser liten ut, men den är den som alla som skriver återställningskod borde sätta upp på väggen.