Si seulement un ou deux clients sont confrontés à des symptômes indiquant une difficulté au niveau de la liaison NIS, les problèmes viennent probablement de ces clients. Reportez-vous à la section Problèmes NIS affectant un client. Si de nombreux clients NIS ne parviennent pas à se relier correctement, le problème se trouve probablement sur un ou plusieurs serveurs NIS.
Créez le fichier /etc/default/yppasswdd qui contient une chaîne spéciale : "check_restricted_shell_name=1".
Si la chaîne "check_restricted_shell_name=1" est commentée, la vérification 'r' n'est pas effectuée.
NIS peut s'arrêter brutalement si le réseau ou les serveurs NIS sont à tel point surchargés que le démon ypserv ne reçoit pas de réponse du processus ypbind client dans ce délai d'attente. NIS peut également s'arrêter brutalement lorsque le réseau est arrêté.
Dans ces circonstances, chaque client sur le réseau subit des problèmes identiques ou similaires. Dans la plupart des cas, le problème est temporaire. Les messages disparaissent généralement lorsque le serveur NIS réinitialise et redémarre ypserv, lorsque la charge sur les serveurs NIS ou sur le réseau lui-même diminue ou que le réseau reprend un fonctionnement normal.
Assurez-vous que les serveurs sont activés et en cours d'exécution. Si vous n'êtes pas physiquement près des serveurs, exécutez la commande ping.
Si les serveurs sont en cours d'exécution, essayez de trouver une machine client fonctionnant normalement et exécutez la commande ypwhich. Si ypwhich ne répond pas, arrêtez-la. Ensuite, connectez-vous avec le compte root sur le serveur NIS et vérifiez que le processus NIS est en cours d'exécution en entrant ce qui suit :
# ptree |grep ypbind 100759 /usr/lib/netsvc/yp/ypbind -broadcast 527360 grep yp
Si ni le démon ypserv (serveur NIS) ni le démon ypbind (client NIS) ne sont exécutés, redémarrez-les en saisissant ce qui suit :
# svcadm restart network/nis/client
Si les deux processus ypserv et ypbind sont en cours d'exécution sur le serveur NIS, exécutez la commande ypwhich. Si la commande ne répond pas, le démon ypserv s'est probablement arrêté brutalement et doit être redémarré. Lorsque vous êtes connecté au serveur en tant que root, redémarrez le service NIS en saisissant ce qui suit :
# svcadm restart network/nis/server
Etant donné que NIS propage les cartes entre les serveurs, il peut arriver que vous trouviez des versions différentes de la même carte sur plusieurs serveurs NIS du réseau. Cette différence de version est tout à fait normale et acceptable si les différences ne durent pas plus d'un court laps de temps.
La cause la plus fréquente de cette différence est un élément qui empêche la propagation normale des cartes. Par exemple, un serveur NIS ou un routeur entre les serveurs NIS est arrêté. Lorsque tous les serveurs NIS et les routeurs situés entre eux sont en cours d'exécution, ypxfr doit réussir.
Si les serveurs et les routeurs fonctionnent correctement, vérifiez les points suivants :
Consultez la sortie de journal ypxfr. Reportez-vous à la section Journalisation de la sortie ypxfr.
Vérifiez la présence éventuelle d'erreurs dans le fichier journal svc:/network/nis/xfr:default.
Vérifiez les fichiers de contrôle. Reportez-vous à la section Vérification du fichier crontab et du script shell ypxfr.
Vérifiez la carte ypservers sur le serveur maître. Reportez-vous à la section Vérification de la carte ypservers.
Si un serveur esclave a des problèmes de mise à jour des cartes, connectez-vous à ce serveur et exécutez la commande ypxfr de façon interactive. En cas d'échec de la commande, il indique la raison de l'échec et vous pouvez résoudre le problème. Si la commande réussit mais que vous suspectez qu'elle ait parfois échoué, créez un fichier journal afin de permettre la journalisation des messages. Pour créer un fichier journal, exécutez la commande suivante sur l'esclave.
ypslave# cd /var/yp ypslave# touch ypxfr.log
Cela crée un fichier ypxfr.log qui enregistre toutes les sorties de ypxfr.
Le résultat ressemble à la sortie affichée par ypxfr lorsqu'elle est exécutée en mode interactif, mais chaque ligne du fichier journal est horodatée. (Vous pouvez voir un ordre d'horodatage inhabituel. Ce n'est pas grave ; l'horodatage vous indique à quel moment l'exécution de ypxfr a démarré. Si des copies de ypxfr ont été exécutées simultanément, mais que leurs opérations n'ont pas duré le même temps, il se peut qu'elles écrivent leur ligne d'état de synthèse dans les fichiers journaux dans un ordre différent de celui dans lequel elles ont été appelées.) Tout type de défaillance intermittente apparaît dans le journal.
Inspectez le fichier root crontab et vérifiez le script de shell ypxfr qu'il appelle. Des erreurs typographiques dans ces fichiers peuvent provoquer des problèmes de propagation. Les échecs de référence à un script shell dans le fichier /var/spool/cron/crontabs/root ou les échecs de référence à une carte au sein de n'importe quel script shell peuvent également provoquer des erreurs.
Assurez-vous également que le serveur esclave NIS est répertorié dans la carte ypservers sur le serveur maître pour le domaine. Si ce n'est pas le cas, le serveur esclave fonctionne toujours parfaitement comme serveur, mais yppush ne propage pas les modifications apportées à la carte sur le serveur esclave.
Si le problème de serveur esclave NIS n'est pas évident, vous pouvez mettre en oeuvre une solution de contournement pendant le débogage du problème, à l'aide de la commande scp ou ssh afin de copier une version récente de la carte incohérente à partir d'un serveur NIS qui fonctionne correctement. Vous trouverez ci-dessous la présentation du transfert de la carte problématique :
ypslave# scp ypmaster:/var/yp/mydomain/map.\* /var/yp/mydomain
Le caractère * a été neutralisé dans la ligne de commande, de manière à le développer sur ypmaster et non localement sur ypslave.
Lorsque le processus ypserv s'arrête brutalement presque immédiatement et disparaît même après plusieurs activations, le processus de débogage est virtuellement identique à celui décrit à la section Arrêt brutal de la commande ypbind. Commencez par exécuter la commande suivante pour vérifier si des erreurs sont signalées :
# svcs -vx nis/server
Vérifiez l'existence du démon rpcbind comme suit :
# ptree |grep rpcbind
Redémarrez le serveur si vous ne trouvez pas le démon. Dans le cas contraire, si le démon est en cours d'exécution, saisissez ce qui suit et recherchez un résultat similaire :
% rpcinfo -p ypserver
% program vers proto port service 100000 4 tcp 111 portmapper 100000 3 tcp 111 portmapper 100068 2 udp 32813 cmsd ... 100007 1 tcp 34900 ypbind 100004 2 udp 731 ypserv 100004 1 udp 731 ypserv 100004 1 tcp 732 ypserv 100004 2 tcp 32772 ypserv
Votre machine peut avoir différents numéros de port. Les quatre entrées représentant le processus ypserv sont les suivantes :
100004 2 udp 731 ypserv 100004 1 udp 731 ypserv 100004 1 tcp 732 ypserv 100004 2 tcp 32772 ypserv
En l'absence d'entrée et si ypserv n'est pas en mesure d'enregistrer ses services avec rpcbind, redémarrez la machine. S'il y a des entrées, annulez l'enregistrement du service à partir de rpcbind avant de redémarrer ypserv. Pour annuler l'enregistrement du service à partir de rpcbind sur le serveur, saisissez ce qui suit.
# rpcinfo -d number 1 # rpcinfo -d number 2
Remplacez number par le numéro d'ID indiqué par rpcinfo (100004, dans l'exemple ci-dessus).