Running Linux, 5th Edition - Matthias Kalle Dalheimer [287]
Using the CUPS web-based interface
The CUPS web-based interface provides an alternative means of controlling print queues whose features largely parallel those of the text-based commands. From the main printer list (Figure 14-3), you can stop a queue (equivalent to disable) or tell it to reject new jobs (equivalent to reject) by clicking the Stop Printer or Reject Jobs links, respectively. Once clicked, these links change to Start Printer and Accept Jobs, respectively, and have the effect of the enable and accept commands.
You can view the contents of print queues by clicking the Jobs link at the top of the page. The result is a process list similar to the one created by lpstat. This list includes a Control column with a Hold Job and a Cancel Job link for each job. Click these links to temporarily stop a job from printing or to delete the job entirely, respectively.
Maintaining LPD Compatibility
CUPS is designed as a drop-in replacement for LPD , and in fact it uses many of the same commands for printing as LPD. (These are described in "Printing," earlier in the chapter.) A couple of key LPD compatibility issues are providing an environment that programs designed for LPD will find helpful and accepting print jobs from networked LPD clients.
Maintaining a legacy /etc/printcap file
Many programs that expect to print using LPD examine the /etc/printcap file to determine what queues are available. Under LPD, this file defines all the available print queues, so it's a critical LPD file. Thus, CUPS tries to maintain a minimal /etc/printcap file for the benefit of user programs. (CUPS-enabled programs communicate with CUPS in other ways to obtain print queue lists.)
A full LPD /etc/printcap file contains many types of fields, and any given printer definition is likely to use about half a dozen field types. The simplified needs of CUPS, though, mean that a stripped-down file is sufficient. A typical file looks like this:
hp4000|Hewlett-Packard HP LaserJet 4000 Series:rm=nessus:rp=hp4000:
epson|Epson RX500 1440x720 dpi:rm=nessus:rp=epson:
epson_360|Epson RX500, 360dpi economy:rm=nessus:rp=epson_360:
These three lines describe three queues: hp4000, epson, and epson_360. Under LPD, print queues may have multiple names, which are separated from one another by vertical bars (|). Typically, a short name begins the entry, and longer names follow. CUPS uses this feature to provide a short name based on the print queue name and a longer name based on the printer description. Subsequent fields in each line are separated by colons (:). In this example, CUPS has generated entries using the rm= and rp= options, which in LPD define the remote server name and remote print queue name for network printers. In this sample, these fields identify the computer on which the file resides and the queue name. CUPS doesn't require this information, nor do most LPD-using programs, but it can help keep a few programs happy to see this minimal information.
Normally, you needn't be concerned with maintaining an /etc/printcap file, because CUPS does so automatically. If something interferes with this process, though, you might want to create a dummy /etc/printcap file yourself. At a minimum, the file should hold each queue's correct name and a colon. Adding rm= and rp= fields, as in the preceding example, might help some programs.
Accepting print jobs from LPD systems
As noted earlier, CUPS uses IPP for communicating with other CUPS systems. LPD systems use the older LPD protocol. Thus, if your network contains a mix of CUPS and LPD systems, or a mix of CUPS systems with