Provided by: manpages-fr_4.15.0-9_all 
NOM
rrpc.statd - Démon du service NSM
SYNOPSIS
rpc.statd [-dh?FLNvV] [-H programme] [-n mon_nom] [-o port-source]
[-p port-écoute] [-P chemin]
[--nlm-port port] [--nlm-udp-port port]
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 distant. 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.
Dans les versions 2 (RFC1094) et 3 (RFC1813) de NFS, on utilise le protocole NSM (Network
Status Monitor) pour notifier les redémarrages aux pairs. Sous Linux, le service NSM est
constitué de deux composants tournant en espace utilisateur :
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.
sm-notify
Un programme d'aide qui avertit les pairs NFS après un redémarrage du système local
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é notifie son redémarrage 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'existe pas d'interaction équivalente 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
connaît pas réellement le nom_monit qui sera utilisé dans une requête SM_NOTIFY. Le client
NFS Linux utilise le nom d'hôte du serveur donné à la commande mount pour identifier le
serveur NFS qui redémarre.
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 du 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 nombre
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, --no-syslog
En conjonction avec l'option -F, demande à rpc.statd d'envoyer ses messages vers la
sortie d'erreur standard plutôt que vers le journal système.
-F, --foreground
Force rpc.statd à rester dans son terminal de contrôle pour permettre de surveiller
directement, ou à l'aide d'un débogueur, les opérations NSM. Si cette option n'est
pas donnée, rpc.statd passe en arrière-plan après son démarrage.
-h, -?, --help
Demande à 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 disponibilité. Si cette option est laissée
vide, aucun appel n'est indiqué. Référez-vous à la section Appels de haute
disponibilité ci-dessous pour plus de détails.
-L, --no-notify
Empêche rpc.statd de lancer la commande sm-notify lors de son démarrage, ce qui
conserve le numéro d'état NSM existant et la liste des machines surveillées
NB : La commande sm-notify a un mécanisme de vérification qui assure qu'elle n'est
lancée qu'une fois après chaque redémarrage du système. Cela permet d'éliminer les
fausses notifications de redémarrage si rpc.statd est relancé sans l'option -L.
-n, --name addrip | nomhôte
Cette chaîne est aussi utilisée par la commande sm-notify comme adresse source à
partir de laquelle sont émises les requêtes de notification de redémarrage.
L'addrip peut être donnée sous la forme d’adresse IPv4 ou IPv6. Si cette option est
omise, rpc.statd utilise une adresse joker comme adresse de lien pour le transport.
Consultez sm-notify(8) pour plus de détails.
-N Demande à rpc.statd de lancer la commande sm-notify, puis de quitter. Puisque
sm-notify peut être lancée directement, cette option n'est donc plus d'actualité.
-o, --outgoing-port port
Indique le numéro du port source que la commande sm-notify doit utiliser quand elle
envoie les notifications de redémarrage. Référez-vous à sm-notify(8) pour plus de
détails.
-p, --port port
Indique le numéro de port utilisé pour les sockets d'écoute RPC. Si cette option
est omise, rpc.statd essayera de consulter /etc/services. S’il réussit à obtenir un
port, il initialisera le même port pour tous les sockets d'écoute, sinon il
choisira un port aléatoire et éphémère pour chaque socket d'écoute.
Cette option peut être utilisée pour indiquer le numéro de port sur les écouteurs
quand les requêtes SM_NOTIFY doivent traverser un pare-feu entre les clients et les
serveurs.
-T, --nlm-port port
Indique le numéro de port que lockd doit écouter pour des requêtes NLM. Cela règle
à la fois les ports TCP et UDP à moins que le port UDP soit défini séparément.
-U, --nlm-udp-port port
Indique le numéro de port UDP que lockd doit écouter pour les requêtes NLM.
-P, --state-directory-path chemin
Précise le nom du répertoire parent où se trouvent les informations sur l'état NSM.
Si l'option n'est pas précisée, rpc.statd utilise /var/lib/nfs par défaut.
Après le démarrage, rpc.statd 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, rpc.statd a seulement besoin d’accéder aux
fichiers sm et sm.bak dans le chemin du répertoire d’états (state-directory-path).
-v, -V, --version
Demande à rpc.statd d'afficher sa version sur la sortie d'erreur standard puis de
quitter.
FICHIER DE CONFIGURATION
La plupart des options pouvant être indiquées sur la ligne de commande peuvent aussi être
contrôlées à l’aide de valeurs définies dans les sections [statd] ou, dans certains cas,
[lockd] du fichier de configuration /etc/nfs.conf. Les valeurs reconnues dans la section
[statd] incluent port, outgoing-port, state-directory-path et ha-callout qui ont chacune
le même effet que l’option de même nom.
Les valeurs reconnues dans la section [lockd] incluent port et udp-port qui ont chacune le
même effet, respectivement, que les options --nlm-port et --nlm-udp-port.
SÉCURITÉ
Le démon rpc.statd doit être lancé en tant que superutilisateur pour avoir le droit de
créer des sockets sur des ports source privilégiés et pour accéder à la base de données
d'informations d'états. Afin d'éviter les risques d'attaque par augmentation de droits,
risques accentués par le fait que rpc.statd est un service tournant longtemps, ce démon
abandonne les droits de superutilisateur dès son démarrage.
Dans le cas normal, l'ID utilisateur effectif utilisé est celui du propriétaire du
répertoire d'état, cela afin de lui permettre de continuer à accéder aux fichiers de ce
répertoire après l’abandon des 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.
Vous pouvez aussi protéger vos écouteurs rpc.statd en utilisant la bibliothèque
tcp_wrapper ou iptables(8). Si vous voulez utiliser la bibliothèque tcp_wrapper, ajoutez
les noms d'hôte des pairs dont l'accès est autorisé dans /etc/hosts.allow. Le nom du démon
sera statd, même si l'exécutable rpc.statd porte un nom différent.
Pour avoir plus d'informations, jetez un œil sur les pages de manuel de tcpd(8) et
hosts_access(5).
NOTES COMPLÉMENTAIRES
La récupération des verrous après redémarrage est essentielle au maintien de l'intégrité
des données et pour éviter des 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 au nom 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é.
Appels de haute disponibilité
rpc.statd peut lancer un programme d'appel spécifique lors d'un traitement réussi de
requêtes SM_MON, SM_UNMON et SM_NUMON_ALL ou de réception d’un SM_NOTIFY. Ce type de
programme peut être utilisé dans des environnements NFS de haute disponibilité (HA-NFS)
pour chercher les états de verrou qui pourraient avoir besoin d'être migrés suite à un
redémarrage du système.
Le nom du programme d'appel peut être indiqué par l'option -H. Le programme doit être
lancé avec 3 arguments. Le premier est add-client, del-client ou sm-notify selon la raison
de l’appel. Le deuxième est le nom_monit du pair observé. Le troisième est le nom_d'appel
du gestionnaire de blocage appelant pour add-client ou del-client, sinon c’est
l’adresse_IP de l’appelant envoyant SM_NOTIFY. Le quatrième est la valeur_état dans la
requête SM_NOTIFY.
Prise en charge d'IPv6 et TI-RPC
TI-RPC est nécessaire pour la prise en charge de NFS sur IPv6. Si la prise en charge de
TI-RPC est incluse dans rpc.statd, il essaye de démarrer l'écoute sur les transports
réseaux marqués comme « visible » dans le fichier /etc/netconfig. Tant qu’au moins un
écouteur de transport réseau démarre sans erreur, rpc.statd fonctionnera.
ENVIRONNEMENT
RPC_STATD_NO_NOTIFY=
Même effet que --no-notify si définie à une valeur entière positive.
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.
/run/run.statd.pid Fichier contenant le PID.
/etc/netconfig Base de données des capacités de transport en réseau.
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 »
RFC 1813 – « NFS Version 3 Protocol Specification »
OpenGroup Protocols for Interworking : XNFS, version 3W - Chapitre 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
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 RPC.STATD(8)