Cloud Intelligence™Cloud Intelligence™

Cloud Intelligence™

Mount automatico di NFS su istanze Linux

By Sayle MatthewsJul 20, 20208 min read

Questa pagina è disponibile anche in English, Deutsch, Español, Français, 日本語 e Português.

1 fl0wtntavgxuf3yqbi5owg

Qualche settimana fa mi sono imbattuto in quello che, all'epoca, mi sembrava un caso d'uso davvero particolare durante la migrazione di numerose VM del mio home lab verso Kubernetes: montare automaticamente un volume NFS su una macchina Linux o un container Docker.

L'obiettivo era spostare il backing store di InfluxDB, MySQL e Grafana sul mio NAS, anziché tenerlo sul filesystem locale del dispositivo su cui giravano. Uso parecchio NFS sulla mia rete per condividere file tra più dispositivi, grazie alla sua semplicità e all'ampio supporto.

Dopo aver completato la configurazione nel mio home lab, mi sono reso conto che in realtà non si trattava affatto di un caso d'uso così raro, vista la diffusione di NFS nel mondo. Si può usare in un ambiente cloud per montare una condivisione NFS on-premise da cui estrarre dati, per consentire ai processi di leggere o scrivere su una condivisione NFS, per montare le home directory degli utenti da NFS e in innumerevoli altri scenari.

Il problema e la chiave per far funzionare il mount automatico

All'inizio ho seguito la strada che conoscevo meglio, ovvero fstab, che ho usato a fasi alterne negli ultimi decenni. Mi sono però accorto molto in fretta che non montava il volume NFS abbastanza rapidamente perché i daemon dei database lo rilevassero in tempo, e questo causava problemi piuttosto seri.

È a questo punto che mi sono imbattuto in un pacchetto Linux chiamato autofs. Farlo funzionare ha richiesto parecchia sperimentazione, perché molte guide online erano obsolete o tralasciavano dettagli fondamentali della configurazione. Questa guida si limita a spiegarti come fare, così non dovrai perderci mezza giornata: il tempo, per chi lavora nel settore, non basta mai.

In sostanza autofs è semplicemente un daemon che monta e smonta automaticamente le condivisioni in background, secondo necessità. A differenza di fstab, lo fa su richiesta, quindi può intervenire durante il boot senza doversi preoccupare dell'ordine di avvio dei daemon.


Prerequisiti

Per semplicità, in questo esercizio darò per scontato che tu abbia già configurato un server NFS sul tuo NAS o su una macchina Linux, oppure che tu stia utilizzando un servizio come Filestore di Google Cloud al posto di un NAS.

Assicurati di avere i percorsi completi delle condivisioni NFS che intendi aggiungere. A volte non sono quelli che ci si aspetta, quindi controllali con attenzione: per esempio, sui NAS Synology il nome viene preceduto dal volume, come in /volume1/share_path.

I comandi che riporto sono specifici per le distribuzioni derivate da Debian, quindi dovrebbero funzionare con Debian, Ubuntu, Kali, ecc.; in ogni sezione aggiungerò anche il comando equivalente per le distribuzioni derivate da Red Hat, così chi usa RHEL o CentOS non dovrà tradurli.

Tieni presente che in questa guida non tratterò le pratiche di sicurezza di NFS, perché è un argomento molto vasto. Aggiungerebbe un livello di complessità tale da raddoppiare con tutta probabilità la lunghezza della guida, perciò lo ometto. Non fraintendermi: è un aspetto FONDAMENTALE, ma non lo affronto in questo articolo. Ti consiglio di approfondirlo per integrarlo in questa configurazione una volta che l'avrai impostata nel modo più adatto alla tua organizzazione. Se vuoi saperne di più, ti suggerisco di partire da questo ottimo articolo di Red Hat che ne illustra le basi qui.


La procedura

  1. Installa il pacchetto autofs eseguendo i seguenti comandi in base alla tua distribuzione:

    Ubuntu: `sudo apt -y install nfs-common autofs

    Red Hat: sudo yum -y install nfs-common autofs`

  2. Apri il file /etc/auto.master con il tuo editor preferito.

  3. Scorri fino in fondo al file e aggiungi una riga come questa per ogni mount che vuoi inserire, sostituendo la parola share in auto.share con il nome che preferisci per la condivisione:

    `/- /etc/auto.share -nosuid,noowners

    `(Se preferisci, aggiungi pure più spazi tra una voce e l'altra per migliorarne la leggibilità: Medium impedisce di inserire più di uno spazio in un blocco di codice all'interno di un elenco numerato.)

  4. A questo punto dovrai creare ciascuno dei file a cui hai fatto riferimento al passaggio precedente. Si trovano tutti in /etc e seguono il formato auto.[share_name]. Quindi, per ogni riga auto.share che hai aggiunto sopra, dovrai aprire il file corrispondente nel tuo editor di testo preferito per crearlo. Una volta dentro, inserisci questa riga sostituendo il nome della condivisione (preferenza personale: tengo tutto in /mnt, ma puoi modificarlo a piacere), il nome del server e il percorso della condivisione:

    `/mnt/[share_name] -fstyle=nfs,user,nolock,nosuid,rw [server_name]:[share_path]

    `(Anche qui, se preferisci, aggiungi più spazi per la leggibilità. Inoltre, se vuoi montare in sola lettura anziché in lettura/scrittura, sostituisci rw con ro.)

  5. Una volta completato, è il momento di riavviare il servizio autofs eseguendo questo comando:

    Ubuntu: sudo service autofs restart

    Red Hat: sudo systemctl restart autofs

  6. Ora bisogna verificare che il servizio sia partito correttamente e che non ci siano errori di sintassi, di rete o di altro tipo nell'avvio. Esegui questo comando per controllarne lo stato:

    Ubuntu: sudo service autofs status

    Red Hat: sudo systemctl status autofs

  7. Nell'output del comando precedente dovresti leggere che lo stato è running e che è tutto a posto. In caso contrario, l'output mostrerà le ultime righe dei log per aiutarti nel debug. In coda ho aggiunto anche una sezione con alcuni passaggi di debug di base.

  8. A questo punto puoi usare il comando cd per entrare nelle directory che hai indicato nei file precedenti e accedere alle condivisioni. Nota che non dovrai creare quelle directory: il daemon autofs le crea per te in automatico.

  9. Un'ultima verifica che puoi fare è eseguire il comando mount, che elenca tutti i mount presenti sull'istanza. Un modo semplice per individuare quelli creati da autofs è eseguire il comando mount | grep autofs.

  10. Da qui in poi, i mount verranno caricati automaticamente sul sistema e ricollegati quando necessario.

  11. A questo punto, ti consiglio caldamente di approfondire la sicurezza di NFS, di mettere in sicurezza i tuoi mount e di adottare il metodo di protezione più adatto al tuo utilizzo.


Debug dei problemi più comuni

Mentre imparavo a usarlo, ho incontrato qualche intoppo che voglio elencare insieme al modo in cui l'ho risolto.

Il primo è stato il daemon che restituiva ogni sorta di errore legato alla mancata connessione a NFS. Si è scoperto che Synology antepone il numero del volume al nome della condivisione, cosa che all'epoca non sapevo. L'ho diagnosticato provando a montare manualmente la condivisione NFS in una cartella della mia home directory con questo comando: mkdir tmp_mnt && sudo mount -v -r -o user,nolock,nosuid [server_name]:[share_path] tmp_mnt, che monta la condivisione in una directory locale. Il risultato sarà un esito positivo o un errore che spiega cosa sta succedendo. Per smontarla, esegui il comando sudo umount tmp_mnt.

Un altro errore che ho riscontrato riguardava il server non raggiungibile tramite hostname. Si è rivelato un problema di DNS interno: l'hostname non veniva risolto. L'ho diagnosticato verificando di poter raggiungere la condivisione tramite l'indirizzo IP e poi eseguendo un nslookup hostname per stabilire che l'IP non veniva tradotto nell'hostname. Nota che per questo potrebbe essere necessario installare i pacchetti bind-utils (per Red Hat sudo yum -y install bind-utils) o dnsutils (per Debian sudo apt install -y dnsutils).

L'ultimo problema è specifico di Kubernetes. Da nessun pod del cluster riuscivo ad accedere ad alcun servizio esterno, comprese le condivisioni NFS, che si trovasse al di fuori del cluster. Il motivo era che non riusciva a risolvere l'hostname tramite DNS, perché il cluster non era a conoscenza del mio server DNS interno, posizionato fuori dal cluster. La teoria dietro a tutto questo va ben oltre lo scopo di questa guida, quindi mi limito a fornire una soluzione e un link per approfondire.

  1. Modifica il configmap di CoreDNS con questo comando: kubectl edit configmap coredns -n kube-system.
  2. Si aprirà un editor di testo con il file yaml di CoreDNS; al suo interno c'è una sezione chiamata Corefile con un blocco yaml che inizia con .:53.
  3. Individua il tuo dominio interno. Dipende da come è configurato il tuo server DNS interno; se non ne hai uno, usa semplicemente local.
  4. Individua l'indirizzo IP del tuo server DNS. Se non ne hai uno, con tutta probabilità sarà l'indirizzo IP del tuo router.
  5. Aggiungi il blocco di codice qui sotto, inserendo i tuoi dati, su una nuova riga subito sotto a quel punto (assicurati di usare spazi e non tabulazioni!), salva ed esci dall'editor:

[domain_name]:53 { errors cache 30 forward . [dns_server] }

Per capire meglio perché funziona, trovi maggiori informazioni qui.