Fonctionnalités de la version 4 de NFS

Cette section fournit les descriptions des fonctions qui ont été introduites dans la version 4 de NFS, procédez comme suit :

• Annulation et rétablissement du partage d'un système de fichiers dans la version 4 de NFS

• Système de fichiers d'un espace de noms dans la version 4 de NFS

• Identificateurs de fichiers volatile de la version 4 de NFS

• Récupération d'un client dans la version 4 de NFS

• Prise en charge du partage OPEN dans la version 4 de NFS

• Délégation dans la version 4 de NFS

• Listes de contrôle d'accès (ACL) et nfsmapid dans la version 4 de NFS

Pour toute information sur la configuration des services NFS, reportez-vous à Configuration du service NFS.

Annulation et rétablissement du partage d'un système de fichiers dans la version 4 de NFS

Dans les versions 3 et 4 de NFS, si un client tente d'accéder à un système de fichiers dont le partage a été annulé, le serveur renvoie un code d'erreur. Cependant, avec la version 3 de NFS, le serveur conserve tous les verrous que les clients avaient obtenu avant que l'annulation du partage du système de fichiers. Par conséquent, lorsque le partage du système de fichiers est rétabli, les clients de la version 3 de NFS peuvent accéder au système de fichiers comme si son partage n'avait jamais été annulé.

Avec la version 4 de NFS, lorsqu'un système de fichiers n'est pas partagé, toutes les informations d'état de tout fichier ouvert ou de tout verrou de fichier dans ce système de fichiers sont détruits. Si le client tente d'accéder à ces fichiers ou à ces verrous; il reçoit un message d'erreur. Généralement, cette erreur est signalée comme étant une erreur I/O à l'application. Cependant, le rétablissement du partage d'un système de fichiers partagé pour modifier les options ne détruit aucune information d'état sur le serveur.

Pour plus d'informations sur la récupération de client dans la version 4 de NFS, reportez-vous à Récupération d'un client dans la version 4 de NFS. Pour plus d'informations sur les options disponibles pour la commande unshare, reportez-vous à la page de manuel unshare_nfs(1M).

Système de fichiers d'un espace de noms dans la version 4 de NFS

Les serveurs de la version 4 de NFS créent et mettent à jour un pseudo-système de fichiers qui donne aux clients un accès transparent à tous les objets exportés sur le serveur. Ce pseudo système de fichiers n'existait pas dans les versions antérieures. Les clients devaient monter chaque système de fichiers de serveur partagé pour l'accès.

Un pseudo-système de fichiers est une structure qui contient uniquement des répertoires et est créée par le serveur. Le pseudo-système de fichiers permet à un client de parcourir la hiérarchie des systèmes de fichiers exportés. Par conséquent, la vue du client du pseudo-système de fichiers est limitée aux chemins qui conduisent à systèmes de fichiers exportés.

Les versions précédentes de NFS n'autorisaient pas un client de parcourir les systèmes de fichiers serveur sans monter chaque système de fichiers. Cependant, dans la version 4 de NFS, l'espace de noms de serveur se comporte comme suit :

• Restreint la vue du système de fichiers du client vers des répertoires qui conduisent à des exports de serveur.

• Fournit aux clients un accès continu aux exports de serveur sans nécessiter que le client monte chaque système de fichiers sous-jacent. Toutefois, différents systèmes d'exploitation peuvent nécessiter que le client monte chaque système de fichiers du serveur.

Figure 2-2  Vues du système de fichiers du serveur et du système de fichiers client dans la version 4 de NFS

Dans l'exemple illustré dans la figure, le client ne peut pas voir les répertoires payroll et nfs4x, car ces répertoires ne sont pas exportés et ne mènent pas à des répertoires exportés. Toutefois, le répertoire local est visible pour le client, car local est un répertoire exporté. Le répertoire projects est visible pour le client, car projects mène vers le répertoire exporté, nfs4. Par conséquent, certaines parties de l'espace de noms du serveur qui ne sont pas explicitement exportées sont reliées par un pont avec un pseudo-système de fichiers qui affiche uniquement les répertoires exportés et ceux qui mènent à des exports de serveur.

Identificateurs de fichiers volatile de la version 4 de NFS

Les identificateurs de fichiers sont créés sur le serveur et contiennent des informations qui identifient de manière unique les fichiers et les répertoires. Dans les versions 2 et 3 de NFS, le serveur renvoyait des identificateurs de fichier persistants. Par conséquent, le client pouvait garantir que le serveur génèrerait un identificateur de fichier qui désigne toujours le même fichier. Ainsi,

• Si un fichier est supprimé et remplacé par un autre fichier du même nom, le serveur peut générer un nouvel identificateur de fichier pour le nouveau fichier. Si le client utilise l'ancien identificateur de fichier, le serveur renvoie une erreur d'identificateur de fichier obsolète.

• Si un fichier est renommé, l'identificateur de fichier reste le même.

• Si le serveur a été réinitialisé, les identificateurs de fichiers restent les mêmes.

Par conséquent, lorsque le serveur a reçu une demande d'un client qui comporte un identificateur de fichier, la résolution est simple et l'identificateur de fichier désigne toujours le fichier approprié.

La méthode de à l'aide des identificateurs de fichier persistants pour rechercher des fichiers et répertoires pour les opérations NFS convient à la plupart des serveurs équipés de UNIX. Cependant, elle n'a pas pu être implémentée sur les serveurs s'appuyant sur d'autres méthodes d'identification telles que le chemin d'accès d'un fichier. Pour résoudre ce problème, le protocole de la version 4 de NFS permet à un serveur de déclarer ses identificateurs de fichier comme étant volatiles. Si l'identificateur de fichier est modifié, le client doit trouver le nouvel identificateur.

Comme pour les versions 2 et 3 de NFS, le serveur de la version 4 d'Oracle Solaris NFS fournit toujours des identificateurs de fichier persistants. Toutefois, les clients de la version 4 d'Oracle Solaris NFS qui accèdent à des serveurs non équipés de la version 4 d'Oracle Solaris NFS doivent prendre en charge les identificateurs de fichier volatiles si le serveur les utilise. En particulier, lorsque le serveur communique au client que l'identificateur de fichier est volatile, le client doit mettre en cache le mappage entre le nom du chemin d'accès et l'identificateur de fichier. Le client utilise l'identificateur de fichier volatile jusqu'à ce qu'il expire. Lors de son expiration, le client effectue les opérations suivantes :

• efface les informations mises en cache qui se rapportent à cet identificateur de fichier ;

• recherche le nouvel identificateur de fichier ;

• retente l'opération.

Les identificateurs de fichier volatiles peuvent expirer dans l'une des situations suivantes :

• Lorsque vous fermez un fichier.

• Lorsque le migre identificateur de fichier du système de fichiers

• Lorsqu'un client renomme un fichier.

• Lorsque le serveur se réinitialise.

Si le client n'est pas en mesure de trouver le nouvel identificateur de fichier, un message d'erreur est placé dans le fichier syslog. Les autres tentatives d'accès à ce fichier échouent avec une erreur I/O .

Récupération d'un client dans la version 4 de NFS

Le protocole de la version 4 de NFS est un protocole avec état. Le client et pour le serveur assurent la maintenance des informations sur les ouvrir des fichiers et verrous externes sur les fichiers.

Si un serveur s'arrête brutalement et est réinitialisé, le serveur perd son état. Le client détecte que le serveur s'est réinitialisé et commence le processus pour aider le serveur à redéfinir les états d'ouverture et de verrouillage qui existaient avant la panne. Ce processus est appelé restauration du client, car le client dirige le processus.

Lorsque le client détecte que le serveur s'est réinitialisé, le client suspend immédiatement son activité actuelle et lance le processus de récupération du client. Lorsque le processus de récupération démarre, un message tel que le suivant s'affiche dans le journal d'erreurs système /var/adm/messages :

NOTICE: Starting recovery server server-name

Au cours du processus de récupération, le client envoie les informations du serveur à propos de l'état précédent du client. Cependant, pendant cette période, le client n'envoie pas de nouvelles demandes pour le serveur. Toutes les nouvelles demandes d'ouverture de fichiers ou de définition de verrous de fichiers doit attendre que le serveur termine le processus de récupération avant de poursuivre.

Lorsque la récupération du client est terminée, le message suivant s'affiche dans le journal d'erreurs système /var/adm/messages :

NOTICE: Recovery done for server server-name

A ce moment, le client a terminé l'envoi des informations d'état pour au serveur. Toutefois, même si le client a terminé ce processus, d'autres clients n'ont peut - être pas fait. Par conséquent, pendant une certaine période, appelée délai de grâce, le serveur n'accepte pas les demandes d'ouverture ou de verrouillage pour activer tous les clients de terminer leur processus de récupération.

Au cours de la période de grâce, si le client tente d'ouvrir de nouveaux fichiers ou d'établir de nouveaux verrous, le serveur refuse la demande avec le code d'erreur GRACE. A la réception de l'erreur, le client doit attendre la fin de la période de grâce, puis renvoyer la demande au serveur. Pendant la période de grâce, le message suivant s'affiche :

NFS server recovering

Pendant la période de grâce, les commandes qui n'ouvrent pas les fichiers ou ne définissent pas de verrouillages peuvent s'effectuer. Par exemple, les commandes ls et cd n'ouvrent pas de fichiers ni ne définissent un verrouillage de fichier ; ces commandes ne sont pas suspendues. Toutefois, une commande telle que cat, qui ouvre un fichier, serait suspendue jusqu'à ce que la période de grâce se termine.

Lorsque la période de grâce est terminée, le message suivant s'affiche :

NFS server recovery ok.

Le client peut maintenant envoyer de nouvelles demandes d'ouverture et de verrouillage au serveur.

La récupération du client peut échouer pour diverses raisons. Par exemple, si une partition réseau existe après la réinitialisation du serveur, le client peut ne pas être en mesure de rétablir son état avec le serveur avant la fin de la période de grâce. Lorsque la période de grâce est terminée, le serveur n'autorise pas le client afin de rétablir son état parce que de nouvelles opérations d'état pourraient créer des conflits. Par exemple, un nouveau verrou de fichier peut entrer en conflit avec un ancien verrou de fichier que le client tente de récupérer. Lorsque de telles situations se produisent, le serveur renvoie le code d'erreur NO_GRACE au client.

Si la récupération d'une opération d'ouverture pour un fichier échoue, le client identifie le fichier comme inutilisable et le message suivant s'affiche.

WARNING: The following NFS file could not be recovered and was marked dead 
(can't reopen:  NFS status n):  file :  filename

Si de la redéfinition d'un verrou de fichier échoue pendant la restauration, le message d'erreur suivant s'affiche :

NOTICE: nfs4_send_siglost:  pid process-ID lost
lock on server server-name

Dans cette situation, le signal SIGLOST est publié dans le processus. L'action par défaut pour le signal SIGLOST est de mettre fin au processus.

Pour restaurer à partir de cet état, vous devez redémarrer toutes les applications qui avaient des fichiers ouverts au moment de la panne. Certains processus qui n'ont pas rouvert le fichier peut recevoir des erreurs d' E/S . D'autres processus ont rouvert le fichier, ou ont exécuté l'opération d'ouverture après la restauration après panne, sont en mesure d'accéder au fichier sans aucun problème.

Par conséquent, certains processus peuvent accéder à un fichier en particulier tandis que d'autres processus ne le peuvent pas.

Prise en charge du partage OPEN dans la version 4 de NFS

Le protocole de la version 4 de NFS offre plusieurs modes partage de fichiers que le client peut utiliser pour contrôler l'accès aux fichiers par d'autres clients. Un client peut spécifier les éléments suivants :

• Le mode DENY_NONE donne aux autres clients l'accès en lecture et en écriture à un fichier.

• Le mode DENY_READ refuse aux autres clients l'accès en lecture à un fichier.

• Le mode DENY_WRITE refuse aux autres clients l'accès en écriture à un fichier.

• Le mode DENY_BOTH mode refuse aux autres clients l'accès en lecture et en écriture à un fichier.

Le serveur de la version 4 d'Oracle Solaris NFS effectue une implémentation complète de ces modes de partage de fichier. Par conséquent, si un client tente d'ouvrir un fichier d'une manière qui entre en conflit avec le mode de partage, le serveur refuse la tentative en faisant échouer l'opération. Lorsque de telles tentatives échouent avec le lancement des opérations de création ou d'ouverture, le client de la version 4 de NFS reçoit une erreur de protocole. Cette erreur est mise en correspondance avec l'erreur d'application EACCES.

Même si le protocole offre plusieurs modes de partage, l'opération d'ouverture dans Oracle Solaris n'offre pas plusieurs modes de partage. Lors de l'ouverture d'un fichier, un client de la version 4 d'Oracle Solaris NFS peut uniquement utiliser le mode DENY_NONE.

Délégation dans la version 4 de NFS

La version 4 de NFS fournit à la fois la prise en charge du client et la prise en charge du serveur pour la délégation. La délégation est une technique par laquelle le serveur délègue la gestion d'un fichier à un client. Par exemple, le serveur peut attribuer une délégation de lecture ou d'écriture à un client. Car les délégations de lecture ne sont pas en conflit avec les autres qu'ils peuvent être accordées à plusieurs clients en même temps. Une délégation d'écriture peut être accordée à un seul client, car une telle délégation peut entrer en conflit avec tout autre accès de fichier par tout autre client. Lorsqu'il détient une délégation d'écriture, le client n'enverrait pas diverses opérations sur le serveur car le client est se voit accorder un accès exclusif à un fichier. De même, le client n'envoie pas diverses opérations au serveur tout en détenant une délégation de lecture. La raison est que le serveur garantit qu'aucun client ne peut ouvrir un fichier en mode écriture.

L'effet de la délégation est de réduire considérablement les interactions entre le serveur et le client pour les fichiers délégués. Par conséquent, le trafic réseau est réduit et les performances sur le client et le serveur sont améliorées. Cependant, le degré d'amélioration des performances dépend du type d'interaction de fichier utilisé par une application et la quantité de surcharge sur le réseau ou le serveur.

Un client ne demande pas de délégation. La décision d'accorder ou non une délégation revient exclusivement au serveur basée sur les modèles d'accès pour un fichier. Si ont récemment accédé à un fichier en mode d'écriture différents clients, le serveur peut ne pas accorder de délégation parce qu'ce modèle d'accès indique le potentiel de conflits futurs.

Un conflit survient lorsqu'un client accède à un fichier d'une manière qui n'est pas cohérente avec les délégations actuellement accordées à ce fichier. Par exemple, si un client détient une délégation d'écriture sur un fichier et qu'un deuxième client ouvre ce fichier pour lire ou écrire l'accès, le serveur rappelle la délégation d'écriture du premier client. De même, si un client détient une délégation de lecture et qu'un autre client ouvre le même fichier pour l'écriture, le serveur rappelle la délégation de lecture. Dans les deux cas, le second client ne se voit pas accorder de délégation parce qu'un conflit existe maintenant.

Lorsqu'un conflit survient, le serveur utilise un mécanisme de rappel pour contacter le client qui détient actuellement la délégation. Lors de la réception de ce rappel, le client envoie l'état mis à jour du fichier au serveur et renvoie la délégation. Si le client ne répond pas au rappel, le serveur révoque la délégation. Dans de tels cas, le serveur rejette toutes les opérations provenant du client pour ce fichier, et le client rapporte les opérations demandées comme ayant échoué. En règle générale, ces défaillances sont signalées à l'application comme des erreurs d' E/S . Pour restaurer à partir de ces erreurs, le fichier doit être fermé, puis rouvert. Les échecs de délégations révoquées peuvent se produire lorsqu'une partition de réseau existe entre le client et le serveur, lorsque le client détient une délégation.

Notez qu'un serveur n'est pas en mesure de résoudre les conflits d'accès à un fichier qui est stocké sur un autre serveur. Par conséquent, un serveur NFS résout uniquement les conflits pour les fichiers qu'il stocke. En outre, en réponse aux conflits causés par des clients qui exécutent différentes versions de NFS, un serveur NFS peut uniquement lancer des rappels pour le client qui exécute la version 4 de NFS. Un serveur NFS ne peut pas initier de rappels pour les clients qui exécutent des versions antérieures de NFS.

Le processus de détection des conflits varie. Par exemple, contrairement à la version 4 de NFS, dans la mesure où les versions 2 et 3 n'ont pas de procédure d'ouverture, le conflit n'est détecté qu'après une tentative de lecture, d'écriture ou de verrouillage d'un fichier par un client. La réponse du serveur à ces conflits varie également. Ainsi,

• Pour la version 3 de NFS, le serveur renvoie l'erreur JUKEBOX, ce qui fait que le client interrompt la demande d'accès et réessaie plus tard. Le client affiche le message File unavailable.

• Pour la version 2 de NFS 2, l'équivalent de l'erreur JUKEBOX n'existant pas, le serveur n'envoie aucune réponse, ce qui fait que le client va attendre, puis réessayer. Le client affiche le message NFS server not responding.

Les messages d'erreur supprimées une fois le conflit de délégation les plus brefs délais.

Par défaut, la délégation de serveur est activée. Vous pouvez désactiver la délégation en définissant le paramètre server_delegation sur off.

# sharectl set -p server_delegation=off nfs

Aucun mot de passe n'est requis pour la délégation de client. Le démon de rappel de la version 4 de NFS, nfs4cbd, fournit le service de rappel sur le client. Ce démon démarre automatiquement dès qu'un montage pour la version 4 de NFS est activé. Par défaut, le client fournit les informations de rappel pour le serveur pour tous les transports Internet répertoriés dans le fichier système /etc/netconfig. Si le client est compatible avec IPv6 et que l'adresse IPv6 pour le nom du client peut être déterminée, le démon de rappel accepte les connexions IPv6.

Le démon de rappel utilise un numéro de programme transitoire et un numéro de port attribué de façon dynamique. Ces informations sont fournies au serveur et ce dernier vérifie le chemin de rappel avant d'accorder les délégations. Si la vérification du chemin de rappel échoue, le serveur n'accorde pas de délégations (il s'agit du seul comportement visible de l'extérieur).

Dans la mesure où les informations de rappel sont intégrées à une demande de la version 4 de NFS, le serveur n'est pas en mesure de contacter le client par le biais d'un périphérique qui utilise la méthode NAT (Network Address Translation). En outre, le démon de rappel utilise un numéro de port dynamique. Par conséquent, le serveur peut ne pas être en mesure de traverser un pare-feu, même si ce pare-feu autorise normalement le trafic NFS sur le port 2049. Dans de telles situations, le serveur n'accorde pas de délégations.

Listes de contrôle d'accès (ACL) et nfsmapid dans la version 4 de NFS

Une liste de contrôle d'accès (ACL) assure la sécurité des fichiers en permettant au propriétaire d'un fichier de définir les autorisations de fichier pour un propriétaire du fichier, un groupe et autres utilisateurs et groupes spécifiques. Sur les systèmes de fichiers ZFS, vous pouvez définir les ACL sur le serveur et le client à l'aide de la commande chmod. Pour les systèmes de fichiers UFS, vous pouvez utiliser la commande setfacl. Pour plus d'informations, reportez-vous aux pages de manuel chmod(1) and setfacl(1). Dans la version 4 de NFS, le mappeur d'ID, nfsmapid, est utilisé pour mettre en correspondance un ID d'utilisateur ou de groupe dans les entrées d'ACL sur un serveur et l'ID d'utilisateur ou de groupe dans entrées d'ACL sur un client. L'inverse s'applique aussi : les ID d'utilisateur et de groupe dans les entrées d'ACL doivent exister à la fois sur le client et le serveur.

Pour plus d'informations sur les ACL et nfsmapid, reportez-vous aux documents suivants :

• Chapitre 7, Utilisation des ACL et des attributs pour protéger les fichiers Oracle Solaris ZFS du manuel Gestion des systèmes de fichiers ZFS dans OracleSolaris 11.2

• Démons NFS

Des problèmes de mappage d'ID

Les situations suivantes peuvent provoquer un échec de mappage d'ID :

• Si l'utilisateur ou le groupe existant dans une entrée d'ACL sur le serveur ne peut pas être mis en correspondance avec un utilisateur ou un groupe valide sur le client, l'utilisateur peut consulter l'ACL, mais certains des utilisateurs ou des groupes seront affichés comme unknown.

  Par exemple, dans cette situation, lorsque vous exécutez la commande ls –lv ou ls –lV, le groupe ou l'utilisateur de certaines entrées d'ACL s'affichera comme unknown.

• Si l'ID d'utilisateur ou de groupe dans n'importe quelle entrée d'ACL qui est définie sur le client ne peut pas être mappé vers un ID d'utilisateur ou de groupe valide sur le serveur, les commandes setfacl ou chmod peuvent échouer et renvoyer le message d'erreur Permission denied.

• Si le client et le serveur possèdent des valeurs nfsmapid_domain incompatibles, le mappage d'ID échoue. Pour plus d'informations, reportez-vous à la section Démons NFS

Pour éviter les problèmes de mappage d'ID, procédez comme suit :

• Assurez-vous que la valeur de nfsmapid_domain est correctement définie. Le domaine NFSv4 actuellement sélectionné est disponible dans le fichier /var/run/nfs4_domain.

• Assurez-vous que tous les ID d'utilisateur et de groupe dans les entrées d'ACL existent à la fois sur le client et le serveur de la version 4 de NFS.

Vérification d'ID d'utilisateur ou de groupe non mappé

Pour déterminer si un utilisateur ou un groupe ne peut pas être mappé sur le serveur ou le client, utilisez le script suivant :

#! /usr/sbin/dtrace -Fs

sdt:::nfs4-acl-nobody
{
     printf("validate_idmapping: (%s) in the ACL could not be mapped!", 
stringof(arg0));
}