JavaScript is required to for searching.
Ignorer les liens de navigation
Quitter l'aperu
Administration d'Oracle Solaris : Services réseau     Oracle Solaris 11 Information Library (Fran├žais)
search filter icon
search icon

Informations document

Préface

Partie I Sujets relatifs aux services réseau

1.  Service réseau (présentation)

2.  Gestion des serveurs cache Web

3.  Services d'horodatage

Partie II Accès aux systèmes de fichiers réseau

4.  Gestion des systèmes de fichiers NFS (présentation)

5.  Administration de système de fichiers réseau (tâches)

6.  Accès aux systèmes de fichiers réseau (référence)

Fichiers NFS

Fichier /etc/default/le

Fichier /etc/nfs/nfslog.conf

Démons NFS

Démon automountd

Démon lockd

Démon mountd

Démon nfs4cbd

Démon nfsd

Démon nfslogd

Démon nfsmapid

Fichiers de configuration et nfsmapid

Règles de priorité

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

Informations complémentaires sur nfsmapid

Démon reparsed

Démon statd

Commandes NFS

Commande automount

clear_locks, commande

Commande fsstat

Commande mount

Options mount pour les systèmes de fichiers NFS

Utilisation de la commande mount

Commande umount

Commande mountall

Commande umountall

Commande sharectl

Sous-commande set

Sous-commande get

Sous-commande status

Commande share

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

Commande unshare

Commande shareall

Commande unshareall

Commande showmount

Commande setmnt

Commande nfsref

Commandes pour le dépannage des problèmes liés à NFS

Commande nfsstat

Commande pstack

Commande rpcinfo

Commande snoop

Commande truss

NFS sur RDMA

Fonctionnement du service 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

Négociation UDP et TCP

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

Basculement côté client

Terminologie du basculement

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

Fichiers volumineux

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

Système NFS sécurisé

RPC sécurisé

Authentification DH

Authentification KERB

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

Création d'une référence NFS

Suppression d'une référence NFS

Mappes Autofs

Mappe principale Autofs

Point de montage /home

Point de montage /net

Point de montage /nfs4

Mappe directe Autofs

Point de montage /-

Mappe indirecte Autofs

Fonctionnement d'Autofs

Fonctionnement de la navigation par Autofs dans le réseau (mappes)

Démarrage du processus de navigation par autofs (mappe principale)

Processus de montage Autofs

Montage autofs simple

Montage hiérarchique

Démontage autofs

Méthode de sélection par Autofs des fichiers en lecture seule les plus proches pour les clients (plusieurs emplacements)

Autofs et pondération

Variables d'une entrée de mappe Autofs

Mappes faisant référence à d'autres mappes

Mappes Autofs exécutables

Modification de la navigation du réseau par Autofs (modification des mappes)

Comportement par défaut d'Autofs avec les services de noms

Référence Autofs

Autofs et les métacaractères

Esperluette (&)

Astérisque (*)

Autofs et caractères spéciaux

Partie III SLP

7.  SLP (présentation)

8.  Planification et activation de SLP (tâches)

9.  Administration de SLP (tâches)

10.  Intégration des services hérités

11.  SLP (références)

Partie IV Sujets relatifs aux services de messagerie

12.  Services de messagerie (présentation)

13.  Services de messagerie (tâches)

14.  Services de messagerie (référence)

Partie V Sujets relatifs à la mise en réseau série

15.  Solaris PPP 4.0 (Présentation)

16.  Planification de la liaison PPP (tâches)

17.  Configuration d'une liaison PPP commutée (tâches)

18.  Configuration d'une liaison PPP de ligne spécialisée (tâches)

19.  Paramétrage de l'authentification PPP (tâches)

20.  Configuration d'un tunnel PPPoE (tâches)

21.  Résolution des problèmes PPP courants (tâches)

22.  Solaris PPP 4.0 (Référence)

23.  Migration de Solaris PPP asynchrone à Solaris PPP 4.0 (tâches)

24.  UUCP (présentation)

25.  Administration du protocole UUCP (tâches)

26.  UUCP (référence)

Partie VI Utilisation de systèmes distants

27.  Utilisation de systèmes distants (présentation)

28.  Administration du serveur FTP (tâches)

29.  Accès aux systèmes distants (tâches)

Partie VII Sujets relatifs au contrôle des services réseau

30.  Contrôle des performances du réseau (tâches)

Glossaire

Index

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

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 :

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.


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 du délai de grâce pour la récupération de verrous pour la version 3 et la version 4 de NFS.

Le paramètre lockd_retransmit_timeout= délai d'attente 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 délai d'attente.

Le paramètre lockd_servers= nthreads spécifie le nombre maximum de threads simultanés que le serveur peut gérer 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 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é.


Remarque - La version 4 de NFS n'utilise pas ce démon.


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

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.


Remarque - La version 4 de NFS n'utilise pas ce démon.


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.


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 :

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 informations sur la configuration SMF trouvées dans svc:system/name-service/switch et dans svc:/network/dns/client :

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 l'enregistrement DNS TXT. nfsmapid s'appuie sur des directives dans le fichier /etc/resolv.conf 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 nommage 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.


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.


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 plus d'informations, reportez-vous aux pages de manuel suivantes :

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é :

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

Dans la version 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.


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

Remarque - Si une valeur existe pour nfsmapid_domain dans le référentiel SMF, le [domain_name] que vous fournissez remplace cette valeur.


Informations complémentaires sur nfsmapid

Pour plus d'informations sur nfsmapid, reportez-vous aux éléments suivants :

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.


Remarque - La version 4 de NFS n'utilise pas ce démon.