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 un directorio, como /usr que contiene archivos propiedad de 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.
Notas - El nombre de dominio NIS distingue entre mayúsculas y minúsculas.
Cliente no vinculado a servidor
Si su nombre de dominio está definido correctamente, ypbind se está ejecutando y los comandos siguen bloqueados, asegúrese de que el cliente está enlazado a un servidor mediante la ejecución del comando ypwhich. Si tiene acaba de iniciar ypbind, ejecute ypwhich varias veces (normalmente, la primera vez informa que el dominio no está vinculado y la segunda se ejecuta con éxito).
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 Chapter 2, Acerca del cambio de servicio de nombres 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 el Chapter 2, Acerca del cambio de servicio de nombres para obtener más información acerca del 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 las opciones –ypset o –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 e –ypsetme puede tener como resultado la vulnerabilidad de la seguridad, ya que, aunque los daemons se están ejecutando, cualquier usuario que puede modificar los enlaces del servidor y así ocasionar problemas a otros 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.