NOM¶
rrpc.statd - Démon du service NSM
SYNOPSIS¶
rpc.statd [
-dh?FLNvV] [
-H programme] [
-n
mon_nom] [
-o port-source] [
-p
port-d-écoute] [
-P chemin]
DESCRIPTION¶
Les systèmes de fichiers ne peuvent garder de manière persistante les
verrous de fichiers. Le verrou 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. 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émarre local, comment
reconnaître quel pair surveillé est en train d'émettre
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 appelée
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 des 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 chiffre 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
- Demande le démarrage de rpc.statd sans
lancement de sm-notify, ce qui conserve le numéro d'état
NSM et la liste des machines surveillées
- NB : La commande sm-notify a un mécanisme
de vérification qui s'assure qu'elle n'est lancée qu'une fois
après un redémarrage du système. Ceci permet
d'éliminer les fausses notifications de redémarrage si
rpc.statd est relancé sans l'option -L.
- -n, --name addrip |
nomhôte
- Indique l'adresse de lien utilisée pour les tuyaux
d'écoutes RPC. L' addrip peut être donnée 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 chaîne est aussi passée à
sm-notify comme adresse source à partir de laquelle sont
émises les notifications de redémarrage. Voir
sm-notify(8) pour plus de détails.
- -N
- Demande à 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'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 tuyaux
d'écoute RPC. Si cette option est omise, rpc.statd essayera de
consulter /etc/services, s'il réussi à obtenir un port,
il initialisera le même port pour tous les tuyaux d'écoute,
sinon il choisira un port aléatoire et éphémère pour
chaque tuyau 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.
- -P, --state-directory-path chemin
- Précise le nom du répertoire parent où se
trouvent les informations sour l'état NSM. Si l'option n'est pas
précisée, rpc.statd utilise /var/lib/nfs par
défaut.
- Après avoir démarrée, rpc.statd
essaye de prendre l'UID et le GID du propriétaire et du groupe
possédant ce répertoire.
- -v, -V, --version
- Demande à rpc.statd d'afficher sa version sur
la sortie d'erreur standard puis de quitter.
SÉCURITɶ
Le démon
rpc.statd doit être lancé en tant que
superutilisateur pour avoir le droit de créer un tuyau sur un port
privilégié, 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 quitte les
droits de superutilisateur dès son démarrage.
Dans le cas normal, l'ID utilisateur effectif utilisé est celui du
possesseur du répertoire d'état, ceci afin de lui permettre de
continuer à accéder aux fichiers de ce répertoire après
qu'il a quitté ses droits de superutilisateur. Pour contrôler l'ID
utilisateur que
rpc.statd prend, il suffit d'utiliser
chown(1)
pour changer le possesseur 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ôtes 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¶
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 votre système doit
correspondre au nom DNS que les pairs NFS utilisent pour se
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 ne doivent pas être contradictoires.
- Le nom d'hôte utilisé par le client pour monter
le serveur doit correspondre au nom_monit utilisé par le
serveur pour envoyer ses requêtes.
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. Ceci peut survenir, par exemple, sur un client NFS utilisant un
système de montage automatique, qui démonte 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ête SM_MON, SM_UNMON, et SM_NUMON_ALL. Ce
type de programme peut être utilisé dans un environnement NFS de
haute disponibilité pour chercher les verrous d'états 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 ou
del-client, selon le besoin. Le deuxième
est le
nom_monit du pair observé. Le troisième est le
nom_d'appel du gestionnaire d'accès appelant.
Prise en charge d'IPv6 et TI-RPC¶
TI-RPC est nécessaire pour la prise en charge d'IPv6 par NFS. Si la prise
en charge 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
que l'écouteur de transport démarre sans erreur,
rpc.statd
fonctionnera.
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.
- /var/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 »
RRFC 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¶
Cette page de manuel a été traduite par Thierry Vignaud <tvignaud
AT mandriva DOT com> en 2000 et mise à jour par Vanessa Cochondon
<nessie AT little-monster DOT org> La version présente 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.