Problemas de enlace NIS

Síntomas de problemas de enlace NIS

Los síntomas comunes de problemas de vinculación de NIS son los siguientes.

• Mensajes que indican que ypbind no puede encontrar un servidor o no puede comunicarse con un servidor.

• Mensajes que indican que el servidor no responde

• Mensajes que indican que NIS no está disponible

• Los comandos de un cliente tienen dificultadas en el modo de fondo o funcionan mucho más lento que lo habitual

• Los comandos en un cliente se bloquean. A veces, los comandos se bloquean aunque el sistema parezca estar bien en general y puede ejecutar nuevos comandos.

• Los comandos de un cliente colapsan con mensajes extraños o sin mensajes

Problemas de NIS que afectan a un cliente

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. Si muchos clientes NIS no se pueden vincular correctamente, el problema probablemente exista en uno o más de los servidores NIS. Consulte Problemas de NIS que afectan a muchos clientes.

ypbind no se ejecuta en el cliente

Un cliente presenta problemas, pero otros clientes en la misma subred funcionan con normalidad. En el cliente que tiene el problema, ejecute ls -l en un directorio, como /usr, que contiene los archivos que pertenecen a muchos usuarios, incluidos algunos que no están en el archivo /etc/passwd del cliente. Si la pantalla que aparece enumera propietarios de archivos que no están en el /etc/passwd local como números, en lugar de nombres, esto indica que servicio NIS no funciona en el cliente.

Estos síntomas generalmente significan que el proceso ypbind del cliente no se está ejecutando. Verifique si se están ejecutando los servicios del cliente NIS.

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

Si los servicios están en estado disabled (desactivado), inicie sesión como root o asuma un rol equivalente, e inicie el servicio del cliente NIS.

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

Falta el nombre de dominio o es incorrecto

Un cliente tiene problemas, los otros clientes funcionan normalmente, pero ypbind se está ejecutando en el cliente con el problema. El cliente puede tener un dominio mal configurado.

En el cliente, ejecute el comando domainname para ver qué nombre de dominio está definido.

client7# domainname
example.com

Compare la salida con el nombre de dominio real en /var/yp en el servidor maestro NIS. El dominio NIS real se muestra como un subdirectorio en el directorio /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 el nombre de dominio devuelto ejecutando domainname en una máquina no es el mismo que el nombre de dominio del servidor enumerado como directorio en /var/yp, el nombre de dominio especificado en el archivo /etc/defaultdomain de la máquina es incorrecto. Restablezca el nombre de dominio NIS como se muestra en Cómo establecer un nombre de dominio NIS de una máquina.

Cliente no vinculado a servidor

Si el nombre de dominio está configurado correctamente, ypbind se está ejecutando y los comandos aún se bloquean, asegúrese de que el cliente esté enlazado a un servidor ejecutando el comando ypwhich. Si acaba de iniciar ypbind, ejecute ypwhich varias veces (por lo general, la primera vez informa que el dominio no está enlazado y la segunda vez se realiza con éxito normalmente).

No hay ningún servidor disponible

Si su nombre de dominio está definido correctamente, ypbind se está ejecutando y recibe mensajes que indican que el cliente no puede comunicarse con un servidor, esto podría indicar diferentes problemas:

• ¿El cliente tiene un archivo /var/yp/binding/domainname/ypservers que contiene una lista de servidores con los cuales realizar el enlace? Si no, ejecute ypinit -c y especifique el orden de preferencia de los servidores a los que se debe vincular el cliente.

• Si el cliente tiene un archivo /var/yp/binding/domainname/ypservers, ¿hay suficientes servidores enumerados si uno o dos dejan de estar disponibles? Si no es así, agregue servidores adicionales a la lista ejecutando ypinit -c.

• ¿Los servidores NIS seleccionados tienen entradas en el archivo /etc/inet/hosts? Para ver los servidores NIS seleccionados, utilice el comando svcprop -p config/ypservers nis/domain. Si estos hosts no están en el archivo /etc/inet/hosts local, agregue los servidores a los mapas de datos NIS hosts y vuelva a crear los mapas mediante la ejecución del comando ypinit -c o ypinit -s como se describe en Trabajo con mapas NIS.

• ¿El conmutador de servicio de nombres está configurado para comprobar el archivo hosts local de la máquina además de NIS? Consulte el Capítulo 2, Conmutador de servicio de nombres (descripción general) para obtener más información sobre el conmutador.

• ¿El conmutador de servicio de nombres está configurado para comprobar files primero para services y rpc? Consulte Capítulo 2, Conmutador de servicio de nombres (descripción general) para obtener más información sobre el conmutador.

Las pantallas de ypwhich son incoherentes

Al usar ypwhich varias veces en el mismo cliente, la pantalla que aparece varía porque el servidor NIS cambia. Esto es normal. El vínculo del cliente NIS al servidor NIS cambia con el tiempo, cuando la red o los servidores NIS están ocupados. Siempre que sea posible, el red pasa a ser estable en un punto en que todos los clientes obtienen un tiempo de respuesta aceptable de los servidores NIS. Siempre que el equipo cliente tenga servicio NIS, no importa el lugar de donde proviene el servicio. Por ejemplo, un equipo servidor NIS puede obtener sus propios servicios NIS de otro servidor NIS de la red.

Cuando la vinculación de servidor no es posible

En casos extremos en que no es posible la vinculación del servidor local, el uso del comando ypset puede permitir temporalmente la vinculación a otro servidor, si está disponible, en otra red o subred. Sin embargo, para poder utilizar la opción -ypset, ypbind se debe iniciar con la opción -ypset o con la opción -ypsetme. Para obtener más información, consulte la página del comando man ypbind(1M).

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

Para ver otro método, consulte Vínculo a un servidor NIS específico.

---

Precaución - Por motivos de seguridad, el uso de las opciones -ypset y -ypsetme no se recomienda. Utilice estas opciones sólo para la depuración en circunstancias controladas. El uso de las opciones -ypset y -ypsetme puede causar brechas de seguridad graves, ya que, aunque los daemons se están ejecutando, cualquier persona puede alterar los enlaces del servidor y provocar problemas a otros usuarios y permitir el acceso no autorizado a datos confidenciales. Si debe iniciar el daemon ypbind con estas opciones, después de solucionar el problema, debe finalizar el proceso ypbind y volver a iniciarlo sin estas opciones. Para reiniciar el daemon ypbind, utilice la SMF de la siguiente forma: # svcadm enable -r svc:/network/nis/client:default

---

ypbind se bloquea

Si el daemon ypbind falla casi inmediatamente cada vez que se inicia, busque un problema en el registro del servicio svc:/network/nis/client:default. Compruebe la presencia del daemon rpcbind escribiendo lo siguiente:

% ps -e |grep rpcbind

Si rpcbind no está presente, no se mantiene activo o se comporta de manera extraña, compruebe el archivo del registro svc:/network/rpc/bind:default. Para obtener más información, consulte las páginas del comando man rpcbind(1M) y rpcinfo(1M).

Es posible que pueda comunicarse con rpcbind en el cliente con el problema desde un equipo que funcione con normalidad. Desde la máquina en funcionamiento, escriba lo siguiente:

% rpcinfo client

Si rpcbind en la máquina con el problema es aceptable, rpcinfo genera la siguiente salida:

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

El equipo tendrá diferentes resultados. Si las direcciones no se muestran, ypbind ha podido registrar sus servicios. Reinicie el equipo y ejecute rpcinfo de nuevo. Si hay procesos de ypbind y cambian cada vez que se intenta reiniciar el servicio NIS, reinicie el sistema, aunque el daemon rpcbind se esté ejecutando.

Problemas de NIS que afectan a muchos clientes

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.

rpc.yppasswdd considera restringido a un shell no restringido que empieza con r

1. Cree /etc/default/yppasswdd que contenga una cadena especial:"check_restricted_shell_name=1".

2. Si se marca la cadena "check_restricted_shell_name=1", no ocurre la comprobación de la 'r'.

No se puede acceder a la red o los servidores

NIS se puede bloquear si la red o los servidores NIS están tan sobrecargados que el daemon ypserv no puede recibir una respuesta para 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 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.

Funcionamiento incorrecto del servidor

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.

Daemons NIS no en ejecución

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

Los servidores tienen versiones diferentes de un mapa NIS

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.

Registro de la salida de ypxfr

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.

Revise el archivo crontab y la secuencia de comandos de shellypxfr

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.

Compruebe el mapa ypservers

Además, asegúrese de que el servidor NIS esclavo esté enumerado en el mapa ypservers del servidor maestro del dominio. Si no es así, el servidor esclavo sigue funcionando perfectamente como servidor, pero yppush no propaga cambios de mapas para el servidor esclavo.

Solución provisional para actualizar mapas en un servidor esclavo roto

Si el problema del servidor NIS esclavo no es claro, puede realizar una solución provisional al depurar el problema mediante el comando scp o ssh para copiar una versión reciente del mapa incoherente desde cualquier servidor NIS en perfectas condiciones. 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.

ypserv se bloquea

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