RPC.STATD
Table des matières
Retour à l'index
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.
SECURITÉ
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
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 à
Index
- NOM
-
- SYNOPSIS
-
- DESCRIPTION
-
- OPÉRATIONS NSM DANS LE DÉTAIL
-
- Notification de redémarrage
-
- OPTIONS
-
- FICHIER DE CONFIGURATION
-
- SECURITÉ
-
- NOTES COMPLÉMENTAIRES
-
- Appels de haute disponibilité
-
- Prise en charge d'IPv6 et TI-RPC
-
- ENVIRONNEMENT
-
- FICHIERS
-
- VOIR AUSSI
-
- AUTEURS
-
- TRADUCTION
-
This document was created by
man2html,
using the manual pages.
Time: 05:06:41 GMT, September 19, 2025