Resolución de problemas de NIS que afectan a un solo cliente

Idioma:

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. Sin embargo, si muchos clientes NIS no se pueden vincular correctamente, el problema probablemente exista en uno o más de los servidores NIS. Consulte Resolución de problemas de NIS que afectan a varios clientes.

Los siguientes son problemas comunes de NIS que afectan a un solo cliente:

ypbind el daemon no se está ejecutando en el cliente

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

Estos síntomas generalmente indican que el proceso ypbind del cliente no se está ejecutando. Verifique si se están ejecutando los servicios del cliente NIS de la siguiente manera:
```
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, inicie sesión y asuma el rol root y, a continuación, inicie el servicio de cliente NIS de la siguiente manera:
```
client# svcadm enable network/nis/domain
client# svcadm enable network/nis/client
```
Falta el nombre de dominio o es incorrecto

Un cliente tiene problemas y los otros clientes funcionan normalmente, pero se está ejecutando el daemon ypbind en ese cliente. En este caso, el cliente puede tener un dominio mal configurado.

Ejecute el comando domainname en el cliente para determinar qué nombre de dominio está configurado:
```
client# domainname
example.com
```
Compare el resultado con el nombre de dominio real en el directorio /var/yp, en el servidor maestro NIS. Como se muestra en el siguiente ejemplo, el dominio NIS real se muestra como un subdirectorio en el directorio /var/yp:
```
client# 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 que se visualiza en el resultado del comando domainname en el cliente no es el mismo que el nombre de dominio del servidor que se muestra como un subdirectorio en el directorio /var/yp, el nombre de dominio en la propiedad config/domain del servicio nis/domain es incorrecto. Restablezca el nombre de dominio NIS. Para obtener instrucciones, consulte Cómo establecer un nombre de dominio NIS de una máquina de Trabajo con servicios de nombres y de directorio en Oracle Solaris 11.2: DNS y NIS .

Notas - El nombre de dominio NIS distingue entre mayúsculas y minúsculas.
Cliente no vinculado a servidor

Si el nombre de dominio está configurado correctamente y el daemon ypbind se está ejecutando pero los comandos aún se bloquean, asegúrese de que el cliente esté vinculado a un servidor mediante la ejecución del comando ypwhich. Si acaba de iniciar el daemon ypbind, ejecute el comando ypwhich. Es posible que deba ejecutar el comando ypwhich varias veces. Normalmente, la primera vez que ejecute el comando, éste informa que el dominio no está vinculado. La segunda vez que ejecute el comando, debe continuar normalmente.
No hay ningún servidor disponible

Si el nombre de dominio está configurado correctamente y el daemon ypbindse está ejecutando, pero aún recibe mensajes que indican que el cliente no puede comunicarse con el servidor, compruebe lo siguiente:
- ¿Tiene el cliente un archivo /var/yp/binding/domainname/ypservers que contiene una lista de servidores a los cuales vincularse? Para ver los servidores NIS seleccionados, utilice el comando svcprop –p config/ypservers nis/domain. De lo contrario, ejecute el comando ypinit –c para especificar a qué servidores se debe vincular este cliente, en orden de preferencia.
- Si el cliente tiene un archivo /var/yp/binding/domainname/ypservers, ¿existen suficientes servidores enumerados en caso de que uno o dos servidores dejen de estar disponibles? Para ver los servidores NIS seleccionados, utilice el comando svcprop –p config/ypservers nis/domain. Si no es así, agregue servidores adicionales a la lista mediante la ejecución del comando 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 NIS hosts y vuelva a crear los mapas mediante la ejecución del comando ypinit –c o ypinit –s. Para obtener más información, consulte Trabajo con mapas NIS de Trabajo con servicios de nombres y de directorio en Oracle Solaris 11.2: DNS y NIS .
- ¿El conmutador de servicios de nombres está configurado para comprobar el archivo hosts local del sistema, además de NIS? Para obtener más información, consulte Capítulo 2, Acerca del cambio de servicio de nombres de Trabajo con servicios de nombres y de directorio en Oracle Solaris 11.2: DNS y NIS .
- ¿El conmutador de servicios de nombres está configurado para comprobar files primero para services y luego rpc?
ypwhich pantallas incoherentes

Si usa el comando ypwhich varias veces en el mismo cliente, la pantalla que aparece varía porque el servidor NIS cambia. Este comportamiento 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, la red pasa a ser estable en un punto en que todos los clientes reciben un tiempo de respuesta aceptable de los servidores NIS. Siempre que el cliente reciba el servicio NIS, no importa el lugar de donde proviene el servicio. Por ejemplo, un servidor NIS puede recibir servicios NIS de otro servidor NIS de la red.

Qué debe hacer si no es posible la vinculación del servidor

En casos extremos en los que no es posible la vinculación del servidor local, use la opción ypset con el comando ypbind para permitir temporalmente la vinculación a otro servidor, si está disponible, en otra red o subred. Tenga en cuenta que para utilizar la opción –ypset option, debe iniciar el daemon ypbind mediante la opción –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 de Trabajo con servicios de nombres y de directorio en Oracle Solaris 11.2: DNS y NIS .

Precaución - Por motivos de seguridad, no se recomienda el uso de las opciones –ypset o –ypsetme. Utilice estas opciones sólo para la depuración en circunstancias controladas. El uso de la opción –ypset o –ypsetme puede causar brechas de seguridad graves. Aunque los daemons se están ejecutando, cualquier persona puede alterar las vinculaciones del servidor, lo que puede permitir el acceso no autorizado a datos confidenciales. Si debe iniciar el daemon ypbind utilizando cualquiera de estas opciones, finalice el proceso ypbind después de corregir el problema y, a continuación, reinícielo sin especificar estas opciones. Reinicie el daemon ypbind de la siguiente manera:

# svcadm enable -r svc:/network/nis/client:default

Consulte la página del comando man ypset(1M).

ypbind bloqueo de daemon

Si el daemon ypbind se bloquea casi inmediatamente cada vez que se inicia, busque un problema en el log del servicio svc:/network/nis/client:default. Compruebe la presencia del daemon rpcbind de la siguiente manera:
```
% ps -e |grep rpcbind
```
Si daemon rpcbind no está presente, no se mantiene activo o se comporta de manera extraña, compruebe el archivo log 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 el daemon enrpcbind del cliente con el problema desde un sistema que esté funcionando con normalidad.

Ejecute el siguiente comando desde un sistema que funcione:
```
% rpcinfo client
```
Si el daemonrpcbind en el sistema problemático es correcto, se muestra el siguiente resultado:
```
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
...
```
Si no se muestran direcciones (el sistema tendrá diferentes direcciones), el daemon ypbind no pudo registrar sus servicios. Reinicie el sistema y ejecute el comando rpcinfo. Si los procesos de ypbind están allí y cambian cada vez que intenta reiniciar el servicio NIS, reinicie el sistema, incluso si el daemon rpcbind se está ejecutando.