Provided by: manpages-fr-extra_20101103_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  avertie  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 revnoie 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 le resultat d'un appel a
       gethostname(3) en tant que chaine mon_nom. 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 re-decouverte des
       les 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     Garde sm-notify attache a son terminal de controle, et  tournant
              en  avant-plan  afin que la progression des notifications puisse
              etre directement observee.

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

       -mtemps-nouvelessai
              Indique  la  longueur (en minutes) 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.

              On re-essaie les notifications  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'on a recu une reponse valide.  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     Empeche  sm-notify  de  mettre  a  jour  le numero d'etat NSM du
              systeme local.

       -p port
              Indique 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
              donne 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
              Indique 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 le resultat de la commande  gethostname
              pour nom_monit.

              Le champ addrip peut etre donne sous la forme d'une adresse IPv4
              ou IPv6.

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

              Il  est  deconseille  d'utiliser une adresse reseau comme chaine
              nom_monit  ou  mon_nom  en  cas   d'inter-operation   avec   des
              implementations non Linux.

       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 prends 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 - Chapter 11

AUTEURS

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

                               1er novembre 2009                  SM-NOTIFY(8)