Provided by: manpages-fr-extra_20140201_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-d-écoute] [-P
       chemin]

DESCRIPTION

       Les systèmes de fichiers ne peuvent garder de manière persistante les verrous de fichiers.
       Le verrou 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. 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é est en train d'émettre

       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 appelée
       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 des 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 chiffre
       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
              Demande le démarrage de rpc.statd sans lancement de sm-notify, ce qui  conserve  le
              numéro d'état NSM et la liste des machines surveillées

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

       -n, --name addrip | nomhôte
              Indique  l'adresse  de  lien  utilisée pour les tuyaux d'écoutes RPC. L'addrip peut
              être donnée sous la forme IPv4 ou  IPv6.  Si  cette  option  est  omise,  rpc.statd
              utilise une adresse joker comme adresse de lien pour le transport.

              Cette chaîne est aussi passée à sm-notify comme adresse source à partir de laquelle
              sont émises les notifications  de  redémarrage.  Voir  sm-notify(8)  pour  plus  de
              détails.

       -N     Demande  à  rpc.statd  de  lancer  la commande sm-notify ; puis de quitter. On peut
              cependant lancer sm-notify 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 tuyaux d'écoute RPC. Si cette option est
              omise,  rpc.statd  essayera  de  consulter  /etc/services, s'il réussi à obtenir un
              port,  il initialisera le même  port  pour  tous  les  tuyaux  d'écoute,  sinon  il
              choisira un port aléatoire et éphémère pour chaque tuyau 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.

       -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 avoir démarré, rpc.statd essaye de prendre l'UID et le GID du propriétaire et
              du groupe possédant ce répertoire.

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

SÉCURITÉ

       Le démon rpc.statd doit être lancé en tant que superutilisateur pour  avoir  le  droit  de
       créer  un tuyau sur un port privilégié 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 quitte les droits
       de superutilisateur dès son démarrage.

       Dans le cas  normal,  l'ID  utilisateur  effectif  utilisé  est  celui  du  possesseur  du
       répertoire  d'état,  ceci  afin de lui permettre de continuer à accéder aux fichiers de ce
       répertoire après qu'il a quitté  ses  droits  de  superutilisateur.  Pour  contrôler  l'ID
       utilisateur  que rpc.statd prend, il suffit d'utiliser chown(1) pour changer le possesseur
       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ôtes 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

       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 votre système doit correspondre au nom DNS que les pairs NFS
              utilisent pour se 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 ne doivent pas être
              contradictoires.

              Le nom d'hôte utilisé par le client pour monter le  serveur  doit  correspondre  au
              nom_monit utilisé par le serveur pour envoyer ses requêtes.

       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. Ceci peut survenir, par exemple,
       sur un client NFS utilisant un système de montage automatique, qui  démonte  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ête SM_MON, SM_UNMON, et SM_NUMON_ALL. Ce type de programme peut être utilisé dans  un
       environnement  NFS de haute disponibilité pour chercher les verrous d'états 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 ou del-client, selon le besoin. Le
       deuxième est le nom_monit du pair observé. Le troisième est le nom_d'appel du gestionnaire
       d'accès appelant.

   Prise en charge d'IPv6 et TI-RPC
       TI-RPC est nécessaire pour la prise en charge d'IPv6 par NFS. Si la prise en charge 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 que l'écouteur de transport
       démarre sans erreur, rpc.statd fonctionnera.

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 »
       RRFC 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

       Cette  page de manuel a été traduite par Thierry Vignaud <tvignaud AT mandriva DOT com> en
       2000 et mise à jour par Vanessa Cochondon <nessie AT little-monster DOT  org>  La  version
       présente  dans Debian est maintenue par Sylvain Cherrier <sylvain DOT cherrier AT free DOT
       fr> et les membres de la liste <debian-l10n-french AT lists DOT debian DOT org>.  Veuillez
       signaler   toute   erreur   de   traduction   par  un  rapport  de  bogue  sur  le  paquet
       manpages-fr-extra.

                                        1er novembre 2009                            RPC.STATD(8)