La version 4 du protocole NFS (RFC3530) a modifié la façon dont les UID ou les GID (identificateurs d'utilisateur ou de groupe) sont échangés entre le client et le serveur. Le protocole exige que le propriétaire d'un fichier et que les attributs de groupe soient échangés entre un client de la version 4 de NFS et un serveur de la version 4 de NFS sous la forme de chaînes comme suit : user@nfsv4-domain ou group@nfsv4-domain respectivement.
Par exemple, l'utilisateur known_user a un UID 123456 sur un client de la version 4 de NFS dont le nom d'hôte pleinement qualifié est system.example.com. Pour que le client envoie des demandes au serveur de la version 4 de NFS, le client doit faire correspondre l'UID 123456 à utilisateur_connu@exemple.com puis envoyer cet attribut au serveur de la version 4 de NFS. Une fois que le serveur reçoit known_user@example.com à partir du client, le serveur met en correspondance la chaîne de caractères et l'UID local 123456, qui est interprété par le système de fichiers sous-jacent. Cette fonctionnalité suppose que chaque UID et GID dans le réseau est unique et que les domaines de la version 4 de NFS sur le client correspondent aux domaines de la version 4 de NFS sur le serveur.
Le client et le serveur de la version 4 de NFS sont tous deux capables d'exécuter des conversions entier-à-chaîne et chaîne-à-entier. Par exemple, en réponse à une opération GETATTR, le serveur de la version 4 de NFS mappe les UID et GID obtenus dans système de fichiers sous-jacent vers leurs représentations sous forme de chaîne respectives et envoie ces informations au client. Le client doit également faire correspondre les UID et GID dans des représentations sous forme de chaîne. Par exemple, en réponse à la commande chown, le client mappe le nouvel UID ou GID vers une représentation sous forme de chaîne avant l'envoi d'une opération SETATTR au serveur.
Notez, cependant, que le client et le serveur répondent différemment aux chaînes non reconnues :
Si l'utilisateur n'existe pas sur le serveur, même au sein d'une même configuration de domaine de la version 4 de NFS, le serveur rejette l'appel de procédure à distance (RPC) et renvoie un message d'erreur pour le client. Cette situation limite les opérations qui peuvent être effectuées par l'utilisateur distant.
Si l'utilisateur existe à la fois sur le client et le serveur, mais que les domaines ne correspondent pas, le serveur rejette les opérations de modification d'attribut (tels que SETATTR) qui nécessitent que le serveur mappe la chaîne d'utilisateur entrante sur une valeur entière que le système de fichiers sous-jacent peut comprendre. Pour que les clients de la version 4 de NFS et les serveurs fonctionnent correctement, leurs domaines de la version 4 de NFS et la partie de la chaîne de caractères après le signe @ doivent correspondre.
Si le client de la version 4 de NFS ne reconnaît pas un nom d'utilisateur ou de groupe à partir du serveur, le client n'est pas en mesure mapper la chaîne vers son ID unique, une valeur entière. Dans de telles circonstances, le client mappe la chaîne de l'utilisateur ou du groupe entrant à l'utilisateur nobody. Cette mise en correspondance avec nobody crée divers problèmes pour différentes applications. Avec la version 4 de NFS, les opérations qui modifient les attributs de fichiers échouent.
Si le serveur ne reconnaît pas le nom d'utilisateur ou de groupe donné, même si les domaines de la version 4 de NFS correspondent, le serveur n'est pas en mesure de mapper le nom de l'utilisateur ou du groupe à son ID unique, une valeur entière. Dans de telles circonstances, le serveur mappe le nom de groupe ou d'utilisateur entrant à l'utilisateur nobody. Pour éviter de telles occurrences, les administrateurs doivent éviter d'établir des comptes spéciaux qui n'existent que sur le client de la version 4 de NFS.
modifier le nom de domaine pour les clients et les serveurs à l'aide de la commande sharectl avec l'option nfsmapid_domain. Cette option définit une pour les clients et les serveurs du domaine commun. Remplace le comportement par défaut de l'utilisation d'un nom de domaine DNS local. Pour plus d'informations sur les tâches, reportez-vous à la sectionConfiguration du service NFS.
Le démon nfsmapid utilise les informations sur la configuration SMF trouvées dans svc:system/name-service/switch et dans svc:/network/dns/client comme suit :
nfsmapid utilise des fonctions de bibliothèque C standard pour les demandes de mot de passe et d'informations de groupe aux services de moteur de traitement de noms. Ces services de noms sont contrôlés par les paramètres dans le service SMF svc:system/name-service/switch. Toutes les modifications apportées aux propriétés du service affectent les opérations nfsmapid. Pour plus d'informations sur le service SMF svc:system/name-service/switch, reportez-vous à la page de manuel nsswitch.conf(4).
Pour assurer que les clients de la version 4 de NFS sont capables de monter les systèmes de fichiers à partir de différents domaines, nfsmapid s'appuie sur la configuration de l'enregistrement de ressource TXT DNS, _nfsv4idmapdomain. Pour plus d'informations sur la configuration de l'enregistrement de ressources _nfsv4idmapdomain , reportez-vous à la rubrique nfsmapid et enregistrements DNS TXT. En outre, notez les points suivants :
L'enregistrement de ressources DNS TXT doit être configuré de manière explicite sur le serveur DNS avec les informations du domaine souhaité.
Le service SMF svc:system/name-service/switch doit être configuré avec les paramètres souhaités pour permettre à la commande resolver d'identifier le serveur DNS et de rechercher les domaines de client et de serveur de la version 4 de NFS dans les enregistrements TXT.
Pour plus d'informations, reportez-vous aux références suivantes :
La page de manuel resolv.conf(4)
Pour que nfsmapid fonctionne correctement, les clients et serveurs de la version 4 de NFS doivent avoir le même domaine. Pour une mise en correspondance correcte des domaines de la version 4 de NFS, nfsmapid suit les règles de priorité strictes suivantes :
Le démon vérifie d'abord si une valeur a été attribuée au paramètre nfsmapid_domain dans le référentiel SMF. Si une valeur est trouvée, celle attribuée est prioritaire sur tous les autres paramètres. La valeur attribuée est ajoutée aux chaînes des attributs sortants et est comparée aux chaînes des attributs entrants. Pour des informations sur les procédures à suivre, reportez-vous à la rubrique Configuration du service NFS.
Si aucune valeur n'a été attribuée à nfsmapid_domain, le démon recherche un nom de domaine dans l'enregistrement DNS TXT sur un serveur de noms DNS. nfsmapid s'appuie sur des directives dans le fichier /etc/resolv.conf et qui sont utilisées par l'ensemble des sous-programmes dans resolver. resolver effectue une recherche dans les serveurs DNS pour les enregistrements de ressources _nfsv4idmapdomain. Notez que l'utilisation des enregistrements DNS TXT est plus évolutive. Pour cette raison, l'utilisation continue des enregistrements TXT est largement préférable à la définition du paramètre dans le référentiel SMF.
Si aucun enregistrement DNS TXT est configuré de manière à fournir un nom de domaine, le démon nfsmapid utilise la valeur indiquée par la directive domain ou search dans le fichier /etc/resolv.conf, avec la directive spécifiée en dernier ayant la priorité.
Dans l'exemple suivant, les deux les directives domain et search sont utilisées. Le démon nfsmapid utilise le premier domaine répertorié après la directive search, qui est example.com.
domain company.example.com search example.com abc.def.com
Si le fichier /etc/resolv.conf n'existe pas, nfsmapid obtient le nom de domaine de la version 4 de NFS en suivant le comportement de la commande domainname. En particulier, si le fichier /etc/defaultdomain existe, nfsmapid utilise le contenu de ce fichier pour le domaine de la version 4 de NFS. Si le fichier /etc/defaultdomain n'existe pas, nfsmapid utilise le nom de domaine qui est fourni par le service de noms configuré du réseau. Pour plus d'informations, reportez-vous à la page de manuel domainname(1M).
L'ubiquité de DNS fournit un mécanisme de stockage et de distribution efficace pour le nom de domaine de la version 4 de NFS. En outre, du fait de l'évolutivité inhérente de DNS, l'utilisation des enregistrements de ressources DNS TXT est la méthode recommandée pour la configuration du nom de domaine de la version 4 de NFS pour les déploiements de grande envergure. Vous devez configurer l'enregistrement TXT _nfsv4idmapdomain au niveau des serveurs DNS au niveau de l'entreprise. Ces configurations assurent que tout client ou serveur de la version 4 de NFS peut trouver son domaine de la version 4 de NFS en parcourant l'arborescence DNS.
L'exemple suivant montre une entrée préférée pour l'activation du serveur DNS pour fournir le nom de domaine de la version 4 de NFS :
_nfsv4idmapdomain IN TXT "abc.def"
Dans cet exemple, le nom de domaine à configurer est la valeur qui est entourée de guillemets. Notez qu'aucun champ ttl n'est spécifié et qu'aucun domaine n'est ajouté à _nfsv4idmapdomain, qui est la valeur dans le champ owner. Cette configuration permet à l'enregistrement TXT d'utiliser l'entrée de la zone ${ORIGIN} de l'enregistrement SOA (Start-Of-Authority). Par exemple, à des niveaux différents de l'espace de noms de domaine, l'enregistrement peut se lire comme suit :
_nfsv4idmapdomain.subnet.example.com. IN TXT "abc.def" _nfsv4idmapdomain.example.com. IN TXT "abc.def"
Cette configuration offre aux clients DNS la souplesse d'utilisation du fichier resolv.conf pour effectuer une recherche dans la hiérarchie de l'arborescence DNS. Voir la page de manuel resolv.conf(4). Cette fonctionnalité fournit une plus grande probabilité de trouver l'enregistrement TXT. Pour encore plus de flexibilité, les sous-domaines DNS de niveau inférieur peuvent définir leurs propres enregistrements de ressources DNS TXT. Cette fonction permet aux sous-domaines DNS de niveau inférieur de remplacer l'enregistrement TXT qui est défini par le domaine DNS de niveau supérieur.
Avant d'attribuer une valeur pour le domaine de la version 4 de NFS de votre réseau, vérifiez si un domaine de la version 4 de NFS a déjà été configuré pour votre réseau. Les exemples suivants constituent des moyens d'identifier le domaine de la version 4 de NFS de votre réseau.
Pour identifier le domaine de la version 4 de NFS à partir d'un enregistrement de ressources DNS TXT, utilisez la commande nslookup ou dig :
L'exemple suivant illustre la sortie pour la commande nslookup :
# nslookup -q=txt _nfsv4idmapdomain Server: 10.255.255.255 Address: 10.255.255.255#53 _nfsv4idmapdomain.company.example.com text = "example.com"
L'exemple suivant illustre la sortie pour la commande dig :
# dig +domain=company.example.com -t TXT _nfsv4idmapdomain ... ;; QUESTION SECTION: ;_nfsv4idmapdomain.company.example.com. IN TXT ;; ANSWER SECTION: _nfsv4idmapdomain.company.example.com. 21600 IN TXT "example.com" ;; AUTHORITY SECTION: ...
Pour plus d'informations sur la configuration d'un enregistrement de ressources DNS TXT, reportez-vous à la section nfsmapid et enregistrements DNS TXT.
Si votre réseau n'est pas configuré avec un enregistrement de ressources DNS TXT de la version 4 de NFS, utilisez la commande suivante pour identifier votre domaine de la version 4 de NFS à partir du nom de domaine DNS :
# egrep domain /etc/resolv.conf domain company.example.com
Si le fichier /etc/resolv.conf n'est pas configuré pour fournir un nom de domaine DNS au client, utilisez la commande suivante pour identifier le domaine à partir de la configuration de domaine du réseau de la version 4 de NFS :
# cat /system/volatile/nfs4_domain example.com
Si vous utilisez un autre service de nommage, tel que NIS, utilisez la commande suivante pour identifier le domaine pour le service de nommage configuré pour votre réseau :
# domainname it.company.example.com
Pour plus d'informations, reportez-vous aux pages de manuel suivantes :
Cette section décrit comment le réseau obtient le domaine par défaut souhaité :
Pour la plupart des versions actuelles, reportez-vous à la section Configuration d'un domaine par défaut de la version 4 de NFS dans la version Solaris 11.
Pour la première version de Solaris 10, reportez-vous à la rubrique Configuration d'un domaine par défaut de la version 4 de NFS dans la version Solaris 10.
Dans la version 11 d'Oracle Solaris NFS, définissez la version de domaine par défaut en tapant la commande suivante :
# sharectl set -p nfsmapid_domain=example.com nfs
Dans la première version Solaris 10 de la version 4 de NFS, si votre réseau comportait plusieurs domaines DNS, mais ne disposait que d'un seul espace de noms UID et GID, tous les clients devaient utiliser une valeur pour nfsmapid_domain. Pour les sites utilisant DNS, nfsmapid résout ce problème en obtenant le nom de domaine à partir de la valeur attribuée à _nfsv4idmapdomain. Pour plus d'informations, reportez-vous à la rubrique nfsmapid et enregistrements DNS TXT. Si le réseau n'est pas configuré pour utiliser DNS, lors de la première initialisation du système, le système d'exploitation utilise l'utilitaire sysidconfig pour générer les invites suivantes pour le nom de domaine de la version 4 de NFS :
This system is configured with NFS Version 4, which uses a domain name that is automatically derived from the system's name services. The derived domain name is sufficient for most configurations. In a few cases, mounts that cross different domains might cause files to be owned by nobody due to the lack of a common domain name. Do you need to override the system's default NFS version 4 domain name (yes/no)? [no]
La réponse par défaut est [no]. Si vous choisissez l'option [no], vous voyez voir le message suivant :
For more information about how the NFS Version 4 default domain name is derived and its impact, refer to the man pages for nfsmapid(1M) and nfs(4), and the System Administration Guide: Network Services.
Si vous choisissez l'option [yes], vous voyez cette invite :
Enter the domain to be used as the NFS Version 4 domain name. NFS Version 4 domain name []:
Pour plus d'informations sur nfsmapid, reportez-vous aux éléments suivants :
Page de manuel nfsmapid(1M)
Page de manuel nfs(4)
http://www.ietf.org/rfc/rfc1464.txthttp://www.ietf.org/rfc/rfc1464.txt
Listes de contrôle d'accès (ACL) et nfsmapid dans la version 4 de NFS