NFS dietro una VPN: mount all’avvio o automount su richiesta?

Due configurazioni risolvono lo stesso problema e falliscono in direzioni opposte. Montare la condivisione all’avvio dà a ogni servizio un filesystem che o c’è, oppure una ragione per cui l’avvio si è fermato. Un automount su richiesta dà alla macchina un avvio rapido e passa l’attesa a chi tocca il percorso per primo. Dietro una VPN il secondo è di solito lo scambio migliore, e la ragione è che il tunnel impone un ordine che la sequenza di avvio non può vedere.

Mount all’avvio contro automount

Un mount all’avvio è semplice da ragionare. Il target del filesystem attende il mount, i servizi che dichiarano una dipendenza da esso partono dopo, e se il server non è raggiungibile la macchina o attende o fallisce a seconda delle opzioni. Tutto ciò che sta a valle eredita quell’unica decisione.

Un automount lo inverte. Il percorso esiste subito, il mount reale avviene quando qualcosa lo apre, e i servizi che partono presto non si bloccano su un tunnel che non è ancora salito.

Il confronto si riduce a chi debba assorbire il ritardo. Una postazione di lavoro che ha bisogno della condivisione prima che l’utente possa lavorare probabilmente dovrebbe attendere. Un portatile che si avvia dentro una borsa, o un server la cui condivisione è facoltativa, no.

Nessuna delle due opzioni sistema una route mancante. Entrambe decidono soltanto quando il guasto viene osservato.

La riga di fstab, opzione per opzione

Supponiamo che un’istanza client OpenVPN esistente sia [email protected], che il server sia files.corp.example e che il punto di mount sia /mnt/work. Sostituisca i tre con i valori autorizzati del proprio sito. Una riga funzionante si presenta così:

files.corp.example:/export/work /mnt/work nfs _netdev,nofail,x-systemd.automount,[email protected],x-systemd.mount-timeout=30s 0 0

_netdev contrassegna il mount come bisognoso di rete, e non nomina alcun tunnel. nofail mantiene la condivisione facoltativa per il target normale del filesystem. x-systemd.automount crea il trigger su richiesta invece di montare subito.

x-systemd.requires= è la parte che lega il tentativo di mount all’unità VPN, e appartiene all’operazione di mount, non al trigger. Mettere un ordine ampio sull’unità di automount stessa è il modo in cui le persone creano cicli di cui systemd poi si lamenta in un linguaggio che nessuno legge due volte.

x-systemd.mount-timeout=30s limita il comando di mount iniziale. Non limita nulla di ciò che accade dopo, e questo è l’equivoco più comune su questa opzione.

Che cosa «avviato» non significa

Verifichi che cosa significa essere attivo per l’unità VPN che ha nominato. Un servizio di tunnel può dichiararsi avviato prima che esista la route verso il file server o prima che il nome privato venga risolto, e ordinare dopo di esso allora non le compra nulla. È in questa lacuna che vive quasi ogni tentativo fallito. È anche invisibile se non guarda la route e il resolver invece dello stato dell’unità.

Usi il segnale di prontezza del proprietario della connessione come prerequisito aggiuntivo dove esiste. Un sonno fisso è una supposizione che funziona sulla sua scrivania e fallisce su una rete più lenta o dopo una riconnessione.

Esamini le unità generate per il percorso dell’esempio: mnt-work.automount e mnt-work.mount. Dopo una modifica di fstab rivista, ricarichi systemd e gestisca quelle unità direttamente invece di eseguire un comando di mount generico che esercita voci non correlate.

Qui va un’ulteriore avvertenza. Un servizio che tocca /mnt/work all’avvio attiva comunque il mount e lo attende comunque, quindi contrassegnare la condivisione come facoltativa non rende paziente ogni applicazione.

Dopo il mount il guasto è un altro

Una volta montato NFS, il comportamento di nuovo tentativo e recupero del filesystem governa ciò che un’interruzione successiva fa a una lettura o a una scrittura. Il timeout di mount impostato non ha alcuna influenza su questo.

Un mount soft accorcia alcune attese e cambia la semantica degli errori, con conseguenze sull’integrità dei dati facili da trascurare quando l’obiettivo è un avvio più rapido. Sceglierlo per guadagnare due secondi di avvio è raramente un buon scambio. Se il requisito è davvero un’operazione limitata durante un’interruzione, è una decisione a livello di applicazione, non un flag di fstab.

Decida che cosa deve accadere a un processo che è a metà di una scrittura quando il tunnel cade, e lo scriva. Quella risposta è più utile di qualsiasi stringa di opzioni.

Provi quattro stati, non uno

Un avvio normale con il tunnel disponibile è il caso facile e non dimostra quasi nulla. Conferma che la stringa è scritta correttamente e nient’altro. Provi il primo accesso senza la VPN, poi il recupero quando sale, poi un’interruzione controllata dopo un mount riuscito.

Quattro stati, quattro osservazioni, e le note vanno accanto alla voce di fstab. La persona successiva eredita un comportamento invece di una configurazione che deve retroingegnerizzare.