rrpc.statd - Démon du service NSM
rpc.statd [
-dh?FLNvV] [
-H programme] [
-n
mon_nom] [
-o port-source] [
-p
port-écoute] [
-P chemin] [
--nlm-port
port] [
--nlm-udp-port port]
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.
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.
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.
-
-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.
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.
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).
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é.
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.
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.
- RPC_STATD_NO_NOTIFY=
- Même effet que --no-notify si définie
à une valeur entière positive.
- /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.
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
Jeff Uphoff <
[email protected]>
Olaf Kirch <
[email protected]>
H.J. Lu <
[email protected]>
Lon Hohberger <
[email protected]>
Paul Clements <
[email protected]>
Chuck Lever <
[email protected]>
La traduction française de cette page de manuel a été
créée par Valéry Perrin
<
[email protected]>, Sylvain Cherrier
<
[email protected]>, Thomas Huriaux
<
[email protected]>, Dominique Simen
<
[email protected]>, Nicolas Sauzède
<
[email protected]>, Romain Doumenc <
[email protected]>, David
Prévot <
[email protected]>, Denis Mugnier
<
[email protected]>, Cédric Boutillier
<
[email protected]> et Jean-Paul Guillonneau
<
[email protected]>
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 à
[email protected]