Provided by: manpages-fr_4.19.0-7_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 l’état du système de
       fichiers. L’état des verrous 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  et
       comment  notifier  au  gestionnaire  de  verrous  local  qu’un pair surveillé signifie son
       redémarrage.

       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  connu  comme
       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  ou
       plusieurs 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 visible 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.

       -m délai_nouvel_essai
              Indiquer  la  durée  (en  minute)  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  valable n'est reçue. Cependant, la procédure SM_NOTIFY renvoie un résultat
              vide. sm-notify ne peut donc pas dire si la machine distante a  reconnu  l'émetteur
              et a commencé la récupération idoine de verrous.

       -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 le démarrage, sm-notify essaie de définir les UID et GID effectifs à ceux  du
              groupe   et  d’utilisateur  du  sous-répertoire  sm  de  ce  répertoire.  Après  la
              modification des identifiants effectifs, sm-notify a seulement besoin d’accéder aux
              fichiers sm et sm.bak dans le chemin du répertoire d’états (state-directory-path).

       -v ipaddr | nom_hô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 comme argument nom_monit pour l'envoi des requêtes
              SM_NOTIFY).

              Le champ addrip peut être sous la forme d'une adresse IPv4 ou  IPv6.  Si  le  champ
              addrip  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.

FICHIER DE CONFIGURATION

       La plupart des options pouvant être indiquées sur la ligne de commande peuvent aussi  être
       contrôlées  à  l’aide  de  valeurs définies dans les sections [sm-notify] ou, dans un cas,
       [statd] du fichier de configuration /etc/nfs.conf.

       Les valeurs reconnues dans la section [sm-notify] incluent  retry-time,  outgoing-port  et
       outgoing-addr. Elles ont le même effet, respectivement, que les options m, p et v

       Une  autre  valeur  reconnue  dans  la  section  [sm-notify]  est  lift-grace. Par défaut,
       sm-notify transformera la période de grâce de lockd  rapidement  s’il  n’a  aucun  hôte  à
       informer.  Certaines  configurations  de  haute disponibilité exécuteront un sm-notify par
       adresse IP variable. Dans  ces  configurations,  transformer  la  période  de  grâce  peut
       rapidement  empêcher  des  clients de récupérer des verrous. Régler lift-grace à n empêche
       sm-notify de mettre rapidement fin à la période de grâce. lift-grace n’a pas  d’option  de
       ligne de commande correspondante.

       La valeur reconnue dans la section [statd] est state-directory-path.

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  abandonne  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  propriétaire  du
       répertoire  d'états,  cela afin de lui permettre de continuer à accéder aux fichiers de ce
       répertoire après qu'il a abandonné ses droits de  superutilisateur.  Pour  contrôler  l'ID
       utilisateur   que   rpc.statd  prend,  il  suffit  d'utiliser  chown(1)  pour  changer  le
       propriétaire 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 vos systèmes doit correspondre aux noms DNS que les pairs NFS
              utilisent pour les 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  doivent  être
              cohérentes.

              Le  nom  d'hôte  utilisé  par le client pour monter le serveur doit correspondre au
              nom_monit utilisé dans les requêtes SM_NOTIFY qu’il envoie.

       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. Cela peut survenir, par  exemple,
       sur  un  client  NFS  utilisant  un  système  de  montage automatique qui démonte tous les
       systèmes NFS suite à une inactivité.

   Prise en charge d'IPv6 et TI-RPC
       L'utilisation d'IPv6 par NFS requiert TI-RPC. Si la  prise  en  charge  de  TI-RPC  a  été
       incluse  dans  la  commande  sm-notify,  le  choix  entre le mode IPv4 ou IPv6 est 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  pour l'instant en charge 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), hostname(7)

       RFC 1094 – « NFS : Network File System Protocol Specification »
       RFC 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>

TRADUCTION

       La  traduction  française  de  cette  page  de  manuel  a  été  créée  par  Valéry  Perrin
       <valery.perrin.debian@free.fr>,   Sylvain   Cherrier   <sylvain.cherrier@free.fr>,  Thomas
       Huriaux <thomas.huriaux@gmail.com>, Dominique Simen <dominiquesimen@hotmail.com>,  Nicolas
       Sauzède    <nsauzede@free.fr>,    Romain    Doumenc   <rd6137@gmail.com>,   David   Prévot
       <david@tilapin.org>,    Denis    Mugnier     <myou72@orange.fr>,     Cédric     Boutillier
       <cedric.boutillier@gmail.com> et Jean-Paul Guillonneau <guillonneau.jeanpaul@free.fr>

       Cette  traduction  est  une  documentation libre ; veuillez vous reporter à la GNU General
       Public  License  version 3  ⟨https://www.gnu.org/licenses/gpl-3.0.html⟩   concernant   les
       conditions de copie et de distribution. Il n'y a aucune RESPONSABILITÉ LÉGALE.

       Si vous découvrez un bogue dans la traduction de cette page de manuel, veuillez envoyer un
       message à ⟨debian-l10n-french@lists.debian.org⟩.

                                         1 Novembre 2009                             SM-NOTIFY(8)