Section 14.2. Managing Print Services
14.2. Managing Print ServicesLinux has a fairly complicated printing system, compared with the printing services most PCs use. Configuring the printing system is usually either very easy (because the semiautomated tools get it right) or very hard (because the semiautomated tools fail or because your printer is poorly supported under Linux). The next few pages describe the Linux printing system, beginning with an overview of the software and moving on to hardware configuration and testing, configuring the Common Unix Printing System (CUPS) to enable its web-based configuration tools and network helpers, defining printers in CUPS, fine-tuning printer definitions, managing printer queues, maintaining LPD compatibility, and troubleshooting printers. 14.2.1. Linux Printing SoftwarePrinting in Linux involves the interactions of several different software packages. The most important of these is the Linux printing daemon, which accepts jobs to be printed, keeps them in one or more queues, and sends the jobs to printers in an orderly manner. Additional software includes Ghostscript, which converts between PostScript and a form the printer can understand; Ghostscript printer definitions; and assorted extra tools that can help you create nicely formatted output. Before you can configure Linux printing, you must install all of these components. 14.2.1.1. Linux printing daemonsA printing daemon's job is to run in the background, accept print jobs from applications, temporarily store those print jobs, and send them to the appropriate printers without interfering with each other. All mainstream Linux distributions ship with at least one printing daemon, and most set them up in at least a minimal way when you install the OS. You may still need to configure your printing daemon so that it knows about your printer, though. This task is described later in this chapter, in "Defining Printers in CUPS." Traditionally, Linux has used the Berkeley Standard Distribution Line Printer Daemon (BSD LPD) or the updated LPRng package for printing. (For simplicity, both systems are referred to as LPD systems from here on.) Basic LPD systems are fairly simple tools; they accept print jobs, store those jobs in queues, and then send them directly to the printer. These systems can be modified to pipe the print jobs through other programs for additional processing, if desired. Unlike printing systems for Windows, Mac OS, and other OSs, LPD printing systems don't provide a two-way communication path. For instance, an application can't query the LPD system about the page width or color capabilities of a printer. Thus, you must tell each application about a printer's special features. LPD systems are, though, network-enabled, which makes it possible for one computer to share its printers with others, or for a computer to print to a network-capable printer. In 1999, an experimental new printing system was developed: CUPS. This package uses a new network printing protocol and enables applications to query a printer's capabilities and set printer features in ways that aren't possible with LPD systems. By 2004, all major Linux distributions had either switched to CUPS as the default printing system or offered it as an option on equal footing with BSD LPD or LPRng. For this reason, we describe CUPS in this chapter. Although some of the principles and support software are the same for BSD LPD and LPRng as for CUPS, the details are completely different. If you're using an older printing system, you may want to consider upgrading to CUPS. In most cases, you can install CUPS (if it's not already installed) by using your distribution's package management tools. Look for a package called cups and install it. If your system is already configured to use BSD LPD or LPRng, you should first remove that package. If you prefer, you can download the original CUPS source code from its web page, http://www.cups.org. 14.2.1.2. GhostscriptThe traditional LPD printing system passes a file from an application to a printer. In its most basic form, this means that the application must know how to create a file that the printer can understand. This contrasts with printing under most other OSs, such as Windows, in which the application can use OS calls to help prepare a document for printing. As a practical matter, Unix and Linux applications almost always generate one of two types of output:
Unfortunately, most printers, and particularly the inexpensive consumer and small business printers that are often paired with Linux, don't understand PostScript. The answer is to pipe output through Ghostscript (http://www.cs.wisc.edu/~ghost/), which is a PostScript interpreter that can reside on the computer rather than in the printer. Ghostscript converts PostScript into formats that most printers can understand. In effect, the combination of PostScript and Ghostscript becomes the Linux equivalent of the Windows printer driver system. Although CUPS changes many things about the Linux printing system, it still relies on Ghostscript to convert PostScript into printers' native languages. Thus, you must have Ghostscript installed on your system if you expect to print to a non-PostScript printer. Fortunately, all major Linux distributions ship with Ghostscript. You may want to check to be sure it's installed, though; look for a package called ghostscript. Ghostscript is actually available in two versions. The most recent version of Ghostscript is AFPL Ghostscript, which is available under a license that permits free use for many purposes, but not free redistribution. After a few months, AFPL Ghostscript is released under the GPL as GNU Ghostscript, and it's this version that comes with most Linux distributions. In most cases, being a few months behind the leading edge of Ghostscript development is unimportant. If you absolutely must have the latest version, though, check the Ghostscript home page. Ghostscript comes with drivers for many common printers , and it can also output many common graphics file formats. You can even generate Adobe Portable Document Format (PDF) files with Ghostscript. (The ps2pdf shell script helps automate this process.) For more flexibility, you can add Ghostscript drivers for assorted printers. As a point of interest, you should know that Ghostscript treats all printers as graphics devices. That is, if you print a purely textual document, Ghostscript converts that text into a graphics bitmap and sends the bitmap to the printer. This means that Ghostscript cannot take advantage of fonts that are built into the printer. It also means that Ghostscript sometimes prints more slowly than other software, such as Windows drivers, can print to the same printer. (This effect is usually negligible, but it's sometimes dramatic.) On some very old laser printers, another consequence is that Ghostscript (and hence Linux) requires a printer memory upgrade for the printer to print at full resolution. In practice, though, even Windows treats many printers as graphics-only devices, so Ghostscript's doing so may not make any difference. 14.2.1.3. Printer definitionsA standard CUPS installation supports a fairly narrow range of printers, typically PostScript models and some Hewlett-Packard and Epson printers. To support more printers, you must install a printer driver package. (In truth, many of these "drivers" are really just printer descriptions coupled to standard Ghostscript drivers, but in practice they're necessary either way.) Several such driver packages exist:
Most distributions ship with Foomatic or GIMP Print, so check for those packages. Sometimes they're called something else, and occasionally they're bundled with still more printer definitions. If you fail to install any printer definitions, you'll see a very limited set of printers when you configure printing. Sometimes multiple printer definitions are available for a single printerfor instance, separate definitions in the Foomatic and GIMP Print packages, or even multiple definitions in a single package. In such cases, you may want to try all the available definitions to see which one works best with your printer and the types of documents you print. Sometimes the developers give you a hint by specifying in the configuration menus that one definition is recommended over the others. 14.2.1.4. Additional printing softwareCUPS (or an LPD printing system) is a practical necessity for printing from Linux. For most printers, Ghostscript and Ghostscript driver definitions are also practical necessities. Several additional tools are often highly desirable, but may not be necessary in all cases:
Some of these tools are covered elsewhere in this book. Most require little configuration, and all are primarily user-level tools. Be aware that this list is not comprehensive; Linux printing tools are extremely plentiful, and range from simple text formatting tools to sophisticated word processors and graphics applications. 14.2.2. Configuring Printer HardwareThe first order of business when configuring a printer is configuring the hardware . You must verify that your printer is compatible with Linux, check its physical interface to the computer, and verify that the interface is working. Failure to check these details can lead to problems when you try to actually configure the printer in Linux, leading to a wild goose chase as you try to debug problems in the wrong subsystems. 14.2.2.1. Verifying printer compatibilityThe main issue with respect to printer compatibility is the language the printer uses. Several languages are common, but many printers use their own unique languages. The more common printer languages include PostScript, HP's Printer Control Language (PCL) , and Epson's ESC/P2 language. (ESC/P2 is most common on old dot matrix printers.) Many manufacturers make printers that use each of these languages, but sometimes they bury this detail in their descriptions or refer to it in another way. One common example is a laser printer that uses PCL; the manufacturer may refer to the printer as being "HP-compatible" (usually with a reference to a specific HP printer model). The best hope for Linux compatibility is to get a printer that supports PostScript. Such printers are typically mid-range to high-end laser printers. Few inkjet or low-end laser printers support PostScript. With a PostScript printer, you needn't be concerned about whether a Ghostscript driver exists for your printer; just configure CUPS to pass the raw PostScript straight through to the printer.
If you don't have a PostScript printer, your best bet for assessing Linux compatibility is to check the Linux Printing web site, and particularly its printer database, located at http://www.linuxprinting.org/printer_list.cgi. Locate your printer make and model in the drop-down fields on this site and then click the Show button. You'll then see a description of your printer and its Linux compatibility. The description may also tell you where to find drivers or printer descriptions to use with CUPS, so you can check that you have the appropriate support software. If your printer is listed on the Linux Printing web site as a "paperweight" (meaning it doesn't work at all under Linux), you may want to try doing a web search on the printer's name and Linux. If you're lucky, you'll turn up a new or experimental driver you can try. If not, you may want to look into replacing the printer with one that's more Linux-friendly. If you have, or are considering buying, a multifunction device (such as one that handles both printing and scanning functions), you should investigate Linux support for all of the device's functions. Sometimes the printer side will work fine but the scanner will be useless, for instance. Typically, support for each function is provided by its own project under Linux, such as Ghostscript for the printer and the Scanner Access Now Easy (SANE ) project for scanner support. Occasionally, a project exists to provide all the necessary drivers in one place, such as the HP Office Jet project (http://hpoj.sourceforge.net) or Epson's drivers (http://www.avasys.jp/english/linux_e). These projects may be independent or sponsored by the device's manufacturer. 14.2.2.2. Printer interfacesPrinters can be connected to computers in several different ways. Four interface methods are common:
You should be aware of which interface method your printer uses. Some testing and configuration features won't work with some interfaces; for instance, you can't easily bypass the printing system to send a file directly to a USB or Ethernet printer. You must also have appropriate ports on your computer to support your printer, and the necessary cabling. If you lack this hardware, you should buy it. You can purchase add-in cards with any of the necessary port types; or if you have USB ports but no open slots in your computer, you can purchase an adapter so that you can connect a parallel, RS-232 serial, or even an Ethernet printer via a USB port. Be sure Linux drivers exist for the adapter, though! If your printer supports multiple interface types, USB is generally the best to use, followed by a parallel interface and then RS-232 serial. USB provides more information to the computer about the printer, uses less bulky cables, and (in its 2.0 incarnation) can be faster than the parallel port. A network-enabled printer can be a big advantage if you want it to be accessible to several computers, but if it uses an odd protocol it could be more trouble than it's worth, particularly if you use it on only one system. Of course, you should also consider your available ports and cables; it might be more trouble than it's worth to install a USB card in an older system that you're using as a print server, for instance. 14.2.2.3. Verifying basic printer connectivityBefore you set up printer services, be sure the printing devices are online. If you also use another operating system, such as Microsoft Windows, you can exercise the hardware to ensure that it is connected properly and working before loading Linux. Successfully printing a document from another operating system immediately eliminates one major source of woe and head scratching. Similarly, if you are going to use printer services on a network, your system should be on the network and all protocols functioning before proceeding. If you have a parallel or RS-232 serial printer, you can test basic printer functionality by sending a document directly to the printer device file. For instance, you might test a parallel printer by typing this command: # cat /etc/fstab > | /dev/lp0 This command copies the /etc/fstab file to /dev/lp0, the most common identifier for a parallel printer. If your printer can print a text file, the result should be a printout of your /etc/fstab file. On some printers, status lights will blink but nothing will emerge. Frequently, pressing a button (marked Form Feed, Continue, or something similar) on the printer will cause the file to print. This happens because the printer didn't receive a full page of data, and so was waiting until it received more data to continue. This shouldn't happen in normal operation, thoughjust when testing the printer. Another problem is "stair-stepping," which is a printout that doesn't reset the line starts, like this: /dev/hda1 / ext3 defaults 1 1 /dev/hda5 /home ext3 defaults 1 2 You might be able to figure out what went wrong here. Text files in Unix use just a newline (also known as a linefeed, ASCII code 10) to terminate each line. MS-DOS uses both a newline and a carriage return. Your printer was therefore set up to use MS-DOS-style line endings with both newline and carriage-return characters at the end of each line. In practice, CUPS normally filters newlines so that printers configured for DOS can understand them. If you still see this problem once you've fully configured printing, though, you can reconfigure your printer to properly return to the start of the line on receipt of a newline character. Often this is simply a matter of setting a dip switch. Check your printer manual. (Be careful about changing your printer characteristics if you use multiple operating systems.) If you're using a USB printer, you can look for it with the lsusb command: $ lsusb Bus 005 Device 004: ID 04b8:0807 Seiko Epson Corp. In practice, you're likely to see more output than this; however, this output shows a USB printeran Epson RX500, to be precise. It's on USB bus 5, device 4. You can learn more about it by viewing the contents of /proc/bus/usb/devices, but most of the information in that file is likely to look like gibberish to the uninitiated. One feature to look for in this file, though, is Driver=usblp. If a line containing this string is present, it means that Linux has recognized the printer as a printer, which means that CUPS should be able to communicate with it. (Whether you can get output from the printer depends on the status of Ghostscript drivers, though.) Finally, Ethernet printers can be treated just like other network devices. Specifically, you can use ping to verify that they're connected to the network. More substantial tests of their connectivity depend on the protocols the printer understands. Although low-level diagnostics of these protocols are possible, the simplest approach is usually to try configuring them, as described later in this chapter, in "Defining Printers in CUPS." 14.2.3. Configuring CUPS SecurityBefore proceeding with configuring CUPS to print, you should review your CUPS security and web-based configuration tool options. Unlike LPD systems, CUPS is best managed through its web-based configuration tool; however, this tool is sometimes disabled or set up in an inconvenient way. (Some distributions provide their own GUI tools for CUPS configuration. When using these distributions, you can either use their GUI tools or use the standard CUPS tools.) Depending on your network configuration, you might want to enable or disable the CUPS browsing feature, which enables CUPS servers to communicate their lists of available printers to one another. Browsing greatly simplifies network printer configuration and maintenance, but some distributions disable it by default. On the other hand, in a high-security environment or if your system is connected directly to the Internet, you might want to disable browsing, but some distributions enable it by default. In any event, you should review these settings and be sure they're set appropriately for your environment and needs. 14.2.3.1. Enabling web-based configurationThe main CUPS configuration file is /etc/cups/cupsd.conf. This file is modeled after the Apache configuration file, so if you're familiar with Apache, you should feel at home with this file. If you're not familiar with the Apache configuration file, the basics are as follows. The file begins with a series of global directives, which take the form of a directive name followed by the directive's value. For instance, to override the default server name (advertised to other systems), you would enter a directive like this one: ServerName gutenberg.example.com This line sets the server name to gutenberg.example.com. CUPS accepts a large number of configuration directives; you should consult its manpage for complete details. Some sets of configuration directives are enclosed in sections delimited by lines that are enclosed in angle brackets: <Location /admin> AuthType Basic AuthClass System Order Deny,Allow Deny From All Allow From 127.0.0.1 Allow from 192.168.1.0/24 </Location> This set of lines sets directives that apply only to certain functions of the serverin this case, those handled by the /admin (administrative) subsystem. You can use this feature to selectively modify the CUPS security functions (or other functions). The /admin area is particularly important for controlling access to the CUPS web-based administration tool. The options shown in the preceding example control features you may want to adjust:
To enable web-based configuration, you should be sure that your CUPS configuration has an /admin location defined and that it grants access to the 127.0.0.1 address, as shown in the preceding example. That example also gives administrative access to users on the 192.168.1.0/24 network. Generally speaking, you should activate such access only for print servers that you want to administer remotely; opening this option up increases the security risks associated with running CUPS. If you want to completely disable the CUPS web-based administrative tools (say, because you intend to use your distribution's own CUPS administrative programs instead), you should remove all the Allow directives and ensure that the configuration includes a Deny from All directive. 14.2.3.2. Enabling or disabling browsingWhile you're digging in the /etc/cups/cupsd.conf file, you may want to examine the server's browsing options. In the context of CUPS, browsing refers to automatic network printer discovery. This feature, supported by IPP, enables IPP servers to exchange lists of printers with one another. Each server periodically sends out broadcasts to which other IPP servers respond. The result is that you need configure each printer only once, on the computer to which it's connected. That server then propagates the configuration for the printer to other CUPS/IPP servers. Applications on those remote systems will see the new printer appear once they're restarted. This feature can be a great time-saver, particularly on networks on which printers are frequently added or removed. A couple of caveats are in order concerning browsing, though. First, like many network features, browsing comes with some security baggage. Systems configured to browse could be tricked into displaying bogus printer information, and it's conceivable that a bug in the CUPS browsing code could lead to more serious system compromises. For this reason, some distributions ship with browsing disabled. This fact is the second caveat: if you do want to use browsing, you may need to enable it. If you fail to do so, your system won't automatically detect other printers on your network. Likewise, if you want to tell your system to enable others to print to its printers you must be sure certain options are enabled. You should check several options on your client and server systems:
These browsing directives are typically set in the global section of the cupsd.conf file. They're sometimes set separately or redundantly in the /printers section, though, so check there if you have problems.
14.2.3.3. Restarting CUPSIf you make changes to your CUPS configuration, you should restart the CUPS daemon. On most distributions, this is done via the SysV startup script file: # /etc/init.d/cupsd restart This command (or one like it; you may need to change the path to cupsd) shuts down the CUPS daemon and restarts it. The result should be that the system implements any changes you make to the server's configuration. 14.2.4. Defining Printers in CUPSNow that you've ensured the CUPS administrative tools are available, you can begin using them. To do so, you'll need a web browser. Any modern browser will work: Mozilla Firefox, Konqueror, Opera, or even the text-mode Lynx, to name just four possibilities. With the help of your web browser, you can add your printer definitions and test your printer configuration.
14.2.4.1. Accessing the printer definition toolCUPS runs its web-based configuration tool on port 631, so you should be able to access the system by entering http://localhost:631 in your web browser's address field. If you've configured CUPS to accept administrative input from other systems, you should be able to access the printer configuration tool from another computer by entering the server's hostname, as in http://gutenberg.example.com:631.
If CUPS is properly configured and running, the result of accessing a computer's port 631 with a web browser should be a display with a series of links called Do Administration Tasks, Manage Printer Classes, On-Line Help, and so on. If you get an error message from your browser, chances are that something is wrong with your CUPS configuration; review the earlier section "Configuring CUPS Security," and check that the cupsd server is running. If you do see the main CUPS page, you can begin using it to add or reconfigure your printers. 14.2.4.2. Creating a printer definitionTo add a printer to a system, you should select the Manage Printers link on the main CUPS configuration page. The result should resemble Figure 14-3, which shows a CUPS configuration with some remote printers already autodetected. To create a new printer definition, follow these steps:
If you decide to change any of the features of your printer configuration, you can do so by clicking Modify Printer in the printer's area on the main printer configuration page (Figure 14-3). The result is a run through the original configuration options, except that the defaults have changed to whatever you've entered before. (You will be unable to change the printer's name, but you can change other options.) Figure 14-4. CUPS configured with printer definitions This procedure (or the GUI tools provided by your distribution) is the simplest way to configure a print queue in CUPS. If you happen to know all the values, though, you can use the lpadmin command-line utility instead. When used to define a queue, this utility takes the following syntax: lpadmin [-E] [-h server] -p printer option... The -E option enables the print queue (a desirable option, typically), while -h enables you to modify the configuration of a server other than the local one, and -p sets the name of the queue. The final, trailing options are the tricky part. Typically, the most important of these options are -i interface, which sets the interface device, and -m model, which points to a PostScript Printer Definition (PPD ) file that defines the printer's model and capabilities. You must know the filename of the PPD file for your printer, which may not be obvious unless you've obtained a PPD file specifically for the printer (say, from the printer's manufacturer). As the name implies, a PPD file describes the capabilities of a PostScript printer, so printer manufacturers normally only make these files available for PostScript models. CUPS printer definitions rely on PPD files for all printers, though, and in fact these are the main part of the Foomatic, GIMP Print, and other Linux printer definition packages.
One type of print queue definition requires special mention: a raw queue. You can create a raw queue by selecting a printer make of Raw and model of Raw Queue. Unlike most CUPS printer queues, a raw queue uses no filteringthat is, CUPS won't try to determine the file's type and pass it through programs such as Ghostscript to produce output that's acceptable for your printer. For most Linux purposes, raw queues aren't very useful; however, there are a few cases where you might want to use one. One such instance is if you want to use Linux as a print server for non-Linux systems, such as Windows computers. You might then install Windows drivers on the Windows clients to have them print to the Linux raw queue. Using a raw queue in this instance guarantees that CUPS won't corrupt the Windows print jobs. (Another option for this scenario is to use PostScript drivers on Windows. Each approach has its plusses and minuses.) A second situation where raw queues can be handy is when you use an application that provides its own printer drivers. The GIMP is one such program, and you might get better results using the GIMP's printer drivers than using the standard Ghostscript drivers for your printer. If in doubt, you should probably create a regular printer queue, which will try to parse the file type and convert it (via Ghostscript or other filtering programs) to your printer's native format. If this doesn't work or if you know you'll need it, though, a raw queue can be the way to go. 14.2.4.3. Testing your printer definitionOnce you've configured your printer queue, you can test it. From the main printer description page (Figure 14-3), click Print Test Page for your queue. CUPS should respond with a message to the effect that a test page has been printed. After a brief delay, the result should be a printer test page being printed. (Precisely how long a delay you'll experience depends on the printer, its configuration, how it's connected to your computer, your computer's CPU speed, and your computer's CPU load.) The standard CUPS test page includes a color wheel; a circle of fine radial lines (used to assess resolution); information on page size, borders, and nominal resolution; and PostScript interpreter data. Check that the resolution (expressed in dots per inch, or dpi, in the Imageable Area box) is reasonable. If it's not, consult "Fine-Tuning Printer Definitions" for help. Likewise, if a color printer produces merely black-and-white printouts, you will have to adjust your configuration. (This is assuming you know the printer is working correctly; it's entirely possible that the printer's color ink is depleted or clogged!) If your printer doesn't generate any output at all, consult the section "Printer Troubleshooting," later in this chapter. 14.2.5. Fine-Tuning Printer DefinitionsMost modern printers provide options that affect print quality and style. These features include variable resolution, ink- or toner-saving modes, printing modes optimized to particular types of paper, and so on. CUPS provides a way to set defaults for these features for a given queue. From the main print queue list page in the web-based CUPS configuration (Figure 14-3), click Configure Printer in the area for the printer you want to modify. The result is a list of options you can set, as shown in Figure 14-5. The list of options available for any given printer varies greatly from one printer to another. Some common options you might want to investigate include the following:
Because printer capabilities vary so much, we can't describe all the options here. You may need to examine the options and experiment with them. Change an option and see how it affects output. Some options will affect text more than graphics or graphics more than text. Different types of graphics, such as digital photos versus charts and graphs, may also be affected differently by certain options. As a general rule, if you don't understand an option you should probably leave it alone. In the past, Linux provided applications with limited or no access to printer options such as those described here. In fact, applications built for the old LPD system may not be able to set these options directly; these programs can only use the printer's defaults. To set such options in such applications, you can create multiple print queues for each printer. For instance, suppose you want to be able to print at 360 dpi for quick printouts or at 1440 dpi for slower but higher-quality printouts. You would create two print queues (say, canon_360 and canon_1440). Both queues would connect to a single printer device, but you'd set different default options for the two queues. You'd then choose your desired print resolution by printing to one queue or the other. Alternatively, if you're running in X and if the application enables you to enter the printing command, you can use kprinter as the printing command. The result is the standard KDE printing dialog box. When you set it to use CUPS (via the listbox near the bottom of the dialog box) and select a print queue, you can click the Properties button in the upper-right corner of the dialog box. The result is the Configuration dialog box shown in Figure 14-6. This dialog box has multiple tabs that correspond to various CUPS configuration options, so you can adjust the resolution (as shown in Figure 14-6) or other printing options. Another fine-tuning detail is setting the default print queue. In theory, you should be able to do this from the CUPS interface by clicking the Set as Default option; however, in practice this often produces an error message about an unknown operation. To work around this bug, use the lpadmin command with its -d option, which takes the name of the default queue: # lpadmin -d hp4500 This command sets the default queue to hp4500. All subsequent print jobs submitted via lp or lpr that don't specify a queue will go to the hp4500 queue. This queue will also be the one to appear in print dialog boxes when they first open. In the case of both text-mode and GUI programs, though, you can still print to non-default queues by specifying the one you want to use. 14.2.6. Managing Printer QueuesAn important part of printer administration is managing active print queues. Once a system has print queues defined, users start using them, and the result can sometimes be problems. You may need to delete jobs that are too big, temporarily shut down a queue while you reconfigure it, or otherwise manipulate the queue. To handle this task, CUPS provides two basic classes of tools: text-mode and web-based. Figure 14-6. kprinter lets you adjust printer features from many CUPS-unaware applications 14.2.6.1. Using command-line toolsText-mode CUPS commands enable you to control print queues from a text-mode login, an xterm window, or any other text-mode interface. Most of these commands require root privilege to function correctly, but a few can be used by ordinary users:
As an example of these commands in action, suppose you have a problem with the hp4000 queueperhaps the printer is malfunctioning and needs to be serviced. Thus, you want to disable it and move some of its jobs to another queue (say, the laserwriter queue), and perhaps delete other jobs. You might type commands like these to do all this: # disable hp4000 # lpc status hp4000 hp4000: printer is on device '/dev/null' speed -1 queuing is enabled printing is disabled no entries daemon present # lpstat hp4000-433 sholmes 15360 Sun Apr 10 22:20:44 2005 hp4000-434 moriarty 2977 Sun Apr 10 22:21:32 # lpmove hp4000-433 laserwriter # lprm hp4000-434 # lpstat laserwriter-433 sholmes 15360 Sun Apr 10 22:20:44 2005 In this example, the hp4000 queue is first disabled, and lpc status hp4000 confirms its disabled statusnote the printing is disabled message. The lpstat command reveals that two jobs are now stuck in the disabled queue. The first of these, belonging to sholmes, is moved to the laserwriter queue with the lpmove command, whereas the second job, belonging to moriarty, is deleted with lprm. A subsequent check with lpstat shows the moved job under its new name. (This job might not show up if it had been completely accepted by the printer before the command was typed.) 14.2.6.2. Using the CUPS web-based interfaceThe 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. 14.2.7. Maintaining LPD CompatibilityCUPS 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. 14.2.7.1. Maintaining a legacy /etc/printcap fileMany 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. 14.2.7.2. Accepting print jobs from LPD systemsAs 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 systems that use some other printing system that nonetheless understands the LPD protocol, you may want to enable LPD support in CUPS. This support will enable a CUPS system to accept print jobs submitted via the LPD protocol. It is not necessary on an all-CUPS network, and is disabled by default on all major Linux distributions. Enabling LPD support is necessary only to accept print jobs from LPD clients. If you want your CUPS daemon to print to a remote system that runs LPD, you can do so without activating this support. In this case, you need to specify the LPD server as a network print server, as described earlier in "Creating a printer definition." The CUPS LPD support is provided by a small daemon called, appropriately enough, cups-lpd. This server is designed to be run via a super server, such as inetd or xinetd. On distributions that use xinetd, such as Fedora, Red Hat, and SUSE, look for a xinetd configuration file called cups-lpd in the /etc/xinetd.d directory. Look for a line in this file that reads disable = yes and edit it so that it reads disable = no. You can then restart xinetd or tell it to reload its configuration, and the cups-lpd server should be started. This server will accept print jobs using the LPD protocol just like BSD LPD or LPRng would, but it will redirect the job into the local CUPS queue of the same name. If your system uses inetd, you must add an entry for cups-lpd to the /etc/inetd.conf file: printer stream tcp nowait lp /usr/lib/cups/daemon/cups-lpd cups-lpd Some systems will require changes to this configuration. For instance, you might want to call cups-lpd via TCP Wrappers (tcpd) rather than calling cups-lpd directly. As with xinetd, you must restart inetd or tell it to reload its configuration to start cups-lpd. 14.2.8. Printer TroubleshootingWith any luck, if you follow the instructions in this chapter, your printer will work with little or no fuss. Unfortunately, CUPS configuration doesn't always work as planned, and printer troubleshooting can be tricky and frustrating. Although we can't provide a sure-fire way to get your printer working, we can provide some suggestions that can help you track down the source of problems and find solutions to them.
On the whole, printer troubleshooting can be as much of an art as a science. A lot of things can go wrong, and it's hard to predict what's most likely to go wrong. The preceding summary should at least help you narrow the list of potential causes and get you on the right track to fixing the problem, though. 14.2.9. Behind the Scenes: CUPS Files and DirectoriesMost of the preceding description of CUPS has steered clear of describing specific files and directories. This is because, with the exception of the /etc/cups/cupsd.conf file, manually editing CUPS configuration files or changing its directories is seldom helpful. CUPS often responds unpredictably to manual changes in its configuration files; you should really use its web-based interface and text-mode commands to configure and control CUPS. That said, you may need to know about these files and directories. The CUPS configuration files reside in /etc/cups. The cupsd.conf file, as already noted, controls the server on a broad level, and you may need to edit this file. Other important files in this directory include printers.conf (which defines local printers) and lpoptions (which identifies the default printer). The ppd subdirectory holds PPD files for local printers (they're copied from elsewhere, as described shortly). CUPS stores a great deal of support data in the /usr/share/cups directory tree. Of particular interest is the /usr/share/cups/model subdirectory, which holds PPD files (most in subdirectories named after the printers' manufacturers). The Foomatic and GIMP Print packages may install PPD files there. If they don't, and if you can't get these printer definitions recognized, try creating symbolic links in this subdirectory to the actual location of the printer definition package's PPD files. This should enable CUPS to locate the PPD files and install the printers. In actual operation, CUPS uses the /var/spool/cups subdirectory to hold print job descriptions and the actual print job files. This directory is owned by root and the lp group and has 0710 (rwx--x---) permissions. CUPS also uses the /var/spool/cups/tmp directory, which is owned by root and the lp group and has 1710 (rwx--x--T) permissions. (These owners and permissions are typical, but may differ between distributions.) Unlike LPD, CUPS doesn't use separate subdirectories for each printer; print jobs for all printers are dumped into the same directory tree. |
EAN: 2147483647
Pages: 220