Si sólo uno o dos clientes experimentan síntomas que indican dificultades en el vínculo de NIS, los problemas probablemente estén en esos clientes. Consulte Problemas de NIS que afectan a un cliente. Si muchos clientes NIS no se pueden vincular correctamente, el problema probablemente exista en uno o más de los servidores NIS.
Cree /etc/default/yppasswdd que contenga una cadena especial:"check_restricted_shell_name=1".
Si se marca la cadena "check_restricted_shell_name=1", no ocurre la comprobación de la 'r'.
NIS puede bloquearse si la red o los servidores NIS están tan sobrecargados que ypserv no puede obtener una respuesta para el proceso ypbind de cliente dentro del período de tiempo de espera. NIS también puede bloquearse si se produce un fallo en la red.
En estas circunstancias, cada cliente de la red experimenta el mismo problema o problemas similares. En la mayoría de los casos, la situación es temporal. Los mensajes normalmente desaparecen cuando el servidor NIS se reinicia y reinicia ypserv, cuando la carga de los servidores NIS o la red disminuye, o cuando la red reanuda las operaciones normales.
Asegúrese de que los servidores estén activos y en ejecución. Si no está físicamente cerca los servidores, utilice el comando ping.
Si los servidores están activos y en ejecución, intente encontrar una equipo cliente que se comporte normalmente, y ejecute el comando ypwhich. Si ypwhich no responde, ciérrelo. A continuación, inicie sesión como root en el servidor NIS y compruebe si el proceso NIS se está ejecutando escribiendo lo siguiente:
# ptree |grep ypbind 100759 /usr/lib/netsvc/yp/ypbind -broadcast 527360 grep yp
Si ni el daemon ypserv (servidor NIS) ni el daemon ypbind (cliente NIS) se están ejecutando, reinícielos escribiendo lo siguiente:
# svcadm restart network/nis/client
Si tanto el proceso ypserv como el proceso ypbind se están ejecutando en el servidor NIS, ejecute el comando ypwhich. Si el comando no responde, el daemon ypserv probablemente se bloqueó y se debe reiniciar. Mientras está conectado como root en el servidor, reinicie el servicio NIS escribiendo lo siguiente:
# svcadm restart network/nis/server
Debido a que NIS propaga mapas entre los servidores, ocasionalmente puede encontrar diferentes versiones del mismo mapa en distintos servidores NIS de la red. Esta diferencia en versiones es normal y es aceptable si las diferencias no duran más de un breve período.
La causa más común de la diferencia de mapas es cuando se impide la propagación normal de los mapas. Por ejemplo, un servidor NIS o un enrutador entre servidores NIS está fuera de servicio. Cuando todos los servidores NIS y los enrutadores entre ellos se están ejecutando, ypxfr se debe realizar correctamente.
Si los servidores y los enrutadores funcionan correctamente, compruebe lo siguiente:
Compruebe la salida del registro de ypxfr. Consulte Registro de la salida de ypxfr.
Compruebe el archivo de registro svc:/network/nis/xfr:default para ver si hay errores.
Compruebe los archivos de control. Consulte Revise el archivo crontab y la secuencia de comandos de shellypxfr.
Compruebe el mapa ypservers en el servidor maestro. Consulte Compruebe el mapa ypservers.
Si un determinado servidor esclavo tiene problemas al actualizar mapas, inicie sesión en ese servidor y ejecute el comando ypxfr de forma interactiva. Si el comando falla, indica por qué ha fallado, y usted puede solucionar el problema. Si el comando tiene éxito, pero usted sospecha que ha fallado en algún momento, cree un archivo de registro para activar el registro de mensajes. Para crear un archivo de registro, introduzca lo siguiente en el servidor esclavo.
ypslave# cd /var/yp ypslave# touch ypxfr.log
Esto crea un archivo ypxfr.log que guarda todos los resultados de ypxfr.
El resultado es similar al resultado que ypxfr muestra cuando se ejecuta de manera interactiva, pero cada línea del archivo de registro tiene una marca de hora y fecha. Es posible que vea un orden poco común en los indicadores de fecha y hora. Esto es correcto, ya que los indicadores de fecha y hora le indican cuándo ypxfr se comenzó a ejecutar. Si se ejecutan copias de ypxfr simultáneamente, pero demoran diferentes cantidades de tiempo, podrían escribir su línea de estado de resumen en los archivos de registro en un orden diferente del que se invocaron. Cualquier patrón de fallas intermitentes aparece en el registro.
Inspeccione el archivo root crontab y compruebe la secuencia de comandos de shell de ypxfr que invoca. Los errores tipográficos de estos archivos puede provocar problemas de propagación. Las fallas al hacer referencia a una secuencia de comandos de shell dentro del archivo /var/spool/cron/crontabs/root, o las fallas para hacer referencia a un mapa dentro de cualquier secuencia de comandos de shell también puede causar errores.
Además, asegúrese de que el servidor NIS esclavo aparezca en el mapa ypservers del servidor maestro para el dominio. Si no es así, el servidor esclavo sigue funcionando perfectamente como servidor, pero yppush no propaga cambios de mapas para el servidor esclavo.
Si el problema del servidor NIS esclavo no es claro, puede aplicar una solución alternativa al depurar el problema mediante los comandos scp o ssh para copiar una versión reciente del mapa incoherente desde cualquier servidor NIS que esté en buen estado. En el siguiente ejemplo, se muestra cómo transferir el mapa con el problema.
ypslave# scp ypmaster:/var/yp/mydomain/map.\* /var/yp/mydomain
El carácter * no se ha incluido en la línea de comandos, por lo que se ampliará en ypmaster, en lugar de localmente en ypslave.
Cuando el proceso de ypserv se bloquea casi inmediatamente y no se mantiene activo ni siquiera con activaciones repetidas, el proceso de depuración es prácticamente idéntico al que se describe en ypbind se bloquea. En primer lugar, ejecute el siguiente comando para ver los errores que aparecen:
# svcs -vx nis/server
Compruebe la existencia del daemon rpcbind de la siguiente forma:
# ptree |grep rpcbind
Reiniciar el servidor si no encuentra el daemon. De lo contrario, si el daemon se está ejecutando, escriba lo siguiente y busque una salida similar:
% 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
Es posible que su equipo tenga diferentes números de puerto. Las cuatro entradas que representan el proceso ypserv son las siguientes:
100004 2 udp 731 ypserv 100004 1 udp 731 ypserv 100004 1 tcp 732 ypserv 100004 2 tcp 32772 ypserv
Si no hay entradas e ypserv es no puede registrar sus servicios con rpcbind, reinicie el equipo. Si hay entradas, anule el registro del servicio de rpcbind antes de reiniciar ypserv. Para anular el registro del servicio de rpcbind, en el servidor, escriba lo siguiente.
# rpcinfo -d number 1 # rpcinfo -d number 2
Donde number es el número de ID indicado por rpcinfo (100004, en el ejemplo anterior).