Omitir Vínculos de navegación | |
Salir de la Vista de impresión | |
Trabajo con servicios de nombres y directorios en Oracle Solaris 11.1 Oracle Solaris 11.1 Information Library (Español) |
Parte I Acerca de los servicios de nombres y directorios
1. Servicios de nombres y directorios (descripción general)
2. Conmutador de servicio de nombres (descripción general)
4. Configuración de clientes de Active Directory de Oracle Solaris (tareas)
Parte II Configuración y administración de NIS
5. Servicio de información de red (descripción general)
6. Instalación y configuración del servicio NIS (tareas)
7. Administración de NIS (tareas)
8. Resolución de problemas de NIS
Síntomas de problemas de enlace NIS
Problemas de NIS que afectan a un cliente
ypbind no se ejecuta en el cliente
Falta el nombre de dominio o es incorrecto
Cliente no vinculado a servidor
No hay ningún servidor disponible
Las pantallas de ypwhich son incoherentes
Cuando la vinculación de servidor no es posible
Problemas de NIS que afectan a muchos clientes
rpc.yppasswdd considera restringido a un shell no restringido que empieza con r
No se puede acceder a la red o los servidores
Funcionamiento incorrecto del servidor
Parte III Servicios de nombres LDAP
9. Introducción a los servicios de nombres LDAP (descripción general)
10. Requisitos de planificación para servicios de nombres LDAP (tareas)
11. Configuración de Oracle Directory Server Enterprise Edition con clientes LDAP (tareas)
12. Configuración de clientes LDAP (tareas)
13. Resolución de problemas de LDAP (referencia)
14. Servicio de nombres LDAP (Referencia)
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.
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
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.
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
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.
Nota - El nombre de dominio NIS distingue entre mayúsculas y minúsculas.
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).
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.
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.
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 |
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.
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 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.
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.
Nota - Cuando ha solucionado el problema, desactive el registro eliminando el archivo de registro. Si olvida eliminarlo, continúa creciendo sin límite.
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 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.
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.
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).