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�:
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.
