Ignorer les liens de navigation | |
Quitter l'aperu | |
Gestion de systèmes de fichiers réseau dans Oracle Solaris 11.1 Oracle Solaris 11.1 Information Library (Français) |
1. Gestion des systèmes de fichiers NFS (présentation)
2. Administration de système de fichiers réseau (tâches)
3. Accès aux systèmes de fichiers réseau (référence)
Fichiers de configuration et nfsmapid
nfsmapid et enregistrements DNS TXT
Vérification du domaine de la version 4 de NFS
Configuration du domaine par défaut de la version 4 de NFS
Configuration d'un domaine par défaut de la version 4 de NFS dans la version Solaris 11
Configuration d'un domaine par défaut de la version 4 de NFS dans la version Solaris 10
Options mount pour les systèmes de fichiers NFS
Utilisation de la commande mount
Options share non spécifiques aux systèmes de fichiers
Options share spécifiques à NFS
Définition des listes d'accès avec la commande share
Commandes pour le dépannage des problèmes liés à NFS
Négociation de version dans NFS
Fonctionnalités de la version 4 de NFS
Annulation et rétablissement du partage d'un système de fichiers dans la version 4 de NFS
Espace de noms du système de fichiers 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
Motifs d'échecs de mappages d'ID
Prévention des problèmes de mappage d'ID avec les ACL
Vérification d'ID d'utilisateur ou de groupe non mappé
Informations supplémentaires sur les ACL ou nfsmapid
Négociation de la taille de transfert de fichiers
Montage des systèmes de fichiers
Effets de l'option -public et des URL NFS lors du montage
Qu'est-ce qu'un système de fichiers répliqué ?
Basculement et verrouillage NFS
Basculement côté client dans la version 4 de NFS
Fonctionnement de la journalisation du serveur NFS
Fonctionnement du service WebNFS
Fonctionnement de la négociation de sécurité WebNFS
Restrictions WebNFS liées à l'utilisation de navigateur Web
Utilisation du RPC sécurisé avec NFS
Fonctionnement des montages miroir
Cas d'utilisation des montages miroir
Montage d'un système de fichiers à l'aide de montages miroir
Démontage d'un système de fichiers recourant à des montages miroir
Fonctionnement des références NFS
Cas d'utilisation des références NFS
Suppression d'une référence NFS
Fonctionnement de la navigation par Autofs dans le réseau (mappes)
Démarrage du processus de navigation par autofs (mappe principale)
Variables d'une entrée de mappe Autofs
Mappes faisant référence à d'autres mappes
Modification de la navigation du réseau par Autofs (modification des mappes)
Pour prendre en charge les activités NFS, plusieurs démons sont lancés lorsqu'un système passe en niveau d'exécution 3 ou en mode multiutilisateur. Les démons mountd et nfsd sont exécutés sur les systèmes qui sont des serveurs. Le démarrage automatique des démons de serveur dépend de l'existence d'au moins un partage NFS. Pour afficher la liste actuelle des partages NFS, exécutez la commande share -F nfs. Pour prendre en charge le verrouillage de fichiers NFS, les démons lockd et statd sont exécutés sur les clients et serveurs NFS. Toutefois, contrairement aux précédentes versions de NFS, dans la version 4 de NFS, les démons lockd, statd et nfslogd ne sont pas utilisés.
Cette section décrit les démons suivants :
Ce démon gère les demandes de montage et de démontage du service autofs. La syntaxe de la commande est indiquée ci-après.
automountd [ -Tnv ] [ -D nom= valeur ]
La commande se comporte comme suit :
-T active le suivi.
-n désactive la navigation sur tous les noeuds autofs.
-v consigne tous les messages d'état sur la console.
-D nom=valeur remplace la valeur de la variable de mappe de montage automatique indiquée par nom.
La valeur par défaut de la mappe de montage automatique est /etc/auto_master. Utilisez l'option -T pour la résolution de problèmes.
Vous pouvez effectuer à l'aide de la commande sharectl les mêmes spécifications que dans la ligne de commande. Toutefois, à la différence des options de ligne de commande, le référentiel SMF conserve les spécifications après le redémarrage de services, la réinitialisation du système et les mises à niveau du système. Les paramètres suivants peuvent être définis pour le démon automountd.
Enregistre les messages d'état sur la console. Il s'agit de l'équivalent de l'argument -v du démon automountd. La valeur par défaut est false.
Active ou désactive la navigation rotations pour tous les points de montage autofs et est l'équivalent de l'argument -n pour automountd. La valeur par défaut est false.
Développe chaque appel de procédure à distance (RPC) et l'affiche sur une sortie standard. Ce mot-clé est l'équivalent de l'argument -T de la commande automountd. La valeur par défaut est 0. Les valeurs peuvent être comprises entre 0 et 5.
Permet d'attribuer différentes valeurs aux différents environnements. Ce mot-clé est l'équivalent de l'argument -D de la commande automountd. Le paramètre environment peut être utilisé plusieurs fois. Cependant, vous devez utiliser des entrées distinctes pour chaque affectation d'environnement.
Ce démon prend en charge les opérations de verrouillage d'enregistrements sur les fichiers NFS. Le démon lockd gère les connexions RPC entre le client et le serveur pour le protocole NLM (Network Lock Manager). Le démon est démarré normalement sans aucune option. Vous pouvez utiliser trois options avec cette commande. Reportez-vous à la page de manuel lockd(1M). Ces options peuvent être utilisées à partir de la ligne de commande ou lors de la configuration des paramètres à l'aide de la commande sharectl. Vous trouverez ci-après des descriptions des paramètres pouvant être définis.
Remarque - Le mot-clé LOCKD_GRACE_PERIOD et l'option -g sont désapprouvés. Le mot-clé désapprouvé a été remplacé par le nouveau paramètre grace_period. Si les deux mots-clés sont définis, la valeur de grace_period remplace celle de LOCKD_GRACE_PERIOD. Reportez-vous à la description suivante de grace_period.
Comme LOCKD_GRACE_PERIOD, le paramètre grace_period= graceperiod définit le nombre de secondes après une réinitialisation du serveur dont disposent les clients pour récupérer les verrous de la version 3 de NFS, fournis par NLM, ainsi que les verrous de la version 4. Par conséquent, la valeur de grace_period détermine la longueur de la période de grâce pour la récupération de verrou pour la version 3 et la version 4 de NFS.
Le paramètre lockd_retransmit_timeout=timeout sélectionne le nombre de secondes à attendre avant la retransmission d'une demande de verrou au serveur distant. Cette option a une incidence sur le client NFS côté service. La valeur par défaut pour le délai d'attente (timeout) est de 5 secondes. Le fait de diminuer la valeur du délai d'attente valeur peut améliorer le temps de réponse pour les clients NFS sur un réseau "parasité". Cependant, cette modification peut entraîner une charge de serveur supplémentaire en augmentant la fréquence des demandes de verrou externe. Le même paramètre peut être utilisé à partir de la ligne de commande en démarrant le démon avec l'option -t timeout.
Le paramètre lockd_servers= number indique le nombre maximal de demandes lockd simultanées. La valeur par défaut est 1024.
Tous les clients NFS qui utilisent UDP partagent une connexion unique avec le serveur NFS. Dans ces conditions, vous pouvez être amené à augmenter le nombre de threads disponibles pour la connexion UDP. Le minimum serait d'autoriser deux threads pour chaque client UDP. Cependant, ce nombre étant spécifique à la charge de travail sur le client, deux threads par client peuvent être insuffisants. L'inconvénient d'utiliser plus de threads est que lorsque les threads sont utilisés, le serveur NFS utilise davantage de mémoire. Si les threads ne sont jamais utilisés, cependant, l'augmentation de nthreads n'a aucun effet. Le même paramètre peut être utilisé à partir de la ligne de commande en démarrant le démon à l'aide de l'option nthreads.
Ce démon gère les demandes de montage de système de fichiers provenant de systèmes distants et fournit le contrôle d'accès. Le démon mountd consulte /etc/dfs/sharetab afin de déterminer quels systèmes de fichiers sont disponibles pour le montage à distance et les systèmes qui sont autorisés à effectuer le montage à distance. Vous pouvez utiliser les options -v et -r avec cette commande. Reportez-vous à la page de manuel mountd(1M).
L'option -v exécute la commande en mode détaillé. Chaque fois qu'un serveur NFS détermine l'accès à accorder à un client, un message s'affiche sur la console. Les informations générées peuvent s'avérer utiles lorsque vous essayez de déterminer la raison pour laquelle un client ne peut pas accéder à un système de fichiers.
L'option -r refuse toutes les futures demandes de montage à partir des clients. Cette option n'affecte pas les clients qui disposent déjà d'un système de fichiers monté.
En plus des options de ligne de commande, plusieurs paramètres SMF peuvent être utilisés pour configurer le démon mountd.
Définit la version minimale du protocole NFS à utiliser par le client NFS. La valeur par défaut est 2. Les autres valeurs valides incluent 3 ou 4. Reportez-vous à la rubrique Configuration des services NFS.
Définit la version maximale du protocole NFS à utiliser par le client NFS. La valeur par défaut est 4. Les autres valeurs valides incluent 2 ou 3. Reportez-vous à la rubrique Configuration des services NFS.
Le démon nfs4cbd, qui est destiné à l'utilisation exclusive du client de la version 4 de NFS, gère les points d'extrémité de communication pour le programme de rappel de la version 4 de NFS. Le démon n'a aucune interface accessible par l'utilisateur. Pour plus d'informations, reportez-vous à la page de manuel nfs4cbd(1M).
Ce démon gère les autres demandes de systèmes de fichiers clients. Vous pouvez utiliser plusieurs options avec cette commande. Reportez-vous à la page de manuel nfsd(1M) pour obtenir la liste complète. Ces options peuvent être utilisées à partir de la ligne de commande ou en définissant le paramètre SMF approprié avec la commande sharectl.
Le paramètre listen_backlog=length définit la longueur de la file d'attente de connexion sur les transports orientés connexion pour NFS et TCP. La valeur par défaut est 32 entrées. La même sélection peut être effectuée à partir de la ligne de commande en démarrant nfsd avec l'option -l.
Le paramètre max_connections=#-conn sélectionne le nombre maximal de connexions par transport orienté connexion. La valeur par défaut pour #-conn est illimitée. Le même paramètre peut être utilisé à partir de la ligne de commande en démarrant le démon à l'aide de l'option -c #-conn.
Le paramètre servers=nservers sélectionne le nombre maximal de demandes simultanées qu'un serveur peut gérer. La valeur par défaut pour nservers est 1024. La même sélection peut être effectuée à partir de la ligne de commande en démarrant nfsd avec l'option nservers.
Contrairement aux versions plus anciennes de ce démon, nfsd ne génère pas plusieurs copies pour traiter les demandes de traitement simultané. La consultation de la table de processus avec ps indique seulement qu'un seul exemplaire du démon est en cours d'exécution.
En outre, ces paramètres SMF peuvent être utilisés pour configurer le démon mountd. Les paramètres suivants n'ont pas d'équivalent de ligne de commande :
Définit la version minimale du protocole NFS enregistrée et proposée par le serveur. La valeur par défaut est 2. Les autres valeurs valides incluent 3 ou 4. Reportez-vous à la rubrique Configuration des services NFS.
Définit la version maximale du protocole NFS enregistrée et proposée par le serveur. La valeur par défaut est 4. Les autres valeurs valides incluent 2 ou 3. Reportez-vous à la rubrique Configuration des services NFS.
Détermine si la fonction de délégation de la version 4 de NFS est activée pour le serveur. Si cette fonctionnalité est activée, le serveur tente de fournir des délégations pour le client de la version 4 de NFS. Par défaut, la délégation de serveur est activée. Pour désactiver la délégation de serveur, reportez-vous à la rubrique Sélection de versions différentes de NFS sur un serveur. Pour plus d'informations, reportez-vous à la section Délégation dans la version 4 de NFS.
Ce démon fournit la journalisation opérationnelle. Les opérations NFS qui sont enregistrées sur le serveur sont basées sur les options de configuration qui sont définies dans /etc/default/nfslogd. Lorsque la consignation de serveur NFS est activée, les enregistrements de toutes les opérations RPC sur un système de fichiers sélectionné sont écrites dans un fichier tampon par le noyau. Ensuite, nfslogd effectue un post-traitement de ces demandes. Le commutateur de service de noms est utilisé pour mettre en correspondance les UID avec les informations de connexion et les adresses IP avec les noms d'hôte. Le nombre est enregistré si aucune correspondance ne peut être trouvée par l'intermédiaire des services de noms identifiés.
Le mappage des identificateurs de fichiers vers les chemins d'accès est également géré par nfslogd. Le démon effectue un suivi de ces mappages dans une table de mappage fichier-identificateur-chemin d'accès. Une table de correspondance existe pour chaque balise identifiée dans /etc/nfs/nfslogd. Après le post-traitement, les enregistrements sont écrits dans les fichiers journaux au format ASCII.
Remarque - La version 4 de NFS n'utilise pas ce démon.
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_domaine ou group@nfsv4_domaine 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. Le serveur de la version 4 de NFS s'attend à recevoir les attributs de fichier utilisateur et de groupe au format user_or_group@nfsv4_domain. 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.
Remarque - 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.
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. En ce qui concerne les fonctionnalités de la version 4 de NFS, les opérations qui modifient les attributs de fichiers échouent.
Vous pouvez changer le nom de domaine pour les clients et les serveurs à l'aide de la commande sharectl et de l'option suivante.
Définit un domaine commun pour les clients et les serveurs. 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 rubrique Configuration des services NFS.
La section suivante décrit l'utilisation par le démon nfsmapid des informations sur la configuration SMF trouvées dans svc:system/name-service/switch et dans svc:/network/dns/client :
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, consultez les références suivantes :
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 des services NFS.
Remarque - L'utilisation du paramètre NFSMAPID_DOMAIN n'est pas évolutive et n'est pas recommandée pour les déploiements de grande envergure.
Si aucune valeur n'a été attribuée à nfsmapid_domain , le démon recherche un nom de domaine dans un enregistrement de ressources DNS TXT. nfsmapid s'appuie sur des directives dans le fichier /etc/resolv.conf et qui sont utilisées par l'ensemble des routines 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, où les directives domain et search sont toutes deux utilisées, le démon nfsmapid utilise le premier domaine répertorié après la directive search, qui est company.com.
domain example.company.com search company.com foo.bar.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/defaultdomainexiste, 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.
Ce qui suit est un exemple d'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 "foo.bar"
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.yourcorp.com. IN TXT "foo.bar" _nfsv4idmapdomain.yourcorp.com. IN TXT "foo.bar"
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. Reportez-vous à 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.
Remarque - Le domaine qui est spécifié par l'enregistrement TXT peut être une chaîne arbitraire qui ne correspond pas nécessairement au domaine DNS pour les clients et les serveurs qui utilisent la version 4 de NFS. Vous avez la possibilité de ne pas partager les données de la version 4 de NFS avec d'autres domaines DNS.
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 :
Le tableau suivant présente un exemple de sortie pour la nslookup commande :
# nslookup -q=txt _nfsv4idmapdomain Server: 10.255.255.255 Address: 10.255.255.255#53 _nfsv4idmapdomain.example.company.com text = "company.com"
Reportez-vous à cet exemple de sortie pour la commande dig :
# dig +domain=example.company.com -t TXT _nfsv4idmapdomain ... ;; QUESTION SECTION: ;_nfsv4idmapdomain.example.company.com. IN TXT ;; ANSWER SECTION: _nfsv4idmapdomain.example.company.com. 21600 IN TXT "company.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 example.company.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 company.com
Si vous utilisez un autre service de noms, tel que NIS, utilisez la commande suivante pour identifier le domaine pour le service de nommage configuré pour votre réseau :
# domainname it.example.company.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 Oracle Solaris 11, la version par défaut du domaine NFS peut être définie à l'aide de la ligne de commande en saisissant la commande suivante :
# sharectl set -p nfsmapid_domain=example.com nfs
Remarque - Compte tenu de la nature évolutive et omniprésente de DNS, l'utilisation des enregistrements DNS TXT pour la configuration du domaine de déploiements de la version 4 de NFS de grande envergure continue d'être préférée et fortement encouragée. Reportez-vous à la rubrique nfsmapid et enregistrements DNS TXT.
Dans la première version Solaris 10 de la version 4 de NFS, si votre réseau comporte plusieurs domaines DNS, mais ne dispose que d'un seul espace de noms UID et GID, tous les clients doivent 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 SE 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 verion 4 domain name (yes/no)? [no]
La réponse par défaut est [no]. Si vous choisissez l'option [no] , vous pouvez voir les éléments suivants :
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 []:
Remarque - Si une valeur existe pour nfsmapid_domain dans le référentiel SMF, le [domain_name] que vous fournissez remplace cette valeur.
Pour plus d'informations sur nfsmapid, reportez-vous aux éléments suivants :
Page de manuel nfsmapid(1M)
Page de manuel nfs(4)
Listes de contrôle d'accès (ACL) et nfsmapid dans la version 4 de NFS
Le démon reparsed interprète les données associées à un point de réanalyse, qui sont utilisées par les références DFS et NFS sur les serveurs de fichiers SMB et NFS. Ce service est géré par SMF et ne doit pas être démarré manuellement.
Ce démon fonctionne avec lockd afin de fournir des fonctions de récupération en cas d'arrêt brutal au gestionnaire de verrous. Le démon statd permet de suivre les clients qui détiennent les verrous sur un serveur NFS. Si un serveur tombe en panne, à la réinitialisation, statd sur le serveur contacte statd sur le client. Le client statd peut alors tenter de récupérer les verrous sur le serveur. Le client statd informe également le serveur statd lorsqu'un client a subi un blocage afin que les verrous du client sur le serveur puissent être effacés. Vous n'avez aucune option à sélectionner avec ce démon. Pour plus d'informations, reportez-vous à la page de manuel statd(1M).
Dans la version Solaris 7, la manière dont statd suit les clients a été améliorée. Dans toutes les versions Solaris antérieures, statd créait des fichiers dans /var/statmon/sm pour chaque client à l'aide du nom d'hôte non qualifié du client. Cette attribution de noms de fichiers provoquait des problèmes si vous aviez deux clients dans des domaines différents partageant un nom d'hôte, ou si les clients ne résidaient pas dans le même domaine que le serveur NFS. Parce que le nom d'hôte non qualifié liste uniquement le nom d'hôte et aucune information relative au domaine ou à l'adresse IP, l'ancienne version de statd n'avait aucun moyen de faire la distinction entre ces types de clients. Pour résoudre ce problème, statd de Solaris 7 crée un lien symbolique dans /var/statmon/sm vers le nom d'hôte non qualifié en utilisant l'adresse IP du client. Le nouveau lien ressemble à ce qui suit :
# ls -l /var/statmon/sm lrwxrwxrwx 1 daemon 11 Apr 29 16:32 ipv4.192.168.255.255 -> myhost lrwxrwxrwx 1 daemon 11 Apr 29 16:32 ipv6.fec0::56:a00:20ff:feb9:2734 -> v6host --w------- 1 daemon 11 Apr 29 16:32 myhost --w------- 1 daemon 11 Apr 29 16:32 v6host
Dans cet exemple, le nom d'hôte du client est myhost et l'adresse IP du client est 192.168.255.255. Si un autre hôte avec le nom myhost montait un système de fichiers, deux liens symboliques mèneraient au nom d'hôte.
Remarque - La version 4 de NFS n'utilise pas ce démon.