Formats des noms de machine¶

Une machine seule

Vous pouvez indiquer un hôte, soit par un nom abrégé reconnu par le mécanisme de résolution, soit par le nom de domaine pleinement qualifié, soit par une adresse IPv4, ou soit par une adresse IPV6. Les adresses IPv6 ne doivent pas être entre crochets dans /etc/exports pour ne pas être confondues avec les caractères de classe jokers correspondants.

Réseaux IP

Il est aussi possible de partager des répertoires avec toutes les machines d'un (sous) réseau IP. Il suffit d'indiquer une paire adresse IP / masque de réseau (adresse/masque), en utilisant le format décimal pointé, ou la longueur du masque CIDR. On peut donc ajouter soit « /255.255.252.0 » soit « /22 » à l'adresse IPv4 du réseau pour obtenir un sous-réseau avec 10 bits pour la partie machine. Les adresses IPv6 doivent utiliser une longueur de masque contiguës et ne doivent pas être à l'intérieur des crochets pour éviter la confusion avec les caractères de classe jokers. En général, les caractères jokers ne fonctionnent pas avec les adresses IP, bien que cela arrive accidentellement quand les recherches inverses de DNS (« reverse DNS lookups ») échouent.

Caractères jokers

Les noms de machine peuvent contenir les caractères jokers * et ?, ou peuvent contenir des listes de classes de caractères entre [crochets]. Cela sert à rendre le fichier exports plus compact. Par exemple, *.cs.toto.edu indique toutes les machines du domaine cs.toto.edu. Puisque les jokers peuvent aussi remplacer les points dans un nom de domaine, ce motif correspondra aussi à toute machine de n'importe quel sous-domaine de cs.toto.edu.

Groupes de machines

Les groupes de machines NIS peuvent être utilisés (tels que @group). Seul le nom court de machine de chacun des membres du groupe est utilisé pour la vérification. Les noms de machines vides, ou ceux contenant un simple tiret (-) sont ignorés.

Anonymement

Ceci est spécifié par un simple caractère * ( ne pas le confondre avec le wildcard entré précédemment) qui correspondra à tous les clients.

Si un client correspond à plusieurs des configurations ci-dessus, alors la première correspondance dans l'ordre de la liste ci-dessus a la priorité - indépendamment de l'ordre d'apparition sur la ligne d'exportation. Toutefois, si un client correspond à plus d'une spécification (par exemple deux groupes réseau), alors la première correspondance dans l'ordre d'apparition sur la ligne d'exportation a la priorité.

Sécurité RPCSEC_GSS¶

sec=

L'option sec=, suivie d'une liste de niveaux de sécurité (délimités par des virgules), limite le partage aux clients qui utilisent cette sécurité. Les niveaux de sécurité disponibles sont sys (pas de sécurité cryptographique, par défaut), krb5 (authentification seulement), krb5i (protection de l'intégrité) et krb5p (protection de la confidentialité). En ce qui concerne la négociation des niveaux de sécurité, l'ordre est important ; et les niveaux préférés doivent être listés en premier. La position de l'option sec= par rapport aux autres options n'a pas d'influence, sauf si ces options s'appliquent différemment selon le niveau de sécurité. Dans ce cas, il faudra utiliser de multiples options sec=, et les options qui suivent ne s'appliqueront alors qu'à ce niveau de sécurité. Les seules options utilisables dans ce cas de figure sont ro, rw, no_root_squash, root_squash, et all_squash.

Options générales¶

secure

Cette option impose l'utilisation d'un port réservé (« IPPORT_RESERVED », inférieur à 1024) comme origine de la requête. Cette option est activée par défaut. Pour la désactiver, utilisez insecure.

rw

Permettre les requêtes en lecture et en écriture sur le volume NFS. Le comportement par défaut est d'interdire toute requête qui modifierait le système de fichiers, mais on peut aussi l'indiquer avec l'option ro.

async

Permettre au serveur NFS de transgresser le protocole NFS en répondant aux requêtes avant que tous les changements impliqués par la requête en cours n'aient été effectués sur le support réel (par exemple, le disque dur).

L'utilisation de cette option améliore généralement les performances, mais au risque de perdre ou de corrompre des données en cas de redémarrage brutal d'un serveur, suite à un plantage par exemple.

sync

Ne répondre aux requêtes qu'après l'exécution de tous les changements sur le support réel (voir async plus haut).

Dans toutes les versions de nfs-utils jusqu'à la 1.0.0 (incluse), async était l'option par défaut. Dans toutes les versions postérieures à 1.0.0, le comportement par défaut est sync, et async doit être explicitement indiquée si vous en avez besoin. Afin d'aider les administrateurs systèmes à prêter attention à cette modification, exportfs affichera un message d'avertissement si ni sync ni async ne sont précisées.

no_wdelay

Cette option est sans effet si async est déjà active. Le serveur NFS va normalement retarder une requête d'écriture sur disque s'il suspecte qu'une autre requête en écriture liée à celle-ci est en cours ou peut survenir rapidement. Cela permet l'exécution de plusieurs requêtes d'écriture en une seule passe sur le disque, ce qui peut améliorer les performances. En revanche, si un serveur NFS reçoit principalement des petites requêtes indépendantes, ce comportement peut réellement diminuer les performances. no_wdelay permet de désactiver cette option. On peut explicitement forcer ce comportement par défaut en utilisant l'option wdelay.

nohide

Cette option est basée sur l'option de même nom fournie dans le NFS d'IRIX. Normalement, si un serveur partage deux systèmes de fichiers dont un est monté sur l'autre, le client devra explicitement monter les deux systèmes de fichiers pour obtenir l'accès complet. S'il ne monte que le parent, il verra un répertoire vide à l'endroit où l'autre système de fichiers est monté. Ce système de fichiers est « caché ».

Définir l'option nohide sur un système de fichiers empêchera de le cacher, et tout client convenablement autorisé pourra alors se déplacer du système de fichiers parent à celui-ci sans s'en apercevoir.

Cependant, quelques clients NFS ne sont pas adaptés à cette situation. Il est alors possible, par exemple, que deux fichiers d'un système de fichiers vu comme unique aient le même numéro d'inœud.

L'option nohide ne concerne actuellement que les partages vers les hôtes seuls. Elle ne fonctionne pas de manière fiable avec les groupes de machines, sous-réseaux et ceux utilisant les caractères jokers.

Cette option peut être très pratique dans certains cas, mais elle doit être utilisée avec parcimonie, et seulement après vérification de la capacité du système client à bien gérer cette situation.

The option can be explicitly disabled for NFSv2 and NFSv3 with hide.

This option is not relevant when NFSv4 is use. NFSv4 never hides subordinate filesystems. Any filesystem that is exported will be visible where expected when using NFSv4.

crossmnt

This option is similar to nohide but it makes it possible for clients to access all filesystems mounted on a filesystem marked with crossmnt. Thus when a child filesystem "B" is mounted on a parent "A", setting crossmnt on "A" has a similar effect to setting "nohide" on B.

With nohide the child filesystem needs to be explicitly exported. With crossmnt it need not. If a child of a crossmnt file is not explicitly exported, then it will be implicitly exported with the same export options as the parent, except for fsid=. This makes it impossible to not export a child of a crossmnt filesystem. If some but not all subordinate filesystems of a parent are to be exported, then they must be explicitly exported and the parent should not have crossmnt set.

The nocrossmnt option can explictly disable crossmnt if it was previously set. This is rarely useful.

no_subtree_check

Cette option neutralise la vérification de sous-répertoires, ce qui a des implications subtiles au niveau de la sécurité, mais peut améliorer la fiabilité dans certains cas.

Si un sous-répertoire d'un système de fichiers est partagé, mais que le système de fichiers ne l'est pas, alors chaque fois qu'une requête NFS arrive, le serveur doit non seulement vérifier que le fichier accédé est dans le système de fichiers approprié (ce qui est facile), mais aussi qu'il est dans l'arborescence partagée (ce qui est plus compliqué). Cette vérification s'appelle subtree_check.

Pour ce faire, le serveur doit ajouter quelques informations sur l'emplacement du fichier dans le « filehandle » (descripteur de fichier) qui est donné au client. Cela peut poser problème lors d'accès à des fichiers renommés alors qu'un client est en train de les utiliser (bien que dans la plupart des cas simples, cela continuera à fonctionner).

La vérification de sous-répertoires est également utilisée pour s'assurer que des fichiers situés dans des répertoires auxquels seul l'administrateur a accès ne sont consultables que si le système de fichiers est partagé avec l'option no_root_squash (voir ci-dessous), et ce, même si les fichiers eux-mêmes offrent un accès plus généreux.

D'une façon générale, un système de fichiers des répertoires personnels (« home directories »), qui est normalement partagé à sa racine et qui va subir de multiples opérations de renommage de fichiers, devrait être partagé sans contrôle de sous-répertoires. Un système de fichiers principalement en lecture seule, et qui donc ne verra que peu de modifications de noms de fichiers (/usr ou /var par exemple) et pour lequel des sous-répertoires pourront être partagés, le sera probablement avec la vérification des sous-répertoires.

On peut explicitement forcer ce comportement par défaut de vérification des sous-répertoires en indiquant l'option subtree_check.

À partir de la version 1.1.0 de nfs-utils, le réglage par défaut sera no_subtree_check car la vérification des sous-répertoires (subtree_checking) pose souvent plus de problèmes qu'elle n'en résout. Si vous voulez vraiment activer la vérification des sous-répertoires, vous devez explicitement indiquer cette option dans le fichier exports. Si vous ne précisez rien, exportfs vous avertira de la modification.

insecure_locks

no_auth_nlm

Cette option (les deux noms sont synonymes) indique au serveur NFS de ne pas exiger l'authentification des requêtes de verrouillage (c.-à-d. les requêtes qui utilisent le protocole NLM). Normalement le serveur de NFS doit exiger d'une requête de verrouillage qu'elle fournisse une accréditation pour un utilisateur qui a accès en lecture au fichier. Avec cette option, aucun contrôle d'accès ne sera effectué.

Les premières implémentations de clients NFS n'envoyaient pas d'accréditations lors de requêtes de verrouillage, et nombre de clients NFS encore utilisés sont basés sur ces anciennes implémentations. Utilisez cette option si vous constatez que vous ne pouvez verrouiller que les fichiers en lecture pour tous (« world readable »).

Par défaut, les demandes d'authentification des requêtes NLM se comportent comme si les options (synonymes !) auth_nlm ou secure_locks avaient été fournies. On peut cependant écrire explicitement ces options.

mountpoint=chemin

mp

Cette option permet de ne partager un répertoire que si son montage a réussi. Si aucun chemin n'est précisé (par exemple mountpoint ou mp) alors le partage doit également être un point de montage. Si ce n'est pas le cas, alors le partage n'est pas fait. Ceci vous permet d'être sûr que le répertoire d'un point de montage ne sera jamais partagé par accident si, par exemple, le montage du système de fichiers échouait suite à une erreur de disque dur.

Si un chemin est précisé (c.-à-d. mountpoint=/chemin ou mp=/chemin), le chemin indiqué doit être un point de montage pour le partage qui est fait.

fsid=num|root|uuid

NFS a besoin de reconnaître chaque système de fichiers qu'il offre en partage. Habituellement, il utilisera un UUID pour ce système de fichiers (si le système de fichiers en dispose) ou de l'identifiant du périphérique qui héberge ce système de fichiers (si le système de fichiers est stocké sur un périphérique).

Puisque tous les systèmes de fichiers ne sont pas toujours stockés sur des périphériques, et qu'ils n'ont pas toujours un UUID, il sera parfois nécessaire d'indiquer comment NFS identifiera un système de fichiers. C'est le rôle de l'option fsid=.

Dans NFSv4, un système de fichiers particulier est la racine de tous les systèmes de fichiers partagés. Il est défini par fsid=root ou fsid=0, qui veulent tous deux dire exactement la même chose.

Les autres systèmes de fichiers peuvent être identifiés avec un entier court, ou un UUID qui doit comporter 32 caractères hexadécimaux et une ponctuation arbitraire.

Les versions du noyau Linux 2.6.20 et précédentes ne comprennent pas les réglages UUID, l'utilisation d'un entier court est donc nécessaire pour définir l'option fsid. La définition conjointe d'un petit nombre et d'un UUID est possible pour une même configuration, ce qui rend possible l'utilisation avec d'anciens ou de nouveaux noyaux.

nordirplus

This option will disable READDIRPLUS request handling. When set, READDIRPLUS requests from NFS clients return NFS3ERR_NOTSUPP, and clients fall back on READDIR. This option affects only NFSv3 clients.

refer=chemin@serveurNFS[+serveurNFS][:chemin@serveurNFS[+serveurNFS]]

Un client qui se connecte à ce partage se verra proposer le choix d'une autre adresse de système de fichiers parmi celles fournies dans cette liste (Notez que le serveur doit absolument avoir un point de montage sur cette destination, bien qu'il ne soit pas nécessaire qu'il s'agisse d'un système de fichiers différent. Ainsi, mount --bind /chemin /chemin suffit).

replicas=chemin@serveurNFS[+serveurNFS][:chemin@serveurNFS[+serveurNFS]]

Si le client demande d'autres adresses pour ce partage, cette liste de possibilités lui sera proposée (Notez que le mécanisme effectif de réplication du système de fichiers doit être géré ailleurs).

pnfs

This option allows enables the use of pNFS extension if protocol level is NFSv4.1 or higher, and the filesystem supports pNFS exports. With pNFS clients can bypass the server and perform I/O directly to storage devices. The default can be explicitly requested with the no_pnfs option.

Correspondance d'ID utilisateur (« User ID Mapping »)¶

Bien souvent, il n'est pas souhaitable que l'administrateur d'une machine cliente soit également traité comme le superutilisateur lors de l'accès à des fichiers du serveur NFS. À cet effet, l'UID 0 est normalement transformé (« mapped ») en utilisateur différent : le prétendu utilisateur anonyme ou UID nobody. C'est le mode de fonctionnement par défaut (appelé « root squashing »), qui peut être désactivé grâce à no_root_squash.

Par défaut, exportfs choisit un UID et un GID de 65534 pour l'accès « squash ». Ces valeurs peuvent également être définies par les options anonuid et anongid. Enfin, vous pouvez faire correspondre toutes les demandes des utilisateurs avec l'UID anonyme en indiquant l'option all_squash.

Voici la liste complète des options de correspondance (« mapping ») :

root_squash

Transformer les requêtes d'UID/GID 0 en l'UID/GID anonyme. Notez que ceci ne s'applique à aucun autre UID ou GID qui pourrait également être sensible, tel que l'utilisateur bin ou le groupe staff par exemple.

no_root_squash

Désactiver la transformation du superutilisateur. Cette option est principalement utile pour les clients sans disque dur.

all_squash

Transformer tous les UID/GID en l'utilisateur anonyme. Utile pour les répertoires FTP publics partagés en NFS, les répertoires de spool de news, etc. L'option inverse est no_all_squash, qui est celle par défaut.

anonuid et anongid

Ces options définissent explicitement l'UID et le GID du compte anonyme. Cette option est principalement utile pour des clients PC/NFS, dans le cas où vous souhaiteriez que toutes les requêtes semblent provenir d'un seul et même utilisateur. Consultez par exemple la ligne définissant le partage pour /home/joe dans la section EXEMPLES ci-dessous, qui attribue toutes les requêtes à l'utilisateur 150 (qui est censé être celui de l'utilisateur Joe).

Tables d'exportation supplémentaire¶