Contents
SUSE Linux Enterprise® supports printing with many types of printers, including remote network printers. Printers can be configured with YaST or manually. Both graphical and command line utilities are available for starting and managing print jobs. If your printer does not work as expected, refer to Section 23.9, “Troubleshooting”.
CUPS is the standard print system in SUSE Linux Enterprise. CUPS is highly user-oriented. In many cases, it is compatible with LPRng or can be adapted with relatively little effort. LPRng is included in SUSE Linux Enterprise only for reasons of compatibility.
Printers can be distinguished by interface, such as USB or network, and printer language. When buying a printer, make sure that the printer has an interface (like USB or parallel port) that is available on your hardware and a suitable printer language. Printers can be categorized on the basis of the following three classes of printer languages:
PostScript is the printer language in which most print jobs in Linux and Unix are generated and processed by the internal print system. This language is already quite old and very efficient. If PostScript documents can be processed directly by the printer and do not need to be converted in additional stages in the print system, the number of potential error sources is reduced. Because PostScript printers are subject to substantial license costs, these printers usually cost more than printers without a PostScript interpreter.
Although these printer languages are quite old, they are still undergoing expansion to address new features in printers. In the case of known printer languages, the print system can convert PostScript jobs to the respective printer language with the help of Ghostscript. This processing stage is referred to as interpreting. The best-known languages are PCL, which is mostly used by HP printers and their clones, and ESC/P, which is used by Epson printers. These printer languages are usually supported by Linux and produce a decent print result. Linux may not be able to address some functions of extremely new and fancy printers, because the open source developers may still be working on these features. Except for HP developing hpijs drivers, there are currently no printer manufacturers who develop Linux drivers and make them available to Linux distributors under an open source license. Most of these printers are in the medium price range.
These printers do not support any of the common printer languages. They use their own undocumented printer languages, which are subject to change when a new edition of a model is released. Usually only Windows drivers are available for these printers. See Section 23.9.1, “Printers without Standard Printer Language Support” for more information.
Before you buy a new printer, refer to the following sources to check how well the printer you intend to buy is supported:
The LinuxPrinting.org printer database.
The Ghostscript Web page.
/usr/share/doc/packages/ghostscript/catalog.devicesList of included drivers.
The online databases always show the latest Linux support status. However, a Linux distribution can only integrate the drivers available at production time. Accordingly, a printer currently rated as “perfectly supported” may not have had this status when the latest SUSE Linux Enterprise version was released. Thus, the databases may not necessarily indicate the correct status, but only provide an approximation.
The user creates a print job. The print job consists of the data to print plus information for the spooler, such as the name of the printer or the name of the printer queue, and, optionally, information for the filter, such as printer-specific options.
At least one dedicated printer queue exists for every printer. The spooler holds the print job in the queue until the desired printer is ready to receive data. When the printer is ready, the spooler sends the data through the filter and back-end to the printer.
The filter converts the data generated by the application that is printing (usually PostScript or PDF, but also ASCII, JPEG, etc.) into printer-specific data (PostScript, PCL, ESC/P, etc.). The features of the printer are described in the PPD files. A PPD file contains printer-specific options with the parameters needed to enable them on the printer. The filter system makes sure that options selected by the user are enabled.
If you use a PostScript printer, the filter system converts the data into printer-specific PostScript. This does not require a printer driver. If you use a non-PostScript printer, the filter system converts the data into printer-specific data using Ghostscript. This requires a Ghostscript printer driver suitable for your printer. The back-end receives the printer-specific data from the filter then passes it to the printer.
There are various possibilities for connecting a printer to the system. The configuration of the CUPS print system does not distinguish between a local printer and a printer connected to the system over the network. In Linux, local printers must be connected as described in the manual of the printer manufacturer. CUPS supports serial, USB, parallel, and SCSI connections. For more information about the printer connection, read the article CUPS in a Nutshell in the Support Database at http://en.opensuse.org/SDB:CUPS_in_a_Nutshell.
►zseries: Printers and similar devices provided by the z/VM that you can connect locally with the IBM System z mainframes are not supported by CUPS or LPRng. On these platforms, printing is only possible over the network. The cabling for network printers must be installed according to the instructions of the printer manufacturer. ◄
![]() | Changing Cable Connections in a Running System |
|---|---|
When connecting the printer to the machine, do not forget that only USB devices can be plugged in or unplugged during operation. To avoid damaging your system or printer, shut down the system before changing any connections that are not USB. | |
PPD (PostScript printer description) is the computer language that describes the properties, like resolution, and options, such as the availability of a duplex unit. These descriptions are required for using various printer options in CUPS. Without a PPD file, the print data would be forwarded to the printer in a “raw” state, which is usually not desired. During the installation of SUSE Linux Enterprise, many PPD files are preinstalled to enable even printers without PostScript support to be used.
To configure a PostScript printer, the best approach is to get a suitable
PPD file. Many PPD files are available in the package
manufacturer-PPDs, which is automatically installed
within the scope of the standard installation. See Section 23.8.3, “PPD Files in Various Packages” and Section 23.9.2, “No Suitable PPD File Available for a PostScript Printer”.
New PPD files can be stored in the directory
/usr/share/cups/model/ or added to the print system
with YaST (as described in Section 23.4.1.2, “Adding PPD Files with YaST”). Subsequently, the PPD file can
be selected during the installation.
Be careful if a printer manufacturer wants you to install entire software packages in addition to modifying configuration files. First, this kind of installation would result in the loss of the support provided by SUSE Linux Enterprise and, second, print commands may work differently and the system may no longer be able to address devices of other manufacturers. For this reason, the installation of manufacturer software is not recommended.
YaST can be used to configure a local printer that is directly connected to your machine (normally with USB or parallel port) or to set up printing over the network. It is also possible to add PPD (PostScript Printer Description) files for your printer with YaST.
If an unconfigured local printer is detected, YaST starts automatically to configure it. YaST can configure the printer automatically if the parallel or USB port can be set up automatically and the connected printer can be detected. The printer model must also be listed in the database used during the automatic hardware detection.
If the printer model is unknown or cannot be automatically detected, configure it manually. There are two possible reasons why a printer is not automatically detected:
The printer does not identify itself correctly. This may apply to very old devices. Try to configure your printer as described in Section 23.4.1.1, “Configuring Manually”.
If the manual configuration does not work, communication between printer and computer is not possible. Check the cable and the plugs to make sure that the printer is properly connected. If this is the case, the problem may not be printer-related, but rather a USB or parallel port–related problem.
To manually configure the printer, select + in the YaST control center. This opens the main window, where the detected devices are listed in the upper part. The lower part lists any queues configured so far (refer to Section 23.1, “The Workflow of the Printing System” for more information about print queues). If no printer was detected, both parts of the configuration window are empty. Use to change the configuration of a listed printer or to set up a printer not automatically detected. Editing an existing configuration uses the same dialogs as in Procedure 23.1, “Adding a Local Printer Manually”.
In , you can also an existing entry. Clicking opens a list with advanced options. Select , to manually start the automatic printer detection. If more than one printer is connected to the machine or more than one queue is configured for a printer, you can mark the active entry as the default. and are advanced configuration options— refer to Chapter 23, Printer Operation for details.
Procedure 23.1. Adding a Local Printer Manually¶
![]() | YaST Print Test |
|---|---|
To make sure that everything works correctly, the crucial configuration steps can be checked with the print test function of YaST. The test page also provides important information about the configuration tested. If the output is garbled, for example, with several pages almost empty, you can stop the printer by first removing all paper then stopping the test from YaST. | |
Start YaST and choose + to open the dialog.
Click to open the window.
Choose .
Select the port to which the printer is connected (usually USB or parallel port) and choose the device in the next configuration screen. It is recommended to at this point. If problems occur, select the correct device or choose to return to the previous dialog.
In , set up a print queue. Specifying a is mandatory. It is recommended to choose a recognizable name—with this name, you can later identify the printer in the printing dialogs of applications. Use and to further describe the printer. This is optional, but useful if you have more than one printer connected to the machine or if you set up a print server. should be checked—it is needed for local printers.
In , specify the printer by and . If your printer is not listed, you can try from the manufacturer list and select an appropriate standard language (the set of commands controlling the printer) from the model list (refer to your printer's documentation to find out which language your printer understands). If this does not work, refer to Section 23.4.1.2, “Adding PPD Files with YaST” for another possible solution.
The screen lists a summary of the printer setup. This dialog is also shown when editing an existing printer configuration from the start screen of this YaST module.
The summary contains the following entries, which you can also modify with :
, , and let you change entries made while following this procedure.
Refer to Section 23.4.1.3, “Choosing an Alternative PPD File with YaST” for details on .
With fine-tune the printer setup. Configure options like , , and here.
By default, every user is able to use the printer. With , list users that are forbidden to use the printer or list users that are allowed to use it.
With you can, for example, deactivate the printer by changing its state and specify whether a page with a or is printed before or after each job (the default is not to print them).
If your printer does not show up in the dialog, a PPD (PostScript Printer Description) file for your model is missing (see Section 23.3, “Installing the Software” for more information about PPD files). With , add a PPD file from the local file system or an FTP or HTTP server.
Get PPD files directly from your printer vendor or from the driver CD of the printer (see Section 23.9.2, “No Suitable PPD File Available for a PostScript Printer” for details). An alternative source for PPD files is http://www.linuxprinting.org/, the “Linux Printing Database”. When downloading PPD files from linuxprinting.org, keep in mind that it always shows the latest Linux support status, which is not necessarily met by SUSE Linux Enterprise.
For many printer models, several PPD files are available. When
configuring the printer, YaST defaults to the one marked
recommended as a general rule. To get a list of PPD
files available for a printer, select
in then click
. See Figure 23.1, “Printer Configuration Summary”.
Normally it should not be necessary to change the PPD file—the PPD file chosen by YaST should produce the best results. However, if you want a color printer to print only in black and white, for example, it is most convenient to use a PPD file that does not support color printing. If you experience performance problems with a PostScript printer when printing graphics, it may help to switch from a PostScript PPD file to a PCL PPD file (provided your printer understands PCL).
Network printers are not detected automatically. They must be configured manually using the YaST printer module. Depending on your network setup, you can print to a print server (CUPS, LPD, SMB, or IPX) or directly to a network printer (preferably via TCP). Ask your network administrator for details on configuring a network printer in your environment.
Procedure 23.2. Configuring a Network Printer with YaST¶
Start YaST and choose + to open the dialog.
Click to open the window.
Choose to open a dialog in which to specify further details that should be provided by your network administrator.
A network printer can support various protocols, some of them even concurrently. Although most of the supported protocols are standardized, some manufacturers expand (modify) the standard because they test systems that have not implemented the standard correctly or because they want to provide certain functions that are not available in the standard. Manufacturers then provide drivers for only a few operating systems, eliminating difficulties with those systems. Unfortunately, Linux drivers are rarely provided. The current situation is such that you cannot act on the assumption that every protocol works smoothly in Linux. Therefore, you may have to experiment with various options to achieve a functional configuration.
![]() | Remote Access Settings |
|---|---|
By default, the cupsd only listens on internal network interfaces
( | |
CUPS supports the socket,
LPD, IPP, and
smb protocols.
Socket refers to a connection in which the data is
sent to an Internet socket without first performing a data handshake.
Some of the socket port numbers that are commonly used are
9100 or 35. The device URI
(uniform resource identifier) syntax is
socket://IP.of.the.printer:port,
for example, socket://192.168.2.202:9100/.
The proven LPD protocol is described in RFC 1179. Under this
protocol, some job-related data, such as the ID of the printer queue, is
sent before the actual print data is sent. Therefore, a printer queue
must be specified when configuring the LPD protocol for the data
transmission. The implementations of diverse printer manufacturers are
flexible enough to accept any name as the printer queue. If necessary,
the printer manual should indicate what name to use. LPT, LPT1, LP1, or
similar names are often used. An LPD queue can also be configured on a
different Linux or Unix host in the CUPS system. The port number for an
LPD service is 515. An example device URI is
lpd://192.168.2.202/LPT1.
IPP is a relatively new (1999) protocol based on the HTTP
protocol. With IPP, more job-related data is transmitted than with the
other protocols. CUPS uses IPP for internal data transmission. This is
the preferred protocol for a forwarding queue between two CUPS servers.
The name of the print queue is necessary to configure IPP correctly. The
port number for IPP is 631. Example device URIs are
ipp://192.168.2.202/ps and
ipp://192.168.2.202/printers/ps.
CUPS also supports printing on printers connected to Windows shares. The
protocol used for this purpose is SMB. SMB uses the port numbers
137, 138, and 139.
Example device URIs are
smb://user:password@workgroup/smb.example.com/printer,
smb://user:password@smb.example.com/printer, and
smb://smb.example.com/printer.
The protocol supported by the printer must be determined before
configuration. If the manufacturer does not provide the needed information,
the command nmap, which comes with the
nmap package, can be used to guess the protocol.
nmap checks a host for open ports. For example:
nmap -p 35,137-139,515,631,9100-10000 printerIPApart from setting CUPS options with YaST when configuring a
network printer, CUPS can be configured with command line tools like
lpadmin and lpoptions. You need a
device URI consisting of a back-end, such as USB, and parameters, like
/dev/usb/lp0. For example, the full URI could be
parallel:/dev/lp0 (printer connected to the first
parallel port) or usb:/dev/usb/lp0 (first detected
printer connected to the USB port).
With lpadmin, the CUPS server administrator can add, remove, or manage class and print queues. To add a print queue, use the following syntax:
lpadmin -pqueue-vdevice-URI-PPPD-file-E
Then the device (-v) is available as
queue (-p), using the specified
PPD file (-P). This means that you must know the PPD file
and the name of the device to configure the printer manually.
Do not use -E as the first option. For all CUPS commands,
-E as the first argument sets use of an encrypted
connection. To enable the printer, -E must be used as
shown in the following example:
lpadmin -p ps -v parallel:/dev/lp0 -P \ /usr/share/cups/model/Postscript.ppd.gz -E
The following example configures a network printer:
lpadmin -p ps -v socket://192.168.2.202:9100/ -P \ /usr/share/cups/model/Postscript-level1.ppd.gz -E
For more options of lpadmin, see the
man page of lpadmin(1).
During printer setup, certain options are set as default. These options can be modified for every print job (depending on the print tool used). Changing these default options with YaST is also possible. Using command line tools, set default options as follows:
First, list all options:
lpoptions -p queue -lExample:
Resolution/Output Resolution: 150dpi *300dpi 600dpi
The activated default option is identified by a preceding asterisk
(*).
Change the option with lpadmin:
lpadmin -p queue -o Resolution=600dpiCheck the new setting:
lpoptions -p queue -l
Resolution/Output Resolution: 150dpi 300dpi *600dpi
When a normal user runs lpoptions, the settings are
written to ~/.lpoptions. However, root settings are written to
/etc/cups/lpoptions.
Tools such as xpp and the KDE program KPrinter provide a graphical interface
for choosing queues and setting both CUPS standard options and
printer-specific options made available through the PPD file. You can even
use KPrinter as the standard printing interface of non-KDE applications. In
the print dialog of these applications, specify either
kprinter or
kprinter --stdin as the print
command. The command to use depends on how the application transmits the
data—just try which one results in starting KPrinter. If set up
correctly, the application should open the KPrinter dialog whenever a print
job is issued from it, so you can use the dialog to select a queue and set
other printing options. This requires that the application's own print setup
does not conflict with that of KPrinter and that printing options are only
changed through KPrinter after it has been enabled.
To print from the command line, enter lp -d
queuename
filename, substituting the
corresponding names for queuename and
filename.
Some applications rely on the lp command for printing. In
this case, enter the correct command in the application's print dialog,
usually without specifying filename, for example,
lp -d queuename.
A number of CUPS features have been adapted for SUSE Linux Enterprise. Some of the most important changes are covered here.
After having performed a default installation of SUSE Linux Enterprise, SuSEfirewall2
is active and the external network devices are configured to be in the
External Zone which blocks incoming traffic. These
default settings have to be adjusted when using CUPS. More information
about the SUSEfirewall2 configuration is available in Section 43.4, “SuSEfirewall2”.
Normally a CUPS client runs on a regular workstation located in a network
behind a firewall. In this case it is recommended to configure the
external network devices to be in the Internal Zone,
so the workstation is reachable from within the network.
If the CUPS server is part of network protected by a firewall, the
external network device should be configured to be in the
Internal Zone of the firewall. When being part of the
external zone, the TCP and UDP port 631 needs to be opened in order to
make the CUPS server available in the network.
BrowseAllow and
BrowseDeny¶
The access permissions set for BrowseAllow and
BrowseDeny apply to all kinds of packages sent to
cupsd. The default settings in
/etc/cups/cupsd.conf are as follows:
BrowseAllow @LOCAL BrowseDeny All
and
<Location /> Order Deny,Allow Deny From All Allow From 127.0.0.1 Allow From 127.0.0.2 Allow From @LOCAL </Location>
In this way, only LOCAL hosts can access
cupsd on a CUPS server. LOCAL hosts
are hosts whose IP addresses belong to a non-PPP interface (interfaces
whose IFF_POINTOPOINT flags are not set) and whose IP
addresses belong to the same network as the CUPS server. Packets from all
other hosts are rejected immediately.
In a standard installation, cupsd is activated
automatically, enabling comfortable access to the queues of CUPS network
servers without any additional manual actions. The items in
Section 23.8.2.1, “Generalized Functionality for BrowseAllow and
BrowseDeny” are vital preconditions for
this feature, because otherwise the security would not be sufficient for
an automatic activation of cupsd.
The YaST printer configuration sets up the queues for CUPS using only
the PPD files installed in /usr/share/cups/model.
To find the suitable PPD files for the printer model, YaST
compares the vendor and model determined during hardware detection with
the vendors and models in all PPD files available in
/usr/share/cups/model on the system. For this
purpose, the YaST printer configuration generates a database from the
vendor and model information extracted from the PPD files. When you
select a printer from the list of vendors and models, receive the PPD
files matching the vendor and model.
The configuration using only PPD files and no other information sources has
the advantage that the PPD files in
/usr/share/cups/model can be modified freely. The
YaST printer configuration recognizes changes and regenerates the vendor
and model database. For example, if you only have PostScript printers,
normally you do not need the Foomatic PPD files in the
cups-drivers package or the Gimp-Print PPD files
in the cups-drivers-stp package. Instead, the PPD
files for your PostScript printers can be copied directly to
/usr/share/cups/model (if they do not already exist
in the manufacturer-PPDs package) to achieve an
optimum configuration for your printers.
cups Package¶
The generic PPD files in the cups package have
been complemented with adapted Foomatic PPD files for PostScript level 1
and level 2 printers:
/usr/share/cups/model/Postscript-level1.ppd.gz
/usr/share/cups/model/Postscript-level2.ppd.gz
cups-drivers
Package¶
Normally, the Foomatic printer filter
foomatic-rip is used together with Ghostscript
for non-PostScript printers. Suitable Foomatic PPD files have the entries
*NickName: ... Foomatic/Ghostscript driver and
*cupsFilter: ... foomatic-rip. These PPD files
are located in the cups-drivers package.
YaST prefers a Foomatic PPD file if a Foomatic PPD file with the entry
*NickName: ... Foomatic ... (recommended) matches
the printer model and the manufacturer-PPDs
package does not contain a more suitable PPD file.
cups-drivers-stp Package¶
Instead of foomatic-rip, the CUPS filter
rastertoprinter from Gimp-Print can be used for
many non-PostScript printers. This filter and suitable Gimp-Print PPD
files are available in the cups-drivers-stp
package. The Gimp-Print PPD files are located in
/usr/share/cups/model/stp/ and have the entries
*NickName: ... CUPS+Gimp-Print and
*cupsFilter: ... rastertoprinter.
manufacturer-PPDs Package¶
The manufacturer-PPDs package contains PPD files
from printer manufacturers that are released under a sufficiently liberal
license. PostScript printers should be configured with the suitable PPD
file of the printer manufacturer, because this file enables the use of all
functions of the PostScript printer. YaST prefers a PPD file from the
manufacturer-PPDs package if the following
conditions are met:
The vendor and model determined during the hardware detection match the
vendor and model in a PPD file from the
manufacturer-PPDs package.
The PPD file from the manufacturer-PPDs
package is the only suitable PPD file for the printer model or a there
is a Foomatic PPD file with a *NickName: ...
Foomatic/Postscript (recommended) entry that also matches
the printer model.
Accordingly, YaST does not use any PPD file from the
manufacturer-PPDs package in the following cases:
The PPD file from the the manufacturer-PPDs
package does not match the vendor and model. This may happen if the
manufacturer-PPDs package contains only one PPD
file for similar models, for example, if there is no separate PPD file
for the individual models of a model series, but the model name is
specified in a form like Funprinter 1000 series
in the PPD file.
The Foomatic PostScript PPD file is not recommended. This may be because the printer model does not operate efficiently enough in PostScript mode, for example, the printer may be unreliable in this mode because it has too little memory or the printer is too slow because its processor is too weak. Furthermore, the printer may not support PostScript by default, for example, because PostScript support is only available as an optional module.
If a PPD file from the manufacturer-PPDs package
is suitable for a PostScript printer, but YaST cannot configure it for
these reasons, select the respective printer model manually in YaST.
The following sections cover some of the most frequently encountered printer hardware and software problems and ways to solve or circumvent these problems. Among the topics covered are GDI printers, PPD files, and port configuration. Common network printer problems, defective printouts, and queue handling are also addressed.
These printers do not support any common printer language and can only be addressed with special proprietary control sequences. Therefore they can only work with the operating system versions for which the manufacturer delivers a driver. GDI is a programming interface developed by Microsoft* for graphics devices. Usually the manufacturer delivers drivers only for Windows and because the Windows driver uses the GDI interface, these printers are also called GDI printers. The actual problem is not the programming interface, but the fact that these printers can only be addressed with the proprietary printer language of the respective printer model.
Some GDI printers can be switched to operate either in GDI mode or one of the standard printer languages. See the manual of the printer whether it is possible. Some models require a special Windows software to do the switch (note that the Windows printer driver may always switch the printer back into GDI mode when printing from Windows). For other GDI printers there are extension modules for a standard printer language available.
Some manufacturers provide proprietary drivers for their printers. The disadvantage of proprietary printer drivers is that there is no guarantee that these work with the installed print system and that they are suitable for the various hardware platforms. In contrast, printers that support a standard printer language do not depend on a special print system version or a special hardware platform.
Instead of spending time trying to make a proprietary Linux driver work, it may be more cost-effective to purchase a supported printer. This would solve the driver problem once and for all, eliminating the need to install and configure special driver software and obtain driver updates that may be required due to new developments in the print system.
If the manufacturer-PPDs package does not contain
any suitable PPD file for a PostScript printer, it should be possible to
use the PPD file from the driver CD of the printer manufacturer or download
a suitable PPD file from the Web page of the printer manufacturer.
If the PPD file is provided as a zip archive (.zip) or a self-extracting
zip archive (.exe), unpack it with
unzip. First, review the license terms of the PPD file.
Then use the cupstestppd utility to check if the PPD
file complies with “Adobe PostScript Printer Description File Format
Specification, version 4.3.” If the utility returns
“FAIL,” the errors in the PPD files are serious and are likely
to cause major problems. The problem spots reported by
cupstestppd should be eliminated. If necessary, ask the
printer manufacturer for a suitable PPD file.
The safest approach is to connect the printer directly to the first parallel port and to select the following parallel port settings in the BIOS:
I/O address: 378 (hexadecimal)
Interrupt: irrelevant
Mode: Normal, SPP, or
Output Only
DMA: disabled
If the printer cannot be addressed on the parallel port despite these
settings, enter the I/O address explicitly in accordance with the setting
in the BIOS in the form 0x378 in
/etc/modprobe.conf. If there are two parallel ports
that are set to the I/O addresses 378 and
278 (hexadecimal), enter these in the form
0x378,0x278.
If interrupt 7 is free, it can be activated with the
entry shown in
Example 23.1, “
/etc/modprobe.conf: Interrupt Mode for the First
Parallel Port
”. Before activating the
interrupt mode, check the file /proc/interrupts to see
which interrupts are already in use. Only the interrupts currently being
used are displayed. This may change depending on which hardware components
are active. The interrupt for the parallel port must not be used by any
other device. If you are not sure, use the polling mode with
irq=none.
Example 23.1.
/etc/modprobe.conf: Interrupt Mode for the First
Parallel Port
¶
alias parport_lowlevel parport_pc options parport_pc io=0x378 irq=7
Connect the printer directly to the computer. For test purposes, configure the printer as a local printer. If this works, the problems are related to the network.
The TCP/IP network and name resolution must be functional.
By default, the cupsd only listens on internal network interfaces
(localhost). Check whether the
Listen directive(s) in
/etc/cups/cupsd.conf allow access from the
outer network:
Listen 192.168.2,*:631
A CUPS server either needs to be in the internal firewall zone or, when being in the external zone, must be able to send and receive data on the UDP and TCP port 631.
Use the following command to test if a TCP connection
can be established to lpd (port
515) on host:
netcat -z host 515 && echo ok || echo failedIf the connection to lpd cannot be established, lpd may not be active or there may be basic network problems.
As the user root, use the
following command to query a (possibly very long) status report for
queue on remote
host, provided the respective
lpd is active and the host accepts queries:
echo -e "\004queue" \
| netcat -w 2 -p 722 host 515
If lpd does not respond, it may not be active or
there may be basic network problems. If lpd
responds, the response should show why printing is not possible on the
queue on host. If you receive a
response like that in Example 23.2, “Error Message from lpd”, the problem is caused
by the
remote lpd.
Example 23.2. Error Message from lpd¶
lpd: your host does not have line printer access lpd: queue does not exist printer: spooling disabled printer: printing disabled
By default, the CUPS network server should broadcast its queues every 30
seconds on UDP port 631. Accordingly, the following
command can be used to test whether there is a CUPS network server in
the network.
netcat -u -l -p 631 & PID=$! ; sleep 40 ; kill $PID
If a broadcasting CUPS network server exists, the output appears as shown in Example 23.3, “Broadcast from the CUPS Network Server”.
►zseries: Take into account that IBM System z ethernet devices do not receive broadcasts by default. ◄
The following command can be used to test if a TCP connection can be
established to cupsd (port 631) on
host:
netcat -z host 631 && echo ok || echo failed
If the connection to
cupsd cannot be established, cupsd
may not be active or there may be basic network problems.
lpstat -h host -l -t
returns a (possibly very long) status report for all queues on
host, provided the respective
cupsd is active and the host accepts queries.
The next command can be used to test if the
queue on host
accepts a print job consisting of a single carriage-return character.
Nothing should be printed. Possibly, a blank page may be ejected.
echo -en "\r" \
| lp -d queue -h hostSpoolers running in a print server box sometimes cause problems when they have to deal with a lot of print jobs. Because this is caused by the spooler in the print server box, there is nothing you can do about it. As a work-around, circumvent the spooler in the print server box by addressing the printer connected to the print server box directly with TCP socket. See Section 23.5, “Network Printers”.
In this way, the print server box is reduced to a converter between the
various forms of data transfer (TCP/IP network and local printer
connection). To use this method, you need to know the TCP port on the
print server box. If the printer is connected to the print server box
and powered on, this TCP port can usually be determined with the
nmap utility from the nmap
package some time after the print server box is powered on. For example,
nmap IP-address may
deliver the following output for a print server box:
Port State Service 23/tcp open telnet 80/tcp open http 515/tcp open printer 631/tcp open cups 9100/tcp open jetdirect
This output indicates that the printer connected to the print server box
can be addressed via TCP socket on port 9100. By
default, nmap only checks a number of commonly known
ports listed in /usr/share/nmap/nmap-services. To
check all possible ports, use the command nmap
-p from_port-to_port IP-address.
This may take some time. For further information, refer to the man page
of nmap.
Enter a command like
echo -en "\rHello\r\f" | netcat -w 1 IP-address port cat file | netcat -w 1 IP-address port
to send character strings or files directly to the respective port to test if the printer can be addressed on this port.
For the print system, the print job is completed when the CUPS back-end completes the data transfer to the recipient (printer). If the further processing on the recipient fails, for example, if the printer is not able to print the printer-specific data, the print system does not notice this. If the printer is not able to print the printer-specific data, select a different PPD file that is more suitable for the printer.
If the data transfer to the recipient fails entirely after several
attempts, the CUPS back-end, such as USB or
socket, reports an error to the print system (to
cupsd). The back-end decides whether and how many
attempts make sense until the data transfer is reported as impossible.
Because further attempts would be in vain, cupsd
disables printing for the respective queue. After eliminating the cause of
the problem, the system administrator must reenable printing with the
command /usr/bin/enable.
If a CUPS network server broadcasts its queues to the client hosts via browsing and a suitable local cupsd is active on the client hosts, the client cupsd accepts print jobs from applications and forwards them to the cupsd on the server. When cupsd accepts a print job, it is assigned a new job number. Therefore, the job number on the client host is different from the job number on the server. Because a print job is usually forwarded immediately, it cannot be deleted with the job number on the client host, because the client cupsd regards the print job as completed as soon as it has been forwarded to the server cupsd.
To delete the print job on the server, use a command such as lpstat -h cups.example.com -o to determine the job number on the server, provided the server has not already completed the print job (that is, sent it completely to the printer). Using this job number, the print job on the server can be deleted:
cancel -h cups.example.com queue-jobnnumberPrint jobs remain in the queues and printing resumes if you switch the printer off and on or shut down and reboot the computer during the printing process. Defective print jobs must be removed from the queue with cancel.
If a print job is defective or an error occurs in the communication between the host and the printer, the printer prints numerous sheets of paper with unintelligible characters, because it is unable to process the data correctly. To deal with this, follow these steps:
To stop printing, remove all paper from ink jet printers or open the paper trays of laser printers. High-quality printers have a button for canceling the current printout.
The print job may still be in the queue, because jobs are only removed
after they are sent completely to the printer. Use lpstat
-o or lpstat -h cups.example.com -o to check
which queue is currently printing. Delete the print job with
cancel
queue-jobnumber
or cancel -h cups.example.com
queue-jobnumber.
Some data may still be transferred to the printer even though the print job has been deleted from the queue. Check if a CUPS back-end process is still running for the respective queue and terminate it. For example, for a printer connected to the parallel port, the command fuser -k /dev/lp0 can be used to terminate all processes that are still accessing the printer (more precisely: the parallel port).
Reset the printer completely by switching it off for some time. Then insert the paper and turn on the printer.
Use the following generic procedure to locate problems in the CUPS print system:
Set LogLevel debug in
/etc/cups/cupsd.conf.
Stop cupsd.
Remove /var/log/cups/error_log*
to avoid having to search through very large
log files.
Start cupsd.
Repeat the action that led to the problem.
Check the messages in /var/log/cups/error_log* to
identify the cause of the problem.