Système de fichiers réseau

Système de fichiers réseau (NFS)
Famille	Protocoles de système de fichiers réseau
Fonction	Accès au système de fichiers via le réseau.
Dernière version	NFSv4
ports	2049
Emplacement dans la pile de protocoles *
Application NFS Présentation XDR Session RPC ONC Transport TCP ou UDP Rapporter IP
* selon le modèle OSI
normes
RFC 1094 (version 2) RFC 1813 (version 3) RFC 3530 (version 4)

Network File System , ouNFS , est un protocole de couche application , selon le modèle OSI . Il est utilisé pour les systèmes de fichiers distribués dans un environnement de réseau informatique local . Il permet à différents systèmes connectés au même réseau d'accéder à des fichiers distants comme s'ils étaient locaux. Il a été développé à l'origine en 1984 par Sun Microsystems , dans le but d'être indépendant de la machine, du système d'exploitation et du protocole de transport, cela a été possible car il est implémenté au-dessus des protocoles XDR .(présentation) et ONC RPC (session). Le protocole NFS est inclus par défaut dans les systèmes d' exploitation UNIX et la plupart des distributions Linux .

• Le système NFS est divisé en au moins deux parties principales : un serveur et un ou plusieurs clients . Les clients accèdent à distance aux données stockées sur le serveur.

• Les postes de travail locaux utilisent moins d'espace disque car les données sont centralisées en un seul endroit mais peuvent être consultées et modifiées par plusieurs utilisateurs, de sorte que les informations n'ont pas besoin d'être répliquées.

• Les utilisateurs n'ont pas besoin d'avoir un répertoire "home" sur chacune des machines de l'organisation. Des répertoires personnels peuvent être créés sur le serveur NFS afin de pouvoir y accéder ultérieurement à partir de n'importe quelle machine sur l'infrastructure réseau.

• Les périphériques de stockage tels que les lecteurs de disquettes, les CD-ROM et les lecteurs ZIP peuvent également être partagés sur le réseau . Cela peut réduire l'investissement dans de tels appareils et améliorer l'utilisation du matériel existant dans l'organisation.

Toutes les opérations sur les fichiers sont synchrones . Cela signifie que l'opération ne revient que lorsque le serveur a terminé tout le travail associé pour cette opération. En cas de demande d'écriture, le serveur écrit physiquement les données sur le disque et, si nécessaire, met à jour la structure des répertoires, avant de renvoyer une réponse au client. Cela garantit l'intégrité des fichiers.

Architecture

Supposons qu'un client de système de fichiers réseau (NFS) essaie de monter un répertoire provenant du serveur NFS vers un répertoire local. Pour ce faire, vous aurez besoin de la commande suivante :

$sudo mount -t nfs remote_machine:/home /local_dir

Dans cette commande, nous spécifions le type de système de fichiers à monter avec -t, la machine distante et le répertoire où nous allons le monter.

Cette commande concerne la connexion au démon rpc mountd exécuté sur la machine distante via RPC. Le serveur vérifie les permissions du client sur le répertoire /home où il va être monté et s'il les a, le montage s'effectue comme s'il s'agissait de n'importe quel autre périphérique physique. Une fois le montage terminé, lorsque vous accéderez au répertoire client, vous accéderez au répertoire du serveur distant.

Lorsque le répertoire /local_dir contient déjà le répertoire /home de la machine distante, les seuls fichiers de protection de ce répertoire sont leurs autorisations.

Lors de l'accès aux fichiers du répertoire NFS, un appel RPC au démon rpc nfsd sera généré sur le serveur, dans lequel les paramètres correspondant à l'UID et au GID de l'utilisateur et le descripteur de fichier sont inclus, avec lesquels les autorisations seront vérifiées.

Implémentation typique

En supposant un scénario de style Unix où une machine (le client) doit accéder aux données stockées sur une autre machine (le serveur NFS) :

• Le serveur implémente des processus démons NFS, s'exécutant par défaut en tant que nfsd, pour rendre ses données disponibles de manière générique pour les clients.
• L'administrateur du serveur détermine ce qu'il faut rendre disponible en exportant les noms et les paramètres des répertoires, généralement à l'aide du fichier de configuration /etc/exports et de la commande exportfs.
• La gestion de la sécurité du serveur garantit qu'il peut reconnaître et approuver les clients validés.
• La configuration réseau du serveur garantit que les clients appropriés peuvent négocier avec lui via n'importe quel système de pare-feu.
• L'ordinateur client demande l'accès aux données exportées, généralement en exécutant une commande de montage. Le client demande au serveur (rpcbind) quel port le serveur NFS utilise, le client se connecte au serveur NFS (nfsd), nfsd transmet la requête à mountd.
• Si tout se passe bien, les utilisateurs de la machine cliente peuvent afficher et interagir avec les systèmes de fichiers montés sur le serveur dans les limites des paramètres autorisés.
• Notez que l'automatisation du processus de montage NFS peut avoir lieu, peut-être en utilisant /etc/fstab et/ou les installations de montage.

Ce système de fichiers est utilisé pour que, dans un réseau local, différents ordinateurs puissent accéder aux fichiers et les partager, de cette manière, un ordinateur peut accéder aux informations d'un autre ordinateur comme s'il s'agissait d'un disque dur. NFS se concentre sur la cohérence, en supposant des opérations d'écriture lourdes qui ne seront probablement pas très fréquentes.

L'une des principales utilisations du protocole NFS est de pouvoir centraliser tous les fichiers sur un seul serveur. Cela permettra de se passer d'unités de mémoire dans les autres ordinateurs et de pouvoir accéder à distance pour lire n'importe quel fichier ou le télécharger.

C'est très utile, surtout lorsque de nombreux utilisateurs doivent se connecter pour modifier ces fichiers.

avantage

• Plusieurs clients peuvent accéder aux fichiers
• Réduit le besoin d'espace disque
• Tout utilisateur peut modifier et mettre à jour les fichiers
• Compatibilité avec de nombreux appareils

Désavantages

• Sécurité : à utiliser uniquement sur des réseaux sécurisés et derrière un pare-feu
• Nécessite une surcharge élevée pour lire les fichiers
• Il n'est pas facile de bloquer des fichiers ou de donner des autorisations

Client NFS

Le client simule les fonctionnalités du système de fichiers UNIX, directement intégré au noyau. Il est chargé de contrôler les requêtes du VFS au serveur. Envoyez les blocs ou les fichiers du serveur et vers le serveur. Lorsque cela est possible, il met en cache les blocs localement.

Mémoire cache

Le module client NFS met en cache les résultats des opérations <readwritegetattlookup> et readdir. Les clients sont chargés d'interroger le serveur pour vérifier l'actualité de leurs données de cache.

Méthode d'horodatage pour maintenir les caches :

Chaque élément est étiqueté avec deux heures différentes, l'une la dernière fois que l'élément a été validé et l'autre la dernière fois qu'il a été modifié sur le serveur. Une entrée de cache est valide à l'instant t si l'instant t de sa dernière validation est inférieur à l'intervalle de rafraîchissement toléré. Si l'entrée n'est pas valide, l'heure à laquelle elle a été modifiée pour la dernière fois sur le serveur est obtenue et si elle est égale à celle du client, alors l'entrée est valide et l'heure du client est mise à jour, sinon l'entrée est invalide.

Pour minimiser les appels à getattr, lorsqu'une valeur est reçue du serveur d'un fichier, elle est appliquée à toutes les entrées pertinentes de ce fichier.

Même avec cela, il y aura des problèmes de cohérence si nous avons des écritures sur deux clients avec une différence de temps inférieure à l'intervalle de rafraîchissement toléré. Pour résoudre ce problème, nous devrons utiliser le verrouillage de fichier en transformant le fichier en une section critique, ceci est réalisé dans NFS via le protocole Network Lock Manager (NLM) .

Serveur NFS

Le serveur NFS fait partie du noyau Linux, dans les noyaux fournis par Debian, il est compilé en tant que module du noyau. Son interface est définie dans la RFC 1813.

Il est chargé de recevoir les requêtes, qui peuvent être similaires à celles du modèle de fichier plat ou simuler celles du système UNIX.

Le serveur propose également des services de montage, d'authentification et de contrôle d'accès, ainsi qu'un cache.

Mémoire cache

Il existe deux options pour maintenir et assurer la cohérence de l'écriture :

• écriture immédiate : les données des opérations d'écriture sont mises en cache et écrites sur le disque avant de répondre au client.
• Commit : les données des opérations d'écriture sont mises en cache uniquement. Ils ne sont écrits sur le disque qu'à la réception d'une opération de validation.

Les démons essentiels du service NFS sont les suivants :

• rpc.mountd : Démon qui gère le montage à distance. Il reçoit la demande du client NFS et vérifie que le système de fichiers est exporté et, s'il est disponible, autorise les demandes d'accès NFS et fournit des informations à ce sujet ( showmount ).
• rpc.nfsd : démon de service de fichiers. Plusieurs copies de ce démon peuvent être démarrées. Il utilise le port TCP/UDP 2049.
• rpc.portmap : Il est chargé d'indiquer aux clients où se trouve le vrai service sur le serveur. Les services basés sur RPC utilisent portmap pour répondre aux demandes des clients, ce service doit donc être disponible en premier. Il n'est pas utilisé dans NFSv4. Pour vérifier qu'il est actif, exécutez :
  • État de la carte de port $ sudo
• rpc.lockd : chargé de fournir le service de verrouillage des fichiers pour assurer leur cohérence puisqu'ils peuvent être accédés simultanément. Il fonctionne à la fois sur le serveur et sur le client.
• rpc.statd : Ce démon fonctionne en conjonction avec lockd pour récupérer des plantages du système. Il conserve des informations sur les processus des clients qui ont des verrous de fichiers d'un certain serveur. Lorsque le serveur NFS récupère, statd informe les autres clients que le serveur a récupéré et résolvent ainsi les verrous qu'ils avaient.

Sécurité

Si nous voulons que notre service NFS soit plus sécurisé, nous devons prendre en compte une série de détails, tels que :

1. Utilisez le moins possible de caractères génériques (métacaractères), car nous pouvons donner accès à plus d'équipes que nous ne le pensons.
2. Utilisez les règles Iptables (pare-feu) pour limiter l'accès aux ports utilisés par les démons de service NFS.
3. L'utilisation des fichiers /etc/hosts.allow et /etc/hosts.deny n'est pas obligatoire, mais il est préférable de les configurer pour assurer la sécurité des données.
4. Exportez les systèmes de fichiers lisibles (ro) dans la mesure du possible.
5. Le propriétaire des fichiers et répertoires exportés doit être root puisqu'il est possible de faire correspondre l'UID de root à celui de l'utilisateur personne.
6. Essayez de rendre les fichiers exportés non inscriptibles pour le groupe ( ACL ).
7. Les versions 2 et 3 de NFS n'ont pas de contrôle d'accès pour des utilisateurs spécifiques. Dans ceux-ci, lorsqu'un système de fichiers est exporté, n'importe quel utilisateur sur n'importe quelle machine distante connectée au serveur NFS peut accéder aux données partagées. Le seul mécanisme de sécurité dont ils disposent consiste à utiliser un accès en lecture seule et à réduire tous les utilisateurs à un utilisateur commun dont nous spécifions l'UID et le GID.
8. Si l' option d'exportation squash n'est pas utilisée , n'importe quel utilisateur root sur la machine cliente peut devenir un utilisateur avec un accès privilégié en exécutant simplement la commande : su - . Il est toujours conseillé d'avoir une option de squash activée .
9. La version la plus sécurisée de NFS est la 4.

<Kerberos>

NFS inclut l'identité de l'utilisateur par défaut dans les requêtes au serveur, mais uniquement pour la comparer avec les autorisations d'accès, il ne la valide pas.

Avec Kerberos, l'authentification de l'utilisateur est effectuée au moment du montage du système de fichiers. Les résultats de ces authentifications sont stockés et utilisés sur chaque requête NFS. Cela protège contre la plupart des attaques.

Versions NFS

Les principales versions de NFS sont NFSv2 (RFC 1094), NFSv3 (RFC 1813) et NFSv4 (RFC 3530).

La version 2 de NFS est la plus largement utilisée et prise en charge par les systèmes d'exploitation, ainsi que la plus ancienne et la moins sécurisée. La version 3 est plus puissante que la version 2 mais n'est pas entièrement compatible avec les clients des versions précédentes. Ces deux versions peuvent fonctionner avec TCP et UDP comme protocole de transport créant des connexions réseau entre le client et le serveur. L'avantage d'utiliser UDP est que le trafic réseau est minimisé, mais s'il venait à chuter, les clients continueraient à envoyer des messages et il serait saturé.

En général, les versions 2 et 3 de NFS vous permettent de contrôler l'exportation et le montage des systèmes de fichiers en fonction de la machine demandeuse, mais pas de l'utilisateur. En d'autres termes, le contrôle d'accès au système de fichiers par l'utilisateur n'est pas envisagé. Uniquement pour les équipes. Cela implique que si un système de fichiers est exporté à partir du serveur NFS, il peut être accessible par n'importe quel utilisateur sur une machine cliente NFS distante. Les seuls mécanismes de sécurité restants dans ce cas sont les autorisations d'accès (lecture seule) ou l'utilisation d'un utilisateur et d'un groupe uniquement. Logiquement, cela limite grandement l'idée de partage que nous avons tous.

Dans le cas de la version 4 de NFS ces problèmes de sécurité disparaissent mais, en contrepartie, il a des exigences de configuration beaucoup plus importantes et des services supplémentaires. Par exemple, dans la version 4, l'utilisation de mécanismes d'authentification des utilisateurs est obligatoire. Pour cela, et selon le type de sécurité choisi, l'utilisation du service Kerberos est nécessaire, dont la mission sera de fonctionner comme un serveur de distribution de tickets (KDC) et qui doit être configuré et fonctionner correctement avant de configurer le serveur NFSv4. Cette exigence fournit la sécurité au service NFS en échange de l'ajout de plus de complexité à sa configuration et à son installation.

Une autre caractéristique importante de NFS4 est l'utilisation d'ACL (listes de contrôle d'accès) de style Windows qui ne sont pas prises en charge par les versions 2 et 3 de NFS. Lorsque nous parlons d'ACL, nous nous référons aux autorisations ou droits d'accès que chaque utilisateur possède sur un fichier ou un répertoire et qui sont spécifiés sous forme de listes modifiables par l'administrateur système.

Avantages NFS

• Ils réduisent le risque que la panne d'un seul équipement empêche l'accès aux données.
• Ils fournissent des emplacements centralisés pour les données qui devraient ou devraient être partagées entre tous les utilisateurs.
• Ils simplifient l'accès aux données existantes sur des systèmes plus rapides.
• Ils offrent la possibilité de centraliser les opérations administratives, telles que la sauvegarde des données ( back-ups ).
• Ils offrent interopérabilité et flexibilité. Les systèmes de fichiers réseau sont généralement accessibles à partir d'ordinateurs exécutant Linux, Windows, Mac OS X, BeOS, BSD et bien d'autres. De cette manière, il est facile d'utiliser le matériel et les logiciels les plus adaptés aux exigences du poste de travail, tout en accédant toujours aux mêmes données à partir de l'environnement du système de fichiers réseau.

Inconvénients de NFS

• NFSv2 y NFSv3 pueden utilizar UDP como protocolo de transporte que al ser una conexión desatendida, minimiza el tráfico de red, pero si el servidor NFS cayera por cualquier circunstancia, los clientes NFS seguirían enviando peticiones al servidor produciendo el efecto contrario, que es la saturación du réseau.
• Les versions 2 et 3 de NFS vous permettent de contrôler l'exportation et le montage des systèmes de fichiers en fonction de la machine demandeuse, mais pas de l'utilisateur. En d'autres termes, le contrôle d'accès au système de fichiers par l'utilisateur n'est pas envisagé. Uniquement pour les équipes. Cela implique que si un système de fichiers est exporté à partir du serveur NFS, il peut être accessible par n'importe quel utilisateur sur une machine cliente NFS distante.
• NFS souffre de certains problèmes de performances en raison de sa conception "sans état" (certains de ces problèmes sont atténués dans les dernières versions de NFS). En particulier, comme le client suppose qu'une opération d'écriture est terminée une fois qu'il reçoit un accusé de réception du serveur, le serveur doit s'assurer qu'il écrit chaque bloc sur le disque avant de répondre, pour éviter les écarts en cas de plantage. Cela introduit un retard important dans le cas des écritures NFS.

Opérations

NFS prenait initialement en charge 18 procédures pour toutes les opérations d'E/S de base. ​ Les commandes de la version 2 du protocole sont les suivantes : ]

• NULL : ne fait rien, mais est utilisé pour envoyer un ping au serveur et mesurer les temps.
• CRÉER : Crée un nouveau fichier.
• RECHERCHE : Recherche un fichier dans le répertoire courant et, s'il est trouvé, renvoie un descripteur de ce fichier ainsi que des informations sur les attributs du fichier.
• READ et WRITE : primitives de base pour accéder au fichier.
• RENAME : Renommer un fichier.
• REMOVE : supprimer un fichier.
• MKDIR et RMDIR : créer/supprimer des sous-répertoires.
• READDIR : pour lire la liste des répertoires.
• GETATTR et SETATTR : renvoient des ensembles d'attributs de fichier.
• LINK : Crée un fichier, qui est un lien vers un fichier dans un répertoire spécifié.
• SYMLINK et READLINK : pour créer et lire, respectivement, des liens symboliques (dans une "chaîne") vers un fichier dans un répertoire.
• STATFS : renvoie les informations sur le système de fichiers.
• ROOT , pour aller à la racine (obsolète dans la version 2).
• WRITECACHE : Réservé pour une utilisation future.

Dans la version 3 du protocole, les commandes STATFS, ROOT et WRITECACHE sont supprimées ; et les éléments suivants ont été ajoutés : ]

• ACCES : Pour vérifier les autorisations d'accès.
• MKOD : Créer un appareil spécial.
• READDIRPLUS : Une version améliorée de READDIR.
• FSSTAT - Renvoie dynamiquement les informations du système de fichiers.
• FSINFO - Renvoie les informations du système de fichiers sous forme statique.
• PATHCONF : Récupère les informations POSIX .
• COMMIT : Envoie les données du cache sur un serveur vers un système de stockage stable.

La version 4 est sortie en avril 2003 et n'est pas rétrocompatible. Prend en charge 41 commandes : 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, SUPPRIMER, RENOMMER, RENOUVELER, RESTOREFH, SAVEFH, SECINFO, SETATTR, SETCLIENTID, SETCLIENTID_CONFIRM, VERIFY, WRITE, RELEASE_LOCKOWNER, ILLEGAL. ]

Voir aussi

Rubriques liées à NFS :

• ONC RPC , appel de procédure à distance utilisé avec NFS.
• XDR , protocole de présentation des données utilisé par NFS.
• VFS , système de fichiers virtuel.

Autres systèmes :

• Apple Talk
• Samba (logiciel)
• Bloc de messages du serveur
• Système de fichiers Andrew
• Système de fichiers Shell sécurisé

Liens externes

• Linux NFS
• Le projet de documentation Linux du système de fichiers réseau . Guide d'administration réseau Linux, chapitre 14.
• Microsoft finance un client Open Source NFS v4 pour Windows
• [1] Santamaria, R. Systèmes distribués.
• [2] Ministère de l'éducation, de la culture et des sports d'Espagne