Problèmes de liaison NIS

Symptômes des problèmes de liaison NIS

Les symptômes habituels des problèmes de liaison NIS sont les suivants.

Messages stipulant que ypbind ne parvient pas à identifier un serveur ni à communiquer avec lui
Messages indiquant que le serveur ne répond pas
Messages disant que NIS n'est pas disponible
Les commandes d'un client ralentissent en mode d'arrière-plan ou fonctionnent beaucoup plus lentement que la normale
Blocage des commandes sur un client. Il arrive parfois que les commandes se bloquent, bien que l'ensemble du système semble en état de fonctionnement et que vous pouvez effectuer de nouvelles commandes
Les commandes d'un client s'arrêtent brutalement en affichant des messages peu clairs ou aucun message.

Problèmes NIS affectant un client

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. Si de nombreux clients NIS ne parviennent pas à se relier correctement, le problème se trouve probablement sur un ou plusieurs serveurs NIS. Reportez-vous à la section Problèmes NIS affectant de nombreux clients.

`ypbind` n'est pas en cours d'exécution sur un client

Un client rencontre des problèmes mais d'autres clients du même sous-réseau fonctionnent normalement. Sur le client qui pose problème, exécutez ls - l sur un répertoire, par exemple /usr, contenant les fichiers détenus par de nombreux utilisateurs, y compris ceux qui ne se trouvent pas dans le fichier /etc/passwd du client. Si l'affichage présenté répertorie des propriétaires de fichiers qui ne sont pas dans les fichiers /etc/passwd locaux sous forme de numéros, plutôt que de noms, cela indique que le service NIS ne fonctionne pas sur le client.

Ces symptômes signifient généralement que le processus ypbind client n'est pas en cours d'exécution. Assurez-vous que les services du client NIS sont en cours d'exécution.

client# svcs \*nis\*
STATE          STIME    FMRI
disabled       Sep_01   svc:/network/nis/domain:default
disabled       Sep_01   svc:/network/nis/client:default

Si les services se trouvent dans l'état disabled, connectez-vous en tant qu'utilisateur root ou prenez un rôle équivalent, puis redémarrez le service client NIS.

client# svcadm enable network/nis/domain
client# svcadm enable network/nis/client

Nom de domaine manquant ou incorrect

Un client rencontre des problèmes, les autres clients fonctionnent normalement, mais ypbind est en cours d'exécution sur le client problématique. Le client peut avoir défini le domaine de manière incorrecte.

Sur le client, exécutez la commande domainname pour voir le nom de domaine défini.

client7# domainname
example.com

Comparez la sortie avec le nom de domaine réel dans /var/yp sur le server maître NIS. Le vrai domaine NIS est affiché sous la forme d'un sous-répertoire dans le répertoire /var/yp.

client7# ls -l /var/yp
-rwxr-xr-x 1 root Makefile
drwxr-xr-x 2 root binding
drwx------ 2 root example.com

Si le nom de domaine renvoyé en exécutant domainname sur une machine n'est pas identique au nom de domaine du serveur répertorié en tant que répertoire dans /var/yp, le nom de domaine spécifié dans le fichier /etc/defaultdomain de la machine est incorrect. Réinitialisez le nom de domaine NIS, comme indiqué à la section Définition d'un nom de domaine NIS de machine.

Remarque - Le nom de domaine NIS est sensible à la casse.

Client non lié à un serveur

Si le nom de domaine est défini correctement et si la commande ypbind est en cours d'exécution, mais que les commandes se bloquent toujours, vérifiez que le client est lié à un serveur en exécutant la commande ypwhich. Si vous venez de démarrer ypbind, exécutez ypwhich plusieurs fois (en général, la première exécution signale que le domaine n'est pas lié et la deuxième exécution réussit normalement).

Aucun serveur n'est disponible

Si le nom de domaine est défini correctement, et su ypbind est en cours d'exécution, mais que vous recevez un message indiquant que le client ne peut pas communiquer avec un serveur, cela peut signaler un certain nombre de problèmes :

Le client contient-il un fichier /var/yp/binding/domainname /ypservers qui répertorie les serveurs auxquels établir une liaison ? Si ce n'est pas le cas, exécutez ypinit -c et indiquez dans l'ordre de préférence les serveurs auxquels ce client doit se relier.
Si le client a bien un fichier /var/yp/binding/domainname/ypservers, contient-il assez de serveurs si un ou deux d'entre eux deviennent indisponibles ? Si ce n'est pas le cas, ajoutez d'autres serveurs à la liste en exécutant ypinit - c.

Les serveurs NIS sélectionnées possèdent-ils des entrées dans le fichier /etc/inet/hosts ? Pour afficher les serveurs NIS sélectionnés, exécutez la commande svcprop -p config/ypservers nis/domain. Si ces hôtes ne se trouvent pas dans le fichier /etc/inet/hosts local, ajoutez les serveurs aux cartes NIS hosts et recréez vos cartes en exécutant la commande ypinit - c ou ypinit -s, comme décrit à la section Utilisation des cartes NIS.
Le commutateur du service de noms est-il configuré pour vérifier le fichier hosts local de la machine en plus de NIS ? Reportez-vous au Chapitre 2, Commutateur du service de noms (présentation) pour plus d'informations sur le commutateur.
Le commutateur du service de noms est-il configuré pour vérifier files d'abord pour services puis pour rpc ? Reportez-vous au Chapitre 2, Commutateur du service de noms (présentation) pour plus d'informations sur le commutateur.

Les affichages de la commande `ypwhich` sont incohérents

Lorsque vous utilisez plusieurs fois la commande ypwhich sur le même client, l'affichage obtenu varie, car le serveur NIS change. Cela est tout à fait normal. La liaison du client NIS au serveur NIS change au fil du temps lorsque le réseau ou les serveurs NIS sont occupés. Chaque fois que cela est possible, le réseau se stabilise à un point où tous les clients obtiennent un temps de réponse acceptable des serveurs NIS. Tant que votre machine client obtient un service NIS, la provenance de ce dernier n'a pas d'importance. Par exemple, un serveur NIS peut obtenir ses propres services NIS à partir d'un autre serveur NIS du réseau.

Liaison au serveur impossible

Dans les cas extrêmes où la liaison au serveur local n'est pas possible, l'utilisation de la commande ypset peut permettre temporairement la liaison à un autre serveur, si disponible, sur un autre réseau ou sous-réseau. Toutefois, pour pouvoir utiliser l'option -ypset, la commande ypbind doit être lancée à l'aide de l'option -ypset ou -ypsetme. Pour plus d'informations, reportez-vous à la page de manuel ypbind(1M).

# /usr/lib/netsvc/yp/ypbind -ypset

Pour une autre méthode, Reportez-vous à la section Liaison à un serveur NIS spécifique.

Attention - Pour des raisons de sécurité, l'utilisation des options -ypset et - ypsetme n'est pas recommandée. N'utilisez ces options qu'à des fins de débogage et dans des circonstances contrôlées. L'utilisation des options -ypset et -ypsetme peut entraîner de graves violations de sécurité, car au cours de l'exécution des démons, toute personne peut altérer les liaisons au serveur et gêner les opérations d'autres personnes, ou autoriser l'accès non autorisé à des données sensibles. Si vous devez démarrer la commande ypbind avec ces options, il faut interrompre le processus ypbind et le redémarrer sans ces options dès que vous avez corrigé le problème.

Pour redémarrer le démon ypbind, utilisez SMF de la façon suivante :

# svcadm enable -r svc:/network/nis/client:default

Arrêt brutal de la commande `ypbind`

Si le démon ypbind s'arrête brutalement presque immédiatement à chaque fois qu'il est démarré, recherchez un problème dans le journal de service svc:/network/nis/client:default . Vérifiez la présence du démon rpcbind en tapant ce qui suit :

% ps -e |grep rpcbind

Si rpcbind n'est pas présent, s'il n'est pas persistant ou qu'il se comporte de manière étrange, consultez le fichier journal svc:/network/rpc/bind:default . Pour plus d'informations, reportez-vous aux pages de manuel rpcbind(1M) et rpcinfo(1M).

Vous pouvez peut-être communiquer avec rpcbind sur le client posant problème à partir d'une machine fonctionnant normalement. Sur la machine qui fonctionne correctement, exécutez la commande suivante :

% rpcinfo client

Si rpcbind fonctionne sur la machine problématique, rpcinfo produit le résultat suivant :

    program    version    netid    address    service    owner
...
    100007    3    udp6      ::.191.161          ypbind     1
    100007    3    tcp6      ::.135.200          ypbind     1
    100007    3    udp       0.0.0.0.240.221     ypbind     1
    100007    2    udp       0.0.0.0.240.221     ypbind     1
    100007    1    udp       0.0.0.0.240.221     ypbind     1
    100007    3    tcp       0.0.0.0.250.107     ypbind     1
    100007    2    tcp       0.0.0.0.250.107     ypbind     1
    100007    1    tcp       0.0.0.0.250.107     ypbind     1
    100007    3    ticlts    2\000\000\000       ypbind     1
    100007    2    ticlts    2\000\000\000       ypbind     1
    100007    3    ticotsord 9\000\000\000       ypbind     1
    100007    2    ticotsord 9\000\000\000       ypbind     1
    100007    3    ticots    @\000\000\000       ypbind     1
...

Votre machine présentera des adresses différentes. Si les adresses ne sont pas affichées, cela signifie que ypbind n'a pas pu enregistrer ses services. Redémarrez la machine et relancez rpcinfo. Si les processus ypbind sont présents et changent à chaque fois que vous essayez de redémarrer le service NIS, redémarrez le système, même si le démon rpcbind est en cours d'exécution.

Problèmes NIS affectant de nombreux clients

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.

`rpc.yppasswdd` considère un shell non restreint commençant par `r` comme étant à restreindre

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.

Le réseau ou les serveurs sont inaccessibles

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, la condition 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 des opérations normales.

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, exécutez la commande ping.

Les démons NIS ne sont pas en cours d'exécution

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) n'est exécuté, 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

Les serveurs ont des versions différentes d'une carte NIS

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 maître serveur. Reportez-vous à la section Vérification de la carte ypservers.

Journalisation de la sortie `ypxfr`

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.

Remarque - Lorsque vous avez résolu le problème, désactivez la journalisation en supprimant le fichier journal. Si vous oubliez de le supprimer, il continue de recueillir les informations sans limite.

Vérification du fichier `crontab` et du script shell `ypxfr`

Inspectez le fichier root crontab puis 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, peut également provoquer des erreurs.

Vérification de la carte `ypservers`

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.

Solution de contournement permettant de mettre à jour un serveur esclave interrompu

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 récente version de la carte incohérente sur 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.

Arrêt brutal de `ypserv`

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).

Ignorer les liens de navigation
Quitter l'aperu
	Utilisation des services de noms et d'annuaire dans Oracle Solaris 11.1 Oracle Solaris 11.1 Information Library (Français)