Provided by:
manpages-fr-extra_20101103_all 
NOM
rrpc.statd - Demon du service NSM
SYNOPSIS
rpc.statd [-dh?FLNvVw] [-H programme] [-n mon-nom] [-o port-source] [-p
port-d-'ecoute] [-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.
Dans les versions 2 (RFC1094) et 3 (RFC1813) de NFS, on utilise le
protocole NSM (Network Status Monitor) pour notifier les redemarrages
aux pairs. Sous Linux, le service NSM est constitue de deux composants
tournant en espace utilisateur :
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.
sm-notify
Un programme d'aide qui avertie les pairs NFS apres un
redemarrage du systeme local
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'existe pas d'interaction equivalente entre un serveur et un client
NFS informant le client de son nom_d'appel sur le serveur. C'est la
raison pour laquelle le client NFS ne connait pas reellement le
nom_monit qui sera utilise dans une requete SM_NOTIFY. Le client NFS
Linux utilise le nom d'hote du serveur donne a la commande mount pour
identifier le serveur NFS qui redemarre.
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, --no-syslog
En conjonction avec l'option -F, demande a rpc.statd d'envoyer
ses messages vers la sortie d'erreur standard plutot que vers le
journal systeme.
-F, --foreground
Force rpc.statd a rester dans son terminal de controle pour
permettre de surveiller directement, ou a l'aide d'un debogueur,
les operations NSM. Si cette option n'est pas donnee, rpc.statd
passe en arriere-plan apres son demarrage.
-h, -?, --help
Demande a rpc.statd de montrer les options d'utilisation sur la
sortie d'erreur standard puis de quitter
-H, --ha-callout programme
Indique un programme d'appel de haute disponibilite. Si cette
option est laissee vide, aucun appel n'est indique. Referez-vous
a la section Appels de haute disponibilit'e ci-dessous pour plus
de details.
-L, --no-notify
Demande le demarrage de rpc.statd sans lancement de sm-notify,
ce qui conserve le numero d'etat NSM et la liste des machines
surveillees
NB : La commande sm-notify a un mecanisme de verification qui
s'assure qu'elle n'est lancee qu'une fois apres un redemarrage
du systeme. Ceci permet d'eliminer les fausses notifications de
redemarrage si rpc.statd est relance sans l'option -L.
-n, --name addrip | nomh^ote
Indique l'adresse de lien utilisee pour les tuyaux d'ecoutes
RPC. L'addrip peut etre donnee sous la forme IPv4 ou IPv6. Si
cette option est omise, rpc.statd utilise une adresse joker
comme adresse de lien pour le transport.
Cette chaine est aussi passee a sm-notify comme adresse source a
partir de laquelle sont emises les notifications de redemarrage.
Voir sm-notify(8) pour plus de details.
-N Demande a rpc.statd de lancer la commande sm-notify ; puis de
quitter. On peut cependant lancer sm-notify directement, cette
option n'est donc plus d'actualite.
-o, --outgoing-port port
Indique le numero du port source que la commande sm-notify doit
utiliser quand elle envoie les notifications de redemarrage.
Referez-vous a sm-notify(8) pour plus de details.
-p, --port port
Indique le numero de port utilise pour les tuyaux d'ecoute RPC.
Si cette option est omise, rpc.statd choisis un nombre aleatoire
et ephemere de port pour chaque tuyau d'ecoute.
Cette option peut etre utilise pour indiquer le numero de port
sur les ecouteurs quand les requetes SM_NOTIFY doivent traverser
un pare-feu entre les clients et les serveurs.
-P, --state-directory-path chemin
Precise le nom du repertoire parent ou se trouvent les
informations sour l'etat NSM. Si l'option n'est pas precisee,
rpc.statd utilise /var/lib/nfs par defaut.
Apres avoir demarree, rpc.statd essaye de prendre l'UID et le
GID du proprietaire et du groupe possedant ce repertoire.
-v, -V, --version
Demande a rpc.statd d'afficher sa version sur la sortie d'erreur
standard puis de quitter.
S'ECURIT'E
Le demon rpc.statd doit etre lance en superutilisateur afin d'avoir
assez de privileges pour creer un tuyau sur un port privilegie, et pour
acceder la la base de donnee d'information d'etats. Afin d'eviter les
risques d'attaque par escalade de privileges (risques accentues par le
fait que rpc.statd soit un service tournant longtemps), ce demon quitte
les privileges superutilisateurs des son demarrage.
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.
Vous pouvez aussi proteger vos ecouteurs rpc.statd en utilisant la
bilbiotheque tcp_wrapper ou iptables(8). Si vous voulez utiliser la
bibliotheque tcp_wrapper, ajoutez les noms d'hotes des pairs dont
l'acces est autorise dans /etc/hosts.allow. Le nom du demon sera statd,
meme si l'executable rpc.statd porte un nom different.
Pour avoir plus d'informations, jetez un oeil sur les pages de manuel
de tcpd(8) et hosts_access(5).
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.
Appels de haute disponibilit'e
rpc.statd peut lancer un programme d'appel specifique lors d'un
traitement reussi de requete SM_MON, SM_UNMON, et SM_NUMON_ALL. Ce type
de programme peut etre utilise dans un environnement NFS de haute
disponibilite pour chercher les verrous d'etats qui pourraient avoir
besoin d'etre migres suite a un redemarrage du systeme.
Le nom du programme d'appel peut etre indique par l'option -H. Le
programme doit etre lance avec 3 arguments : le premier est add-client
ou del-client, selon le besoin. Le second est le nom_appell'e du pair
observe. Le troisieme est le nom_d'appel du gestionnaire d'acces
appelant.
prise en charge d'IPv6 et TI-RPC
TI-RPC est necessaire pour la prise en charge d'IPv6 par NFS. Si la
prise en charge TI-RPC est inclus dans rpc.statd, il essaye de demarrer
l'ecoute sur les transports reseaux marques comme << visible >> dans le
fichier /etc/netconfig. Tant que l'ecouteur de transport demarre sans
erreur, rpc.statd fonctionnera.
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
/var/run/run.statd.pid fichier contenant le pid
/etc/netconfig base de donnee des capacites de transport en
reseau
VOIR AUSSI
sm-notify(8), nfs(5), rpc.nfsd(8), rpcbind(8), tcpd(8),
hosts_access(5), iptables(8), netconfig(5)
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
Jeff Uphoff <juphoff@users.sourceforge.net>
Olaf Kirch <okir@monad.swb.de>
H.J. Lu <hjl@gnu.org>
Lon Hohberger <hohberger@missioncriticallinux.com>
Paul Clements <paul.clements@steeleye.com>
Chuck Lever <chuck.lever@oracle.com>
TRADUCTION
Cette page de manuel a ete traduite par Thierry Vignaud <tvignaud AT
mandriva DOT com> en 2000 et mise a jour par Vanessa Cochondon <nessie
AT little-monster DOT org> La version presente dans Debian est
maintenue par Sylvain Cherrier <sylvain DOT cherrier AT free DOT fr> et
les membres de la liste <debian-l10n-french AT lists DOT debian DOT
org>. Veuillez signaler toute erreur de traduction par un rapport de
bogue sur le paquet manpages-fr-extra.
1er novembre 2009 RPC.STATD(8)