| SUSE LINUX – Manual de Administración Capítulo 5. Funcionamiento de la impresora / 5.8. Impresión en redes TCP/IP | ||||
|---|---|---|---|---|
 | 5.7. Herramientas de línea de comandos para el sistema de impresión CUPS | Capítulo 6. El proceso de arranque y el gestor de arranque |  | |
| SUSE LINUX – Manual de Administración Capítulo 5. Funcionamiento de la impresora / 5.8. Impresión en redes TCP/IP | ||||
|---|---|---|---|---|
| 5.7. Herramientas de línea de comandos para el sistema de impresión CUPS | Capítulo 6. El proceso de arranque y el gestor de arranque | | |
Puede encontrar información más detallada sobre el spooler LPRng en el LPRng-Howto en file:/usr/share/doc/packages/lprng/LPRng-HOWTO.html. Respecto a CUPS, véase CUPS Software Administrators Manual en file:/usr/share/doc/packages/cups/sam.html.
Por servidor de impresión se entiende aquí un ordenador completo con tiempo de CPU y capacidad de memoria suficientes.
Un servidor de impresión dedicado (printserver-box) es un pequeño dispositivo con conexión a la red TCP/IP y posibilidad de conexión local para una impresora. También existen las llamadas router boxes que cuentan con una posibilidad de conexión para una impresora y se manejan igual que las impresoras de red.
Una impresora de red tiene una conexión propia a la red TCP/IP y es en última instancia una impresora que incorpora un servidor de impresión dedicado. Se trabaja de la misma forma con servidores de impresión dedicados que con impresoras de red.
Existe una diferencia importante entre una impresora de red o un servidor de impresión dedicado por un lado y un verdadero servidor de impresión por el otro. Asimismo hay impresoras grandes con las que se suministra un ordenador que hace las funciones de servidor de impresión para imprimir en la red. Pero en este caso, los trabajos de impresión no se envían a la impresora, sino al servidor de impresión incluido.
Un servidor LPD es un servidor de impresión al que puede accederse por medio del protocolo LPD. Este es el caso cuando en el servidor de impresión se ejecuta el sistema de impresión LPRng/lpdfilter (o más exactamente lpd) o cuando se ejecuta el sistema de impresión CUPS configurado de tal modo que sea posible acceder al ordenador a través del protocolo LDP (o más exactamente, a través de cups-lpd).
Un servidor IPP o servidor CUPS es un servidor de impresión al que puede accederse por medio del protocolo IPP. Este es el caso cuando en el servidor de impresión funciona el sistema de impresión CUPS (o más exactamente cupsd).
Denominamos servidor de red CUPS a un servidor CUPS configurado de tal forma que comunique vía broadcast UDP (a través del puerto UDP 631) sus colas de impresión a otros ordenadores en la red.
Generalmente, un cliente en la red no dispone de una impresora conectada localmente, sino que los trabajos de impresión son enviados por el cliente a un servidor de impresión. En caso de tener un servidor de impresión además de una impresora conectada localmente al cliente, deberá configurar no sólo el cliente sino también la impresora conectada localmente. En el cliente se ha de seleccionar un sistema de impresión adecuado al que existe en el servidor de impresión.
Si en la red no existe ningún servidor de red CUPS sino tan sólo un servidor LPD, debe utilizar el sistema de impresión LPRng/lpdfilter en el cliente. No es necesario configurar el cliente de manera adicional, ya que con el spooler LPRng se puede acceder directamente a colas de impresión remotas con el comando lpr.
El único requisito es que el servidor LPD esté configurado de forma que el cliente pueda imprimir en su cola de impresión. Para imprimir desde aplicaciones, introduzca como comando de impresión lpr -P<cola-impresión>@<servidor-impresión>, es decir, pero sin especificar ningún archivo.
Algunos programas están ya preconfigurados para CUPS y su configuración ha de modificarse para LPRng. Especialmente en el caso de KDE y su programa de impresión kprinter ha de seleccionarse la opción . En caso contrario no será posible introducir el comando de impresión mencionado arriba.
Si el servidor de impresión es un servidor de red CUPS, puede elegir entre las siguientes posibilidades al seleccionar y en la configuración de impresora de YaST:
Si no existe ninguna impresora conectada localmente, no se ha configurado ninguna cola local con YaST. En este caso, cupsd no se inicia automáticamente. Para iniciar cupsd tiene que activar el servicio (normalmente para los niveles de ejecución 3 y 5).
No es necesario configurar el cliente de manera adicional, ya que un servidor de red CUPS comunica periódicamente sus colas a todos los ordenadores de la red por medio de un broadcast. De esta forma, las colas del servidor de red CUPS estarán disponibles automáticamente en el cliente en muy poco tiempo.
Como único requisito, el servidor de red CUPS ha de estar configurado de tal forma que la función de broadcast esté activada, que se utilice una dirección broadcast adecuada para el cliente y que el cliente esté autorizado a imprimir en las colas del servidor de red CUPS.
Para imprimir en las colas de impresión del servidor de red CUPS, es suficiente con que CUPS funcione sólo como cliente. Para ello basta con introducir el nombre del servidor de red CUPS en la configuración de impresión Client-only de YaST.
En este caso, en el cliente no funciona ningún cupsd y no existe por tanto el archivo /etc/printcap. Sin embargo, los programas que no son compatibles con CUPS ofrecen sólo las colas incluidas en el archivo /etc/printcap local. En este caso se recomienda que, cuando CUPS funcione como servidor, el cupsd local cree automáticamente un archivo /etc/printcap con el nombre de las colas del servidor de red CUPS.
Existen distintas posibilidades de impresión en una red TCP/IP, las cuales no dependen tanto del hardware como del protocolo utilizado. Por eso en la configuración con YaST se distingue en función del protocolo y no del hardware.
No obstante, en la configuración de impresora en YaST primero hay que seleccionar con qué tipo de "hardware" se va a imprimir (por ejemplo a través de un servidor de red CUPS, un servidor de red LPD o directamente en una impresora de red o servidor de impresión dedicado). Según la opción escogida se ofrecen los protocolos posibles; si bien el protocolo que debería funcionar en la mayoría de los casos está preseleccionado. Si sólo un protocolo es posible, no se ofrece ninguna selección. A continuación algunos ejemplos:
Imprimir a través de un servidor de red CUPS
Protocolo IPP (única posibilidad)
Imprimir a través de un servidor de red LPD
Protocolo LPD (única posibilidad)
Imprimir directamente desde una impresora de red o printserver-box:
Socket TCP
Protocolo LPD
Protocolo IPP
Para poder transmitir datos del remitente al destinatario según un protocolo determinado, es necesario que ambos soporten dicho protocolo. El software que funciona en el remitente y el destinatario también debe soportar ese protocolo.
Por consiguiente, el hardware y el software empleados no son relevantes: lo importante es que tanto el remitente como el destinatario soporten el protocolo correspondiente. Dependiendo del protocolo utilizado, se transmiten trabajos de impresión o sólo datos en crudo.
Además de los datos que se van a imprimir, un trabajo de impresión contiene también datos adicionales — qué usuario ha creado el trabajo de impresión y en qué máquina o, en caso necesario, opciones específicas de impresión (por ejemplo tamaño del papel, impresión en modo dúplex, etc.).
En este caso, el remitente envía la tarea de impresión a través del protocolo LPD a una cola de impresión en el destinatario. Según el protocolo LPD, el destinatario recibe los trabajos de impresión en el puerto 515. Por lo tanto, en el ordenador destinatario siempre se requiere un servicio que acepte los trabajos de impresión en el puerto 515 (este servicio se llama normalmente lpd). Asimismo, también se requiere una cola de impresión a la que mandar los trabajos aceptados.
LPRng soporta el protocolo LPD mediante lpd. Para ello se necesita una cola de impresión local mediante la cual el lpd del remitente reenvíe el trabajo de impresión al lpd del destinatario.
Con LPRng la transmisión se puede hacer también sin lpd local. El programa lpr del paquete lprng puede reenviar la tarea de impresión directamente al lpd del destinatario utilizando el protocolo LPD.
CUPS soporta el protocolo LPD sólo a través del daemon cupsd. Para ello se necesita una cola de impresión local mediante la cual el cupsd local reenvíe la tarea de impresión al lpd del destinatario.
La transmisión de datos a través del protocolo LPD no está soportadas en los clientes CUPS.
El protocolo LPD es muy antiguo, por lo que cualquier sistema operativo debería soportarlo al menos como remitente. Es posible que no se soporte por defecto. En este caso habría que instalar manualmente el software necesario.
LPRng soporta la recepción de datos a través del protocolo LPD mediante lpd.
CUPS soporta la recepción de datos a través del protocolo LPD mediante cups-lpd. Puede activar cups-lpd por medio de inetd o xinetd.
Los clientes CUPS no soportan la recepción de datos a través del protocolo LPD.
El protocolo LPD es muy antiguo, por lo que cualquier servidor de impresión, servidor de impresión dedicado o impresora de red de uso extendido debería soportar este protocolo.
En los servidores de impresión dedicados e impresoras de red el nombre de las colas de impresión varía en función del modelo o existen varias colas de impresión que funcionan de forma distinta.
Aquí el remitente envía la tarea de impresión a través del protocolo IPP a una cola de impresión en el destinatario. Según el protocolo IPP, el remitente acepta los trabajos de impresión en el puerto 631. Por lo tanto, en el ordenador destinatario se requiere un servicio que acepte los trabajos de impresión en el puerto 631 (este servicio se llama en CUPS cupsd) y una cola de impresión en la que se guarden los trabajos aceptados.
LPRng no soporta el protocolo IPP.
CUPS también soporta el envío de datos a través del protocolo IPP sin cupsd local. Los programas lpr o lp del paquete cups-client o el programa xpp o el programa KDE kprinter pueden reenviar el trabajo de impresión a través del protocolo IPP directamente al destinatario.
El protocolo IPP es relativamente nuevo, por lo que el soporte depende de cada caso concreto.
LPRng no soporta el protocolo IPP.
CUPS soporta la recepción a través del protocolo IPP mediante cupsd. En el ordenador destinatario se requiere una cola de impresión en la que cups-lpd guarde el trabajo de impresión que ha recibido del remitente.
Los clientes CUPS no soportan la recepción a través del protocolo IPP.
El protocolo IPP es relativamente nuevo, por lo que el soporte depende de cada caso concreto.
Aquí no se envía ninguna tarea de impresión a una cola de impresión remota, ya que no existe ningún protocolo (LPD o IPP) que pueda trabajar tanto con trabajos como con colas de impresión. En vez de esto se envían directamente datos en crudo a un puerto TCP remoto utilizando el socket TCP. Normalmente se utiliza para enviar datos específicos de una impresora a impresoras de red y servidores de impresión dedicados. En muchos casos se emplea el puerto TCP 9100.
LPRng soporta el envío directo a través del socket TCP mediante lpd. Se requiere una cola en el ordenador remitente de la que el lpd del remitente tome el trabajo de impresión y envíe los datos que se van a imprimir al puerto TCP del destinatario.
LPRng también lo soporta sin lpd local. El programa lpr del paquete lprng puede enviar directamente los datos al puerto TCP del destinatario a través del socket TCP con la opción -Y. Véase al respecto la página del manual correspondiente a lpr.
CUPS soporta el envío directo de datos a través del socket TCP por medio de cupsd. Se requiere una cola en el ordenador remitente desde la que cupsd tome el trabajo de impresión y envíe los datos que se van a imprimir al puerto TCP del destinatario.
Los clientes CUPS no soportan el envío directo a través del socket TCP.
No obstante, los siguientes comandos permiten enviar datos al puerto de un ordenador.
cat archivo | netcat -w 1 host puerto
Para la recepción directa a través del socket TCP no se requiere ningún sistema de impresión y ningún sistema de impresión lo soporta directamente, ya que normalmente no tiene sentido enviar datos en crudo cuando existe un sistema de impresión que soporta trabajos de impresión con sus protocolos correspondientes (LPD o IPP).
No obstante, por ejemplo en el sistema de impresión CUPS es posible aceptar datos en el puerto 9100 y reenviarlos a una cola de impresión. Para ello debe introducirse en /etc/inetd.conf alguna de las líneas siguientes:
9100 stream tcp nowait lp /usr/bin/lp \ lp -d <cola-impresión>
Si no se va a realizar ningún proceso de filtrado, añada -o raw.
También es posible emular un servidor de impresión dedicado que recibe datos en el puerto 9100 y los envía directamente a la impresora. Para ello debe introducirse en /etc/inetd.conf una línea del tipo:
9100 stream tcp nowait lp /bin/dd dd of=/dev/lp0
El soporte depende de cada caso concreto.
Especialmente el puerto correcto varía en función del modelo. Con impresoras de red HP o servidores de impresión dedicados HP JetDirect, este suele ser el puerto 9100, o con servidores de impresión dedicados JetDirect con dos o tres conexiones para impresoras suele ser los puertos 9100, 9101 y 9102. Estos puertos también son utilizados por muchos otros servidores de impresión dedicados. Consulte el manual de servidores de impresión dedicados y, en caso de duda, pregunte al fabricante del servidor o de la impresora de red qué puerto utiliza la impresora para comunicarse. Puede encontrar más información en LPRng-Howto en /usr/share/doc/packages/lprng/LPRng-HOWTO.html y allí más concretamente en:
/usr/share/doc/packages/lprng/LPRng-HOWTO.html#SECNETWORK
/usr/share/doc/packages/lprng/LPRng-HOWTO.html#SOCKETAPI
/usr/share/doc/packages/lprng/LPRng-HOWTO.html#AEN4858
Varias estaciones de trabajo, un servidor de impresión y uno o varios servidores de impresión dedicados o impresoras de red:
Las estaciones de trabajo han de utilizar también el sistema de impresión LPRng.
En el servidor de impresión existe una cola para cada impresora conectada al servidor de impresión dedicado o para cada impresora de red.
Las estaciones de trabajo transmiten los trabajos de impresión a través del protocolo LPD a la cola de la impresora en el servidor de impresión.
Dependiendo del protocolo soportado por el servidor de impresión dedicado o la impresora de red, el servidor de impresión utiliza el protocolo LPD o la transmisión directa de datos a través del socket TCP para enviar los datos al servidor de impresión dedicado/impresora de red.
Las estaciones de trabajo han de utilizar también el sistema de impresión CUPS. El sistema CUPS como cliente es más que suficiente en este caso.
En el servidor de impresión existe una cola para cada impresora conectada al servidor de impresión dedicado o para cada impresora de red.
Las estaciones de trabajo transmiten los trabajos de impresión a través del protocolo IPP a la cola de la impresora en el servidor de impresión.
Dependiendo del protocolo soportado por el servidor de impresión dedicado o la impresora de red, el servidor de impresión utiliza el protocolo LPD o la transmisión directa de datos a través del socket TCP para enviar los datos al servidor de impresión dedicado/impresora de red.
Unas pocas estaciones de trabajo, ningún servidor de impresión y una o varias impresoras de red o servidores de impresión dedicados.
En cada estación de trabajo existe una cola para cada impresora conectada al servidor de impresión dedicado o para cada impresora de red. Debido a que es necesario configurar todas las colas en cada estación de trabajo, este escenario sólo se recomienda en caso de tener pocas estaciones de trabajo.
Dependiendo del protocolo soportado por el servidor de impresión dedicado o impresora de red, las estaciones de trabajo utilizan el protocolo LPD o la transmisión directa de datos a través del socket TCP para enviar los datos al servidor de impresión dedicado o a la impresora de red.
En caso de que varias estaciones de trabajo envíen simultáneamente datos a la misma impresora de red o servidor de impresión dedicado, pueden producirse problemas incluyendo la pérdida de datos, sobre todo si se ha empleado el protocolo LDP para transmitir los datos. El motivo es que la implementación del destinatario LPD en la impresora de red o servidor de impresión dedicado suele ser deficiente por falta de memoria suficiente para aceptar y guardar temporalmente varios trabajos de impresión. En cambio, la transmisión de datos a través del socket TCP suele resultar muy fiable.
En el apartado anterior se ha explicado cómo se transmiten trabajos de impresión o datos en crudo de la estación de trabajo a la impresora. Ahora veremos cómo se realiza el proceso de filtrado (la transformación de los datos originales en datos específicos de la impresora) al imprimir en red. El filtrado en la red se produce de la misma forma que en una impresora conectada a un ordenador autónomo y los filtros de impresión son también los mismos. La única diferencia radica en que el flujo de datos de la estación de trabajo a la impresora sigue un camino más complicado y pasa por varias estaciones; por ejemplo:
Estación de trabajo -> servidor de impresión -> printserver-box -> impresora
Es en esta posición donde el archivo de salida se convierte al formato que puede imprimir la impresora (PostScript, PCL, ESC/P).
La conversión se realiza por medio de filtros de impresión que sólo funcionan en un ordenador que tenga la cantidad de memoria y el rendimiento necesarios. Es decir, en una estación de trabajo o un servidor de impresión pero no en una impresora de red ni en el servidor de impresión dedicado. Estos últimos no suelen incluir ningún filtro de impresión, sólo pueden aceptar datos específicos de impresora y enviarlos a la impresora.
Una cola de impresión puede crearse con o sin filtrado. En la configuración de impresora en YaST hay que seleccionar primero el hardware (por ejemplo a través del servidor de red CUPS, servidor de red LPD o impresión directa a una impresora de red o servidor de impresión dedicado) sobre el que se va a imprimir. Por este motivo, la configuración predeterminada referente a la existencia de filtrado suele ser la más adecuada para el proceso de impresión. Si es necesario, las opciones de configuración estándar pueden modificarse.
Las opciones de configuración predeterminadas son:
Sin filtrado (ya que el filtrado se produce normalmente en el servidor de red CUPS).
Sin filtrado (ya que el filtrado se produce normalmente en el servidor de red LDP).
Con filtrado
Al crear la cola con filtrado, los datos originales se guardan temporalmente en la cola. Cuando estos datos se envían al destinatario, pasan por el filtro que se encuentra en el ordenador que contiene la cola. El filtrado se lleva a cabo antes de enviar los datos para que el destinatario los reciba ya reformateados (figura 5.2, “Resumen del proceso de filtrado”).
A continuación se muestran las posibilidades de filtrado en los ejemplos superiores:
Varias estaciones de trabajo, un servidor de impresión y uno o varios servidores de impresión dedicados o impresoras de red:
La configuración más sencilla y útil es la que se ilustra en la figura 5.3, “Configuración 1”.
Para cada cola con filtrado en el servidor de impresión puede configurarse una cola sin filtrado en cada estación de trabajo para que, en caso de fallo o sobrecarga en el servidor de impresión, los datos puedan almacenarse temporalmente en las estaciones de trabajo y se pueda imprimir hasta que el servidor vuelva a estar disponible. La desventaja es que hay que configurar todas las colas de impresión en cada una de las estaciones de trabajo (sin filtro) y en caso de cambiar las colas en el servidor, la configuración ha de cambiarse también en las estaciones de trabajo.
La figura 5.4, “Configuración 2” muestra esta configuración algo más compleja:
En teoría, el filtrado podría producirse en las estaciones de trabajo y el servidor de impresión se limitaría a transmitir los datos específicos de impresora a la impresora de red o servidor de impresión dedicado. Esto sólo tiene sentido si el servidor de impresión tiene tan poca potencia que el proceso de filtrado ocasiona una sobrecarga. Los inconvenientes son que habría que configurar (con filtro) las colas en todas las estaciones de trabajo y en caso de cambiar la configuración de las colas, esta habría de cambiarse también en todas las estaciones de trabajo.
Esta configuración es la que se muestra en la figura 5.5, “Configuración 3”.
Unas pocas estaciones de trabajo, ningún servidor de impresión y una o varias impresoras de red o servidores de impresión dedicados.
La única configuración posible sería tener en cada estación de trabajo una cola con filtro para cada impresora. El inconveniente es que habría que configurar las colas en todas las estaciones de trabajo (con filtro) y en caso de cambiar la configuración, habría que adaptar también la configuración en todas las estaciones de trabajo.
La configuración se refleja en la figura 5.6, “Configuración 4”.
Esta configuración es casi idéntica a la de un sistema autónomo con una impresora conectada localmente.
En la figura 5.7, “Configuración 5” se muestra la configuración de un sistema autónomo con fines comparativos:
Al observar retrospectivamente cada uno de los ejemplos de configuración empezando por el final, se ve la evolución de un sistema autónomo con una impresora local a una configuración más compleja para múltiples estaciones de trabajo con un servidor de impresión para varias impresoras de red/servidores de impresión dedicados.
La red TCP/IP, resolución de nombres incluida, debe funcionar adecuadamente.
Conecte la impresora directamente al primer puerto paralelo del ordenador, configurándola como impresora local para evitar posibles problemas con la red (sólo durante la prueba). Una vez que la impresora funciona localmente, ya conoce el controlador de Ghostscript y los demás parámetros para la configuración del filtro.
El siguiente comando le permite comprobar si es posible una conexión TCP a lpd (puerto 515) en el ordenador host:
netcat -z host 515 && echo ok || echo failed
Si no lo es, o bien no funciona el lpd, o existen problemas importantes en la red.
Como usuario root se puede solicitar un informe (que puede llegar a ser muy largo) sobre el estado de la cola de impresión queue en un ordenador (remoto) host, siempre que el lpd remoto esté funcionando y sea accesible:
echo -e "\004queue" \
| netcat -w 2 -p 722 host 515
Si no se recibe respuesta del lpd puede que no funcione el lpd o que haya problemas importantes en la red. Si hay respuesta del lpd esta debería aclarar por qué no se puede imprimir a la cola de impresión queue del ordenador host– Ejemplos:
Ejemplo 5.1. Mensaje de error de lpd
lpd: your host does not have line printer access lpd: queue does not exist printer: spooling disabled printer: printing disabled
Si se recibe tal respuesta del lpd, se trata de un problema del lpd remoto.
Con el siguiente comando se puede comprobar si en la red existe un servidor de red CUPS, ya que este debería anunciar su cola de impresión por broadcast a través del puerto UDP 631 cada 30 segundos.
netcat -u -l -p 631 & PID=$! ; sleep 40 ; kill $PID
Después de 40 segundos de espera se produce una salida semejante a esta cuando el servidor de red CUPS realiza el broadcast:
El siguiente comando permite comprobar si es posible establecer una conexión TCP al cupsd (puerto 631) del ordenador host:
netcat -z host 631 && echo ok || echo failed
Si no lo es, o no funciona el cupsd o bien existen problemas importantes en la red.
lpstat -h host -l -t
Con este comando se puede solicitar un informe (que a veces puede llegar a ser muy largo) del estado de todas las colas de impresión del ordenador host, siempre que haya un cupsd en funcionamiento y que sea posible conectarse con él.
echo -en "\r" \
| lp -d queue -h host
Con este comando se puede comprobar si la cola de impresión queue del ordenador host acepta un trabajo de impresión compuesto por un único signo de retorno de carro. Es decir, es sólo una prueba y no debería imprimirse nada. En caso de imprimirse, el resultado será sólo una hoja en blanco.
El funcionamiento básico puede comprobarse con el siguiente comando:
echo -en "\r" \
| smbclient '/HOST/SHARE' 'PASSWORD' \
-c 'print -' -N -U 'USER' \
&& echo ok || echo failed
Introduzca en HOST el nombre del ordenador del servidor Samba, en SHARE el nombre de la cola de impresión remota ( el nombre del directorio compartido Samba); en PASSWORD la contraseña y en USER el nombre de usuario. Aquí se trata sólo de una prueba y no debería imprimirse nada; pero en caso de imprimirse, el resultado será únicamente una hoja en blanco.
Con el siguiente comando se muestran los shares o directorios compartidos disponibles en el ordenador host — véase la página del manual man smbclient:
smbclient -N -L host
A veces hay problemas con el spooler de impresión que se ejecuta en el servidor de impresión dedicado cuando se incrementa el volumen de impresión. Puesto que es un problema del spooler en el servidor de impresión dedicado o en la impresora de red, no se puede hacer nada. Sin embargo, existe la posibilidad de evitar el spooler del servidor de impresión dedicado comunicándose directamente a través del socket TCP con la impresora conectada al servidor de impresión dedicado.
De esta forma, el servidor de impresión dedicado sólo funciona como conversor entre las distintas formas de transmisión de datos (red TCP/IP y conexión local a la impresora). Así la impresora conectada al servidor de impresión dedicado se comporta como una impresora local. Asimismo el control sobre la impresora es más directo que el que se tendría si el spooler estuviera funcionando. Para esto debe conocerse el puerto TCP correspondiente del servidor de impresión dedicado. Con la impresora encendida y conectada al servidor de impresión dedicado, este puerto TCP se puede averiguar normalmente con el programa nmap del paquete nmap poco después de haber arrancado el servidor de impresión dedicado.
Este es el ejemplo de la salida de nmap<dirección-IP> con un servidor de impresión dedicado:
Port State Service
23/tcp open telnet
80/tcp open http
515/tcp open printer
631/tcp open cups
9100/tcp open jetdirect
La salida significa:
Es posible registrarse en el servidor de impresión dedicado vía telnet. Allí puede solicitar información general y realizar configuraciones básicas.
Vía HTTP es posible comunicarse con un servidor web que esté en funcionamiento en el servidor de impresión dedicado. Este normalmente proporciona información detallada y permite realizar configuraciones avanzadas.
Es posible comunicarse con el spooler de impresión que está en funcionamiento en el servidor de impresión dedicado a través del puerto 515 mediante el protocolo LPD.
Es posible comunicarse con el spooler de impresión que está en funcionamiento en el servidor de impresión dedicado a través del puerto 631 y utilizando el protocolo IPP.
Es posible comunicarse con la impresora conectada al servidor de impresión dedicado a través del puerto 9100 y utilizando un socket TCP.
Por defecto, nmap sólo comprueba una lista de puertos conocidos que está recogida en el archivo /usr/share/nmap/nmap-services. Para comprobar todos los puertos posibles ha de utilizar el comando nmap -p <puerto-origen>-<puerto-destino> <dirección-IP> (este proceso puede ser muy largo). Para obtener más información al respecto consulte la página del manual man nmap.
Un comando semejante a
echo -en "\rHello\r\f" | netcat -w 1 <dirección-IP> puerto cat file | netcat -w 1 <dirección-I>P puerto
permite enviar secuencias de caracteres o archivos directamente al puerto en cuestión para comprobar si es posible acceder a la impresora a través de este puerto.
Aunque por lo general un servidor CUPS sólo soporta el protocolo IPP, el programa /usr/lib/cups/daemon/cups-lpd del paquete cups permite que un servidor CUPS pueda aceptar trabajos de impresión que le han sido enviados al puerto 515 mediante el protocolo LPD. Para ello se debe activar el servicio correspondiente para xinetd — normalmente con YaST o manualmente activando la línea correspondiente en el archivo /etc/xinetd.d/cups-lpd.
Puede ocurrir que desee ejecutar ambos sistemas de impresión LPRng/lpdfilter y CUPS en el mismo ordenador, ya sea por ampliar un servidor de impresión LPD con CUPS, o porque en algunos casos sea necesario el sistema LPRng/lpdfilter.
En principio se presentan dificultades cuando los dos sistemas de impresión se ejecutan en el mismo ordenador. Aquí se expondrá brevemente los problemas y limitaciones que pueden ocurrir. No obstante, este tema es demasiado complejo y no es posible ofrecer una solución en estas páginas.
La configuración de la impresora no se debe realizar con YaST ya que la configuración de YaST no ha sido diseñada para estos casos.
Existe un conflicto entre los paquetes lprng y cups-client debido a que contienen archivos con el mismo nombre por ejemplo /usr/bin/lpr y /usr/bin/lp. Por eso el paquete cups-client no debe estar instalado. La consecuencia es que no hay herramientas CUPS de línea de comandos disponibles, sino sólo para LPRng. Sin embargo, es posible imprimir desde una interfaz gráfica con xpp o kprinter en colas de impresión CUPS, así como desde todas las aplicaciones que soportan CUPS directamente.
Por lo general, al arrancar, cupsd vuelve a crear el archivo /etc/printcap que sólo contiene los nombres de todas las colas de impresión CUPS. Esto ocurre por razones de compatibilidad, ya que muchas aplicaciones leen las colas de impresión de /etc/printcap para poder ofrecerlas en el menú de impresión. Este servicio debe ser desactivado para cupsd de tal forma que /etc/printcap sólo esté disponible para LPRng/lpdfilter. La consecuencia es que las aplicaciones que sólo utilizan los nombres de colas de impresión que se encuentran en /etc/printcap sólo mostrarán las colas locales, pero no las colas CUPS disponibles en la red.
