Provided by: manpages-fr-extra_20111118_all bug

NOM

       sm-notify - Envoyer une notification de redémarrage aux pairs NFS

SYNOPSIS

       /usr/sbin/sm-notify [-dfn] [-m minutes] [-v nom] [-p port-notification]
       [-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.

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

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

       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.

       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émarre  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'y a pas d'interactions équivalentes 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 requête SM_NOTIFY. Le client NFS Linux enregistre le
       nom d'hôte du serveur utilisé dans une commande mount  pour  identifier
       les serveurs NFS qui redémarrent.

   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  de  ce  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 numro 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     Garder sm-notify attaché à son terminal de contrôle, et tournant
              au premier plan afin que la progression des notifications puisse
              être directement observée.

       -f     Envoyer les notifications même si sm-notify  a  déjà  été  lancé
              depuis le redémarrage du système.

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

              Les notifications sont réémises si  l'envoi  échoue,  si  l'hôte
              distant  ne  répond  pas,  si  le  service NSM distant n'est pas
              enregistré, ou si la  résolution  DNS  échoue,  ce  qui  empêche
              l'adressage de l'hôte distant nom_monit.

              Les  hôtes  ne  sont pas supprimés de la liste des notifications
              tant  qu'aucune  réponse  valide  n'est  reçue.  Cependant,   la
              procédure  SM_NOTIFY  renvoie un résultat nul. sm-notify ne peut
              donc pas dire si la machine distante a reconnu l'émetteur  et  a
              commencé la récupération de verrous idoines.

       -n     Empêcher  sm-notify  de  mettre  à  jour le numéro d'état NSM du
              système local.

       -p port
              Indiquer le numéro de port source que  sm-notify  doit  utiliser
              pour  envoyer  les notifications de redémarrage. Si cette option
              n'est pas précisée, un port éphémère est choisi au hasard.

              Cette option peut être utilisée pour traverser un pare-feu entre
              le client et le serveur.

       -P, --state-directory-path chemin
              Donner  le  chemin  du  répertoire  parent  où les notifications
              d'état  NSM  sont  enregistrées.  Si  cette  option  n'est   pas
              précisée, sm-notify utilisera /var/lib/nfs par défaut

              Après avoir démarré, sm-notify essaie de régler ses UID et GID à
              ceux du possesseur et du groupe de ce répertoire.

       -v ipaddr | nomhte
              Indiquer l'adresse réseau à partir de laquelle  seront  envoyées
              les notifications de redémarrage, ainsi que l'argument nom_monit
              utilisé pour l'envoi de  requêtes  SM_NOTIFY.  Si  cette  option
              n'est  pas  précisée,  sm-notify utilise une adresse joker comme
              adresse de transport, et la variable mon_nom enregistrée lors de
              la  surveillance  du poste distant (c'était l'argument nom_monit
              utilisé pour l'envoi de la requête SM_NOTIFY).

              Le champ ipaddr peut être 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'hôte qui servira d'arguments
              à nom_monit lors de l'envoi de requêtes SM_NOTIFY.

              Cette  option  peut  être  utile dans des réseaux partagés entre
              plusieurs  lieux,  pour  lesquels  l'hôte  distant  attend   une
              notification provenant d'une adresse réseau précise.

SÉCURITÉ

       La commande sm-notify doit être lancée en superutilisateur afin d'avoir
       les privilèges suffisants pour accéder à la base d'information d'états.
       Elle  quitte  les  droits  superutilisateur dès qu'elle démarre afin de
       réduire les risques d'attaque par élévation des privilèges.

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

NOTES

       La  récupération  des verrous après un redémarrage est indispensable au
       maintien de l'intégrité des données et à la prévention de 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é.

   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 été incluse dans la commande sm-notify, le choix entre une  le
       mode  IPv4  ou IPv6 sera fait en fonction de l'adresse réseau retournée
       par  DNS  pour  les  clients  distants.  Ce  système  est   normalement
       parfaitement  compatible  avec  les  machines qui ne gère 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/*        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.

       /proc/sys/fs/nfs/nsm_local_state
                                Copie du numéro d'état NSM dans le noyau.

VOIR AUSSI

       rpc.statd(8), nfs(5), uname(2), nomhôte(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)