Kommandot som tar bort prenumerationsnotisen: den vanligaste enradaren, den tystaste skadan

Du installerade Proxmox, loggade in och prenumerationsnotisen dök upp. Den stör, för den kommer tillbaka vid varje inloggning. Du söker och hittar ett kommando på en rad. Det verkar fungera.

Den här artikeln handlar om det kommandot, men dess verkliga ämne är inte kommandot: den tysta kostnaden av att klistra in något man inte förstår.

Det uppmätta felet

Inuti den vitt spridda enradaren finns ett verkligt fel, och felet är fint.

I de enkla reguljära uttrycken hos klassiska textverktyg är ett lodstreck skrivet med omvänt snedstreck inget vanligt tecken utan alternativoperatorn. Villkoret i gränssnittskoden innehåller två lodstreck, och när kommandot skyddar dem som de är uppstår en tom alternativ mellan två alternativoperatorer.

En tom alternativ matchar på varje position i filen. Kört tillsammans med "ersätt alla" strör uttrycket ändringen över hela filen.

Detta är ingen gissning. Det mättes på en kopia av den riktiga filen: 26458 av 26458 rader ändrades, och antalet false i filen gick från 558 till 26458. Den administratör som körde det kommandot hade förstört hela Proxmox gränssnittsbibliotek.

Ovanpå det finns ett andra problem: det avsedda villkoret ryms inte på en rad, Proxmox fördelar det över sex. Ett verktyg som arbetar rad för rad hade ändå aldrig kunnat träffa det rätt.

Varför ingen märkte det

För att skadan är tyst. Kommandot ger inget fel, ingenting lyser rött. Gränssnittet kan fortsätta fungera ett tag, besväret dyker upp senare, och i det ögonblicket kopplar ingen det till "kommandot jag klistrade in förra veckan".

Den allmänna läxan: "det fungerar för alla" är inget bevis. Oftast är det bara bevis på att ingen har tittat.

Fyra regler för varje ändring av det här slaget

Varje åtgärd som rör en systemfil, oavsett vem som utför den, måste bära dessa fyra.

Säkerhetskopian tas en gång och skrivs aldrig över. Att förnya den vid varje körning betyder att man vid den andra sparar det trasiga tillståndet.

Siktet är smalt. Har den avsedda texten verkligen ändrats utförs åtgärden inte. Att på måfå ändra det närmaste är sämre än att inte ändra alls.

Efter skrivningen läses filen tillbaka. Uteblir det väntade resultatet återställs säkerhetskopian. Att en skrivning inte gav fel betyder inte att den skrev rätt sak.

Ett märke lämnas. Frågan "är den här filen ändrad" måste besvaras av att ett märke finns, inte av gissning.

Fallet ingen tänker på: om säkerhetskopian redan är trasig

Även med alla fyra återstår en lucka. Tänk om ett annat verktyg förstörde filen tidigare och du tog säkerhetskopian efteråt?

Då för återställningen tillbaka den trasiga filen och du tror att du har åtgärdat det. Därför måste även återställningen kontrolleras: kom originalet verkligen tillbaka, eller var säkerhetskopian själv redan ändrad?

Detta är ett exempel på frågan man ständigt måste ställa när man arbetar med en redan installerad maskin: inte vad som händer vid en ren installation, utan vad som händer på en maskin som bär ett gammalt tillstånd.

Vad Atlas gör

Atlas gör detta arbete inne i produkten i stället för genom ett inklistrat kommando, och tillämpar alla fyra punkterna ovan.

Säkerhetskopian tas en gång och skrivs inte över. Siktet är smalt: ett mönster som är tillåtande med blanksteg men troget i övrigt, så att det fortsätter greppa om Proxmox ändrar formateringen, men har villkoret självt ändrats görs ingenting. Efter skrivningen läses filen tillbaka och kontrolleras; uteblir det väntade resultatet återställs säkerhetskopian. Och texten som sätts in bär ett märke, så att frågan "är den ändrad" besvaras med visshet.

På återställningssidan hanteras även det sista fallet: efter att säkerhetskopian återställts kontrolleras om originalet verkligen kom tillbaka, och om det inte gjorde det sägs det rakt ut.

Den enda mening den här artikeln verkligen vill säga är denna: arbetet är inte svårt, men skillnaden mellan att göra det rätt och att se ut att fungera går genom att mäta.