sm-notify - Envoyer une notification de redémarrage aux pairs NFS
/usr/sbin/sm-notify [
-dfn] [
-m minutes] [
-v
nom] [
-p port-notification] [
-P chemin]
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. 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.
Pour les versions 2 et 3 du protocole NFS, le protocole
Network Status
Monitor (ou NSM) est utilisé pour avertir les pairs des
redémarrages. Sous Linux, deux composants tournant en espace
utilisateur fournissent un service NSM :
- sm-notify
- Un programme d'aide qui avertit les pairs NFS après
un redémarrage du système local
- 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.
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é est en train
d'émettre 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'y a pas d'interactions équivalentes entre un serveur NFS et un
client pour donner au client le
nom_d'appel du serveur. C'est pourquoi
les clients NFS ne connaissent pas le
nom_monit qu'un serveur NFS peut
utiliser dans une requête SM_NOTIFY. Le client NFS Linux enregistre le
nom d'hôte du serveur utilisé dans une commande mount pour
identifier les serveurs NFS qui redémarrent.
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 de ce 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 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.
- -d
- Garder sm-notify attaché à son
terminal de contrôle et visible au premier plan afin que la
progression des notifications puisse être directement
observée.
- -f
- Envoyer les notifications même si sm-notify a
déjà été lancé depuis le
redémarrage du système.
-
-m délai_nouvel_essai
- Indiquer la durée (en minute) entre deux essais de
notifications à des hôtes sourds. Si cette option n'est pas
indiquée, sm-notify notifie toutes les 15 minutes.
Donner la valeur 0 pousse sm-notify à envoyer
continuellement des notifications aux hôtes sourds jusqu'à
ce qu'il soit tué manuellement.
- Les notifications sont réémises si l'envoi
échoue, si l'hôte distant ne répond pas, si le
service NSM distant n'est pas enregistré ou si la résolution
DNS échoue, ce qui empêche l'adressage de l'hôte
distant nom_monit.
- Les hôtes ne sont pas supprimés de la liste
des notifications tant qu'aucune réponse valable n'est
reçue. Cependant, la procédure SM_NOTIFY renvoie un
résultat vide. sm-notify ne peut donc pas dire si la machine
distante a reconnu l'émetteur et a commencé la
récupération idoine de verrous.
- -n
- Empêcher sm-notify de mettre à jour le
numéro d'état NSM du système local.
-
-p port
- Indiquer le numéro de port source que
sm-notify doit utiliser pour envoyer les notifications de
redémarrage. Si cette option n'est pas précisée, un
port éphémère est choisi au hasard.
- Cette option peut être utilisée pour
traverser un pare-feu entre le client et le serveur.
-
-P, --state-directory-path chemin
- Donner le chemin du répertoire parent où les
notifications d'état NSM sont enregistrées. Si cette option
n'est pas précisée, sm-notify utilisera
/var/lib/nfs par défaut
- Après le démarrage, sm-notify 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, sm-notify a seulement besoin d’accéder aux
fichiers sm et sm.bak dans le chemin du répertoire
d’états (state-directory-path).
-
-v ipaddr | nom_hôte
- Indiquer l'adresse réseau à partir de
laquelle seront envoyées les notifications de redémarrage,
ainsi que l'argument nom_monit utilisé pour l'envoi de
requêtes SM_NOTIFY. Si cette option n'est pas
précisée, sm-notify utilise une adresse joker comme
adresse de transport et la variable mon_nom enregistrée lors
de la surveillance du poste distant comme argument nom_monit pour
l'envoi des requêtes SM_NOTIFY).
- Le champ addrip peut être sous la forme d'une
adresse IPv4 ou IPv6. Si le champ addrip est fourni, la commande
sm-notify convertit cette adresse en un nom d'hôte qui
servira d'arguments à nom_monit lors de l'envoi de
requêtes SM_NOTIFY.
- Cette option peut être utile dans des réseaux
partagés entre plusieurs lieux pour lesquels l'hôte distant
attend une notification provenant d'une adresse réseau
précise.
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
[sm-notify]
ou, dans un cas,
[statd] du fichier de configuration
/etc/nfs.conf.
Les valeurs reconnues dans la section
[sm-notify] incluent
retry-time,
outgoing-port et
outgoing-addr. Elles ont le
même effet, respectivement, que les options
m,
p
et
v
Une autre valeur reconnue dans la section
[sm-notify] est
lift-grace. Par défaut,
sm-notify transformera la
période de grâce de
lockd rapidement s’il
n’a aucun hôte à informer. Certaines configurations de
haute disponibilité exécuteront un
sm-notify par adresse
IP variable. Dans ces configurations, transformer la période de
grâce peut rapidement empêcher des clients de
récupérer des verrous. Régler
lift-grace à
n empêche
sm-notify de mettre rapidement fin à la
période de grâce.
lift-grace n’a pas
d’option de ligne de commande correspondante.
La valeur reconnue dans la section
[statd] est
state-directory-path.
La commande
sm-notify doit être lancée en superutilisateur
afin d'avoir les privilèges suffisants pour accéder à la
base d'informations d'états. Elle abandonne les droits de
superutilisateur dès qu'elle démarre afin de réduire les
risques d'attaque par augmentation de droits.
Dans le cas normal, l'ID utilisateur effectif utilisé est celui du
propriétaire du répertoire d'états, cela afin de lui
permettre de continuer à accéder aux fichiers de ce
répertoire après qu'il a abandonné ses 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.
La récupération des verrous après un redémarrage est
indispensable au maintien de l'intégrité des données et
à la prévention de 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 aux noms 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é.
L'utilisation d'IPv6 par NFS requiert TI-RPC. Si la prise en charge de TI-RPC a
été incluse dans la commande
sm-notify, le choix entre le
mode IPv4 ou IPv6 est fait en fonction de l'adresse réseau
retournée par DNS pour les clients distants. Ce système est
normalement parfaitement compatible avec les machines qui ne gèrent ni
TI-RPC, ni IPv6.
La commande
sm-notify ne prend pour l'instant en charge que l'envoi des
notifications uniquement par les protocoles de transport en datagramme.
- /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.
- /proc/sys/fs/nfs/nsm_local_state
- Copie du numéro d'état NSM dans le
noyau.
rpc.statd(8),
nfs(5),
uname(2),
hostname(7)
RFC 1094 – « NFS : Network File System
Protocol Specification »
RFC 1813 – « NFS Version 3 Protocol
Specification »
OpenGroup Protocols for Interworking : XNFS, version 3W -
Chapitre 11
Olaf Kirch <
[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]