Démons NFS

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 :

• Démon automountd

• Démon lockd

• Démon mountd

• Démon nfs4cbd

• Démon nfsd

• Démon nfslogd

• Démon nfsmapid

• Démon reparsed

• Démon statd

Démon automountd

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.

automountd_verbose

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.

nobrowse

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.

trace

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.

environment

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.

Démon lockd

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.

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.

Démon mountd

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.

client_versmin

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.

client_versmax

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.

Démon nfs4cbd

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).

Démon nfsd

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 :

server_versmin

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.

server_versmax

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.

server_delegation

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.

Démon nfslogd

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.

Démon nfsmapid

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.

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.

nfsmapid_domain

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.

Fichiers de configuration et nfsmapid

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 :

  • Règles de priorité

  • Configuration du domaine par défaut de la version 4 de NFS

  • Page de manuel resolv.conf(4)

Règles de priorité

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 :

1. 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.

   ---

2. 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.

3. 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

4. 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).

nfsmapid et enregistrements DNS TXT

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.

Vérification du domaine de la version 4 de NFS

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 :

• nslookup(1M)

• dig(1M)

• resolv.conf(4)

• domainname(1M)

Configuration du domaine par défaut de la version 4 de NFS

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.

Configuration d'un domaine par défaut de la version 4 de NFS dans la version Solaris 11

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 

Configuration d'un domaine par défaut de la version 4 de NFS dans la version Solaris 10

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 []:

Informations complémentaires sur nfsmapid

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.txt

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

Démon reparsed

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.

Démon statd

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.