File system di rete

File system di rete (NFS)
Famiglia	Protocolli del file system di rete
Funzione	Accesso al file system tramite rete.
Ultima versione	NFSv4
porti	2049
Posizione nello stack del protocollo *
App NFS Presentazione XDR Sessione ONC RPC Trasporto TCP o UDP Rete IP
* secondo il Modello OSI
standard
RFC 1094 (versione 2) RFC 1813 (versione 3) RFC 3530 (versione 4)

Network File System , oNFS , è un protocollo a livello di applicazione , secondo il modello OSI . Viene utilizzato per file system distribuiti in un ambiente di rete di computer locali . Consente a diversi sistemi collegati alla stessa rete di accedere ai file remoti come se fossero locali. È stato originariamente sviluppato nel 1984 da Sun Microsystems , con l'obiettivo di essere indipendente da macchina, sistema operativo e protocollo di trasporto, questo è stato possibile perché è implementato sopra i protocolli XDR .(presentazione) e ONC RPC (sessione). Il protocollo NFS è incluso per impostazione predefinita nei sistemi operativi UNIX e nella maggior parte delle distribuzioni Linux .

• Il sistema NFS è diviso in almeno due parti principali: un server e uno o più client . I client accedono in remoto ai dati archiviati sul server.

• Le workstation locali utilizzano meno spazio su disco perché i dati sono centralizzati in un unico posto ma possono essere consultati e modificati da più utenti, quindi le informazioni non devono essere replicate.

• Gli utenti non devono disporre di una directory "home" su ciascuna delle macchine dell'organizzazione. Le directory home possono essere create sul server NFS in modo da potervi accedere in seguito da qualsiasi macchina sull'infrastruttura di rete.

• I dispositivi di archiviazione come unità floppy, CD-ROM e unità ZIP possono anche essere condivisi sulla rete . Ciò può ridurre l'investimento in tali dispositivi e migliorare l'uso dell'hardware esistente nell'organizzazione.

Tutte le operazioni sui file sono sincrone . Ciò significa che l'operazione viene restituita solo quando il server ha completato tutto il lavoro associato per tale operazione. In caso di richiesta di scrittura, il server scriverà fisicamente i dati su disco e, se necessario, aggiornerà la struttura delle directory, prima di restituire una risposta al client. Ciò garantisce l'integrità dei file.

Architettura

Si supponga che un client NFS (Network File System) tenti di montare una directory presa dal server NFS in una directory locale. Per fare ciò, avrai bisogno del seguente comando:

$sudo mount -t nfs macchina_remota:/home /dir_locale

In questo comando specifichiamo il tipo di file system da montare con -t, la macchina remota e la directory dove andremo a montarlo.

Questo comando riguarda la connessione al demone rpc mountd in esecuzione sulla macchina remota tramite RPC. Il server controlla i permessi del client sulla directory /home dove verrà montato e se li ha, il montaggio viene eseguito come se fosse un qualsiasi altro dispositivo fisico. Una volta terminato il montaggio, quando accedi alla directory del client, accederai alla directory del server remoto.

Quando la directory /local_dir ha già la directory /home della macchina remota montata, gli unici file di protezione in quella directory sono i loro permessi.

Quando si accede ai file nella directory NFS, sul server verrà generata una chiamata RPC al demone rpc nfsd , in cui sono inclusi i parametri corrispondenti all'UID e GID dell'utente e al descrittore di file, con cui verranno verificati i permessi.

Implementazione tipica

Supponendo uno scenario in stile Unix in cui una macchina (il client) deve accedere ai dati archiviati su un'altra macchina (il server NFS):

• Il server implementa processi daemon NFS, eseguiti per impostazione predefinita come nfsd, per rendere i suoi dati genericamente disponibili ai client.
• L'amministratore del server determina cosa rendere disponibile esportando i nomi ei parametri delle directory, solitamente utilizzando il file di configurazione /etc/exports e il comando exportfs.
• La gestione della sicurezza del server garantisce che possa riconoscere e approvare i client convalidati.
• La configurazione di rete del server garantisce che i client appropriati possano negoziare con esso attraverso qualsiasi sistema firewall.
• Il computer client richiede l'accesso ai dati esportati, in genere emettendo un comando di montaggio. Il client chiede al server (rpcbind) quale porta sta utilizzando il server NFS, il client si connette al server NFS (nfsd), nfsd passa la richiesta a mountd.
• Se tutto va bene, gli utenti sulla macchina client possono visualizzare e interagire con i file system montati sul server entro i parametri consentiti.
• Si noti che l'automazione del processo di montaggio NFS può aver luogo, magari usando /etc/fstab e/o strutture di montaggio.

Questo file system viene utilizzato in modo che in una rete locale diversi computer possano accedere ai file e condividerli, in questo modo un computer può accedere alle informazioni di un altro computer come se fosse un disco rigido. NFS si concentra sulla coerenza, presupponendo operazioni di scrittura pesanti che difficilmente saranno molto frequenti.

Uno degli usi principali del protocollo NFS è quello di poter avere tutti i file centralizzati su un unico server. Ciò consentirà di fare a meno delle unità di memoria negli altri computer e di poter accedere in remoto per leggere qualsiasi file o scaricarlo.

È molto utile, soprattutto quando molti utenti dovranno effettuare il login per modificare quei file.

Vantaggio

• Più client possono accedere ai file
• Riduce la necessità di spazio su disco
• Qualsiasi utente può modificare e aggiornare i file
• Compatibilità con molti dispositivi

Svantaggi

• Sicurezza: utilizzare solo su reti sicure e dietro un firewall
• Richiede un sovraccarico elevato per leggere i file
• Non è facile bloccare file o concedere permessi

Client NFS

Il client simula le funzionalità del file system UNIX, integrato direttamente nel kernel. È responsabile del controllo delle richieste dal VFS al server. Invia i blocchi oi file dal server e al server. Quando possibile, memorizza nella cache i blocchi localmente.

Memoria cache

Il modulo client NFS memorizza nella cache i risultati delle operazioni <readwritegetattlookup> e readdir. I clienti sono responsabili del polling del server per verificare la valuta dei dati della cache.

Metodo timestamp per il mantenimento delle cache:

Ogni elemento è contrassegnato con due tempi diversi, uno l'ultima volta che l'elemento è stato convalidato e l'altro l'ultima volta che è stato modificato sul server. Una voce della cache è valida all'istante t se l'ultima volta che è stata convalidata è inferiore all'intervallo di aggiornamento tollerato. Se l'input non è valido si ottiene l'ora in cui è stata modificata l'ultima volta sul server e se è uguale a quella del client allora l'input è valido e l'ora del client viene aggiornata, altrimenti l'input non è valido.

Per ridurre al minimo le chiamate a getattr, quando un valore viene ricevuto dal server di un file, viene applicato a tutte le voci rilevanti in quel file.

Anche con questo ci saranno problemi di coerenza se abbiamo scritture su due client con una differenza di tempo inferiore all'intervallo di aggiornamento tollerato. Per risolvere questo problema dovremo utilizzare il blocco dei file trasformando il file in una sezione critica, ciò si ottiene in NFS tramite il protocollo Network Lock Manager (NLM) .

Server NFS

Il server NFS fa parte del kernel Linux, nei kernel forniti da Debian è compilato come modulo del kernel. La sua interfaccia è definita in RFC 1813.

È responsabile della ricezione delle richieste, che possono essere simili a quelle del modello di file flat o possono simulare quelle del sistema UNIX.

Il server offre anche servizi di montaggio, autenticazione e controllo degli accessi e una cache.

Memoria cache

Esistono due opzioni per mantenere e garantire la coerenza della scrittura:

• write-through : i dati delle operazioni di scrittura vengono memorizzati nella cache e scritti su disco prima di rispondere al client.
• Commit : solo i dati delle operazioni di scrittura vengono memorizzati nella cache. Vengono scritti su disco solo quando viene ricevuta un'operazione di commit.

I demoni essenziali del servizio NFS sono i seguenti:

• rpc.mountd : Demone che gestisce il montaggio remoto. Riceve la richiesta dal client NFS e controlla che il file system sia esportato e, se disponibile, consente le richieste di accesso NFS e fornisce informazioni su di esso ( showmount ).
• rpc.nfsd: demone per il servizio di file. È possibile avviare più copie di questo demone. Utilizza la porta TCP/UDP 2049.
• rpc.portmap : È responsabile di indicare ai client dove si trova il servizio reale sul server. I servizi basati su RPC utilizzano portmap per soddisfare le richieste dei client, quindi questo servizio deve essere prima disponibile. Non viene utilizzato in NFSv4. Per verificare che sia attivo esegui:
  • $ sudo portmap stato
• rpc.lockd : responsabile della fornitura del servizio di blocco dei file per garantirne la coerenza poiché è possibile accedervi contemporaneamente. Funziona sia sul server che sul client.
• rpc.statd : questo demone funziona insieme a lockd per il ripristino da arresti anomali del sistema. Mantiene le informazioni sui processi nei client che hanno blocchi di file di un determinato server. Quando il server NFS recupera, statd informa gli altri client che il server è stato ripristinato e quindi risolvono i blocchi che avevano.

Sicurezza

Se vogliamo che il nostro servizio NFS sia più sicuro, dovremmo prendere in considerazione una serie di dettagli, come ad esempio:

1. Usa i caratteri jolly (metacaratteri) il meno possibile, poiché possiamo dare accesso a più squadre di quanto pensiamo.
2. Utilizzare le regole Iptables (firewall) per limitare l'accesso alle porte utilizzate dai daemon del servizio NFS.
3. L'uso dei file /etc/hosts.allow e /etc/hosts.deny non è obbligatorio, ma è preferibile configurarli per garantire la sicurezza dei dati.
4. Esporta file system leggibili (ro) quando possibile.
5. Il proprietario dei file e delle directory esportati deve essere root poiché è possibile mappare l'UID di root a quello dell'utente nessuno.
6. Prova a rendere i file esportati non scrivibili per il gruppo ( ACL ).
7. Le versioni 2 e 3 di NFS non hanno il controllo dell'accesso per utenti specifici. In essi, quando viene esportato un file system, qualsiasi utente su qualsiasi macchina remota connessa al server NFS può accedere ai dati condivisi. L'unico meccanismo di sicurezza che hanno è usare l'accesso di sola lettura e ridurre tutti gli utenti a uno comune il cui UID e GID specifichiamo.
8. Se l' opzione di esportazione squash non viene utilizzata , qualsiasi utente root sulla macchina client può diventare un utente con accesso privilegiato semplicemente eseguendo il comando: su - . È sempre consigliabile avere qualche opzione di squash attivata .
9. La versione più sicura di NFS è la 4.

<Kerberos>

NFS include l'identità dell'utente per impostazione predefinita nelle richieste al server, ma solo per confrontarla con i permessi di accesso, non la convalida.

Con Kerberos, l'autenticazione dell'utente viene eseguita al momento del montaggio del file system. I risultati di queste autenticazioni vengono archiviati e utilizzati su ogni richiesta NFS. Questo protegge dalla maggior parte degli attacchi.

Versioni NFS

Le principali versioni di NFS sono NFSv2 (RFC 1094), NFSv3 (RFC 1813) e NFSv4 (RFC 3530).

NFS versione 2 è la più utilizzata e supportata dai sistemi operativi, nonché la più vecchia e insicura. La versione 3 è più potente della versione 2 ma non è completamente compatibile con i client della versione precedente. Queste due versioni possono funzionare sia con TCP che con UDP come protocollo di trasporto creando connessioni di rete tra client e server. Il vantaggio dell'utilizzo di UDP è che il traffico di rete è ridotto al minimo, ma se dovesse cadere, i client continuerebbero a inviare messaggi e sarebbe saturo.

In generale, le versioni 2 e 3 di NFS consentono di controllare l'esportazione e il montaggio dei file system in base alla macchina richiedente, ma non all'utente. In altre parole, non è previsto il controllo dell'accesso al file system da parte dell'utente. Solo per squadre. Ciò implica che se un file system viene esportato dal server NFS, è possibile accedervi da qualsiasi utente su una macchina client NFS remota. Gli unici meccanismi di sicurezza rimasti in questo caso sono i permessi di accesso (sola lettura) o l'utilizzo di un solo utente e gruppo. Logicamente, questo limita notevolmente l'idea di condivisione che tutti abbiamo.

Nel caso della versione 4 di NFS questi problemi di sicurezza scompaiono ma, in cambio, ha requisiti di configurazione e servizi aggiuntivi molto più importanti. Ad esempio, nella versione 4 l'uso di meccanismi per l'autenticazione dell'utente è obbligatorio. Per questo, ea seconda del tipo di sicurezza scelto, è richiesto l'utilizzo del servizio Kerberos, la cui missione sarà quella di fungere da server di consegna dei biglietti (KDC) e che dovrà essere configurato e funzionante correttamente prima di configurare il server NFSv4. Questo requisito fornisce sicurezza al servizio NFS in cambio dell'aggiunta di maggiore complessità alla sua configurazione e configurazione.

Un'altra caratteristica importante di NFS4 è l'uso di ACL (Access Control List) in stile Windows che non sono supportati dalle versioni 2 e 3 di NFS. Quando parliamo di ACL ci riferiamo alle autorizzazioni o diritti di accesso che ogni utente ha su un file o una directory e che sono specificati come elenchi modificabili dall'amministratore di sistema.

Vantaggi NFS

• Riducono il rischio che il guasto di una singola apparecchiatura impedisca l'accesso ai dati.
• Forniscono posizioni centralizzate per i dati che dovrebbero o dovrebbero essere condivisi tra tutti gli utenti.
• Semplificano l'accesso ai dati esistenti su sistemi più veloci.
• Offrono l'opportunità di centralizzare le operazioni amministrative, come il backup dei dati ( back-up ).
• Forniscono interoperabilità e flessibilità. Di solito è possibile accedere ai file system di rete da computer che eseguono Linux, Windows, Mac OS X, BeOS, BSD e molti altri. In questo modo è facile utilizzare l'hardware e il software più adatti alle esigenze del desktop e accedere comunque agli stessi dati dall'ambiente del file system di rete.

Svantaggi NFS

• NFSv2 e NFSv3 possono utilizzare UDP come protocollo di trasporto che, essendo una connessione non presidiata, riduce al minimo il traffico di rete, ma se il server NFS dovesse andare inattivo per qualsiasi motivo, i client NFS continuerebbero a inviare richieste al server, producendo l'effetto opposto , che è la saturazione della rete.
• Le versioni 2 e 3 di NFS consentono di controllare l'esportazione e il montaggio dei file system in base alla macchina richiedente, ma non all'utente. In altre parole, non è previsto il controllo dell'accesso al file system da parte dell'utente. Solo per squadre. Ciò implica che se un file system viene esportato dal server NFS, è possibile accedervi da qualsiasi utente su una macchina client NFS remota.
• NFS soffre di alcuni problemi di prestazioni a causa del suo design "stateless" (alcuni di questi problemi sono attenuati nelle ultime versioni di NFS). In particolare, poiché il client presume che un'operazione di scrittura sia completa una volta ricevuto un riconoscimento dal server, il server deve assicurarsi di scrivere ogni blocco su disco prima di rispondere, per evitare discrepanze in caso di arresto anomalo. Ciò introduce un ritardo significativo nel caso di scritture NFS.

Operazioni

Inizialmente NFS supportava 18 procedure per tutte le operazioni di I/O di base. ​ I comandi del protocollo versione 2 sono i seguenti: ]

• NULL : non fa nulla, ma viene utilizzato per eseguire il ping del server e misurare i tempi.
• CREA : crea un nuovo file.
• CERCA : cerca un file nella directory corrente e, se trovato, restituisce un descrittore a quel file più informazioni sugli attributi del file.
• READ e WRITE : primitive di base per accedere al file.
• RENAME : Rinomina un file.
• RIMUOVI : cancella un file.
• MKDIR e RMDIR : crea/cancella sottodirectory.
• READDIR : per leggere l'elenco delle directory.
• GETATTR e SETATTR : restituiscono set di attributi di file.
• LINK : crea un file, che è un collegamento a un file in una directory specificata.
• SYMLINK e READLINK : per creare e leggere, rispettivamente, link simbolici (in una "stringa") ad un file in una directory.
• STATFS : Restituisce le informazioni sul file system.
• ROOT , per andare alla radice (obsoleto nella versione 2).
• WRITECACHE : Riservato per uso futuro.

Nella versione 3 del protocollo, i comandi STATFS, ROOT e WRITECACHE vengono rimossi; e sono stati aggiunti: ]

• ACCESSO : per controllare i permessi di accesso.
• MKNOD : crea un dispositivo speciale.
• READDIRPLUS : Una versione migliorata di READDIR.
• FSSTAT - Restituisce le informazioni sul file system in modo dinamico.
• FSINFO - Restituisce le informazioni sul file system in forma statica.
• PATHCONF : Recupera le informazioni POSIX .
• COMMIT : invia i dati della cache su un server a un sistema di archiviazione stabile.

La versione 4 è stata rilasciata nell'aprile 2003 e non è compatibile con le versioni precedenti. Supporta 41 comandi: NULL, COMPOUND, ACCESS, CLOSE, COMMIT, CREATE, DELEGPURGE, DELEGRETURN, GETATTR, GETFH, LINK, LOCK, LOCKT, LOCKU, LOOKUP, LOOKUPP, NVERIFY, OPEN, OPENATTR, OPEN_CONFIRM, OPEN_DOWNGRADE, PUTFH, PUTPUBFH, PUTROOTFH, READ, READDIR, READLINK, REMOVE, RENAME, RENEW, RESTOREFH, SAVEFH, SECINFO, SETATTR, SETCLIENTID, SETCLIENTID_CONFIRM, VERIFY, WRITE, RELEASE_LOCKOWNER, ILLEGAL. ]

Vedi anche

Argomenti correlati NFS:

• ONC RPC , chiamata di procedura remota utilizzata con NFS.
• XDR , protocollo di presentazione dei dati utilizzato da NFS.
• VFS , file system virtuale.

Altri sistemi:

• AppleTalk
• Samba (software)
• Blocco messaggi server
• Andrea File System
• Secure Shell File System

Collegamenti esterni

• NFS Linux
• Il progetto di documentazione Linux del file system di rete . Guida all'amministrazione della rete Linux, capitolo 14.
• Microsoft finanzia un client NFS v4 open source per Windows
• [1] Santamaria, R. Sistemi distribuiti.
• [2] Ministero dell'Istruzione, della Cultura e dello Sport della Spagna