Provided by:
manpages-fr-extra_20101103_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 avertie 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 revnoie 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 le resultat d'un appel a
gethostname(3) en tant que chaine mon_nom. 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 re-decouverte des
les 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 Garde sm-notify attache a son terminal de controle, et tournant
en avant-plan afin que la progression des notifications puisse
etre directement observee.
-f Envoie les notifications meme si sm-notify a deja ete lance
depuis le redemarrage du systeme.
-mtemps-nouvelessai
Indique la longueur (en minutes) 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.
On re-essaie les notifications 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'on a recu une reponse valide. 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 Empeche sm-notify de mettre a jour le numero d'etat NSM du
systeme local.
-p port
Indique 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
donne 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
Indique 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 le resultat de la commande gethostname
pour nom_monit.
Le champ addrip peut etre donne sous la forme d'une adresse IPv4
ou IPv6.
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 suffisant 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.
Il est deconseille d'utiliser une adresse reseau comme chaine
nom_monit ou mon_nom en cas d'inter-operation avec des
implementations non Linux.
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 prends 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 - Chapter 11
AUTEURS
Olaf Kirch <okir@suse.de>
Chuck Lever <chuck.lever@oracle.com>
1er novembre 2009 SM-NOTIFY(8)