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 Resolución de problemas de NIS que afectan a un solo cliente. Sin embargo, si muchos clientes NIS no se pueden vincular correctamente, el problema probablemente exista en uno o más de los servidores NIS.
Los siguientes son problemas de NIS comunes que pueden afectar a varios clientes:
rpc.yppasswdd considera un shell no restringido que comienza con r como restringido
Para resolver este problema, realice las siguientes acciones:
Cree un /etc/default/yppasswdd archivo 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 r.
No se puede acceder a la red o los servidores
NIS puede bloquearse si la red o los servidores NIS están tan sobrecargados que el daemon ypserv no puede recibir una respuesta desde el proceso ypbind del cliente antes de que se supere el tiempo de espera. NIS también puede bloquearse si se produce un fallo en la red.
En estas circunstancias, cada cliente que está en 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 el daemon ypserv, cuando la carga de los servidores NIS o la red disminuye, o cuando la red reanuda las operaciones normales.
Funcionamiento incorrecto del servidor
Asegúrese de que los servidores estén activos y en ejecución. Si no está físicamente cerca de los servidores, utilice el comando ping para determinar si se puede acceder al servidor.
Los daemons NIS no se están ejecutando
Si los servidores están activos y en ejecución, intente encontrar un cliente que se comporte normalmente y ejecute el comando ypwhich. Si el comando ypwhich no responde, ciérrelo. A continuación, asuma el rol en el servidor NIS y compruebe si el proceso NIS se está ejecutando de la siguiente manera:
# 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 de la siguiente manera:
Reinicie el servicio del cliente NIS de la siguiente manera:
# 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.
En el servidor, reinicie el servicio NIS de la siguiente manera:
# svcadm restart network/nis/server
Los servidores tienen versiones diferentes de un mapa NIS
Debido a que NIS propaga asignaciones entre los servidores, ocasionalmente puede encontrar diferentes versiones de la misma asignación en distintos servidores NIS que están en la red. Esta diferencia en versiones es normal y aceptable si las diferencias no duran demasiado.
La causa más común de la diferencia en asignaciones es cuando se evita la propagación normal de las asignaciones. Por ejemplo, un servidor NIS o un enrutador que está ubicado entre los servidores NIS está inactivo. Cuando todos los servidores NIS y los enrutadores entre ellos se están ejecutando, el comando ypxfr se debe realizar correctamente.
Si los servidores y los enrutadores funcionan correctamente, siga estos pasos:
Compruebe la salida del log de ypxfr. Consulte Example 3–1.
Compruebe el archivo log svc:/network/nis/xfr:default para ver si hay errores.
Revise los archivos de control (archivo crontab y secuencia de comandos shell yupxfr).
Compruebe el mapa ypservers en el servidor maestro.
ypserv bloqueo de proceso
Cuando el proceso ypserv se bloquea casi inmediatamente y no se mantiene activo ni siquiera con activaciones repetidas, el proceso de depuración es prácticamente el mismo que se describe para los bloqueos ypbind.
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, ejecute el siguiente comando y busque un resultado 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
En el ejemplo anterior, las siguientes cuatro entradas representan el proceso ypserv.
100004 2 udp 731 ypserv 100004 1 udp 731 ypserv 100004 1 tcp 732 ypserv 100004 2 tcp 32772 ypserv
Si no hay entradas y ypserv no puede registrar sus servicios con rpcbind, reinicie el sistema. Si existen entradas, anule el registro del servicio de rpcbind antes de reiniciar ypserv. Por ejemplo, debe anular el registro del servicio desde rpcbind de la siguiente manera:
# rpcinfo -d number 1 # rpcinfo -d number 2
Donde number es el número de ID indicado por rpcinfo (100004, en el ejemplo anterior).
Si un determinado servidor esclavo tiene problemas al actualizar las asignaciones, inicie sesión en ese servidor y ejecute el comando ypxfr de forma interactiva.
Si el comando falla, se muestra un mensaje sobre por qué ha fallado para poder solucionar el problema. Si el comando se ejecuta satisfactoriamente, pero usted sospecha que ha fallado en algún momento, cree un archivo log en el servidor esclavo para activar el registro de mensajes de la siguiente manera:
ypslave# cd /var/yp ypslave# touch ypxfr.log
El resultado del archivo log se parece al resultado del comando ypxfr cuando se lo ejecuta de manera interactiva, con la excepción de que cada línea del archivo log tiene un registro de hora. Si observa un orden poco común en los registros de hora es porque se muestra cada vez que el comando ypxfr realmente no se ha ejecutado. Si copias de ypxfr se ejecutan simultáneamente, pero tardan diferentes cantidades de tiempo en terminar, cada copia puede escribir una línea de estado de resumen al archivo log en un orden distinto que cuando se ejecutó el comando. Cualquier patrón de fallas intermitentes aparece en el log.
Revise el archivo crontab y la secuencia de comandos shell ypxfr.
Inspeccione el archivo root crontab y compruebe la secuencia de comandos shell ypxfr que éste invoca. Los errores tipográficos de estos archivos puede provocar problemas de propagación. Las fallas al hacer referencia a una secuencia de comandos shell dentro del archivo /var/spool/cron/crontabs/root, o las fallas para hacer referencia a una asignación dentro de cualquier secuencia de comandos shell también puede causar errores.
Compruebe la asignación ypservers.
Además, asegúrese de que el servidor NIS esclavo aparezca en la asignación 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 asignaciones para el servidor esclavo.
Actualice las asignaciones en un servidor esclavo roto.
Si el problema del servidor esclavo NIS no es obvio, puede realizar una solución provisional al depurar el problema mediante el uso del scp o ssh. Estos comandos copian una versión reciente de la asignación incoherente desde cualquier servidor NIS en perfectas condiciones.
En el siguiente ejemplo, se muestra cómo transferir la asignación con el problema:
ypslave# scp ypmaster:/var/yp/mydomain/map.\* /var/yp/mydomain
En el ejemplo anterior, 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.