Provided by: manpages-fr-extra_20111118_all bug

NOM

       sm-notify - Envoyer une notification de redemarrage aux pairs NFS

SYNOPSIS

       /usr/sbin/sm-notify [-dfn] [-m minutes] [-v nom] [-p port-notification]
       [-P chemin]

DESCRIPTION

       Les systemes de fichiers ne peuvent garder de maniere  persistante  les
       verrous  de  fichiers.  Le verrou est donc perdu lors du redemarrage de
       l'hote.

       Les systemes  de  fichiers  en  reseau  doivent  detecter  si  un  etat
       verrouille  est  perdu  a  cause  du  redemarrage  de  l'hote. Apres le
       redemarrage d'un client NFS, le  serveur  NFS  doit  enlever  tous  les
       verrous  de  fichiers  poses par des applications qui tournaient sur ce
       client. Apres un redemarrage du serveur, un  client  doit  rappeler  au
       serveur quels etaient les fichiers verrouilles par ses applications.

       Pour  les versions 2 et 3 du protocole NFS, le protocole Network Status
       Monitor (ou NSM) est utilise pour avertir les pairs  des  redemarrages.
       Sous  Linux, deux composants tournant en espace utilisateur fournissent
       un service NSM :

       sm-notify
              Un  programme  d'aide  qui  avertit  les  pairs  NFS  apres   un
              redemarrage du systeme local

       rpc.statd
              Un  demon  qui ecoute les avertissements de redemarrage d'autres
              hotes, et gere la liste des hotes qui doivent etre avertis quand
              le systeme local redemarre.

       Le  gestionnaire  de verrous NFS local indique au rpc.statd local quels
       sont les pairs qui doivent etre  surveilles.  Quand  le  systeme  local
       redemarre,  la  commande  sm-notify  avertit  le  service NSM des hotes
       surveilles de son redemarrage. Quand un hote distant redemarre, ce pair
       notifie  le  rpc.statd  local, qui en retour renvoie l'avertissement de
       redemarrage au gestionnaire de verrous NFS local.

OP'ERATIONS NSM DANS LE D'ETAIL

       La premiere interaction visant a 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  surveille
       dans  un  fichier persistant. Ce fichier decrit la maniere de contacter
       un pair distant en cas de redemarre  local,  comment  reconnaitre  quel
       pair surveille est en train d'emettre

       Un    client   NFS   envoie   un   nom   d'hote,   appele   nom_d'appel
       (<< caller_name >>)  du  client,  pour  chaque  demande  de  verrou  de
       fichier.  Un  serveur  NFS peut utiliser ce nom d'hote pour envoyer des
       appels GRANT asynchrones au client, ou pour avertir le  client  de  son
       redemarrage.

       Le  serveur  NFS  Linux  peut  fournir  le nom_d'appel du client ou son
       adresse reseau a rpc.statd. Pour les besoins du protocole NSM,  ce  nom
       (ou  cette  adresse)  est  appelee  nom_monit  du pair observe. En meme
       temps, le gestionnaire de verrous local indique a rpc.statd son  propre
       nom  d'hote  suppose.  Pour les besoins du protocole NSM, ce nom d'hote
       est appele mon_nom.

       Il n'y a pas d'interactions equivalentes entre un  serveur  NFS  et  un
       client  pour donner au client le nom_d'appel du serveur. C'est pourquoi
       les clients NFS ne connaissent pas le nom_monit qu'un serveur NFS  peut
       utiliser  dans une requete SM_NOTIFY. Le client NFS Linux enregistre le
       nom d'hote du serveur utilise dans une commande mount  pour  identifier
       les serveurs NFS qui redemarrent.

   Notification de red'emarrage
       Quand  le  systeme  local  redemarre,  la commande sm-notify lit sur un
       stockage persistant la liste des pairs surveilles et envoie une requete
       SM_NOTIFY  au  service  NSM  tournant  sur  chacun des pairs listes. Il
       utilise la chaine nom_monit comme destination. Pour  identifier  l'hote
       ayant  redemarre,  la  commande  sm-notify  envoie  la  chaine  mon_nom
       enregistree lors de la surveillance  de  ce  poste  distant.  Le  demon
       rpc.statd   distant  utilise  cette  chaine  (ou  l'adresse  reseau  de
       l'appelant) pour lier les requetes SM_NOTIFY entrantes a un  des  pairs
       sur sa propre liste de surveillance.

       Si  rpc.statd  ne  trouve  pas  un  pair  dans  sa propre liste d'hotes
       surveilles lie a une  requete  SM_NOTIFY,  la  notification  n'est  pas
       transmise  au  gestionnaire  de  verrous  local.  En  plus, chaque pair
       possede son propre num'ero d''etat NSM, un  entier  de  32 bits  qui  est
       change  apres  chaque  redemarrage par la commande sm-notify. rpc.statd
       utilise  ce  chiffre  pour   separer   les   redemarrages   reels   des
       notifications re-envoyees.

       Une  partie  de  la recuperation de verrous NFS est la redecouverte des
       pairs qui doivent etre a nouveaux  surveilles.  La  commande  sm-notify
       nettoie  la  liste  de  surveillance  stockee sur un stockage permanent
       apres chaque redemarrage.

OPTIONS

       -d     Garder sm-notify attache a son terminal de controle, et tournant
              au premier plan afin que la progression des notifications puisse
              etre directement observee.

       -f     Envoyer les notifications meme si sm-notify  a  deja  ete  lance
              depuis le redemarrage du systeme.

       -mtemps-nouvelessai
              Indiquer  la  longueur (en minute) du temps entre deux essais de
              notifications a des hotes sourds.  Si  cette  option  n'est  pas
              indiquee,  sm-notify  notifie  toutes  les 15 minutes. Donner la
              valeur  0  pousse  sm-notify  a  envoyer   continuellement   des
              notifications  aux  hotes  sourds  jusqu'a  ce  qu'il  soit  tue
              manuellement.

              Les notifications sont reemises si  l'envoi  echoue,  si  l'hote
              distant  ne  repond  pas,  si  le  service NSM distant n'est pas
              enregistre, ou si la  resolution  DNS  echoue,  ce  qui  empeche
              l'adressage de l'hote distant nom_monit.

              Les  hotes  ne  sont pas supprimes de la liste des notifications
              tant  qu'aucune  reponse  valide  n'est  recue.  Cependant,   la
              procedure  SM_NOTIFY  renvoie un resultat nul. sm-notify ne peut
              donc pas dire si la machine distante a reconnu l'emetteur  et  a
              commence la recuperation de verrous idoines.

       -n     Empecher  sm-notify  de  mettre  a  jour le numero d'etat NSM du
              systeme local.

       -p port
              Indiquer le numero de port source que  sm-notify  doit  utiliser
              pour  envoyer  les notifications de redemarrage. Si cette option
              n'est pas precisee, un port ephemere est choisi au hasard.

              Cette option peut etre utilisee pour traverser un pare-feu entre
              le client et le serveur.

       -P, --state-directory-path chemin
              Donner  le  chemin  du  repertoire  parent  ou les notifications
              d'etat  NSM  sont  enregistrees.  Si  cette  option  n'est   pas
              precisee, sm-notify utilisera /var/lib/nfs par defaut

              Apres avoir demarre, sm-notify essaie de regler ses UID et GID a
              ceux du possesseur et du groupe de ce repertoire.

       -v ipaddr | nomh^ote
              Indiquer l'adresse reseau a partir de laquelle  seront  envoyees
              les notifications de redemarrage, ainsi que l'argument nom_monit
              utilise pour l'envoi de  requetes  SM_NOTIFY.  Si  cette  option
              n'est  pas  precisee,  sm-notify utilise une adresse joker comme
              adresse de transport, et la variable mon_nom enregistree lors de
              la  surveillance  du poste distant (c'etait l'argument nom_monit
              utilise pour l'envoi de la requete SM_NOTIFY).

              Le champ ipaddr peut etre sous la forme d'une  adresse  IPv4  ou
              IPv6.  Si  le  champ  ipaddr  est  fourni, la commande sm-notify
              convertit cette adresse en un nom d'hote qui servira d'arguments
              a nom_monit lors de l'envoi de requetes SM_NOTIFY.

              Cette  option  peut  etre  utile dans des reseaux partages entre
              plusieurs  lieux,  pour  lesquels  l'hote  distant  attend   une
              notification provenant d'une adresse reseau precise.

S'ECURIT'E

       La commande sm-notify doit etre lancee en superutilisateur afin d'avoir
       les privileges suffisants pour acceder a la base d'information d'etats.
       Elle  quitte  les  droits  superutilisateur des qu'elle demarre afin de
       reduire les risques d'attaque par elevation des privileges.

       Dans le cas normal, l'ID utilisateur  effectif  utilise  est  celui  du
       possesseur  du  repertoire  d'etat,  ceci  afin  de  lui  permettre  de
       continuer a acceder aux fichiers de ce repertoire apres qu'il a  quitte
       ses  droits  superutilisateurs.  Pour  controler  l'ID  utilisateur que
       rpc.statd  prend,  il  suffit  d'utiliser  chown(1)  pour  changer   le
       possesseur du repertoire d'etat.

NOTES

       La  recuperation  des verrous apres un redemarrage est indispensable au
       maintien de l'integrite des donnees et a la prevention de blocages  non
       necessaires d'applications

       Afin  d'aider rpc.statd a faire correspondre les requetes SM_NOTIFY aux
       requetes NLM, un  certain  nombre  de  bonnes  pratiques  doivent  etre
       respectees. Par exemple :

              Le  nom  du  noeud UTS de votre systeme doit correspondre au nom
              DNS que les pairs NFS utilisent pour se contacter.

              Les noms de noeuds UTS de vos systemes doivent toujours etre des
              noms de domaine pleinement qualifies (<< FQDN >>).

              Les translations DNS directes et inverses des noms de noeuds UTS
              ne doivent pas etre contradictoires.

              Le nom d'hote utilise par le client pour monter le serveur  doit
              correspondre  au  nom_monit  utilise par le serveur pour envoyer
              ses requetes.

       Demonter un systeme de fichiers NFS n'empeche pas le client NFS  ou  le
       serveur  de  se  surveiller. Les deux peuvent continuer a se surveiller
       pendant un moment au cas  ou  la  reprise  du  trafic  entre  les  deux
       entrainerait de nouveaux montages et d'autres verrous de fichiers.

       Sous  Linux,  et en conditions normales d'operation, le dechargement du
       module lockd du noyau entraine l'arret de  la  surveillance  des  pairs
       NFS.  Ceci  peut  survenir, par exemple, sur un client NFS utilisant un
       systeme de montage automatique, qui demonte les systemes  NFS  suite  a
       une inactivite.

   Prise en charge d'IPv6 et TI-RPC
       L'utilisation  de l'IPv6 par NFS requiert TI-RPC. Si la prise en charge
       TI-RPC a ete incluse dans la commande sm-notify, le choix entre une  le
       mode  IPv4  ou IPv6 sera fait en fonction de l'adresse reseau retournee
       par  DNS  pour  les  clients  distants.  Ce  systeme  est   normalement
       parfaitement  compatible  avec  les  machines qui ne gere ni TI-RPC, ni
       IPv6.

       La commande sm-notify ne prend en charge pour l'instant que l'envoi des
       notifications via les protocoles de transport en datagramme.

FICHIERS

       /var/lib/nfs/sm/*        Repertoire contenant la liste des moniteurs.

       /var/lib/nfs/sm.bak      Repertoire     contenant    la    liste    des
                                notifications.

       /var/lib/nfs/state       Numero d'etat NSM de cet hote.

       /proc/sys/fs/nfs/nsm_local_state
                                Copie du numero d'etat NSM dans le noyau.

VOIR AUSSI

       rpc.statd(8), nfs(5), uname(2), nomh^ote(7)

       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

       Olaf Kirch <okir@suse.de>
       Chuck Lever <chuck.lever@oracle.com>

                               1er novembre 2009                  SM-NOTIFY(8)