Provided by: manpages-fr-extra_20140201_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é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'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 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     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 | nomhôte
              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'informations  d'états. Elle quitte les droits de
       superutilisateur  dès  qu'elle  démarre  afin  de  réduire  les  risques   d'attaque   par
       augmentation de droits.

       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.

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 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èrent ni TI-RPC, ni IPv6.

       La commande sm-notify ne prend en charge pour  l'instant  que  l'envoi  des  notifications
       uniquement par 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)