Capítulo 12. Impresoras / 12.7. Particularidades en SUSE LINUX | ||||
|---|---|---|---|---|
 | 12.6. Configuración de las aplicaciones | 12.8. Posibles problemas y soluciones |  | |
Capítulo 12. Impresoras / 12.7. Particularidades en SUSE LINUX | ||||
|---|---|---|---|---|
| 12.6. Configuración de las aplicaciones | 12.8. Posibles problemas y soluciones | | |
CUPS se ha modificado en algunos aspectos para un mejor funcionamiento con SUSE LINUX. A continuación se explican las modificaciones más importantes:
Existen numerosos métodos para configurar CUPS como cliente de un servidor de red.
Se pueden crear colas locales para cada cola del servidor de red y utilizarlas para enviar los trabajos de impresión a la cola respectiva del servidor de red. Este método no es recomendable ya que si se modifica la configuración del servidor de red, será necesario volver a configurar todos los clientes.
También es posible reenviar los trabajos de impresión a un solo servidor de red. Para esta configuración no es necesario que se ejecute el daemon CUPS; lpr (o librerías equivalentes activadas por otros programas) puede enviar trabajos de impresión directamente al servidor de red. No obstante, este tipo de configuración no funciona si se quiere imprimir en una impresora conectada localmente.
Otro método consiste en estar a la escucha de paquetes broadcast IPP. El daemon CUPS puede escuchar este tipo de paquetes enviados por otros servidores de red para anunciar las colas de impresión disponibles. Esta es la configuración de CUPS más adecuada para imprimir a través de un servidor CUPS remoto. No obstante, con esta configuración también se corre el riesgo de que un agresor envíe al daemon paquetes broadcast IPP con sus colas y de que estas colas estén disponibles a través del daemon local. Si el daemon anuncia una de estas colas con el mismo nombre que otra cola del servidor local y el paquete IPP se ha recibido antes, los trabajos de impresión serán enviados al servidor del agresor en lugar de al servidor local sin que el usuario se aperciba de ello. Esta configuración requiere que el puerto UDP 631 esté abierto para paquetes entrantes.
Para detectar un servidor CUPS, YaST puede sondear (“scan”) todos los equipos de una red red para ver si ofrecen este servicio, o bien estar a la escucha de paquetes broadcast IPP (siguiendo el principio descrito en las líneas superiores). Este método también se utiliza durante la instalación para detectar un servidor CUPS para la propuesta de instalación. El segundo método requiere que el puerto UDP 631 esté abierto para paquetes entrantes.
En cuanto al cortafuegos, está preconfigurado (conforme a la propuesta) de
tal forma que no acepta los broadcasts IPP en ninguna
interfaz. Esto significa que tanto el segundo método para detectar un
servidor CUPS como el tercer método para acceder a colas de impresión
remotas no pueden funcionar. Para que funcionen es necesario modificar la
configuración del cortafuegos, bien marcando una interfaz como
interna para que el puerto esté abierto por defecto,
bien abriendo explícitamente el puerto de las interfaces
externas. Ninguna de estas opciones puede estar activada
por defecto por razones de seguridad. La apertura del puerto exclusivamente
a efectos de detección (para configurar el acceso remoto a las colas
conforme al segundo método) constituye también un problema de seguridad:
los usuarios podrían no leer la propuesta y aceptar el servidor de un
agresor externo.
Resumiendo, el usuario debe modificar la propuesta de configuración del cortafuegos para permitir a CUPS detectar colas remotas durante la instalación y posteriormente acceder a las colas remotas de múltiples servidores en la red local. Como alternativa, el usuario puede sondear los ordenadores de la red para detectar un servidor CUPS o bien configurar todas las colas manualmente (lo cual no se recomienda por las razones mencionadas arriba).
Para poder utilizar la administración con el frontal web de CUPS o la
herramienta de administración de impresoras de KDE, es necesario configurar
al usuario root como
administrador de CUPS con el grupo de administración sys y una contraseña para CUPS. Esto se
lleva a cabo ejecutando el siguiente comando como root:
lppasswd -g sys -a root
En caso contrario no es posible llevar a cabo la administración a través de
la web porque la autentificación falla si no se ha configurado ningún
administrador de CUPS. En lugar de root, otro usuario puede figurar como
administrador de CUPS; vea a este respecto la Sección 12.7.3, “Cambios en el sistema de impresión CUPS (cupsd)” .
Los siguientes cambios fueron introducidos a partir de SUSE LINUX 9.1.
Después de iniciarse, cupsd cambia del usuario
root a lp. Esto incrementa la seguridad ya que el
servicio de impresión de CUPS ya no se ejecuta con derechos ilimitados
sino sólo con los derechos necesarios para el servicio de impresión.
La desventaja de este cambio radica en que ya no es posible realizar la
autentificación (para ser más exacto, la comprobación de la contraseña)
mediante /etc/shadow porque lp no tiene acceso a este archivo. En su
lugar debe utilizarse la autentificación específica de CUPS vía
/etc/cups/passwd.md5. Para ello es preciso dar de
alta un administrador de CUPS con el grupo de administración sys y una contraseña de CUPS dentro de
/etc/cups/passwd.md5. Ejecute el siguiente comando
como root:
lppasswd -g sys -a CUPS-admin-name
Cuando cupsd se ejecuta como lp, no es posible crear
/etc/printcap ya que lp no puede crear archivos dentro del
directorio /etc/. Por eso cupsd crea
/etc/cups/printcap. Además se genera un enlace
simbólico /etc/printcap que apunta a
/etc/cups/printcap.
Después de ejecutar cupsd como lp ya no se puede abrir el puerto 631. Esto
hace que resulte imposible volver a cargar cupsd mediante el comando
rccups reload. En lugar de ello se puede utilizar
rccups restart.
Las condiciones de acceso definidas en BrowseAllow
y BrowseDeny se refieren a todos los paquetes
enviados a cupsd. La configuración por defecto en
/etc/cups/cupsd.conf es la siguiente:
BrowseAllow @LOCAL BrowseDeny All
y además
<Location /> Order Deny,Allow Deny From All Allow From 127.0.0.1 Allow From 127.0.0.2 Allow From @LOCAL </Location>
De este modo, sólo los equipos de tipo LOCAL pueden
acceder al cupsd en el servidor CUPS. Los ordenadores
LOCAL son aquellos cuya dirección IP no pertenece a una
interfaz punto a punto (una interfaz que carece de la bandera
IFF_POINTOPOINT) y cuya dirección IP pertenece a la
misma red del servidor CUPS. Los paquetes procedentes de cualquier otro
ordenador se rechazan inmediatamente.
Después de una instalación estándar, cupsd se activa
automáticamente permitiendo así acceder de forma directa a las colas de
impresión de servidores CUPS en la red sin necesidad de ninguna
intervención adicional. Las dos restricciones de seguridad mencionadas
(ver
Sección 12.7.3.1, “cupsd se ejecuta como usuario lp” y Sección 12.7.3.2, “Funcionalidad general de BrowseAllow y BrowseDeny”) son condiciones necesarias para la
activación automática de cupsd sin comprometer la
seguridad.
La configuración de impresora de YaST crea las colas de CUPS sólo a
partir de los archivos PPD almacenados en el sistema en
/usr/share/cups/model/. YaST compara el nombre de
la impresora detectada con los nombres de fabricantes y modelos que se
encuentran en los archivos PPD de
/usr/share/cups/model/. A partir de esta información,
YaST crea una base de datos con los nombres de fabricantes y modelos. De
esta forma es posible seleccionar el modelo de impresora y utilizar el
archivo PPD correcto.
La ventaja de la configuración exclusivamente a base de archivos PPD
radica en la posibilidad de modificar los archivos PPD de
/usr/share/cups/model/. YaST reconoce los cambios y
vuelve a crear la base de datos de modelos y fabricantes. En caso de uso
exclusivo de impresoras PostScript, no se requieren los archivos PPD del
paquete cups-drivers ni los archivos PPD
Gimp-Print del paquete cups-drivers-stp. Puede
copiar los archivos PPD correspondientes a las impresoras PostScript
utilizadas en /usr/share/cups/model/ y configurar las
impresoras de forma óptima. Esto no es necesario si los archivos PPD ya se
encuentran en el paquete manufacturer-PPDs.
Los siguientes archivos PPD Foomatic han sido adaptados para dar soporte
especial a las impresoras PostScript de nivel 1 y 2 y se han añadido a los
archivos PPD genéricos del paquete cups.
/usr/share/cups/model/Postscript-level1.ppd.gz
/usr/share/cups/model/Postscript-level2.ppd.gz
Para dar soporte a las impresoras que no son PostScript se utiliza
normalmente el filtro de impresión foomatic-rip
junto con GhostScript. Los archivos PPD Foomatic adecuados se identifican
con las líneas *NickName: ... Foomatic/Ghostscript
driver y *cupsFilter: ...
foomatic-rip. Estos archivos se encuentran en el paquete
cups-drivers.
YaST da preferencia a un archivo PPD Foomatic cuando existe un archivo
PPD Foomatic recomendado para el modelo de impresora que se reconoce por
*NickName: ... Foomatic ... (recommended) y el
paquete manufacturer-PPDs no contiene ningún
archivo PPD más adecuado (ver abajo).
Muchas impresoras que no son PostScript pueden utilizar el filtro
rastertoprinter de Gimp-Print en lugar de
foomatic-rip. Este filtro y los archivos PPD
correspondientes se encuentran en el paquete
cups-drivers-stp. Los archivos PPD Gimp-Print se
encuentran en /usr/share/cups/model/stp/ y se
identifican con la líneas *NickName: ...
CUPS+Gimp-Print y *cupsFilter: ...
rastertoprinter.
El paquete manufacturer-PPDs contiene archivos
PPD publicados con una licencia de carácter abierto. El archivo PPD del
fabricante permite el uso de todas las características de la impresora
PostScript y es recomendable usarlo. YaST da preferencia a un archivo
PPD del paquete manufacturer-PPDs si se cumplen
las siguientes condiciones:
El fabricante y modelo detectado coincide con el fabricante y modelo de
un archivo PPD del paquete manufacturer-PPDs.
El archivo PPD de manufacturer-PPDs es el único
adecuado para el modelo de impresora o hay otro archivo PPD de tipo
Foomatic con la siguiente entrada: *NickName: ...
Foomatic/Postscript (recommended) también para ese modelo
de impresora.
De manera correspondiente, YaST no utiliza un archivo PPD de
manufacturer-PPDs en los siguientes casos:
El archivo PPD de manufacturer-PPDs no se
corresponde con el nombre de fabricante y modelo. Esto pasa, por
ejemplo, cuando el paquete manufacturer-PPDs
sólo contiene un archivo PPD para modelos parecidos. Por ejemplo, un
nombre como Funprinter 1000 series en el
archivo PPD identifica toda una serie de impresoras en lugar de
almacenar un archivo PPD para cada modelo.
El archivo PPD de PostScript Foomatic no aparece como “recommended”: la impresora no funciona de forma suficientemente fiable en modo PostScript (ej. por falta de memoria o de potencia de procesador) o bien no soporta PostScript de forma nativa (ej. porque el soporte nativo PostScript se realiza con un módulo opcional).
Si manufacturer-PPDs contiene un archivo PPD
adecuado para una impresora PostScript pero YaST no lo puede configurar
por las razones mencionadas, el modelo de impresora debe seleccionarse
manualmente.
