SM-NOTIFY(8) System Manager's Manual SM-NOTIFY(8)
NOM
sm-notify - Envoyer une notification de redémarrage aux pairs NFS
SYNOPSIS
/usr/sbin/sm-notify [-dfn] [-m minutes] [-v nom] [-p port-notification]
[-P chemin]
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 ver-
rouillé est perdu à cause du redémarrage de l'hôte. Après le redémar-
rage 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émar-
rage 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 re-
démarre, la commande sm-notify avertit le service NSM des hôtes sur-
veillé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é est en train d'émettre et comment notifier au gestion-
naire de verrous local qu’un pair surveillé signifie son redémarrage.
Un client NFS envoie un nom d'hôte, appelé nom_d'appel (« cal-
ler_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.
Notification de redémarrage
Quand le système local redémarre, la commande sm-notify lit sur un sto-
ckage 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 uti-
lise 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 enre-
gistré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 sur-
veillés lié à une requête SM_NOTIFY, la notification n'est pas trans-
mise 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éen-
voyé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 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é de-
puis 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-no-
tify 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 enre-
gistré ou si la résolution DNS échoue, ce qui empêche l'adres-
sage 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 com-
mencé la récupération idoine de verrous.
-n Empêcher sm-notify de mettre à jour le numéro d'état NSM du sys-
tè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éci-
sé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 ef-
fectifs, sm-notify a seulement besoin d’accéder aux fichiers sm
et sm.bak dans le chemin du répertoire d’états (state-direc-
tory-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 notifi-
cation provenant d'une adresse réseau précise.
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 [sm-notify] ou, dans un cas, [statd] du fichier de configura-
tion /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, respective-
ment, 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 rapide-
ment 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 em-
pêcher des clients de récupérer des verrous. Régler lift-grace à n em-
pê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.
SÉCURITÉ
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 pro-
priétaire du répertoire d'états, cela afin de lui permettre de conti-
nuer à 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.
NOTES
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 res-
pecté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é.
Prise en charge d'IPv6 et TI-RPC
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 com-
patible 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.
FICHIERS
/var/lib/nfs/sm Répertoire contenant la liste des moniteurs.
/var/lib/nfs/sm.bak Répertoire contenant la liste des notifica-
tions.
/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.
VOIR AUSSI
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
AUTEURS
Olaf Kirch <okir@suse.de>
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.cher-
rier@free.fr>, Thomas Huriaux <thomas.huriaux@gmail.com>, Dominique Si-
men <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.boutil-
lier@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 SM-NOTIFY(8)
Generated by dwww version 1.15 on Sat Jun 29 01:35:43 CEST 2024.