



(7 opiniones)
El árbol de errores es para diagnosticar y resolver problemas que ocurren cuando estás instalando y reconfigurando Samba. Es una expansión de un documento sobre problemas y diagnósticos que es parte de la distribución de Samba.
Antes de que te metas en faena, deberías conocer la siguiente información:
Para mayor claridad, hemos renombrado el servidor en los próximos ejemplos a server.example.com, y la máquina cliente a client.example.com.
Cómo usar el árbol de errores
Comienza los tests aquí, sin saltarte nada; no te llevará mucho (unos 5 minutos). Cuando se ejecuta un test, recibirás un nombre de sección y de página, para que sepas cuál te puedes saltar.
Resolución de Problemas de IP a Bajo Nivel
La primera serie de tests se refiere a los servicios de bajo nivel que Samba necesita para funcionar. Los tests en esta sección verificarán que:
Secciones siguientes añadirán software TCP, los demonios de Samba smbd y nmbd, control de acceso basado en host, control de autentificación y acceso por usuario, servicios de fichero, y nagevación (browsing). Los tests son descritos en gran detalle para hacerlos comprensibles tanto por usuarios finales como por experimentados administradores de sistemas y redes.
Ahora que ya has testeado IP, UDP, y servicio de nomrbes con ping, es momento de testear TCP. Los ping y la navegación (browsing) usan ICMP y UDP; los servicios de ficheros e impresión (recursos) usan TCP. Ambos dependen de la IP en su capa más baja y todos dependen del servicio de nombres. El testeo de TCP se hace mejor usando el programa FTP (file transfer protocol, protocolo de transferencia de ficheros).
Testeando TCP con FTP
Intenta conectar vía FTP, una vez desde el servidor contra sí mismo, y otra desde el cliente hacia el servidor:
server% ftp server Connected to server.example.com. 220 server.example.com FTP server (Version 6.2/OpenBSD/Linux-0.10) ready. Name (server:davecb): 331 Password required for davecb. Password: 230 User davecb logged in. ftp> quit 221 Goodbye.
Si esto funciona, pasa a la sección 9.2.4, Problemas con los Demonios del Servidor. De lo contrario:
Problemas con los Demonios del Servidor
Uan vez hemos confirmado que el TCP de red está trabajando correctamente, el siguiente paso es asegurarnos de que los demonios están corriendo en el servidor. Esto requiere la realización de tres tests distintos, porque ninguno de los tres por separado probará definitivamente que estos están funcionando correctamente.
Para asegurarnos de que los demonios están corriendo, necesitas comprobar que:
Antes de Empezar
Primero comprueba los ficheros de registro. Si has iniciado los demonios, el mensaje 'smbd version some_number started' (smbd version XX iniciado) debería aparecer. Si no lo hace, necesitarás reiniciar los demonios de Samba.
Si el demonio reporta que ha sido iniciado, busca 'bind failed on port 139 socket_addr=0 (Address already in use)' (la asociación falló en el puerto 139 socket_addr=0 (La dirección ya está en uso). Esto significa que otro demonio había sido iniciado sobre el puerto 139 (normalmente es el que usa smbd). Además, nmbd reportará un fallo similar si no puede ser asociado al puerto 137. Los demonios pueden ser iniciados por ti manualmente, o bien por el servidor inetd. Si este último es tu caso, lo diagnosticaremos en un momento.
Buscando procesos de demonios con ps
A continuación, necesitas saber si los demonios han sido iniciados. Usa el comando ps en el servidor con la opción adecuada para tu tipo de máquina (normalmente ps ax o ps -ef. En Linux, prueba ps -A o ps -uax), y mira si tienes smbd y nmbd corriendo. Esto se te presentaría por la pantalla de la siguiente manera:
server% ps ax PID TTY STAT TIME COMMAND 1 ? S 0:03 init [2] 2 ? SW 0:00 (kflushd) (...más líneas de procesos...) 234 ? S 0:14 nmbd -D3 237 ? S 0:11 smbd -D3
Este ejemplo ilustra que smbd y nmbd han sido iniciados como demonios autosuficientes (la opción -D) en el nivel de arranque 3.
Buscando Demonios Asociados a Puertos
Ahora, los demonios deben ser registrados con el sistema operativo, de manera que puedan acceder a los puertos TCP/IP. El comando netstat te dirá si esto se ha hecho. Ejecuta el comando netstat -a en el servidor, y mira línesa que mencionen los términos netbios, 137 o 139:
server% netstat -a Active Internet connections (including servers) Proto Recv-Q Send-Q Local Address Foreign Address (state) udp 0 0 *.netbios- *.* tcp 0 0 *.netbios- *.* LISTEN tcp 8370 8760 server.netbios- client.1439 ESTABLISHED
o:
server% netstat -a Active Internet connections (including servers) Proto Recv-Q Send-Q Local Address Foreign Address (state) udp 0 0 *.137 *.* tcp 0 0 *.139 *.* LISTEN tcp 8370 8760 server.139 client.1439 ESTABLISHED
Aparte de otras líneas similares, debería haber al menos una línea UDP para *.netbios- o *.137. Esto indica que el servidor nmbd está registrado y que (eso esperamos) está esperando para responder a peticiones. Debería haber también al menos una línea TCP mencionando *.netbios- o *.139, y probablemente estará en el estado LISTENING. Esto significa que smbd está levantado y a la escucha, esperando conexiones.
Pueden existir otras líneas TCP, indicando conexiones desde smbd a clientes, una por cada cliente. Estas están normalmente en el estado ESTABLISHED. Si hay líneas smbd en el estado ESTABLISHED, smbd está definitivamente funcionando. Si sólo hay una línea en el estado LISTENING, no lo podríamos asegurar. Si alguna de las líneas no aparece, uno de los demonios no ha sido iniciado, así que es momento de comprobar los ficheros de registro y volver al Capítulo 2.
Si hay una línea por cada cliente, esta puede venir tanto desde un demonio de Samba como del demonio maestro IP, inetd. Es muy posible tu fichero de arranque de inetd contenga líneas para iniciar los demonios de Samba sin que tú tengas que intervenir; por ejemplo, las líneas podrían haber sido creadas si instalaste Samba como parte de una distribución Linux. Los demonios que son iniciados por inetd no requieren de nosotros para ser iniciados. Este problema suele producir mensajes en el fichero de registro, tales como 'bind failed on port 139 socket_addr=0 (Address already in use)'.
Comprueba tu /etc/inetd.conf ; a menos que intencionadamente quieras que se inicien desde ahí, no deberían existir servidores netbios-ns (puerto udp 137) o netbios-ssn (puerto tcp 139). inetd es un demonio que proporciona numerosos servicios, controlados por entradas en /etc/inetd.conf. Si tu sistema está proporcionando un demonio SMB vía inetd, deberían existir líneas como las siguientes en el mencionado fichero:
netbios-ssn stream tcp nowait root /usr/local/samba/bin/smbd smbd netbios-ns dgram udp wait root /usr/local/samba/bin/nmbd nmbd
Comprobando smbd con telnet
Irónicamente, la forma más sencilla de comprobar que el servidor smbd está actualmente funcionando es enviando un mensaje sin sentido y viendo si lo rechaza. Intenta algo como esto:
echo hello | telnet localhost 139
Esto envía un erróneo pero inofensivo mensaje a smbd. El mensaje hello es importante. No intentes un telnet al puerto y luego teclear algo; probablemente sólo consigas colgar tu proceso. hello, sin embargo, es generalmente un mensaje inofensivo:
server% echo "hello" | telnet localhost 139 Trying Trying 192.168.236.86 ... Connected to localhost. Escape character is '^]'. Connection closed by foreign host.
Si obtienes un mensaje 'Connected' (Conectado) seguido de un mensaje 'Connection closed' (Conexión Cerrada), el test ha tenido éxito. Tienes un demonio smbd escuchando en el puerto y rechazando mensajes de conexión inadecuados. Por otra parte, si obtienes un 'telnet: connect: Connection refused' (telnet: conexión: Conexión rechazada) hay un posible problema de demonio no presente. Comprueba los ficheros de registro y regresa alCapítulo 2.
Desgraciadamente, no hay un test sencillo para nmbd. Si los tests usandotelnet ynetstat te indicaban que había unsmbd corriendo, también hay una buena opción para comprobar el funcionamiento denmbd.
Testeando los Demonios con testparm
Una vez que sabes que hay un demonio, siempre deberías ejecutar testparm, a la espera de obtener:
server% testparm Load smb config files from /opt/samba/lib/smb.conf Processing section "[homes]" Processing section "[printers]" ... Processing section "[tmp]" Loaded services file OK. ...
El programa testparm normalmente reporta procesos y series de secciones, y responde con 'Loaded services file OK' (fichero de servicios cargado OK) si tiene éxito. Si no, reportará uno o más de uno de los siguiente mensajes, que también aparecerán en los ficheros de registro:
Tras el test copn testparm, repítelo con (exactamente) tres parámetros: el nombre de tu fichero smb.conf, el nombre de tu cliente y su dirección IP:
testparm samba_directory/lib/smb.conf client 192.168.236.10
Esto ejecutará un test más que comprobará el nombre de máquina y su dirección contra las opciones host allow y host deny, y puede producir el mensaje de servicio 'Allow/Deny connection from account account_name' (Conexión Admitida/Denegada desde cuenta nombre_de_cuenta) para la máquina del cliente. Este mensaje indica que tienes opciones sobre máquinas válidas/inválidas en tu smb.conf, que prohíben el acceso desde la máquina cliente. Introducir testparm /usr/local/lib/experimental.conf es también una forma efectiva de testear un fichero smb.conf experimental antes de ponerlo en producción.
Resolviendo Problemas con Conexiones SMB
Ahora que sabemos que los servidores están funcionando, necesitamos asegurarnos de que están funcionando adecuadamente. Comenzaremos por el fichero smb.conf en el directorio de samba directorio_samba/lib.
Un Fichero de Configuración Mínimo
En los próximos tests, asumiremos que tenemos un recurso [temp] preparado para ser comprobado, y al menos una cuenta. Un fichero smb.conf que incluya esto sería de la forma:
[global] workgroup = EXAMPLE security = user browsable = yes local master = yes [homes] guest ok = no browseble = no [temp] path = /tmp public = yes
Una nota de advertencia: la opción public = yes en el recurso [temp] es sólo para las pruebas. Probablemente no querrás que los usuarios sin cuentas están habilitados para almacenar cosas en tu servidor Samba, así que deberías comentar esta línea cuando hayas acabado las pruebas.
Testeando Localmente con smbclient
El primer test es asegurarnos de que el servidor puede listar sus propios servicios (recursos). Ejecuta el comando smbclient con la opción -L contra localhost para que se conecte consigo mismo, y una opción -U% para especificar al usuario invitado. Deberías ver lo siguiente:
server% smbclient -L localhost -U% Server time is Wed May 27 17:57:40 1998 Timezone is UTC-4.0 Server=[localhost] User=[davecb] Workgroup=[EXAMPLE] Domain=[EXAMPLE] Sharename Type Comment --------- ----- ---------- temp Disk IPC$ IPC IPC Service (Samba 1.9.18) homes Disk Home directories This machine does not have a browse list
Si recibes esta salida, vete al siguiente test, en la sección 9.2.5.3, 'Testeando Conexiones con smbclient'. Por el otro lado, si recibes un error, comprueba lo siguiente:
Si obtienes el mensaje 'Your server software is being unfriendly' (El software de tu servidor no está siendo amigable), el paquete de petición de sesión inicial obtuvo una respuesta con basura desde el servidor. El servidor puede haberse caído o iniciado inadecuadamente. Las causas más comunes de esto pueden descubrirse buscando en los ficheros de registro:
Testeando Conexiones con smbclient
Ejecuta el comando smbclient \\server\temp, el cual conecta al recurso /tmp de tu servidor, para ver si puedes conectar a ese servicio de ficheros. Deberías obtener la siguiente respuesta:
server% smbclient '\\server\temp' Server time is Tue May 5 09:49:32 1998 Timezone is UTC-4.0 Password: smb: \> quit
Si obtienes el mensaje 'Get_Hostbyname: Unknown host name', 'Connect error: Connection refused' o 'Your server software is being unfriendly', mira la sección 9.2.5.2, 'Testeando localmente con smbclient' para los diagnósticos.
Si obtienes el mensaje 'servertemp: Not enough `\' characters in service' (servertemp: No hay bastantes caracteres '\' en el servicio), probablemente no pusiste bien las barras de dirección. También puedes escribir el comando:
smbclient \\\\ server \\temp
o:
smbclient // server/temp
Ahora, proporciona tu contraseña de cuenta Unix al prompt Password. si obtienes un prompt smb\>, funciona. Introduce quit, y continúa con la sección 9.2.5.4, 'Testeando conexiones con NET USE'. Si entonces obtienes 'SMBtconX failed. ERRSRV - ERRinvnetname', el problema puede ser cualquiera de los siguientes:
Hay una razón más para éste fallo, que no tiene nada que ver con las contraseñas: la línea path = de tu fichero smb.conf puede apuntar a algún sitio que no exista. Esto no será detectado por testparm, y la mayoría de los clientes SMB tampoco te lo podrán indicar. Lo tendrás que chequear manualmente.
Una vez hayas conseguido conectar a [temp] con éxito, repite el test, esta vez logeándote en tu directorio home (p.e., mapea la unidad de red \davecb) a la busca de fallos en el intento de conexión. Si tienes que cambiar algo, una vez lo hayas echo vuelve a testear [temp].
Testeando las Conexiones con NET USE
Ejecuta el comando net use * \server\temp desde el cliente DOS o Windows para ver si puede conectarse al servidor. Debería aparecerte una petición de contraseña, y luego recibir la respuesta 'The command was completed successfully' (El comando fue cumplido satisfactoriamente), como se muestra en la Figura 9.2.
Si sale todo bien, continúa con los pasos de la sección 9.2.5.5, 'Testeando Conexiones con el Explorador de Windows'. De lo contrario:
Si obtienes 'The computer name specified in the network path cannot be located' (el nombre de computadora especificado en la ruta de red no pudo ser localizado) o 'Cannot locate specified computer' (no puedo localizar la computadora especificada), se te ha olvidado el nombre del directorio, o el servicio de nomrbes ha fallado, o existe un problema de red, o la opción hosts deny = incluye a tu máquina.
Los clientes Windows 95 y 98 mantienen un fichero de contraseñas local, pero es sólo una copia de la contraseña que estos envían a los servidores Samba y NT para autenticarse. Eso es lo que se te está pidiendo aquí. En una máquina Windows puedes logearte (acceder) sin introducir contraseñas (esto no lo puedes hacer en una máquina NT).
Gracias a 'la buena voluntad' del Internet Explorer que nos permite acceder a direcciones o URLs tales como file://algun_host/algun_fichero para hacer conexiones SMB, los clientes con Windows 95 Service Pack 2 podrían fácilmente enviar su contraseña, en texto plano, a servidores SMB desde cualquier lugar de Internet. Esto es considerado una mala idea, y Microsoft ha pasado rápidamente a usar sólo contraseñas encriptadas en el protocolo SMB. Todas las versiones siguientes de sus productos han incluido esta corrección. Las contraseñas encriptadas no son actualmente necesarias a menos que estés usando Internet Explorer 4.0 sin un cortafuegos, así que es razonable continuar usando contraseñas sin encriptar en tus propias redes.
El término 'bind' (enlace) es usado para indicar la conexión de una pieza de software a otra en este caso. El cliente SMB de Microsoft es enlazado a TCP/IP en la sección Enlaces del panel de propiedades TCP/IP bajo el icono de red de Windows 95/98 en el Panel de Control. TCP/IP en cambio está enlazado a una tarjeta Ethernet. No tiene exactamente el mismo sentido que el enlace de un demonio SMB a un puerto TCP/IP.
Testeando Conexiones con el Explorador de Windows
Inicia el Explorador de Windows o NT (no el Internet Explorer), selecciona Herramientas/Mapear Unidad de Red y especifica \\server\temp para ver si puedes conectar con el directorio /tmp. Deberías ver una pantalla similar a la de la Figura 9.3. Si es así, has conectado y puedes pasar a la sección 9.2.6, 'Problemas con la Navegación'.
Unas palabras de advertencia: el Explorador de Windows y el Explorador de NT son bastante pobres como herramientas de diagnóstico: te dirán que algo va mal, pero probablemente no te dirán qué es lo que va mal. Si obtienes un error, necesitarás hacerle un seguimiento con el comando NET USE, el cual es superior como herramienta de reporte de errores:
Si obtienes 'The password for this connection that is in your password file is no longer correct' (la contraseña para esta conexión que se encuentra en tu fichero de contraseñsa no es correcta), puedes comprobar lo siguiente:
Si obtienes 'The network name is either incorrect', o 'A network to which you do not have full access' (el nombre de red es incorrecto, o una red a la que no tienes acceso total) o 'Cannot locate specified computer' (no puedo localizar a la computadora especificada), puedes comprobar lo siguiente:
Una vez hayas conseguido conectar al recurso [temp], intentalo de nuevo, esta vez usando tu directorio home. Si tienes que cambiar algo para hacer que los directorios home funcionen, vuelve a testearlo con [temp], y viceversa, como vimos en la sección 9.2.5.4. Como siempre, si el Explorador falla, vuelve a la sección y depúrala.
Finalmente, vamos a navegar. Esto se ha dejado para el final, no precisamente porque sea el método más difícil, sino porque es opcional y parcialmente dependiente de un protocolo que no garantiza la entrega de paquetes. Navegando es difícil diagnosticar, si no estás seguro de que los demás servicios están corriendo.
La navegación es puramente opcional: es sólo una manera de encontrar servidores en tu red y los recursos que estos ofrecen. La navegación también asume que todas tus máquinas están en una red local (LAN) donde los mensajes por difución o broadcasts están permitidos.
Primero, el mecanismo de navegación identifica una máquina utilizando el protocolo UDP (inseguro); luego hace una conexión normal TCP/IP (segura) para listar los recursos que la máquina proporciona.
Testeando la Navegación con smbclient
Comenzaremos por testear primero la conexión segura. Desde el servidor, intenta listar sus propios recursos via smbclient con la opción -L , seguido del nombre de tu servidor. Deberías obtener:
server% smbclient -L server Added interface ip=192.168.236.86 bcast=192.168.236.255 nmask=255.255.255.0 Server time is Tue Apr 28 09:57:28 1998 Timezone is UTC-4.0 Password: Domain=[EXAMPLE] OS=[Unix] Server=[Samba 1.9.18] Server=[server] User=[davecb] Workgroup=[EXAMPLE] Domain=[EXAMPLE] Sharename Type Comment --------- ---- ------- cdrom Disk CD-ROM cl Printer Color Printer 1 davecb Disk Home Directories This machine has a browse list: Server Comment --------- ------- SERVER Samba 1.9.18 This machine has a workgroup list: Workgroup Master --------- ------- EXAMPLE SERVER
Si aún no obtienes nada, no deberías haber llegado hasta aquí. Regresa hasta al menos la sección 9.2.3.1, o quizás la 9.2.2.4. Chequea a partir de ahí.Por otra parte:
Si obtienes 'Bad password' (Contraseña incorrecta) entonces presumiblemente tienes algo de lo siguiente:
Testeando el Servidor con nmblookup
Esto testeará el sistema de 'advertencias' usado por el servicio de nombres y navegación de Windows. Los avisos funcionan mediante difusión de una presencia o buena voluntad para proveer servicios. Esta es la parte de la navegación que usa un protocolo poco seguro, o 'Unreliable Protocol' (UDP), y funciona sólo en redes de difusión como las reder Ethernet. El programa nmblookup hace difusión de peticiones de nombres para el nombre de máquina que proporcionas, y retorna su dirección IP y el nombre de la máquina, algo así como hace nslookup con DNS. Aquí, la opción -d (depuración o nivel de registro), y la opción -B (difusión de direcciones) dirigen peticiones a máquinas específicas.
Primero, comprobaremos el servidor desde sí mismo. Ejecuta nmblookup con la opción -B y el nombre de tu servidor para decirle que envíe la petición al servidor Samba, y el parámetro __SAMBA__ 9.1 como nombre simbólico a buscar. Deberías obtener:
server% nmblookup -B __SAMBA__ Added interface ip=192.168.236.86 bcast=192.168.236.255 nmask=255.255.255.0 Sending queries to 192.168.236.86 192.168.236.86 __SAMBA__
Deberías obtener la dirección IP del servidor, seguido del nombre __SAMBA__ , lo que significa que el servidor ha sido satisfactoriamente advertido de que tiene un servicio llamado __SAMBA__ , y por lo tanto al menos la parte de servicio de nombres NetBIOS funciona.
Si obtienes 'Name_query failed to find name __SAMBA__' (Petición de nombre falló al intentar encontrar a __SAMBA__) puedes haber especificado una dirección incorrecta en la opción -B, o bien nmbd no está funcionando. La opción -B actualmente toma una dirección broadcast: estamos usando un nombre de máquina para obtener una dirección única,y para preguntar al servidor si esta la reclama __SAMBA__.
Intenta de nuevo con -B dirección_IP, y si también falla, entonces nmbd no está reclamando el nombre. Regresa a la parte 'Testeando demonios con testparm' para ver si nmbd está funcionando. Si es así, puede que no esté reclamando nombres; esto significa que Samba no está proporcionando el servicio de navegavión (un problema de configuración). Si este es el caso, asegúrate de que smb.conf no contiene la opción browsing = no.
Testeando el Cliente con nmblookup
A continuación, comprueba la dirección IP del cliente desde el servidor con nmblookup, usando la opción -B para el nombre del cliente y un parámetro '*', significando'cualquiera', como ves a continuación:
server% nmblookup -B client '*' Sending queries to 192.168.236.10 192.168.236.10 * Got a positive name query response from 192.168.236.10 (192.168.236.10)
Repite el comando con las siguientes opciones si obtienes algún error:
Testeando la Red con nmblookup
Ejecuta el comando nmblookup de nuevo, con la opción -d (nivel de depuración) a 2 y un parámetro '*'. Esta vez estamos testeando la capacidad de los programas (tales como nmbd) para usar difusión o broadcast. Se trata esencialmente de un test de conectividad, hecho a través de una difusión enviada a la dirección por defecto de broadcast de la red.
Un número de máquinas NetBIOS/TCP-IP de la red deberían responder con mensajes 'got a positive name query response' (Se obtuvo una respuesta positiva de nombre). Samba puede no capturar todas las respuestas en el corto espacio de tiempo que está escuchando, así que no siempre verás a todos los clientes SMB de la red. Sin embargo, deberías ver a la mayoría de ellos:
server% nmblookup -d 2 '*' Added interface ip=192.168.236.86 bcast=192.168.236.255 nmask=255.255.255.0 Sending queries to 192.168.236.255 Got a positive name query response from 192.168.236.191 (192.168.236.191) Got a positive name query response from 192.168.236.228 (192.168.236.228) Got a positive name query response from 192.168.236.75 (192.168.236.75) Got a positive name query response from 192.168.236.79 (192.168.236.79) Got a positive name query response from 192.168.236.206 (192.168.236.206) Got a positive name query response from 192.168.236.207 (192.168.236.207) Got a positive name query response from 192.168.236.217 (192.168.236.217) Got a positive name query response from 192.168.236.72 (192.168.236.72) 192.168.236.86 *
Sin embargo:
Testeando la Navegación del Cliente net view
En el cliente, ejecuta el comando net view \\server en una ventana DOS para ver si puedes conectar con el cliente al servidor y ver qué recursos está ofreciendo éste último. Deberías obtener una lista de los recursos disponibles en el servidor, como muestra la Figura 9.4.
Si recibes esto, continúa con la Sección 9.2.7, 'Otras Cosas que pueden Fallar'.
Navegando por el Servidor desde el Cliente
Dede el Entorno de Red, intenta navegar por el servidor. Tu servidor Samba debería aparecer en la lista de máquina de tu grupo de trabajo de tu red. Deberías poder picar sobre el servidor y obtener una lista de recursos, como se ilustra en la Figura 9.5.
Si recibes un error 'Unable to browse the network' (Incapaz de navegar por la red), algo de lo siguiente ha ocurrido:
Si recibes el mensaje '\\server is not accessible' (el servidor \\server no está accesible) entonces:
Otras Cosas que pueden Fallar
Si has llegado hasta aquí, o el problema ha sido resuelto o se trata de algo que nadie ha visto aún. Las siguientes secciones cubren tareas de solución de problemas que son requeridas para la infraestructura de ejecución de Samba, no para Samba mismo.
No hay logeado
Un problema ocasional es olvidar logearse en el cliente, o logearse como un usuario incorrecto. Lo anterior no está controlado del todo: Windows intenta ser amigable y te permite entrar ¡Localmente! (sin acceso a red). La única advertencia es que Windows te da la bienvenida y te pide des de alta una nueva cuenta. Intenta reseteando la máquina y logeándote de nuevo.
Problemas con Servicios de Nombres
Esta sección busca la solución de errores simples en todos los servicios de nombres conlos que te puedas encontrar, pero sólo en relación a los problemas típicos que afectan a Samba.
Hay varias buenas referencias para resolver problemas particulares con servicios de nombres: el libro 'Paul Albitz and Cricket Liu's DNS and Bind' cubre el Domain Name Service (DNS), el de Hal Stern 'NFS and NIS' (ambos disponibles en O'Reilly) cubre NIS ('Páginas Amarillas') mientras que WINS (Windows Internet Name Service), ficheros hosts/LMHOSTS y NIS+ están cubiertos en sus respectivos manuales originales de producto.
Los problemas tratados en ésta sección son:
Identificando qué está en uso
Primero, veamos si tanto el servidor como el cliente están usando DNS, WINS, NIS, o ficheres hosts para localizar direcciones IP cuando damos un nombre. Cada tipo de máquina tendrá unas preferencias diferente:
|