Provided by:
manpages-fr-extra_20111118_all 
NOM
sm-notify - Envoyer une notification de redemarrage aux pairs NFS
SYNOPSIS
/usr/sbin/sm-notify [-dfn] [-m minutes] [-v nom] [-p port-notification]
[-P chemin]
DESCRIPTION
Les systemes de fichiers ne peuvent garder de maniere persistante les
verrous de fichiers. Le verrou est donc perdu lors du redemarrage de
l'hote.
Les systemes de fichiers en reseau doivent detecter si un etat
verrouille est perdu a cause du redemarrage de l'hote. Apres le
redemarrage d'un client NFS, le serveur NFS doit enlever tous les
verrous de fichiers poses par des applications qui tournaient sur ce
client. Apres un redemarrage du serveur, un client doit rappeler au
serveur quels etaient les fichiers verrouilles par ses applications.
Pour les versions 2 et 3 du protocole NFS, le protocole Network Status
Monitor (ou NSM) est utilise pour avertir les pairs des redemarrages.
Sous Linux, deux composants tournant en espace utilisateur fournissent
un service NSM :
sm-notify
Un programme d'aide qui avertit les pairs NFS apres un
redemarrage du systeme local
rpc.statd
Un demon qui ecoute les avertissements de redemarrage d'autres
hotes, et gere la liste des hotes qui doivent etre avertis quand
le systeme local redemarre.
Le gestionnaire de verrous NFS local indique au rpc.statd local quels
sont les pairs qui doivent etre surveilles. Quand le systeme local
redemarre, la commande sm-notify avertit le service NSM des hotes
surveilles de son redemarrage. Quand un hote distant redemarre, ce pair
notifie le rpc.statd local, qui en retour renvoie l'avertissement de
redemarrage au gestionnaire de verrous NFS local.
OP'ERATIONS NSM DANS LE D'ETAIL
La premiere interaction visant a 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 surveille
dans un fichier persistant. Ce fichier decrit la maniere de contacter
un pair distant en cas de redemarre local, comment reconnaitre quel
pair surveille est en train d'emettre
Un client NFS envoie un nom d'hote, appele nom_d'appel
(<< caller_name >>) du client, pour chaque demande de verrou de
fichier. Un serveur NFS peut utiliser ce nom d'hote pour envoyer des
appels GRANT asynchrones au client, ou pour avertir le client de son
redemarrage.
Le serveur NFS Linux peut fournir le nom_d'appel du client ou son
adresse reseau a rpc.statd. Pour les besoins du protocole NSM, ce nom
(ou cette adresse) est appelee nom_monit du pair observe. En meme
temps, le gestionnaire de verrous local indique a rpc.statd son propre
nom d'hote suppose. Pour les besoins du protocole NSM, ce nom d'hote
est appele mon_nom.
Il n'y a pas d'interactions equivalentes 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 requete SM_NOTIFY. Le client NFS Linux enregistre le
nom d'hote du serveur utilise dans une commande mount pour identifier
les serveurs NFS qui redemarrent.
Notification de red'emarrage
Quand le systeme local redemarre, la commande sm-notify lit sur un
stockage persistant la liste des pairs surveilles et envoie une requete
SM_NOTIFY au service NSM tournant sur chacun des pairs listes. Il
utilise la chaine nom_monit comme destination. Pour identifier l'hote
ayant redemarre, la commande sm-notify envoie la chaine mon_nom
enregistree lors de la surveillance de ce poste distant. Le demon
rpc.statd distant utilise cette chaine (ou l'adresse reseau de
l'appelant) pour lier les requetes SM_NOTIFY entrantes a un des pairs
sur sa propre liste de surveillance.
Si rpc.statd ne trouve pas un pair dans sa propre liste d'hotes
surveilles lie a une requete SM_NOTIFY, la notification n'est pas
transmise au gestionnaire de verrous local. En plus, chaque pair
possede son propre num'ero d''etat NSM, un entier de 32 bits qui est
change apres chaque redemarrage par la commande sm-notify. rpc.statd
utilise ce chiffre pour separer les redemarrages reels des
notifications re-envoyees.
Une partie de la recuperation de verrous NFS est la redecouverte des
pairs qui doivent etre a nouveaux surveilles. La commande sm-notify
nettoie la liste de surveillance stockee sur un stockage permanent
apres chaque redemarrage.
OPTIONS
-d Garder sm-notify attache a son terminal de controle, et tournant
au premier plan afin que la progression des notifications puisse
etre directement observee.
-f Envoyer les notifications meme si sm-notify a deja ete lance
depuis le redemarrage du systeme.
-mtemps-nouvelessai
Indiquer la longueur (en minute) du temps entre deux essais de
notifications a des hotes sourds. Si cette option n'est pas
indiquee, sm-notify notifie toutes les 15 minutes. Donner la
valeur 0 pousse sm-notify a envoyer continuellement des
notifications aux hotes sourds jusqu'a ce qu'il soit tue
manuellement.
Les notifications sont reemises si l'envoi echoue, si l'hote
distant ne repond pas, si le service NSM distant n'est pas
enregistre, ou si la resolution DNS echoue, ce qui empeche
l'adressage de l'hote distant nom_monit.
Les hotes ne sont pas supprimes de la liste des notifications
tant qu'aucune reponse valide n'est recue. Cependant, la
procedure SM_NOTIFY renvoie un resultat nul. sm-notify ne peut
donc pas dire si la machine distante a reconnu l'emetteur et a
commence la recuperation de verrous idoines.
-n Empecher sm-notify de mettre a jour le numero d'etat NSM du
systeme local.
-p port
Indiquer le numero de port source que sm-notify doit utiliser
pour envoyer les notifications de redemarrage. Si cette option
n'est pas precisee, un port ephemere est choisi au hasard.
Cette option peut etre utilisee pour traverser un pare-feu entre
le client et le serveur.
-P, --state-directory-path chemin
Donner le chemin du repertoire parent ou les notifications
d'etat NSM sont enregistrees. Si cette option n'est pas
precisee, sm-notify utilisera /var/lib/nfs par defaut
Apres avoir demarre, sm-notify essaie de regler ses UID et GID a
ceux du possesseur et du groupe de ce repertoire.
-v ipaddr | nomh^ote
Indiquer l'adresse reseau a partir de laquelle seront envoyees
les notifications de redemarrage, ainsi que l'argument nom_monit
utilise pour l'envoi de requetes SM_NOTIFY. Si cette option
n'est pas precisee, sm-notify utilise une adresse joker comme
adresse de transport, et la variable mon_nom enregistree lors de
la surveillance du poste distant (c'etait l'argument nom_monit
utilise pour l'envoi de la requete SM_NOTIFY).
Le champ ipaddr peut etre 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'hote qui servira d'arguments
a nom_monit lors de l'envoi de requetes SM_NOTIFY.
Cette option peut etre utile dans des reseaux partages entre
plusieurs lieux, pour lesquels l'hote distant attend une
notification provenant d'une adresse reseau precise.
S'ECURIT'E
La commande sm-notify doit etre lancee en superutilisateur afin d'avoir
les privileges suffisants pour acceder a la base d'information d'etats.
Elle quitte les droits superutilisateur des qu'elle demarre afin de
reduire les risques d'attaque par elevation des privileges.
Dans le cas normal, l'ID utilisateur effectif utilise est celui du
possesseur du repertoire d'etat, ceci afin de lui permettre de
continuer a acceder aux fichiers de ce repertoire apres qu'il a quitte
ses droits superutilisateurs. Pour controler l'ID utilisateur que
rpc.statd prend, il suffit d'utiliser chown(1) pour changer le
possesseur du repertoire d'etat.
NOTES
La recuperation des verrous apres un redemarrage est indispensable au
maintien de l'integrite des donnees et a la prevention de blocages non
necessaires d'applications
Afin d'aider rpc.statd a faire correspondre les requetes SM_NOTIFY aux
requetes NLM, un certain nombre de bonnes pratiques doivent etre
respectees. Par exemple :
Le nom du noeud UTS de votre systeme doit correspondre au nom
DNS que les pairs NFS utilisent pour se contacter.
Les noms de noeuds UTS de vos systemes doivent toujours etre des
noms de domaine pleinement qualifies (<< FQDN >>).
Les translations DNS directes et inverses des noms de noeuds UTS
ne doivent pas etre contradictoires.
Le nom d'hote utilise par le client pour monter le serveur doit
correspondre au nom_monit utilise par le serveur pour envoyer
ses requetes.
Demonter un systeme de fichiers NFS n'empeche pas le client NFS ou le
serveur de se surveiller. Les deux peuvent continuer a se surveiller
pendant un moment au cas ou la reprise du trafic entre les deux
entrainerait de nouveaux montages et d'autres verrous de fichiers.
Sous Linux, et en conditions normales d'operation, le dechargement du
module lockd du noyau entraine l'arret de la surveillance des pairs
NFS. Ceci peut survenir, par exemple, sur un client NFS utilisant un
systeme de montage automatique, qui demonte les systemes NFS suite a
une inactivite.
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 ete incluse dans la commande sm-notify, le choix entre une le
mode IPv4 ou IPv6 sera fait en fonction de l'adresse reseau retournee
par DNS pour les clients distants. Ce systeme est normalement
parfaitement compatible avec les machines qui ne gere 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/* Repertoire contenant la liste des moniteurs.
/var/lib/nfs/sm.bak Repertoire contenant la liste des
notifications.
/var/lib/nfs/state Numero d'etat NSM de cet hote.
/proc/sys/fs/nfs/nsm_local_state
Copie du numero d'etat NSM dans le noyau.
VOIR AUSSI
rpc.statd(8), nfs(5), uname(2), nomh^ote(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)