SM-NOTIFY(8) System Manager's Manual SM-NOTIFY(8) NOM sm-notify - Envoyer une notification de redemarrage aux pairs NFS SYNOPSIS /usr/sbin/sm-notify [-dfn] [-m minutes] [-v nom] [-p port-notification] [-P chemin] DESCRIPTION Les systemes de fichiers ne peuvent garder de maniere persistante l'etat du systeme de fichiers. L'etat des verrous est donc perdu lors du redemarrage de l'hote. Les systemes de fichiers en reseau doivent detecter si un etat verrouille est perdu a cause du redemarrage de l'hote. Apres le redemarrage d'un client NFS, le serveur NFS doit enlever tous les verrous de fichiers poses par des applications qui tournaient sur ce client. Apres un redemarrage du serveur, un client doit rappeler au serveur quels etaient les fichiers verrouilles par ses applications. Pour les versions 2 et 3 du protocole NFS, le protocole Network Status Monitor (ou NSM) est utilise pour avertir les pairs des redemarrages. Sous Linux, deux composants tournant en espace utilisateur fournissent un service NSM : sm-notify Un programme d'aide qui avertit les pairs NFS apres un redemarrage du systeme local rpc.statd Un demon qui ecoute les avertissements de redemarrage d'autres hotes et gere la liste des hotes qui doivent etre avertis quand le systeme local redemarre. Le gestionnaire de verrous NFS local indique au rpc.statd local quels sont les pairs qui doivent etre surveilles. Quand le systeme local redemarre, la commande sm-notify avertit le service NSM des hotes surveilles de son redemarrage. Quand un hote distant redemarre, ce pair notifie le rpc.statd local, qui en retour renvoie l'avertissement de redemarrage au gestionnaire de verrous NFS local. OPERATIONS NSM DANS LE DETAIL La premiere interaction visant a 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 surveille dans un fichier persistant. Ce fichier decrit la maniere de contacter un pair distant en cas de redemarrage local, comment reconnaitre quel pair surveille est en train d'emettre et comment notifier au gestionnaire de verrous local qu'un pair surveille signifie son redemarrage. Un client NFS envoie un nom d'hote, appele nom_d'appel (<< caller_name >>) du client, pour chaque demande de verrou de fichier. Un serveur NFS peut utiliser ce nom d'hote pour envoyer des appels GRANT asynchrones au client, ou pour avertir le client de son redemarrage. Le serveur NFS Linux peut fournir le nom_d'appel du client ou son adresse reseau a rpc.statd. Pour les besoins du protocole NSM, ce nom (ou cette adresse) est connu comme nom_monit du pair observe. En meme temps, le gestionnaire de verrous local indique a rpc.statd son propre nom d'hote suppose. Pour les besoins du protocole NSM, ce nom d'hote est appele mon_nom. Il n'y a pas d'interactions equivalentes 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 requete SM_NOTIFY. Le client NFS Linux enregistre le nom d'hote du serveur utilise dans une commande mount pour identifier les serveurs NFS qui redemarrent. Notification de redemarrage Quand le systeme local redemarre, la commande sm-notify lit sur un stockage persistant la liste des pairs surveilles et envoie une requete SM_NOTIFY au service NSM tournant sur chacun des pairs listes. Il utilise la chaine nom_monit comme destination. Pour identifier l'hote ayant redemarre, la commande sm-notify envoie la chaine mon_nom enregistree lors de la surveillance de ce poste distant. Le demon rpc.statd distant utilise cette chaine (ou l'adresse reseau de l'appelant) pour lier les requetes SM_NOTIFY entrantes a un ou plusieurs pairs sur sa propre liste de surveillance. Si rpc.statd ne trouve pas un pair dans sa propre liste d'hotes surveilles lie a une requete SM_NOTIFY, la notification n'est pas transmise au gestionnaire de verrous local. En plus, chaque pair possede son propre numero d'etat NSM, un entier de 32 bits qui est change apres chaque redemarrage par la commande sm-notify. rpc.statd utilise ce chiffre pour separer les redemarrages reels des notifications reenvoyees. Une partie de la recuperation de verrous NFS est la redecouverte des pairs qui doivent etre a nouveaux surveilles. La commande sm-notify nettoie la liste de surveillance stockee sur un stockage permanent apres chaque redemarrage. OPTIONS -d Garder sm-notify attache a son terminal de controle et visible au premier plan afin que la progression des notifications puisse etre directement observee. -f Envoyer les notifications meme si sm-notify a deja ete lance depuis le redemarrage du systeme. -m delai_nouvel_essai Indiquer la duree (en minute) entre deux essais de notifications a des hotes sourds. Si cette option n'est pas indiquee, sm-notify notifie toutes les 15 minutes. Donner la valeur 0 pousse sm-notify a envoyer continuellement des notifications aux hotes sourds jusqu'a ce qu'il soit tue manuellement. Les notifications sont reemises si l'envoi echoue, si l'hote distant ne repond pas, si le service NSM distant n'est pas enregistre ou si la resolution DNS echoue, ce qui empeche l'adressage de l'hote distant nom_monit. Les hotes ne sont pas supprimes de la liste des notifications tant qu'aucune reponse valable n'est recue. Cependant, la procedure SM_NOTIFY renvoie un resultat vide. sm-notify ne peut donc pas dire si la machine distante a reconnu l'emetteur et a commence la recuperation idoine de verrous. -n Empecher sm-notify de mettre a jour le numero d'etat NSM du systeme local. -p port Indiquer le numero de port source que sm-notify doit utiliser pour envoyer les notifications de redemarrage. Si cette option n'est pas precisee, un port ephemere est choisi au hasard. Cette option peut etre utilisee pour traverser un pare-feu entre le client et le serveur. -P, --state-directory-path chemin Donner le chemin du repertoire parent ou les notifications d'etat NSM sont enregistrees. Si cette option n'est pas precisee, sm-notify utilisera /var/lib/nfs par defaut Apres le demarrage, sm-notify essaie de definir les UID et GID effectifs a ceux du groupe et d'utilisateur du sous-repertoire sm de ce repertoire. Apres la modification des identifiants effectifs, sm-notify a seulement besoin d'acceder aux fichiers sm et sm.bak dans le chemin du repertoire d'etats (state-directory-path). -v ipaddr | nom_hote Indiquer l'adresse reseau a partir de laquelle seront envoyees les notifications de redemarrage, ainsi que l'argument nom_monit utilise pour l'envoi de requetes SM_NOTIFY. Si cette option n'est pas precisee, sm-notify utilise une adresse joker comme adresse de transport et la variable mon_nom enregistree lors de la surveillance du poste distant comme argument nom_monit pour l'envoi des requetes SM_NOTIFY). Le champ addrip peut etre 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'hote qui servira d'arguments a nom_monit lors de l'envoi de requetes SM_NOTIFY. Cette option peut etre utile dans des reseaux partages entre plusieurs lieux pour lesquels l'hote distant attend une notification provenant d'une adresse reseau precise. FICHIER DE CONFIGURATION La plupart des options pouvant etre indiquees sur la ligne de commande peuvent aussi etre controlees a l'aide de valeurs definies 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 meme effet, respectivement, que les options m, p et v Une autre valeur reconnue dans la section [sm-notify] est lift-grace. Par defaut, sm-notify transformera la periode de grace de lockd rapidement s'il n'a aucun hote a informer. Certaines configurations de haute disponibilite executeront un sm-notify par adresse IP variable. Dans ces configurations, transformer la periode de grace peut rapidement empecher des clients de recuperer des verrous. Regler lift-grace a n empeche sm-notify de mettre rapidement fin a la periode de grace. lift-grace n'a pas d'option de ligne de commande correspondante. La valeur reconnue dans la section [statd] est state-directory-path. SECURITE La commande sm-notify doit etre lancee en superutilisateur afin d'avoir les privileges suffisants pour acceder a la base d'informations d'etats. Elle abandonne les droits de superutilisateur des qu'elle demarre afin de reduire les risques d'attaque par augmentation de droits. Dans le cas normal, l'ID utilisateur effectif utilise est celui du proprietaire du repertoire d'etats, cela afin de lui permettre de continuer a acceder aux fichiers de ce repertoire apres qu'il a abandonne ses droits de superutilisateur. Pour controler l'ID utilisateur que rpc.statd prend, il suffit d'utiliser chown(1) pour changer le proprietaire du repertoire d'etat. NOTES La recuperation des verrous apres un redemarrage est indispensable au maintien de l'integrite des donnees et a la prevention de blocages non necessaires d'applications. Afin d'aider rpc.statd a faire correspondre les requetes SM_NOTIFY aux requetes NLM, un certain nombre de bonnes pratiques doivent etre respectees. Par exemple : Le nom du noeud UTS de vos systemes doit correspondre aux noms DNS que les pairs NFS utilisent pour les contacter. Les noms de noeuds UTS de vos systemes doivent toujours etre des noms de domaine pleinement qualifies (<< FQDN >>). Les translations DNS directes et inverses des noms de noeuds UTS doivent etre coherentes. Le nom d'hote utilise par le client pour monter le serveur doit correspondre au nom_monit utilise dans les requetes SM_NOTIFY qu'il envoie. Demonter un systeme de fichiers NFS n'empeche pas le client NFS ou le serveur de se surveiller. Les deux peuvent continuer a se surveiller pendant un moment au cas ou la reprise du trafic entre les deux entrainerait de nouveaux montages et d'autres verrous de fichiers. Sous Linux, et en conditions normales d'operation, le dechargement du module lockd du noyau entraine l'arret de la surveillance des pairs NFS. Cela peut survenir, par exemple, sur un client NFS utilisant un systeme de montage automatique qui demonte tous les systemes NFS suite a une inactivite. 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 ete incluse dans la commande sm-notify, le choix entre le mode IPv4 ou IPv6 est fait en fonction de l'adresse reseau retournee par DNS pour les clients distants. Ce systeme est normalement parfaitement compatible avec les machines qui ne gerent 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 Repertoire contenant la liste des moniteurs. /var/lib/nfs/sm.bak Repertoire contenant la liste des notifications. /var/lib/nfs/state Numero d'etat NSM de cet hote. /proc/sys/fs/nfs/nsm_local_state Copie du numero d'etat 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 Chuck Lever TRADUCTION La traduction francaise de cette page de manuel a ete creee par Valery Perrin , Sylvain Cherrier , Thomas Huriaux , Dominique Simen , Nicolas Sauzede , Romain Doumenc , David Prevot , Denis Mugnier , Cedric Boutillier et Jean-Paul Guillonneau Cette traduction est une documentation libre ; veuillez vous reporter a la GNU General Public License version 3 concernant les conditions de copie et de distribution. Il n'y a aucune RESPONSABILITE LEGALE. Si vous decouvrez un bogue dans la traduction de cette page de manuel, veuillez envoyer un message a . 1 Novembre 2009 SM-NOTIFY(8)