RPC.STATD(8) System Manager's Manual RPC.STATD(8) NOM rrpc.statd - Demon du service NSM SYNOPSIS rpc.statd [-dh?FLNvV] [-H programme] [-n mon_nom] [-o port-source] [-p port-ecoute] [-P chemin] [--nlm-port port] [--nlm-udp-port port] 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 distant. 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. Dans les versions 2 (RFC1094) et 3 (RFC1813) de NFS, on utilise le protocole NSM (Network Status Monitor) pour notifier les redemarrages aux pairs. Sous Linux, le service NSM est constitue de deux composants tournant en espace utilisateur : 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. sm-notify Un programme d'aide qui avertit les pairs NFS apres un redemarrage du systeme local 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 notifie son redemarrage 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'existe pas d'interaction equivalente 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 connait pas reellement le nom_monit qui sera utilise dans une requete SM_NOTIFY. Le client NFS Linux utilise le nom d'hote du serveur donne a la commande mount pour identifier le serveur NFS qui redemarre. 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 du 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 nombre pour separer les redemarrages reels des notifications re-envoyees. 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, --no-syslog En conjonction avec l'option -F, demande a rpc.statd d'envoyer ses messages vers la sortie d'erreur standard plutot que vers le journal systeme. -F, --foreground Force rpc.statd a rester dans son terminal de controle pour permettre de surveiller directement, ou a l'aide d'un debogueur, les operations NSM. Si cette option n'est pas donnee, rpc.statd passe en arriere-plan apres son demarrage. -h, -?, --help Demande a 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 disponibilite. Si cette option est laissee vide, aucun appel n'est indique. Referez-vous a la section Appels de haute disponibilite ci-dessous pour plus de details. -L, --no-notify Empeche rpc.statd de lancer la commande sm-notify lors de son demarrage, ce qui conserve le numero d'etat NSM existant et la liste des machines surveillees NB : La commande sm-notify a un mecanisme de verification qui assure qu'elle n'est lancee qu'une fois apres chaque redemarrage du systeme. Cela permet d'eliminer les fausses notifications de redemarrage si rpc.statd est relance sans l'option -L. -n, --name addrip | nomhote Cette chaine est aussi utilisee par la commande sm-notify comme adresse source a partir de laquelle sont emises les requetes de notification de redemarrage. L'addrip peut etre donnee 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 details. -N Demande a rpc.statd de lancer la commande sm-notify, puis de quitter. Puisque sm-notify peut etre lancee directement, cette option n'est donc plus d'actualite. -o, --outgoing-port port Indique le numero du port source que la commande sm-notify doit utiliser quand elle envoie les notifications de redemarrage. Referez-vous a sm-notify(8) pour plus de details. -p, --port port Indique le numero de port utilise pour les sockets d'ecoute RPC. Si cette option est omise, rpc.statd essayera de consulter /etc/services. S'il reussit a obtenir un port, il initialisera le meme port pour tous les sockets d'ecoute, sinon il choisira un port aleatoire et ephemere pour chaque socket d'ecoute. Cette option peut etre utilisee pour indiquer le numero de port sur les ecouteurs quand les requetes SM_NOTIFY doivent traverser un pare-feu entre les clients et les serveurs. -T, --nlm-port port Indique le numero de port que lockd doit ecouter pour des requetes NLM. Cela regle a la fois les ports TCP et UDP a moins que le port UDP soit defini separement. -U, --nlm-udp-port port Indique le numero de port UDP que lockd doit ecouter pour les requetes NLM. -P, --state-directory-path chemin Precise le nom du repertoire parent ou se trouvent les informations sur l'etat NSM. Si l'option n'est pas precisee, rpc.statd utilise /var/lib/nfs par defaut. Apres le demarrage, rpc.statd 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, rpc.statd a seulement besoin d'acceder aux fichiers sm et sm.bak dans le chemin du repertoire d'etats (state-directory-path). -v, -V, --version Demande a rpc.statd d'afficher sa version sur la sortie d'erreur standard puis de quitter. 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 [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 meme effet que l'option de meme nom. Les valeurs reconnues dans la section [lockd] incluent port et udp-port qui ont chacune le meme effet, respectivement, que les options --nlm-port et --nlm-udp-port. SECURITE Le demon rpc.statd doit etre lance en tant que superutilisateur pour avoir le droit de creer des sockets sur des ports source privilegies et pour acceder a la base de donnees d'informations d'etats. Afin d'eviter les risques d'attaque par augmentation de droits, risques accentues par le fait que rpc.statd est un service tournant longtemps, ce demon abandonne les droits de superutilisateur des son demarrage. Dans le cas normal, l'ID utilisateur effectif utilise est celui du proprietaire du repertoire d'etat, cela afin de lui permettre de continuer a acceder aux fichiers de ce repertoire apres l'abandon des 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. Vous pouvez aussi proteger vos ecouteurs rpc.statd en utilisant la bibliotheque tcp_wrapper ou iptables(8). Si vous voulez utiliser la bibliotheque tcp_wrapper, ajoutez les noms d'hote des pairs dont l'acces est autorise dans /etc/hosts.allow. Le nom du demon sera statd, meme si l'executable rpc.statd porte un nom different. Pour avoir plus d'informations, jetez un oeil sur les pages de manuel de tcpd(8) et hosts_access(5). NOTES COMPLEMENTAIRES La recuperation des verrous apres redemarrage est essentielle au maintien de l'integrite des donnees et pour eviter des 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 au nom 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. Appels de haute disponibilite rpc.statd peut lancer un programme d'appel specifique lors d'un traitement reussi de requetes SM_MON, SM_UNMON et SM_NUMON_ALL ou de reception d'un SM_NOTIFY. Ce type de programme peut etre utilise dans des environnements NFS de haute disponibilite (HA-NFS) pour chercher les etats de verrou qui pourraient avoir besoin d'etre migres suite a un redemarrage du systeme. Le nom du programme d'appel peut etre indique par l'option -H. Le programme doit etre lance avec 3 arguments. Le premier est add-client, del-client ou sm-notify selon la raison de l'appel. Le deuxieme est le nom_monit du pair observe. Le troisieme 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 quatrieme est la valeur_etat dans la requete SM_NOTIFY. Prise en charge d'IPv6 et TI-RPC TI-RPC est necessaire 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 demarrer l'ecoute sur les transports reseaux marques comme << visible >> dans le fichier /etc/netconfig. Tant qu'au moins un ecouteur de transport reseau demarre sans erreur, rpc.statd fonctionnera. ENVIRONNEMENT RPC_STATD_NO_NOTIFY= Meme effet que --no-notify si definie a une valeur entiere positive. 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. /run/run.statd.pid Fichier contenant le PID. /etc/netconfig Base de donnees des capacites de transport en reseau. 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 >> RFC 1813 - << NFS Version 3 Protocol Specification >> OpenGroup Protocols for Interworking : XNFS, version 3W - Chapitre 11 AUTEURS Jeff Uphoff Olaf Kirch H.J. Lu Lon Hohberger Paul Clements 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 RPC.STATD(8)