Provided by: manpages-fr_4.13-4_all 
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.
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)