8. How to set things up

8.1. Configuring CUPS

If you are using a client with CUPS and a CUPS server has already been configured, installing the printers on your client can not get much easier than this: do nothing. Through broadcasting, the client should find the CUPS server and automatically configure the printers that are installed on that print server. This is one of the features of CUPS that will be really appreciated on large networks.

Manually configuring printers with CUPS, also is a peace of cake. If you are new to CUPS and/or Unix printing, the way to go is probably the web interface. If you have to configure lots of printers, using the command-line will probably be faster.

The URL to access the CUPS web interface is http://hostname:631/admin by default. The port can be changed in cupsd.conf if necessary.

To add a printer from the command-line the general syntax is lpadmin -p printer -E -v device -m ppd Lpadmin with the -p option adds or modifies a printer. The printers are saved in the file The -x option deletes the named printer. Read the lpadmin man page for available options.

/usr/sbin/lpadmin -p testpr1 -E -v socket://192.168.1.9 -m deskjet.ppd
/usr/sbin/lpadmin -p testpr2 -E -v parallel:/dev/lp0 -m laserjet.ppd
/usr/sbin/lpadmin -x testpr1

More information about configuring printers and options can be found in the CUPS documentation. The Software Administrators Manual will teach you all you need to know about configuring printers with CUPS.

8.2. Configuring LPD

Until recently most GNU/Linux distributions shipped with LPD. This section describes a very basic setup for LPD; further sections detail the creation of complex filters and network configuration.

8.2.2. LPD for PostScript Printers

While most versions of LPD don't gracefully handle PostScript (never mind user options), VA Linux modified LPD and Red Hat's filtering software to support PostScript printers fairly well. Because the intention was to donate the code to the gnu project, they called it GNUlpr

8.2.2.1. How it works

VA's system uses Postscript Printer Definition, or PPD, files. PPD files are provided by printer manufacturers and declare the available options on a printer, along with the Postscript code needed to activate them. With the VA system, the normal LPD scheme works a little differently:

1. The user can specify options with the -o flag. For example, you might specify -o MediaType:Transparency if you were about to print on overhead film. Alternatively, the front-end GPR can be used to specify options in a dialog box; you can see screenshots of GPR in Section 3.4.3.

2. LPR passes the options to LPD as an extended attribute in the LPD control file.

3. A modified version of the rhs-printfilters package is given the extended options data in an environment variable, and uses ppdfilt to add these options to the print data.

8.2.2.2. Obtaining and Installing

You can obtain RPM packages, or source tarballs, from the project's website on SourceForge. For installation details, consult the project's installation micro-HOWTO. In essence, you need to uninstall the Red Hat version of printtool, lpd, and rhs-printfilters entirely, and then install the VA versions, plus ppdfilt, gpr, and a few other utilities.

You will also need PPD files for your Postscript printers. PPD files are usually fairly easy to find. VA Linux and HP distribute PPD files for many Laserjet models. Other vendors provide PPDs for their own printers, and Adobe distributes PPD files for many printers.

At the moment, much of this is a bit difficult to install. But future installation tools will build upon the printer configuration library libprinterconf, which enables both the autodetection and rhs-printfilter configuration of both networked and local printers.

It is possible to use GPR alone, without the modified LPD or even rhs-printfilters. GPR can be compiled with all the logic needed to massage Postscript jobs directly. This may be an easier-to-install option suitable for people who never really need to print using lpr directly.

8.2.2.3. Controlling Postscript Options

Once you've setup VA's Postscript-capable LPD system (GNUlpr), you can control your printer's options in two ways:

With the GUI

To use GPR, you first make sure that you've specified the proper PPD file. Then the printer's options will be available on the `Advanced' panel. Basic ppdfilt options will be available on the `Common' panel.

With the command line

This lpr supports the -o option. You may specify any option/value pair from your printer's PPD file with -o. For example, consider this PPD file option clause:

*OpenUI *PrintQuality/Print Quality: PickOne *DefaultPrintQuality: None *OrderDependency: 150 AnySetup *PrintQuality *PrintQuality None/Printer Setting: "" *PrintQuality Quick/QuickPrint: "<< /DeviceRenderingInfo ... *PrintQuality Normal/Normal: "<< /DeviceRenderingInfo << /... *PrintQuality Pres/Presentation: "<< /DeviceRenderingInfo ... *PrintQuality Image/1200 Image Quality: "<< /DeviceRenderi... *CloseUI: *PrintQuality

For the option PrintQuality, the possible values are Quick, Normal,Pres, or Image. You might give a command like:

% lpr -o PrintQuality:Image file.ps

There are a number of options common to all printers which will work in addition to the ones from your PPD. These include:

page-ranges

You can specify a range of pages to print. For example,page-ranges:2-3.

page-set

You can print only odd or even pages. For example,page-set:odd.

number-up

You can print multiple pages on each piece of paper. For example, number-up:2.

Other options are detailed in the ppdfilt man page.

8.3. Large Installations

Large installations, by which I mean networks including more than two printers or hosts, have special needs. Below are some tips.

CUPS has some nice features that make a good choice for a large network. Printer classes, access control and automatic client configuration to name a few.

If you use LPD, for really large environments, merely distributing printcap/filter information becomes a difficult problem; the Cisco Enterprise Print System addresses this and is probably either a good starting point or a nearly complete solution, depending on your needs. Medium to large environments can be well supported by native LPRng features.

• Each printer should have a single point of control, where an administrator can pause, reorder, or redirect the queue. To implement this, have everyone printing to a local server, which will then queue jobs and direct them to the proper printer. For large campuses or distributed networks, have one server per building or other suitable network subset.

• Use CUPS or LPRng, at least on servers; the BSD LPD is too buggy for "real" use. But don't take my word for it—you should test a number of spoolers and see which suits you best.

• Client systems should not have unique printing configurations. CUPS provides automatic client configuration of printers on the same subnet. You can even configure CUPS (BrowsePoll) to poll servers on other subnets for available printers. These features limit the amount of configuration that needs to take place at the client. To implement a uniform printing configuration with LPRng, use LPRng's extended printcap syntax so that you have one printcap to use everywhere. CEPS provides for this by building atop a lightweight distributed database instead of traditional printcap files.

• Print queues should not be named for make or model; name print queues for something sensible like location (floor2_nw) or capability (color_transparency). Three years from now, when a printer breaks, you will be able to replace it with a different make or model without causing confusion.

• Operate a web page which shows detailed information on each printer, including location, capabilities, etc. Consider having it show the queue and include a button to remove jobs from the queue. Complex networked environments are unmanageable for users without proper documentation.

• On Windows and Apple systems, use either the platform-specific drivers everywhere (Samba supports the Windows automagical driver-download mechanism) or, better, use generic Postscript drivers everywhere. Do not mix and match; primitive word processors often produce different output when the installed printer driver changes; users cannot deal with output that varies depending on the particular client/printer pair.

• If at all possible, buy a large-volume printer for large-volume printing. If on a budget, use LPRng's multiple printers/one queue facility or CUPS printer classes and assign a babysitter; printers are complex mechanical devices that will often jam and run out of paper in such configurations.

• Do not feel that printers must be plugged into workstations; Ethernet "print servers" now cost under $100. The ability to locate printers anywhere you can network is a big improvement over forced location near a host; locate printers in sensible, central locations.

• Use any SNMP trap or other monitoring/alert facility available to you - someone should be tasked with running around and fixing printers with no ink or paper. Npadmin (see Section 11.10.1) can be used to do some management operations with SNMP printers.

8.4. Accounting

Regular LPD provides very little to help you with accounting. You can specify the name of an accounting file in the af printcap attribute, but this is merely passed as an argument to your if filter. It's up to you to make your if filter write entries to the accounting file, and up to you to process the accounting file later (the traditional format is mainly useful for line printers, and is nontrivial to parse in Perl, so there's no reason to preserve it). Also, if you're using foomatic-rip program as your filter, you'll need to make changes, since it depends on being given a configuration file as the ``accounting'' file name.

CUPS provides page accounting by passing jobs through the pstops filter. This filter expects Postscript input. If you use print "raw" jobs, this is always counted as 1 page. This means that accounting will not work, if you print from Windows client with the native printer driver.

Ghostscript provides a PageCount operator that you can use to count the number of pages in each job; basically you just tack a few lines of postscript onto the end of the job to write an accounting file entry; for the best example of this see the fileunix-lpr.sh in the Ghostscript source distribution.

Note that the unix-lpr implementation of accounting writes to a file from the Ghostscript interpreter, and is thus incompatible with the recommended -dSAFER option. A better solution might be to query the printer with a PJL command after each job, or to write a postscript snippet that prints the pagecount on stdout, where it can be captured without having to write to a file.

The LPRng print spooler includes an HP-specific sample implementation of accounting; I assume that it queries the printer with PJL. This technique should work for most PJL, Postscript, or SNMP printers with which you have two-way communications.

If you have a networked printer that supports SNMP, you can use the npadmin program to query a pagecount after each job. This should work properly for all print jobs. See Section 11.10.1 for more information on npadmin.