Montaggi permanenti: la singola riga che può impedire a una macchina di avviarsi

Monti un disco o un archivio di rete a mano e funziona. Riavvii la macchina ed è sparito.

La soluzione è ovvia: aggiungere una riga all’elenco delle cose montate all’avvio. Ed è proprio lì che comincia il pericolo.

Questo file non è come gli altri

La maggior parte dei file di configurazione sul server, se rotti, impediscono a un servizio di funzionare. Se questo file è rotto, la macchina potrebbe non avviarsi.

L’esito non è "il servizio è giù" ma "il sistema è caduto in una shell di ripristino". E a quel punto non ti colleghi da remoto; servono tastiera e monitor o una console fisica.

L’asimmetria che nessuno nota

Una configurazione di rete rotta è fastidiosa: perdi l’accesso remoto. Ma la macchina si avvia comunque.

Una riga di montaggio rotta può impedire del tutto l’avvio della macchina.

Eppure le persone sono molto più prudenti quando modificano il file di rete. L’ordine del pericolo è l’opposto dell’intuizione, ed è l’intuizione a sbagliare.

Tre regole

Verifica la struttura prima di scrivere. Una riga vuole almeno tre campi: origine, destinazione e tipo di file system. Una riga con campi mancanti dà noie a ogni strumento che legge il file.

Scrivi in modo atomico. Una scrittura lasciata a metà in questo file è peggio di nessuna scrittura: resta un file troncato e la macchina prova ad avviarsi con quello.

Non lasciare che un disco assente tenga la macchina in ostaggio. Per archivi di rete e dischi rimovibili usa l’opzione che lascia proseguire l’avvio quando il montaggio fallisce. Che un disco di backup non sia collegato non è un motivo perché il server non si avvii.

La trappola della verifica: un controllo che va in crash non è un controllo superato

La lezione più generale di questo articolo sta qui, e non vale solo per questo file.

Esiste uno strumento standard per validare questo file. Misurato su una macchina reale, è venuto fuori questo: lo strumento va in crash quando vede una riga con meno di tre colonne. Cioè esplode esattamente quando vede la forma malformata che dovrebbe intercettare.

Che uno strumento di verifica vada in crash non significa che la verifica sia passata. La risposta giusta non è "nessun problema" ma "non verificabile".

Un procedimento che non fa questa distinzione approva il file più pericoloso nel suo momento più debole.

La seconda trappola: non ogni lamentela è un errore

Lo stesso strumento di validazione può dire due cose diverse, e confonderle crea un nuovo problema.

Un errore di formato significa che il file non è leggibile. È davvero pericoloso e la scrittura va annullata.

Una lamentela semantica è altro: cose come "destinazione irraggiungibile all’avvio" o "tipo di file system sconosciuto". Queste non corrompono il file e possono essere legittime. Aggiungere una riga per un dispositivo non ancora collegato è comune e corretto; l’opzione che lascia proseguire l’avvio esiste proprio per questo.

Un controllo che mette entrambe nello stesso cesto rifiuta una riga nuova di zecca e perfettamente valida. In altre parole, una porta troppo severa rende il lavoro impossibile e spinge le persone a spegnerla.

Che cosa fa Atlas

In Atlas ogni scrittura su questo file passa da un’unica porta. Ogni riga viene controllata strutturalmente prima della scrittura, la scrittura è atomica, e dopo la scrittura il file viene riletto e verificato; se il risultato atteso non compare, viene ripristinato lo stato precedente.

Entrambe le trappole sopra sono trattate di proposito. Lo strumento di validazione esterno conta solo come segnale secondario: se va in crash, il risultato non è "pulito" ma "non verificabile". Ed errori di formato e lamentele semantiche sono trattati a parte; solo un errore di formato causa il ripristino, mentre le lamentele semantiche non vengono inghiottite ma riferite al chiamante.

Anche la necessità di quella distinzione è emersa dalla misura: nella prima stesura entrambe causavano il ripristino e, in quello stato, veniva rifiutata perfino una riga nuova e del tutto valida.

Una nota onesta sulla storia: il prodotto scriveva su questo file da otto punti diversi, e in nessuno si controllava che quanto scritto fosse valido; in due l’intero file veniva sovrascritto in modo non atomico. Nello stesso prodotto il file di rete, che non può impedire l’avvio della macchina, veniva scritto in modo atomico. Il file più pericoloso era quindi il meno protetto. È stato misurato e portato dietro un’unica porta.