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 problématique, exécutez ls –l sur un répertoire, tel que /usr, qui contient des fichiers appartenant à plusieurs utilisateurs, y compris certains non inclus dans le fichier /etc/passwd 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 serveur 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 que 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és 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 ? Pour plus d'informations à propos du commutateur, reportez-vous au Chapter 2, A propos du commutateur du service de noms.
Le commutateur du service de noms est-il configuré pour vérifier files d'abord pour services puis pour rpc ? Pour plus d'informations à propos du commutateur, reportez-vous au Chapter 2, A propos du commutateur du service de noms.
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. C'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.
 | Mise en garde - 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 le démon 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.