Provided by: manpages-fr_4.18.1-1_all bug

NOM

       rrpc.statd - Démon du service NSM

SYNOPSIS

       rpc.statd [-dh?FLNvV] [-H programme] [-n mon_nom] [-o port-source]
                 [-p port-écoute] [-P chemin]
                 [--nlm-port port] [--nlm-udp-port port]

DESCRIPTION

       Les  systèmes  de  fichiers  ne peuvent garder de manière persistante l’état du système de
       fichiers. L’état des verrous est donc perdu lors du redémarrage de l'hôte.

       Les systèmes de fichiers en réseau doivent détecter si un  état  verrouillé  est  perdu  à
       cause  du  redémarrage de l'hôte distant. Après le redémarrage d'un client NFS, le serveur
       NFS doit enlever tous les verrous de fichiers posés par des  applications  qui  tournaient
       sur  ce  client. Après un redémarrage du serveur, un client doit rappeler au serveur quels
       étaient les fichiers verrouillés par ses applications.

       Dans les versions 2 (RFC1094) et 3 (RFC1813) de NFS, on utilise le protocole NSM  (Network
       Status  Monitor)  pour notifier les redémarrages aux pairs. Sous Linux, le service NSM est
       constitué de deux composants tournant en espace utilisateur :

       rpc.statd
              Un démon qui écoute les avertissements de redémarrage d'autres  hôtes  et  gère  la
              liste des hôtes qui doivent être avertis quand le système local redémarre.

       sm-notify
              Un programme d'aide qui avertit les pairs NFS après un redémarrage du système local

       Le  gestionnaire  de verrous NFS local indique au rpc.statd local quels sont les pairs qui
       doivent être surveillés. Quand le système local redémarre, la commande  sm-notify  avertit
       le  service  NSM des hôtes surveillés de son redémarrage. Quand un hôte distant redémarre,
       ce pair notifie le rpc.statd local, qui en retour renvoie l'avertissement  de  redémarrage
       au gestionnaire de verrous NFS local.

OPÉRATIONS NSM DANS LE DÉTAIL

       La  première interaction visant à verrouiller un fichier entre le client et le serveur NFS
       fait intervenir les deux gestionnaires de verrous NFS  qui  contactent  leur  service  NSM
       local afin de stocker des informations sur le pair distant. Sous Linux, le gestionnaire de
       verrous local contacte rpc.statd.

       rpc.statd enregistre les informations sur  chaque  pair  NFS  surveillé  dans  un  fichier
       persistant.  Ce  fichier  décrit  la  manière  de  contacter  un  pair  distant  en cas de
       redémarrage local, comment reconnaître quel pair  surveillé  notifie  son  redémarrage  et
       comment  notifier  au  gestionnaire  de  verrous  local  qu’un pair surveillé signifie son
       redémarrage.

       Un client NFS envoie un nom d'hôte, appelé nom_d'appel (« caller_name ») du  client,  pour
       chaque  demande  de  verrou  de  fichier.  Un serveur NFS peut utiliser ce nom d'hôte pour
       envoyer des appels  GRANT  asynchrones  au  client  ou  pour  avertir  le  client  de  son
       redémarrage.

       Le  serveur  NFS  Linux  peut  fournir  le  nom_d'appel  du client ou son adresse réseau à
       rpc.statd. Pour les besoins du protocole NSM, ce nom (ou cette adresse)  est  connu  comme
       nom_monit  du  pair  observé.  En  même  temps, le gestionnaire de verrous local indique à
       rpc.statd son propre nom d'hôte supposé. Pour les besoins du protocole NSM, ce nom  d'hôte
       est appelé mon_nom.

       Il  n'existe  pas d'interaction équivalente entre un serveur et un client NFS informant le
       client de son nom_d'appel sur le serveur. C'est la raison pour laquelle le client  NFS  ne
       connaît pas réellement le nom_monit qui sera utilisé dans une requête SM_NOTIFY. Le client
       NFS Linux utilise le nom d'hôte du serveur donné à la commande mount  pour  identifier  le
       serveur NFS qui redémarre.

   Notification de redémarrage
       Quand  le système local redémarre, la commande sm-notify lit sur un stockage persistant la
       liste des pairs surveillés et envoie une requête SM_NOTIFY au  service  NSM  tournant  sur
       chacun des pairs listés. Il utilise la chaîne nom_monit comme destination. Pour identifier
       l'hôte ayant redémarré, la commande sm-notify envoie la chaîne mon_nom enregistrée lors de
       la  surveillance  du  poste  distant.  Le démon rpc.statd distant utilise cette chaîne (ou
       l'adresse réseau de l'appelant) pour  lier  les  requêtes  SM_NOTIFY  entrantes  à  un  ou
       plusieurs pairs sur sa propre liste de surveillance.

       Si  rpc.statd  ne  trouve  pas  un  pair dans sa propre liste d'hôtes surveillés lié à une
       requête SM_NOTIFY, la notification n'est pas transmise au gestionnaire de  verrous  local.
       En  plus,  chaque  pair possède son propre numéro d'état NSM, un entier de 32 bits qui est
       changé après chaque redémarrage par la commande sm-notify.  rpc.statd  utilise  ce  nombre
       pour séparer les redémarrages réels des notifications ré-envoyées.

       Une  partie  de  la  récupération de verrous NFS est la redécouverte des pairs qui doivent
       être à nouveaux surveillés. La commande sm-notify nettoie la liste de surveillance stockée
       sur un stockage permanent après chaque redémarrage.

OPTIONS

       -d, --no-syslog
              En conjonction avec l'option -F, demande à rpc.statd d'envoyer ses messages vers la
              sortie d'erreur standard plutôt que vers le journal système.

       -F, --foreground
              Force rpc.statd à rester dans son terminal de contrôle pour permettre de surveiller
              directement,  ou à l'aide d'un débogueur, les opérations NSM. Si cette option n'est
              pas donnée, rpc.statd passe en arrière-plan après son démarrage.

       -h, -?, --help
              Demande à rpc.statd de montrer les options d'utilisation  sur  la  sortie  d'erreur
              standard puis de quitter.

       -H, --ha-callout programme
              Indique  un  programme  d'appel de haute disponibilité. Si cette option est laissée
              vide, aucun appel  n'est  indiqué.  Référez-vous  à  la  section  Appels  de  haute
              disponibilité ci-dessous pour plus de détails.

       -L, --no-notify
              Empêche  rpc.statd  de  lancer  la commande sm-notify lors de son démarrage, ce qui
              conserve le numéro d'état NSM existant et la liste des machines surveillées

              NB : La commande sm-notify a un mécanisme de vérification qui assure qu'elle  n'est
              lancée  qu'une fois après chaque redémarrage du système. Cela permet d'éliminer les
              fausses notifications de redémarrage si rpc.statd est relancé sans l'option -L.

       -n, --name addrip | nomhôte
              Cette chaîne est aussi utilisée par la commande sm-notify comme  adresse  source  à
              partir de laquelle sont émises les requêtes de notification de redémarrage.

              L'addrip peut être donnée sous la forme d’adresse IPv4 ou IPv6. Si cette option est
              omise, rpc.statd utilise une adresse joker comme adresse de lien pour le transport.
              Consultez sm-notify(8) pour plus de détails.

       -N     Demande  à  rpc.statd  de  lancer  la  commande sm-notify, puis de quitter. Puisque
              sm-notify peut être lancée directement, cette option n'est donc plus d'actualité.

       -o, --outgoing-port port
              Indique le numéro du port source que la commande sm-notify doit utiliser quand elle
              envoie  les  notifications de redémarrage. Référez-vous à sm-notify(8) pour plus de
              détails.

       -p, --port port
              Indique le numéro de port utilisé pour les sockets d'écoute RPC.  Si  cette  option
              est omise, rpc.statd essayera de consulter /etc/services. S’il réussit à obtenir un
              port, il initialisera le même  port  pour  tous  les  sockets  d'écoute,  sinon  il
              choisira un port aléatoire et éphémère pour chaque socket d'écoute.

              Cette  option  peut être utilisée pour indiquer le numéro de port sur les écouteurs
              quand les requêtes SM_NOTIFY doivent traverser un pare-feu entre les clients et les
              serveurs.

       -T, --nlm-port port
              Indique  le numéro de port que lockd doit écouter pour des requêtes NLM. Cela règle
              à la fois les ports TCP et UDP à moins que le port UDP soit défini séparément.

       -U, --nlm-udp-port port
              Indique le numéro de port UDP que lockd doit écouter pour les requêtes NLM.

       -P, --state-directory-path chemin
              Précise le nom du répertoire parent où se trouvent les informations sur l'état NSM.
              Si l'option n'est pas précisée, rpc.statd utilise /var/lib/nfs par défaut.

              Après  le démarrage, rpc.statd essaie de définir les UID et GID effectifs à ceux du
              groupe  et  d’utilisateur  du  sous-répertoire  sm  de  ce  répertoire.  Après   la
              modification des identifiants effectifs, rpc.statd a seulement besoin d’accéder aux
              fichiers sm et sm.bak dans le chemin du répertoire d’états (state-directory-path).

       -v, -V, --version
              Demande à rpc.statd d'afficher sa version sur la sortie d'erreur standard  puis  de
              quitter.

FICHIER DE CONFIGURATION

       La  plupart des options pouvant être indiquées sur la ligne de commande peuvent aussi être
       contrôlées à l’aide de valeurs définies dans les sections [statd] ou, dans  certains  cas,
       [lockd]  du  fichier de configuration /etc/nfs.conf. Les valeurs reconnues dans la section
       [statd] incluent port, outgoing-port, state-directory-path et ha-callout qui  ont  chacune
       le même effet que l’option de même nom.

       Les valeurs reconnues dans la section [lockd] incluent port et udp-port qui ont chacune le
       même effet, respectivement, que les options --nlm-port et --nlm-udp-port.

SÉCURITÉ

       Le démon rpc.statd doit être lancé en tant que superutilisateur pour  avoir  le  droit  de
       créer  des  sockets  sur des ports source privilégiés et pour accéder à la base de données
       d'informations d'états. Afin d'éviter les risques d'attaque par  augmentation  de  droits,
       risques  accentués  par  le fait que rpc.statd est un service tournant longtemps, ce démon
       abandonne les droits de superutilisateur dès son démarrage.

       Dans le cas normal, l'ID  utilisateur  effectif  utilisé  est  celui  du  propriétaire  du
       répertoire  d'état,  cela  afin de lui permettre de continuer à accéder aux fichiers de ce
       répertoire après l’abandon des droits de superutilisateur. Pour contrôler l'ID utilisateur
       que  rpc.statd  prend,  il  suffit  d'utiliser  chown(1)  pour  changer le propriétaire du
       répertoire d'état.

       Vous  pouvez  aussi  protéger  vos  écouteurs  rpc.statd  en  utilisant  la   bibliothèque
       tcp_wrapper  ou  iptables(8). Si vous voulez utiliser la bibliothèque tcp_wrapper, ajoutez
       les noms d'hôte des pairs dont l'accès est autorisé dans /etc/hosts.allow. Le nom du démon
       sera statd, même si l'exécutable rpc.statd porte un nom différent.

       Pour  avoir  plus  d'informations,  jetez  un  œil  sur  les pages de manuel de tcpd(8) et
       hosts_access(5).

NOTES COMPLÉMENTAIRES

       La récupération des verrous après redémarrage est essentielle au maintien  de  l'intégrité
       des  données  et  pour  éviter  des  blocages non nécessaires d'applications. Afin d'aider
       rpc.statd à faire correspondre les requêtes SM_NOTIFY aux requêtes NLM, un certain  nombre
       de bonnes pratiques doivent être respectées. Par exemple :

              Le  nom  du nœud UTS de vos systèmes doit correspondre au nom DNS que les pairs NFS
              utilisent pour les contacter.

              Les noms de nœuds UTS de vos systèmes doivent toujours être  des  noms  de  domaine
              pleinement qualifiés (« FQDN »).

              Les  translations  DNS  directes  et  inverses  des  noms de nœuds UTS doivent être
              cohérentes.

              Le nom d'hôte utilisé par le client pour monter le  serveur  doit  correspondre  au
              nom_monit utilisé dans les requêtes SM_NOTIFY qu’il envoie.

       Démonter  un  système  de  fichiers  NFS  n'empêche  pas le client NFS ou le serveur de se
       surveiller. Les deux peuvent continuer à se surveiller pendant un  moment  au  cas  où  la
       reprise  du trafic entre les deux entraînerait de nouveaux montages et d'autres verrous de
       fichiers.

       Sous Linux, et en conditions normales d'opération, le  déchargement  du  module  lockd  du
       noyau  entraîne l'arrêt de la surveillance des pairs NFS. Cela peut survenir, par exemple,
       sur un client NFS utilisant un  système  de  montage  automatique  qui  démonte  tous  les
       systèmes NFS suite à une inactivité.

   Appels de haute disponibilité
       rpc.statd  peut  lancer  un  programme  d'appel  spécifique lors d'un traitement réussi de
       requêtes SM_MON, SM_UNMON et SM_NUMON_ALL ou de  réception  d’un  SM_NOTIFY.  Ce  type  de
       programme  peut  être  utilisé dans des environnements NFS de haute disponibilité (HA-NFS)
       pour chercher les états de verrou qui pourraient avoir besoin d'être  migrés  suite  à  un
       redémarrage du système.

       Le  nom  du  programme  d'appel  peut être indiqué par l'option -H. Le programme doit être
       lancé avec 3 arguments. Le premier est add-client, del-client ou sm-notify selon la raison
       de  l’appel. Le deuxième est le nom_monit du pair observé. Le troisième est le nom_d'appel
       du  gestionnaire  de  blocage  appelant  pour  add-client  ou  del-client,   sinon   c’est
       l’adresse_IP  de  l’appelant  envoyant  SM_NOTIFY. Le quatrième est la valeur_état dans la
       requête SM_NOTIFY.

   Prise en charge d'IPv6 et TI-RPC
       TI-RPC est nécessaire pour la prise en charge de NFS sur IPv6. Si la prise  en  charge  de
       TI-RPC  est  incluse  dans  rpc.statd,  il  essaye de démarrer l'écoute sur les transports
       réseaux marqués comme « visible » dans le fichier  /etc/netconfig.  Tant  qu’au  moins  un
       écouteur de transport réseau démarre sans erreur, rpc.statd fonctionnera.

ENVIRONNEMENT

       RPC_STATD_NO_NOTIFY=
              Même effet que --no-notify si définie à une valeur entière positive.

FICHIERS

       /var/lib/nfs/sm          Répertoire contenant la liste des moniteurs.

       /var/lib/nfs/sm.bak      Répertoire contenant la liste des notifications.

       /var/lib/nfs/state       Numéro d'état NSM de cet hôte.

       /run/run.statd.pid       Fichier contenant le PID.

       /etc/netconfig           Base de données des capacités de transport en réseau.

VOIR AUSSI

       sm-notify(8),  nfs(5),  rpc.nfsd(8),  rpcbind(8),  tcpd(8),  hosts_access(5), iptables(8),
       netconfig(5)

       RFC 1094 – « NFS : Network File System Protocol Specification »
       RFC 1813 – « NFS Version 3 Protocol Specification »
       OpenGroup Protocols for Interworking : XNFS, version 3W - Chapitre 11

AUTEURS

       Jeff Uphoff <juphoff@users.sourceforge.net>
       Olaf Kirch <okir@monad.swb.de>
       H.J. Lu <hjl@gnu.org>
       Lon Hohberger <hohberger@missioncriticallinux.com>
       Paul Clements <paul.clements@steeleye.com>
       Chuck Lever <chuck.lever@oracle.com>

TRADUCTION

       La  traduction  française  de  cette  page  de  manuel  a  été  créée  par  Valéry  Perrin
       <valery.perrin.debian@free.fr>,   Sylvain   Cherrier   <sylvain.cherrier@free.fr>,  Thomas
       Huriaux <thomas.huriaux@gmail.com>, Dominique Simen <dominiquesimen@hotmail.com>,  Nicolas
       Sauzède    <nsauzede@free.fr>,    Romain    Doumenc   <rd6137@gmail.com>,   David   Prévot
       <david@tilapin.org>,    Denis    Mugnier     <myou72@orange.fr>,     Cédric     Boutillier
       <cedric.boutillier@gmail.com> et Jean-Paul Guillonneau <guillonneau.jeanpaul@free.fr>

       Cette  traduction  est  une  documentation libre ; veuillez vous reporter à la GNU General
       Public  License  version 3  ⟨https://www.gnu.org/licenses/gpl-3.0.html⟩   concernant   les
       conditions de copie et de distribution. Il n'y a aucune RESPONSABILITÉ LÉGALE.

       Si vous découvrez un bogue dans la traduction de cette page de manuel, veuillez envoyer un
       message à ⟨debian-l10n-french@lists.debian.org⟩.

                                         1 Novembre 2009                             RPC.STATD(8)