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) |
Partie I A propos des services d'annuaire et de noms
1. Services d'annuaire et de noms (présentation)
2. Commutateur du service de noms (présentation)
4. Configuration des clients Active Directory Oracle Solaris (tâches)
Partie II Configuration et administration NIS
5. Service d'information réseau (présentation)
6. Définition et configuration du service NIS (tâches)
7. Administration de NIS (tâches)
Symptômes des problèmes de liaison NIS
Problèmes NIS affectant un client
ypbind n'est pas en cours d'exécution sur un client
Nom de domaine manquant ou incorrect
Aucun serveur n'est disponible
Les affichages de la commande ypwhich sont incohérents
Arrêt brutal de la commande ypbind
Problèmes NIS affectant de nombreux clients
rpc.yppasswdd considère un shell non restreint commençant par r comme étant à restreindre
Le réseau ou les serveurs sont inaccessibles
Les démons NIS ne sont pas en cours d'exécution
Partie III Service de noms LDAP
9. Introduction aux services de noms LDAP (présentation)
10. Exigences de planification pour les services de noms LDAP (tâches)
11. Configuration de Oracle Directory Server Enterprise Edition avec les clients LDAP (tâches)
12. Configuration des clients LDAP (tâches)
13. Dépannage LDAP (référence)
14. Service de noms LDAP (référence)
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
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.
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.
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
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.
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).
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.
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.
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 |
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.
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, 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.
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) 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
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.
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.
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.
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 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.
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).