David Martín :: Suki_ :: escribió: > El Miércoles, 21 de Febrero de 2007 14:51, Miguel Da Silva - Centro de > Matemática escribió: >> Mirando el script /etc/init.d/nis me di cuenta que el problema es cuando >> se trata de "enlazar" el cliente al dominio. Yo puedo ejecutar >> manualmente el comando ypbind -broadcast o solamente ypbind para >> levantar el daemon, pero eso tampoco resuelve el problema. Siempre que >> ejectue ypwhich recibo un mensaje de error en vez de recibir el nombre >> del host que se hace de servidor NIS. > > Efectivamente, tiene toda la pinta de que no resuelve bien el nombre de la > máquina. > >> Ese problema empezó el lunes pasado y la máquina llevaba unos 15 dias de >> uptime. No sé si será coincidencia o casualidad, pero justo el lunes >> hice una actualización de esa PC (que corre Etch). Como dije antes, es >> la única PC que tiene ese problema. Sus compañeras no tienen nada de malo. >> >> Alguna sugerencia? > > Para confirmar que es la resolución de nombre, añade a mano en el /etc/hosts > el nombre de la máquina servidor del NIS. Si así te funciona correctamente, > ya sabes donde tienes el problema. :)
Gracias por la sugerencia David, pero eso ya lo hice. Por experiencias previas (y por algunas lecturas que hice sobre el tema), me di cuenta que no es buena idea esperar que el servidor de nombres resuelva el nombre del servidor de NIS en el cliente NIS. Así que todos los clientes NIS que tenemos poseen en el archivo /etc/hosts una linea correspondiente al servidor NIS. Allí ponemos el nombre que usaremos en algún cliente que necesite esa configuración en el archivo /etc/yp.conf. O sea, el archivo /etc/hosts de la máquina problemática tiene esa linea incluída: 192.168.25.4 nis.dominio.com nis Donde 192.168.25.4 es la IP del servidor NIS. Además estube probando agregar la siguiente linea al archivo /etc/yp.conf: ypserver nis.dominio.com Lo más curioso es que el daemon de la NIS se levanta bien en el cliente durante el boot, pero si lo bajo y trato de levantarlo nuevamente, una vez que la PC está funcionando, ya no tengo éxito y ahí empiezan los problemas. Estube mirando los logs y encontré eso en el archivo /var/log/daemon.log: Feb 21 08:25:09 dogbert ypbind[2709]: Connection to D-BUS system message bus failed: Failed to connect to socket /var/run/dbus/system_bus_soc ket: No such file or directory. Feb 21 08:25:09 dogbert ypbind[2709]: Assuming online mode Esa linea que comunica la falta de un archivo de D-BUS empezó a aparecer después que hice la actualización del sistema y aparece porque la NIS se está levantado antes que D-BUS. En ese cliente se tiene S19nis y S20dbus en las carpetas de los runlevels. Hice la prueba de cambiar el valor que tiene el link que levanta la NIS, lo puse como S21nis y entonces ya no tuve más éxito ni siquiera cuando reiniciba la PC. Será eso un problema con el cliente NIS y D-BUS? Estuve leyendo, creo que en el manpage de ypbind, algo sobre deshabilitar el soporte a D-BUS en el cliente NIS. No lo probé porque estoy en mi otro trabajo y solo tengo acceso remoto a la PC problemática. Voy a revisar las últimas actualizaciones hechas para ver qué fue lo que ha sido actualizado y además sguir investigando ese problema. Saludos. -- Miguel Da Silva Administrador de Red Centro de Matemßtica - http://www.cmat.edu.uy Facultad de Ciencias - http://www.fcien.edu.uy Universidad de la Rep·blica - http://www.rau.edu.uy -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]