Provided by: manpages-fr-extra_20151231_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 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)