Chapitre 9. Système de fichiers réseau (NFS, Network File System)
Un système de fichiers réseau (ou NFS de l'anglais Network File System), permet aux hôtes distants de monter des systèmes de fichiers sur un réseau et de les utiliser exactement comme des systèmes de fichiers locaux. Ceci permet aux administrateurs système de stocker des ressources sur des serveurs centralisés sur le réseau.
Ce chapitre se concentre sur les concepts fondamentaux de NFS et des références supplémentaires. Pour obtenir des instructions spécifiques sur la configuration et l'exploitation de logiciels clients et serveurs NFS, consultez le chapitre intitulé Système de fichiers réseau (NFS) du Guide d'administration système de Red Hat Enterprise Linux.
9.1. Comment ça marche
À l'heure actuelle, il existe trois versions de NFS. La version 2 de NFS (NFSv2), une version plus ancienne qui est largement prise en charge. La version 3 de NFS (NFSv3) qui a davantage de fonctionnalités, y compris le traitement de fichiers de tailles variables et un meilleur rapportage d'erreurs, mais qui n'est pas entièrement compatible avec les clients NFSv2. La version 4 de NFS (NFSv4) qui inclut la sécurité Kerberos, fonctionne à travers des pare-feu et qui sur Internet, n'a plus besoin de portmapper, prend en charge les ACL et utilise des opérations avec état (ou qualifiées de stateful). Red Hat Enterprise Linux supporte les clients NFSv2, NFSv3 et NFSv4 et lors du montage d'un système de fichiers via NFS, Red Hat Enterprise Linux utilise NFSv4 par défaut, si le serveur le prend en charge.
Toutes les versions de NFS peuvent utiliser le protocole TCP (de l'anglais Transmission Control Protocol ) exécuté sur un réseau IP, sachant qu'il est nécessaire pour NFSv4. NFSv2 et NFSv3 peuvent utiliser le protocole UDP (de l'anglais User Datagram Protocol) exécuté sur un réseau IP pour fournir une connexion réseau sans état (aussi qualifiée de stateless) entre le client et le serveur.
Lors de l'utilisation de NFSv2 ou NFSv3 avec UDP, la connexion UDP stateless dans des conditions normales minimise le trafic réseau, car le serveur NFS envoie un cookie au client une fois que ce dernier est autorisé à accéder au volume partagé. Ce cookie, qui représente une valeur aléatoire stockée côté serveur, est transmis en même temps que les requêtes RPC en provenance du client. Le serveur NFS peut être redémarré sans affecter le client et le cookie reste intact. Ceci étant, le protocole UDP étant sans état (ou stateless), si le serveur s'arrête inopinément, les clients UDP continuent à saturer le réseau de requêtes pour le serveur. Telle est la raison pour laquelle TCP est le protocole préféré lors de la connexion à un serveur NFS.
Lors de l'utilisation de NFSv4, une connexion dite stateful est effectuée et l'authentification Kerberos des utilisateurs et groupes avec des niveaux de sécurité variés est disponible de manière optionnelle. NFSv4 n'a pas d'interaction avec portmapper, rpc.mountd, rpc.lockd et rpc.statd étant donné qu'ils ont été incorporés au noyau. NFSv4 est en écoute sur le port bien connu 2049.
 | Remarque |
|---|---|
TCP est le protocole de transport par défaut pour NFS sous Red Hat Enterprise Linux. Reportez-vous au chapitre intitulé Système de fichiers réseau (NFS) du Guide d'administration système de Red Hat Enterprise Linux afin d'obtenir de plus amples informations sur la connexion aux serveurs NFS à l'aide de TCP. Il est possible d'utiliser le protocole UDP si nécessaire pour des raisons de compatibilité mais il n'est pas recommandé pour une utilisation générale. |
NFS n'effectue d'authentification que lorsqu'un système client tente de monter une ressource NFS partagée. Pour limiter l'accès au service NFS, des enveloppeurs TCP sont employés. Ceux-ci lisent les fichiers /etc/hosts.allow et /etc/hosts.deny pour déterminer si un client particulier doit se voir refuser ou accorder l'accès au service NFS. Pour plus d'informations sur la configuration des contrôles d'accès avec les enveloppeurs TCP, consultez le Chapitre 17.
Une fois que l'accès du client a été autorisé par les enveloppeurs TCP, le serveur NFS se réfère à son fichier de configuration, /etc/exports pour déterminer si le client peut monter l'un des systèmes de fichiers exportés. Dès que l'accès est autorisé, toutes opérations sur les fichiers ou répertoires sont possibles par l'utilisateur.
 | Avertissement |
|---|---|
Lors de l'utilisation de NFSv2 ou NFSv3, qui ne prennent pas en charge l'authentification Kerberos, les privilèges de montage NFS sont accordés à l'hôte client et non pas à l'utilisateur. Ainsi, tout utilisateur sur un hôte client ayant des permissions d'accès peut accéder aux systèmes de fichiers exportés. Lors de la configuration de partages NFS, prêtez une attention particulière aux hôtes qui obtiennent les permissions de lecture/écriture (rw). |
 | Important |
|---|---|
Afin que NFS puisse fonctionner avec une installation par défaut de Red Hat Enterprise Linux dotée d'un pare-feu activé, il est nécessaire que IPTables soit configurée avec le port 2049 en TCP par défaut. Sans une configuration de IPTables, NFS ne peut fonctionner correctement. Le script d'initialisation de NFS et le processus rpc.nfsd permettent désormais la liaison à un port spécifique lors du démarrage du système. Toutefois, cette opération est susceptible de créer des erreurs si le port n'est pas disponible ou entre en conflit avec un autre démon. |
9.1.1. Services requis
Red Hat Enterprise Linux utilise une combinaison de prise en charge de niveau noyau avec des processus démons pour fournir le partage de fichiers NFS. NFSv2 et NFSv3 utilisent les appels de procédure distante (ou RPC de l'anglais Remote Procedure Calls) pour coder et décoder des requêtes entre les clients et les serveurs. Les services RPC sous Linux sont contrôlés par le service portmap. Pour partager ou monter les systèmes de fichiers NFS, les services suivants fonctionnent de concert, selon la version de NFS qui est implémentée :
nfs — Un service qui lance les processus RPC appropriés pour répondre aux requêtes pour les systèmes de fichiers NFS partagés.
nfslock — Un service facultatif qui lance les processus RPC appropriés pour permettre aux clients NFS de verrouiller des fichiers sur le serveur.
portmap — Le service RPC pour Linux ; il répond aux requêtes pour des services RPC et définit des connexions vers le service RPC. Il n'est pas utilisé avec NFSv4.
Les processus RPC suivants facilitent les services NFS :
rpc.mountd — Ce processus reçoit la requête de montage en provenance d'un client NFS et vérifie que le système de fichiers demandé est bien exporté. Ce processus est démarré automatiquement par le service nfs et ne nécessite pas de configuration au niveau de l'utilisateur. Ce processus n'est pas utilisé avec NFSv4.
rpc.nfsd — Ce processus est le serveur NFS. Il fonctionne avec le noyau Linux pour satisfaire les requêtes dynamiques des clients NFS, comme par exemple pour fournir des fils de serveur (ou threads) chaque fois qu'un client NFS se connecte. Ce processus correspond au service nfs.
rpc.lockd — Un processus facultatif qui permet aux clients NFS de verrouiller des fichiers sur le serveur. Il correspond au service nfslock. Ce processus n'est pas utilisé avec NFSv4.
rpc.statd — Ce processus implémente le protocole RPC de Moniteur de statut de réseau (NSM) (de l'anglais Network Status Monitor) qui avertit les clients NFS lorsqu'un serveur est redémarré sans avoir été préalablement arrêté correctement. Ce processus est lancé automatiquement par le service nfslock et ne nécessite pas de configuration au niveau de l'utilisateur. Ce processus n'est pas utilisé avec NFSv4.
rpc.rquotad — Ce processus fournit des informations sur les quotas utilisateur s'appliquant aux utilisateurs distants. Il est lancé automatiquement par le service nfs et ne nécessite pas de configuration au niveau de l'utilisateur.
rpc.idmapd — Ce processus fournit au client et serveur NFSv4 des appels ascendants (aussi appelés upcalls) qui établissent la correspondance entre les noms NFSv4 (qui sont des chaînes se présentant sous la forme utilisateur@domaine) et les UID et GID locaux. Pour que idmapd puisse fonctionner avec NFSv4, /etc/idmapd.conf doit être configuré. Ce service est nécessaire pour une utilisation avec NFSv4.
rpc.svcgssd — Ce processus fournit le mécanisme de transport serveur pour le processus d'authentification (Kerberos Version 5) avec NFSv4. Ce service est nécessaire pour une utilisation avec NFSv4.
rpc.gssd — Ce processus fournit le mécanisme de transport client pour le processus d'authentification (Kerberos Version 5) avec NFSv4. Ce service est nécessaire pour une utilisation avec NFSv4.
9.1.2. NFS et portmap
| Remarque |
|---|---|
La section suivante s'applique seulement aux implémentations de NFSv2 ou NFSv3 nécessitant le service de portmap pour la compatibilité ascendante. |
Le service portmap sous Linux est nécessaire pour orienter les requêtes RPC vers les services appropriés. Les processus RPC s'annoncent à portmap lorsqu'ils démarrent, révélant le numéro de port qu'ils contrôlent et les numéros de programmes RPC qu'ils entendent servir. Le système client contacte alors portmap sur le serveur avec un numéro de programme RPC particulier. Le service portmap redirige ensuite le client vers le numéro de port correct afin de communiquer avec le service souhaité.
Parce que les services utilisant RPC se basent sur portmap pour assurer toutes les connexions avec les requêtes client entrantes, portmap doit être disponible avant le démarrage de chacun de ces services.
Le service portmap utilise des enveloppeurs TCP pour le contrôle d'accès et les règles de contrôle d'accès pour portmap affectent tous les services basés sur RPC. Il est également possible de spécifier chacun des démons RPC NFS devant être affectés par une règle de contrôle d'accès. Les pages de manuel relatives à rpc.mountd et rpc.statd contiennent des informations sur la syntaxe précise de ces règles.
9.1.2.1. Résolution de problèmes liés à NFS et portmap
Parce que portmap fournit la coordination entre les services RPC et les numéros des ports utilisés pour communiquer avec eux, il est utile d'afficher le statut des services RPC actuels à l'aide de portmap lors de la résolution de problèmes. La commande rpcinfo affiche chaque service basé sur RPC avec des numéros de port, un numéro de programme RPC, un numéro de version et un type de protocole IP (TCP ou UDP).
Pour s'assurer que les bons services NFS basés sur RPC sont activés pour portmap, utilisez la commande suivante en tant que super-utilisateur :
rpcinfo -p |
Ci-dessous figure un exemple de sortie de cette commande :
program vers proto port
100000 2 tcp 111 portmapper
100000 2 udp 111 portmapper
100021 1 udp 32774 nlockmgr
100021 3 udp 32774 nlockmgr
100021 4 udp 32774 nlockmgr
100021 1 tcp 34437 nlockmgr
100021 3 tcp 34437 nlockmgr
100021 4 tcp 34437 nlockmgr
100011 1 udp 819 rquotad
100011 2 udp 819 rquotad
100011 1 tcp 822 rquotad
100011 2 tcp 822 rquotad
100003 2 udp 2049 nfs
100003 3 udp 2049 nfs
100003 2 tcp 2049 nfs
100003 3 tcp 2049 nfs
100005 1 udp 836 mountd
100005 1 tcp 839 mountd
100005 2 udp 836 mountd
100005 2 tcp 839 mountd
100005 3 udp 836 mountd
100005 3 tcp 839 mountd |
La sortie ci-dessus montre que les bons services NFS sont en cours d'exécution. Si l'un des services NFS ne démarre pas correctement, portmap sera incapable d'établir la correspondance entre les requêtes RPC provenant du clients pour ce service et le port adéquat. Souvent, i NFS n'est pas présent dans la sortie de rpcinfo, le redémarrage de NFS permet à ces services de s'enregistrer correctement auprès de portmap et de commencer à fonctionner. Pour obtenir de plus amples informations sur le lancement de NFS, reportez-vous à la Section 9.2.
D'autres options utiles sont disponibles pour la commande rpcinfo. Reportez-vous à la page de manuel de rpcinfo afin d'obtenir de plus amples informations.