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 multi-utilisateur. 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'entrées qui sont libellées avec le type de système de fichiers NFS dans /etc/dfs/sharetab. 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, mountd 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 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 nœuds 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.

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 en modifiant la chaîne appropriée dans /etc/default/nfs. Vous trouverez ci-après des descriptions des mots-clés qui peuvent être définis dans le fichier/etc/default/nfs.

Tout comme LOCKD_GRACE_PERIOD , GRACE_PERIOD=graceperiod dans /etc/default/nfs 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=délai d'attente dans /etc/default/nfs 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 est de 15 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= nthreads dans /etc/default/nfs spécifie le nombre maximum de threads simultanés que peut gérer le serveur par connexion. Basez la valeur de nthreads sur la charge qui est prévue sur le serveur NFS. La valeur par défaut est 20. Chaque client NFS qui utilise le protocole TCP utilise une connexion unique avec le serveur NFS. Par conséquent, chaque client peut utiliser un maximum de 20 threads simultanés sur le serveur.

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 requêtes 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é.

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 modifiant la chaîne appropriée dans /etc/default/nfs.

Le paramètre NFSD_LISTEN_BACKLOG=longueur dans /etc/default/nfs 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 NFSD_MAX_CONNECTIONS=#-conn dans /etc/default/nfs sélectionne le nombre maximum 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 NFSD_SERVER=nservers dans /etc/default/nfs sélectionne le nombre maximal de demandes simultanées qu'un serveur peut gérer. La valeur par défaut pour nservers est de 16. 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.

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 avec 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 fichiers /etc/nsswitch.conf et /etc/resolv.conf :

• 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 nom sont contrôlés par les paramètres situés dans le fichier /etc/nsswitch.conf. Les modifications apportées au fichier nsswitch.conf affectent les opérations nfsmapid . Pour plus d'informations sur le fichier nsswitch.conf, 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 fichier /etc/resolv.conf doit être configuré avec les paramètres souhaités pour activer resolver afin de trouver 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 :

  • 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. Il vérifie d'abord le fichier /etc/default/nfs pour une valeur attribuée au mot-clé NFSMAPID_DOMAIN. 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 plus d'informations sur les mots-clés dans le fichier /etc/default/nfs, reportez-vous à la rubrique Mots-clés pour le fichier /etc/default/nfs. 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 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 mot-clé dans le fichier /etc/default/nfs.

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 d'attribution 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, voir 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 /var/run/nfs4_domain
  company.com

• Si vous utilisez un autre service d'attribution de noms, tel que NIS, utilisez la commande suivante pour identifier le domaine pour le service d'attribution de nom 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 du domaine par défaut de la version 4 de NFS.

• 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 du domaine par défaut de la version 4 de NFS

Dans la première version de Solaris 10, le domaine était défini lors du premier redémarrage après l'installation du système d'exploitation. Dans les versions ultérieures, le domaine de la version 4 de NFS est défini au cours de l'installation du système d'exploitation. Pour fournir cette fonctionnalité, les fonctions suivantes ont été ajoutées :

• La commande sysidtool inclut le programme sysidnfs4. Le programme s'exécute pendant la phase d'installation afin de déterminer si un domaine de la version 4 de NFS a été configuré pour le réseau. Reportez-vous aux pages de manuel sysidtool(1M) et sysidnfs4(1M).

• Le fichier sysidcfg a un nouveau mot-clé, nfs4_domain. Ce mot-clé peut être utilisé pour définir le domaine de la version 4 de NFS. Notez que d'autres mots-clés peuvent être définis dans le fichier sysidcfg. Reportez-vous à la page de manuel sysidcfg(4).

La section suivante décrit le fonctionnement de la fonctionnalité :

1. Le programme sysidnfs4 vérifie le fichier /etc/.sysIDtool.state afin de déterminer si un domaine de la version 4 de NFS a été identifié.

   • Si le fichier .sysIDtool.state indique qu'un domaine de la version 4 de NFS a été configuré pour le réseau, le programme sysidnfs4 n'effectue pas de contrôles supplémentaires. Voir l'exemple suivant d'un fichier .sysIDtool.state :

     1       # System previously configured?
     1       # Bootparams succeeded?
     1       # System is on a network?
     1       # Extended network information gathered?
     1       # Autobinder succeeded?
     1       # Network has subnets?
     1       # root password prompted for?
     1       # locale and term prompted for?
     1       # security policy in place
     1       # NFSv4 domain configured
     xterms

     Le 1 qui s'affiche avant # NFSv4 domain configured confirme que le domaine de la version 4 de NFS a été configuré.

   • Si le fichier .sysIDtool.state indique qu'aucun domaine de la version 4 de NFS n'a été configuré pour le réseau, le programme sysidnfs4 doit effectuer des contrôles supplémentaires. Voir l'exemple suivant d'un fichier .sysIDtool.state :

     1       # System previously configured?
     1       # Bootparams succeeded?
     1       # System is on a network?
     1       # Extended network information gathered?
     1       # Autobinder succeeded?
     1       # Network has subnets?
     1       # root password prompted for?
     1       # locale and term prompted for?
     1       # security policy in place
     0       # NFSv4 domain configured
     xterms

     Le 0 qui s'affiche avant # NFSv4 domain configured confirme qu'aucun domaine de la version 4 de NFS n'a été configuré.

2. Si aucun domaine de la version 4 de NFS n'a été identifié, le programme sysidnfs4 vérifie le mot-clé nfs4_domain dans le fichier sysidcfg.

   • Si une valeur pour nfs4_domain existe, cette valeur est affectée au mot-clé NFSMAPID_DOMAIN dans le fichier /etc/default/nfs. Notez que toute valeur affectée à NFSMAPID_DOMAIN remplace la fonctionnalité de sélection de domaine dynamique du démon nfsmapid. Pour plus d'informations sur la fonctionnalité de sélection de domaine dynamique de nfsmapid, reportez-vous à la rubrique Règles de priorité.

   • En l'absence d'une valeur pour nfs4_domain, le programme ysidnfs4 identifie le domaine que nfsmapid dérive des services de noms configurés du système d'exploitation. Cette valeur dérivée est présentée en tant que domaine par défaut à une invite de commande interactive qui vous donne la possibilité d'accepter la valeur par défaut ou d'affecter un autre domaine de la version 4 de NFS.

Cette fonctionnalité rend obsolète les suivantes :

• L'exemple de script JumpStart, set_nfs4_domain , qui a été fourni dans le média de distribution initial de Solaris 10 n'est plus nécessaire ni recommandé.

• Le fichier /etc/.NFS4inst_state.domain, qui a été créé par l'implémentation précédente du programme sysidnfs4, n'est plus nécessaire.

Pour obtenir des informations spécifiques sur le processus d'installation de Solaris, reportez-vous aux sections suivantes :

• Guide d’installation d’Oracle Solaris 10 9/10 : installations de base

• Guide d’installation Oracle Solaris 10 9/10 : installations réseau

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(1M) afin de 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 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, au redémarrage, 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éé 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é répertorie uniquement le nom d'hôte, en l'absence de domaine ou d'informations sur 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é à l'aide de 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.