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. Voir la section Dépannage des problèmes de NIS affectant un seul client Toutefois, si de nombreux clients NIS ne parviennent pas à se lier correctement, le problème se situe probablement sur un ou plusieurs serveurs NIS.
Voici quelques problèmes de NIS fréquents pouvant affecter plusieurs clients :
rpc.yppasswdd considère un shell non limité commençant par r à restreindre
Pour résoudre ce problème, procédez comme suit :
Créez un fichier /etc/default/yppasswdd contenant 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'a pas lieu.
Réseau ou serveurs inaccessibles
Le NIS peut se bloquer si le réseau ou les serveurs NIS sont tellement surchargés que le démon ypserv ne peut recevoir aucune réponse du processus ypbind du client en respectant le délai d'expiration. NIS peut également s'arrêter brutalement lorsque le réseau est arrêté.
Dans les deux cas, chaque client sur le réseau connaît des problèmes identiques ou similaires. Dans la plupart des cas, le problème est temporaire. Généralement, les messages disparaissent lorsque le serveur NIS est réinitialisé et redémarre le démon ypserv, lorsque la charge sur les serveurs NIS ou le réseau lui-même diminue, ou lorsque le réseau recommence à fonctionner normalement.
Dysfonctionnement du serveur
Assurez-vous que les serveurs sont activés et en cours d'exécution. Si vous n'êtes pas physiquement près des serveurs, utilisez la commande ping pour déterminer si le serveur est accessible.
Démons NIS inactifs
Si les serveurs sont en cours d'exécution, essayez de trouver un client se comportant normalement et exécutez dessus la commandeypwhich. Si la commande ypwhich ne répond pas, interrompez-la. Puis, connectez-vous avec le compte root sur le serveur NIS et vérifiez que le processus NIS s'exécute comme 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 s'exécutent, redémarrez-les comme suit :
Redémarrez le service client NIS comme 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 est probablement bloqué et doit être redémarré.
Sur le serveur, redémarrez le service de la manière suivante :
# svcadm restart network/nis/server
Les serveurs ont des versions différentes d'une carte NIS
Etant donné que le NIS propage les cartes entre les serveurs, il peut arriver que vous trouviez des versions différentes d'une même carte sur plusieurs serveurs NIS du réseau. Cette différence de version est normale et acceptable si ces différences ne s'éternisent pas.
Cette différence de carte s'explique généralement par un blocage de la propagation normale des cartes. Par exemple, un serveur NIS ou un routeur situé 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, la commande ypxfr doit aboutir.
Si les serveurs et les routeurs fonctionnent correctement, procédez comme suit :
Consultez la sortie de journal ypxfr. Voir l'Example 3–1.
Vérifiez la présence éventuelle d'erreurs dans le fichier journal svc:/network/nis/xfr:default.
Vérifiez les fichiers de contrôle (fichier crontab et fichier de script yupxfr).
Vérifiez la carte ypservers sur le serveur maître.
Le processus ypserv s'arrête
Lorsque le processus ypserv s'arrête presque instantanément et disparaît même après plusieurs activations, le processus de débogage est quasiment le même que celui à appliquer en cas d'arrêt du processus 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, exécutez la commande suivante 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
Dans l'exemple précédent, les quatre entrées suivantes représentent le processus ypserv :
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ées, et si ypserv ne peut enregistrer ses services avec rpcbind, réinitialisez le système. Si des entrées sont présentes, annulez l'enregistrement du service à partir de rpcbind avant de redémarrer ypserv. Par exemple, annulez l'enregistrement du service à partir de rpcbind en procédant comme suit :
# rpcinfo -d number 1 # rpcinfo -d number 2
où number est le numéro d'ID rapporté par rpcinfo (100004 dans l'exemple précédent).
Si un serveur esclave particulier rencontre des problèmes de mise à jour des cartes, connectez-vous au serveur et exécutez la commande ypxfr de manière interactive.
En cas d'échec de la commande, un message expliquant la cause de cet échec apparaît pour vous permettre de résoudre le problème. Si la commande aboutit mais que vous suspectez qu'elle ait parfois échoué, créez un fichier journal sur le serveur esclave afin de permettre la journalisation des messages comme suit :
ypslave# cd /var/yp ypslave# touch ypxfr.log
La sortie du fichier journal ressemble à la sortie de la commande ypxfr lorsque vous l'exécutez en mode interactif, à ceci près que chaque ligne du journal est horodatée. Tout ordre d'horodatage inhabituel s'explique par le fait que celui-ci s'affiche à chaque fois que la commande ypxfr est exécutée. Si des copies de ypxfr ont été exécutées en simultané mais avec des durées différentes, il se peut que chaque copie ait inscrit une ligne de statut récapitulative dans le fichier journal, dans un ordre différent par rapport au moment où la commande a été exécutée. Tout type de défaillance intermittente apparaît dans le journal.
Vérifiez le fichier crontab et le fichier shell ypxfr.
Inspectez le fichier root crontab et vérifiez le script de shell ypxfr invoqué. 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.
Vérifiez la carte ypservers.
Assurez-vous également que le serveur esclave est répertorié dans la carte ypservers sur le serveur maître du domaine. Dans le cas contraire, le serveur esclave fonctionne quand même parfaitement en tant que serveur, mais yppush ne propage pas les modifications apportées à la carte sur le serveur esclave.
Mettez les cartes à jour sur un serveur esclave interrompu.
Si le problème du serveur esclave NIS n'est pas flagrant, vous pouvez contourner le problème pendant son débogage à l'aide des commandes scp ou ssh. Ces commandes copient une version récente de la carte incohérente à partir de n'importe quel serveur NIS fonctionnant correctement.
L'exemple suivant illustre le transfert de la carte problématique :
ypslave# scp ypmaster:/var/yp/mydomain/map.\* /var/yp/mydomain
Dans l'exemple précédent, le caractère * a été neutralisé dans la ligne de commande de manière à le développer sur ypmaster, et non localement sur ypslave.