El reto de compartir impresoras en Linux con Samba

Lograr que las impresoras compartidas con Samba funcionen correctamente en puestos de trabajo con sistemas operativo Linux no siempre es una cuestión sencilla, y aún más si hablamos de entornos de producción empresariales donde se intenta implementar tecnologías libres en remplazo de Windows, el claro dominador de ese segmento.

Este es uno de esos artículos que ayudan a evitar que un caso similar nos pueda sorprender con la mente en blanco, ya que cuando se presentan requieren de una solución inmediata.

Compartir una impresora en Windows quizás sea bastante sencillo y fiable, suele funcionar sin mayores problemas ya que al fin y al cabo estamos hablando de los creadores del protocolo. Samba sin embargo hace su mejor esfuerzo con su implementación libre del protocolo CIFS, que sin duda ha permitido a los entornos Unix-like hacerse de un hueco en entornos laborales.

Mi experiencia con Samba nunca ha sido demasiado grande, siendo sincero, pero por sus fines pienso que no se debería necesitar ser un gurú para poder configurar un servicio medianamente adecuado. Con respecto a las impresoras compartidas en Samba, se me han presentado ciertas incidencias, algunas menores y otras más complicadas, de las cuales quisiera compartir dos con ustedes a continuación.

A modo de aclaración quisiera agregar que las incidencias no necesariamente están relacionadas solo con Samba, sino que dependen también del sistema operativo utilizado (openSUSE) y de las versiones de ambos. Así que no se buscan culpables, sino solamente contar los hechos y como fueron solucionados "al vuelo"...


Problemas con la base de datos de la impresora compartida

Este es uno de esos problemas que son difíciles de reproducir y que te dan mil vueltas hasta que uno encuentra la solución. El síntoma que se presentaba "esporádicamente" era que al enviar varias impresiones, una o dos salían de forma consecutiva y sin problemas, pero al enviar más a la vez las impresiones se pausaban cada vez más y luego las mismas ya ni siquiera salían.

Al probar impresiones locales todo funcionaba bien por lo que el problema definitivamente no estaba con Cups, sino con el recurso compartido mediante Samba. Finalmente el problema resultó estar en los archivos TDB (Trivial Database), que son bases de datos que Samba crea individualmente por cada una de las impresoras compartidas para manejar el recurso.

En openSUSE dichos archivos se encuentran ubicados en el directorio /var/lib/samba/printing y deberían mantener un tamaño uniforme similar al que se puede observar a continuación:
testsrv:~ # cd /var/lib/samba/printing/
testsrv:/var/lib/samba/printing # ls -l
total 56
-rw------- 1 root root 28672 Dec 28 17:51 miImpresora.tdb
-rw------- 1 root root 28672 Dec 28 06:51 printers.tdb
testsrv:/var/lib/samba/printing #
El problema antes mencionado se presentaba cuando el tamaño del archivo tdb de la impresora superaba con creces el tamaño normal. Esto quizás era provocado por algún bug presente en la compilación de Samba para openSUSE 11.2 o bien por la gran cantidad de impresiones que se realizaban, lo que sí era seguro es que se debía solucionar el problema de la forma más sencilla y rápida posible para que los puestos ya no presentaran el inconveniente.

La solución que se implementó fue editar el archivo halt.local ubicado en el directorio /etc/init.d:
testsrv:~ # vi /etc/init.d/halt.local
y agregar al final un comando que se encargue de eliminar los archivos .tdb:
#! /bin/sh
#
# Copyright (c) 2002 SuSE Linux AG Nuernberg, Germany.  All rights reserved.
#
# Author: Werner Fink, 1998
#         Burchard Steinbild, 1998
#
# /etc/init.d/halt.local
#
# script with local commands to be executed from init on system shutdown
#
# Here you should add things, that should happen directly before shuting
# down.
#
/bin/rm -f /var/lib/samba/printing/*.tdb

Así al apagar el equipo siempre los archivos son eliminados, Samba ya se encargará de crearlos nuevamente durante el arranque al detectar que los mismos no existen.


Fallo al intentar utilizar el recurso desde entornos Unix-like

Recientemente se me ha presentado un caso bastante peculiar al tratar de implementar unos puestos de facturación que estrenaban una nueva distribución openSUSE 12.2 personalizada para dicho fin. Si bien no se había probado previamente el envío de impresiones a los recursos compartidos, se suponía "erróneamente" que al aparecer el recurso compartido ya lo demás debería funcionar.

Lo interesante de este caso es que al intentar enviar una impresión remota desde un equipo o servidor Unix-like en el recurso compartido simplemente la impresión no salía, sin embargo, al enviarla desde un equipo con Windows la misma salía sin problemas.

Las impresiones enviadas con el comando lp desde la línea de comandos de equipos con sistemas operativos SCO OpenServer 6.0 u openSUSE no desplegaban información alguna relacionada con el inconveniente
testsrv# lp -d miImpresora /tmp/prueba.txt
request id is miImpresora-4635 (1 file)
testsrv#
Editando el archivo miImpresora del directorio /etc/lp/interfaces para conocer un poco más acerca de cómo se encontraban montadas las impresoras remotas en SCO....
testsrv# vi /etc/lp/interfaces/miImpresora
pude encontrar la directiva Samba (resalta más abajo) que utiliza el comando lp para enviar las impresiones a recursos compartidos mediante el protocolo CIFS.
# Modelo de lp/interface para samba en SCO Unix
#
# Copyright (c) CPC S.R.L. 1997
#
# Habilite por scoadmin, poniendo /dev/null como dispositivo
#
# Reemplace win95 y hp por los valores correspondientes
# de nombre de PC y nombre de impresora
server=ip_equipo_linux
service=miImpresora
password=$2
options=$5
#
shift; shift; shift; shift; shift
files=$*
samba=/usr/bin/smbclient

for file in $files
do
(echo translate; echo "print -"; cat $file; echo "\f\c") \
| $samba "\\\\$server\\$service" -N  > /dev/null
done
#
# Para imprimir sin clave secreta, reemplace $password por -N
#
Y que al ejecutarlo de forma independiente en la línea de comandos la salida ya aportaba mayor información:
testsrv# (echo translate; echo "print -"; cat /tmp/prueba.txt; echo "\f\c") | smbclient -N "\\\\ip_equipo_linux\\miImpresora"
Domain=[TEST2] OS=[Unix] Server=[Samba 3.6.7-48.12.1-2831-SUSE-SL12.2-i386]
NT_STATUS_ACCESS_DENIED opening remote file stdin-5838
El error y su solución la encontré leyendo éste enlace, donde comentan que el problema se soluciona agregando la directiva use client driver = Yes a la configuración del archivo /etc/samba/smb.conf del equipo que comparte el recurso.
# smb.conf is the main Samba configuration file. You find a full commented
# version at /usr/share/doc/packages/samba/examples/smb.conf.SUSE if the
# samba-doc package is installed.
# Date: 2008-12-03
[global]
        workgroup = TESTNET.LOCAL
        printing = cups
        printcap name = /etc/printcap
        printcap cache time = 750
        cups options = raw
        map to guest = Bad User
        logon path = \\%L\profiles\.msprofile
        logon home = \\%L\%U\.9xprofile
        logon drive = P:
        usershare allow guests = Yes
        add machine script = /usr/sbin/useradd  -c Machine -d /var/lib/nobody -s /bin/false %m$
        domain logons = No
        domain master = No
        local master = No
        os level = 65
        preferred master = No
        security = user
        usershare max shares = 100
        passdb backend = smbpasswd
        wins support = No

[printers]
        comment = All Printers
        path = /var/tmp
        printable = Yes
        create mask = 0600
        guest ok = yes
        browseable = Yes
        use client driver = Yes
Este problema no se presenta con los equipos que utilizan la versión openSUSE 11.2. Quizás esté relacionado con la nueva versión de Samba presente en la distro openSUSE 12.2 personalizada y el acceso a los recursos compartidos desde otros equipos con sistemas operativos más antiguos distintos a Windows, que obviamente utilizan versiones más antiguos u obsoletas de Samba.

Lamentablemente la poca disponibilidad de tiempo (que raro) no permitió investigar más profundamente acerca de la causa del problema y su correcta solución, dejando ciertas dudas al respecto pero con la tranquilidad de que todo funciona... por el momento.


Enlaces

Comentarios

Entradas populares