A veces Unix parece estar compuesto de un conjunto de aplicaciones y herramientas. Hay herramientas para resolver problemas con las herramientas. Y, por supuesto, hay varias maneras de realizar la misma tarea. Cuando estás intentando resolver un problema relativo a Samba, un buen plan de ataque es comprobar lo siguiente:
- Los Logs de Samba.
- El Árbol de Errores.
- Utilidades Unix.
- Utilidades de Testeo de Samba.
- Documentación y FAQs.
- Búsqueda de Archivos.
- Grupos de Noticias sobre Samba.
Vamos a ver cada uno de ellos en las siguientes secciones.
Tu primera línea de ataque debería ser siempre chequear los ficheros de registro. Lo ficheros de registro (logs) de Samba te pueden ayudar a detectar la mayoría de problemas a nivel de administrador principiante y medio. Samba es muy flexible en cuanto al registro. Puedes configurar el servidor para que registre pocos eventos o todo lo que tú quieras. Las variables de sustitución te permiten aislar registros individuales para cada máquina, recurso, o combinación de ambos.
Por defecto, los registros se colocan en el directorio directorio_de_samba/var/smbd.log y directorio_de_samba/var/nmbd.log, donde directorio_de_samba es la localización donde se instaló la distribución (normalmente, /usr/local/samba). Como ya mencionamos en el Capítulo 4, 'Recursos de Disco', puedes modificar la ubicación y el nombre usado con la opción de configuración log file en smb.conf. Esta opción acepta todas las variables de sustitución mencionadas en el Capítulo 2,'Instalando Samba sobre un Sistema Unix', así que podrías fácilmente mantener en el servidor un registro separado por cada conexión de cliente especificando lo siguiente en la sección [global] del fichero smb.conf :
log file = %m.log
Alternativamente, puedes especificar un directorio de registro con el flag -l en la línea de comandos. Por ejemplo:
smbd -l /usr/local/var/samba
Otra cosa útil es decirle al servidor que mantenga un registro por cad servicio (recurso) que ofrezca, especialmente si sospechas que un recurso en particular es el causante de tus problemas. Usa la variable %S para configurar esto en la sección [global] del fichero de configuración:
log file = %S.log
Niveles de Registro (Log Levels)
El nivel de registro que usa Samba puede ser controlado en el fichero smb.conf usando la opción global log level o debug level; son equivalente. El nivel de registro es un valor entero con inicio en el rango 0 (no hay registro), y que incrementa el volumen de registro hasta el nivel log level = 3. Por ejemplo, asumamos que vamos a usar un cliente Windows para recorrer un directorio de un servidor Samba. Para tener una pequeña cantidad de información en el registro, puedes usar log level = 1, lo cual indica a Samba que muestre sólo información en curso, que en nuestro caso es sólo la conexión misma:
105/25/98 22:02:11 server (192.168.236.86) connect to service public as user pcguest
(uid=503,gid=100) (pid 3377)
Niveles de registro mayores producen información más detallada. Normalmente no necesitarás más nivel que 2; es más que adecuado para la mayoría de administradores Samba. Los niveles por encima del 3 son de uso para desarrolladores y registran cantidades enormes de información.
Aquí tienes un ejemplo de salidas a nivel 2 y 3 para la misma operación. No te preocupes si no entiendes los recovecos de una conexión SMB; esto es sólamente para demostrarte los tipos de información que se muestran a diferentes niveles de registro:
/* Nivel 2 */
Got SIGHUP
Processing section "[homes]"
Processing section "[public]"
Processing section "[temp]"
Allowed connection from 192.168.236.86 (192.168.236.86) to IPC$
Allowed connection from 192.168.236.86 (192.168.236.86) to IPC/
/* Nivel 3 */
05/25/98 22:15:09 Transaction 63 of length 67
switch message SMBtconX (pid 3377)
Allowed connection from 192.168.236.86 (192.168.236.86) to IPC$
ACCEPTED: guest account and guest ok
found free connection number 105
Connect path is /tmp
chdir to /tmp
chdir to /
05/25/98 22:15:09 server (192.168.236.86) connect to service IPC$ as user pcguest
(uid=503,gid=100) (pid 3377)
05/25/98 22:15:09 tconX service=ipc$ user=pcguest cnum=105
05/25/98 22:15:09 Transaction 64 of length 99
switch message SMBtrans (pid 3377)
chdir to /tmp
trans <\PIPE\LANMAN> data=0 params=19 setup=0
Got API command 0 of form <WrLeh> <B13BWz> (tdscnt=0,tpscnt=19,mdrcnt=4096,mprcnt=8)
Doing RNetShareEnum
RNetShareEnum gave 4 entries of 4 (1 4096 126 4096)
05/25/98 22:15:11 Transaction 65 of length 99
switch message SMBtrans (pid 3377)
chdir to /
chdir to /tmp
trans <\PIPE\LANMAN> data=0 params=19 setup=0
Got API command 0 of form <WrLeh> <B13BWz> (tdscnt=0,tpscnt=19,mdrcnt=4096,mprcnt=8)
Doing RNetShareEnum
RNetShareEnum gave 4 entries of 4 (1 4096 126 4096)
05/25/98 22:15:11 Transaction 66 of length 95
switch message SMBtrans2 (pid 3377)
chdir to /
chdir to /pcdisk/public
call_trans2findfirst: dirtype = 0, maxentries = 6, close_after_first=0, close_if_end = 0
requires_resume_key = 0 level = 260, max_data_bytes = 2432
unix_clean_name [./DESKTOP.INI]
unix_clean_name [desktop.ini]
unix_clean_name [./] creating new dirptr 1 for path ./, expect_close = 1
05/25/98 22:15:11 Transaction 67 of length 53
switch message SMBgetatr (pid 3377)
chdir to /
[...]
Paramos aquí porque si no ocuparia muchas páginas. Sin embargo, puedes con esto advertir que los niveles por encima del 3 llenarán rápidamente tu espacio en disco con megas y megas de información concerniente a operaciones internas de Samba. El nivel de registro 3 es extremadamente útil para saber qué es lo que exactamente está haciendo el servidor, y la mayoría de las veces será fácil advertir un error mirando en el fichero de registro.
Unas palabras de ADVERTENCIA: el uso de un nivel alto de registro (3 o superior) ralentizará seriamente el servidor Samba. Recuerda que cada mensaje generado causa una escritura a disco (una operación inherentemente lenta) y los niveles superiores a 2 producen cantidades masivas de datos. Esencialmente, deberías poner el nivel 3 sólo cuando estés intentando localizar un problema en el servidor Samba.
Activando y Desactivando el registro
Para activar/desactivar las operaciones de registro, establece el nivel apropiado en la sección [global] del fichero smb.conf. Entonces, puedes tanto reiniciar Samba, como obligar al demonio actual a que reprocese el fichero de configuración. También puedes enviar al proceso smbd una señal SIGUSR1 para incrementar su nivel de registro en uno mientras está corriendo, y una señal SIGUSR2 para decrementarlo en uno:
# Increase the logging level by 1
kill -SIGUSR1 1234
# Decrease the logging level by 1
kill -SIGUSR2 1234
Registro de Máquinas Clientes o Usuarios Individualmente
Una manera efectiva de diagnosticar problemas sin tener que molestar a los demás usuarios es asignar diferentes niveles de registro para diferentes máquinas en la sección [global] del fichero smb.conf. Podemos hacerlo usando la estrategia que presentamos antes:
[global]
log level = 0
log file = /usr/local/samba/lib/log.%m
include = /usr/local/samba/lib/smb.conf.%m
Estas opciones indican a Samba que use configuraciones y ficheros de registro independientes para cada cliente que se conecta. Ahora, todo lo que tienes que hacer es crear un fichero smb.conf para una máquina cliente específica con una entrada log level = 3 (los demás usarán el nivel de registro por defecto, 0) y usar ese fichero de registro para localizar el problema.
Similarmente, si sólo determinados usuarios están experimentando el problema, y este pasa de máquina a máquina con ellos, puedes aislar el registro para un determinado usuario añadiendo lo siguiente al fichero smb.conf:
[global]
log level = 0
log file = /usr/local/samba/lib/log.%u
include = /usr/local/samba/lib/smb.conf.%u
Entonces puedes crear un único fichero smb.conf para cada usuario
(p.e., /var/log/samba/smb.conf.pepe), y algunos de ellos conteniendo la opción log level = 3. Así, sólo aquellos usuarios tendrán un registro más detallado.
Un riguroso juego de tests que ejercitan la mayoría de las partes de Samba se describe en varios ficheros en el directorio /docs/textdocs de la distribución, comenzando pr DIAGNOSIS.TXT. El árbol de errores en este capítulo es una versión más detallada de los tests básicos sugeridos por el equipo de Samba, pero sólo cubre diagnósticos de instalación y reconfiguración, como DIAGNOSIS.TXT. Los demás ficheros del directorio /docs tratan problemas específicos (tales como los relacionados con clientes Windows NT) e instruyen sobre cómo resolver problemas no incluídos en este libro. Si el árbol de errores no es suficiente, asegúrate de mirar en DIAGNOSIS.TXT y los demás.
A veces es útil usar una utilidad que no viene con Samba para examinar qué está pasando en el servidor. Unix siempre ha sido un sistema operativo apto para el 'cacharreo'. Dos herramientas de diagnóstico pueden ser de particular ayuda en la depuración de problemas con Samba: trace y tcpdump.
Usando trace
El comando trace se enmascara bajo diferentes nombres, dependiendo del sistema operativo que estés usando. En Linux será strace, en Solaris usarás truss, y SGI tendrá padc y par. Todos tienen esencialmente la misma función, que es displayar cada llamada a una función del sistema operativo cuando esta es ejecutada. Esto te permite seguir la ejecución de un programa, tal como el servidor Samba, y frecuentemente te apuntará la llamada exacta que está causando la dificultad.
Un problema que trace puede detectar es la localización de una versión incorrecta de una librería de enlace dinámico. Esto puede ocurrir si te has bajado binarios precompilados de Samba. Normalmente verás el fallo en la llamada al final del trazado, justo antes de que el programa termine.
Un ejemplo de salida de strace para el sistema operativo Linux se muestra a continuación. Esta es una pequeña parte de un fichero mucho mayor creado durante la apertura de un directorio en el servidor Samba. Cada línea es un nombre de llamada a sistema, e incluye sus parámetros y el valor de retorno. Si hubiera un error, el valor del error (p.e., ENOENT) y su explicación son también mostrados. Puedes mirar los tipos de parámetros y los errores que pueden ocurrir en la página apropiada del manual del comando trace.
chdir("/pcdisk/public") = 0
stat("mini/desktop.ini", 0xbffff7ec) = -1 ENOENT (No such file or directory)
stat("mini", {st_mode=S_IFDIR|0755, st_size=1024, ...}) = 0
stat("mini/desktop.ini", 0xbffff7ec) = -1 ENOENT (No such file or directory)
open("mini", O_RDONLY) = 5
fcntl(5, F_SETFD, FD_CLOEXEC) = 0
fstat(5, {st_mode=S_IFDIR|0755, st_size=1024, ...}) = 0
lseek(5, 0, SEEK_CUR) = 0
SYS_141(0x5, 0xbfffdbbc, 0xedc, 0xbfffdbbc, 0x80ba708) = 196
lseek(5, 0, SEEK_CUR) = 1024
SYS_141(0x5, 0xbfffdbbc, 0xedc, 0xbfffdbbc, 0x80ba708) = 0
close(5) = 0
stat("mini/desktop.ini", 0xbffff86c) = -1 ENOENT (No such file or directory)
write(3, "\0\0\0#\377SMB\10\1\0\2\0\200\1\0"..., 39) = 39
SYS_142(0xff, 0xbffffc3c, 0, 0, 0xbffffc08) = 1
read(3, "\0\0\0?", 4) = 4
read(3, "\377SMBu\0\0\0\0\0\0\0\0\0\0\0\0"..., 63) = 63
time(NULL) = 896143871
Este ejemplo muestra varias estadísticas de llamadas fallando al intentar encontrar los ficheros que buscan. No tienes que ser un experto para ver que el fichero desktop.ini no se encuentra en el directorio. De hecho, muchos problemas complejos pueden ser identificados buscando lo obvio, errores que se repiten con trace. Frecuentemente, no necesitarás buscar más allá del último mensaje antes de la caída.
Usando tcpdump
El programa tcpdump, escrito por Van Jacobson, Craig Leres, y Steven McCanne, y ampliado por Andrew Tridgell, te permite monitorear tráfico de red a tiempo real. Están disponibles una variedad de formatos de salida y puedes filtrar la salida para buscar sólo un tipo particular de tráfico. El programa tcpdump te permite examinar todas las conversaciones entre el cliente y el servidor, incluyendo mensajes de broadcast SMB y NMB. Mientras que sus capacidades ee detección de errores están principalmente a nivel de capa de red (OSI), todavía puedes usar su salida para obtener una idea general que qué están intentando hacer el servidor y el cliente.
A continuación, un ejemplo de registro tcpdump. En este ejemplo, el cliente ha solicitado un listado de directorios, y el servidor ha respondido apropiadamente, dando los nombres de directorios homes, public, IPC$, y temp (hemos añadido unas cuantas aclaraciones a la derecha de las líneas):
$
tcpdump -v -s 255 -i eth0 port not telnet
SMB PACKET: SMBtrans (REQUEST)
Paquete de Respuesta
SMB Command = 0x25
La petición fue ls o dir.
[000] 01 00 00 10 ....
>>> Paquete NBT
Outer frame of SMB packet
NBT Session Packet
Flags=0x0
Length=226
[lines skipped]
SMB PACKET: SMBtrans (REPLY)
Comienzo de una respuesta a una petición
SMB Command = 0x25
El comando fue un ls o un dir
Error class = 0x0
Error code = 0
No hay errores
Flags1 = 0x80
Flags2 = 0x1
Tree ID = 105
Proc ID = 6075
UID = 100
MID = 30337
Word Count = 10
TotParamCnt=8
TotDataCnt=163
Res1=0
ParamCnt=8
ParamOff=55
Res2=0
DataCnt=163
DataOff=63
Res3=0
Lsetup=0
Param Data: (8 bytes)
[000] 00 00 00 00 05 00 05 00 ........
Data Data: (135 bytes)
Directorio Actual contiene:
[000] 68 6F 6D 65 73 00 00 00 00 00 00 00 00 00 00 00 homes... ........
[010] 64 00 00 00 70 75 62 6C 69 63 00 00 00 00 00 00 d...publ ic......
[020] 00 00 00 00 75 00 00 00 74 65 6D 70 00 00 00 00 ....u... temp....
[030] 00 00 00 00 00 00 00 00 76 00 00 00 49 50 43 24 ........ v...IPC$
[040] 00 00 00 00 00 00 00 00 00 00 03 00 77 00 00 00 ........ ....w...
[050] 64 6F 6E 68 61 6D 00 00 00 00 00 00 00 00 00 00 donham.. ........
[060] 92 00 00 00 48 6F 6D 65 20 44 69 72 65 63 74 6F ....Home Directo
[070] 72 69 65 73 00 00 00 49 50 43 20 53 65 72 76 69 ries...I PC Servi
[080] 63 65 20 28 53 61 6D ce (Sam
Esto es parte de la misma sesión de depuración que con el comando trace; el listado de un directorio. Las opciones que usamos han sido -v (verboso), -i eth0 para decirle a tcpdump el interfaz por el que escuchar (un puerto Ethernet), y -s 255 para decirle que almacene los primeros 255 bytes de cada paquete, en vez del valor por defecto, que es los primeros 68. La opción port not telnet es usada para evitar pantallas de tráfico de telnet, ya que estamos logeados en el sistema remotamente. El programa tcpdump actualmente tiene opciones para filtrar sólo el tráfico que quieres vigilar. Si ya has usado comandos como snoop o etherdump, esto te resultará vagamente familiar.
Puedes descargar el tcpdump modificado desde el servidor FTP de Samba en ftp://samba.anu.edu.au/pub/samba/tcpdump-smb. Otras versiones no incluyen soporte para el protocolo SMB; si no ves salidas como la mostrada en el ejemplo, necesitarás usar la versión preparada para SMB.
