8. How to set things up
For common configurations, you can probably ignore this section entirely - instead, you should jump straight to Section 9 below, or better yet, your vendor's documentation. Most GNU/Linux distributions supply one or more "idiot-proof" tools to do everything described here for common printers.
If your vendor's tool doesn't work out for you, or you'd like the ability to interactively control printing options when you print, then you should use some other system. APS Filter is another good system; it configures LPD queues and filters very easily on most any sort of Unix system.
You can also use the printing system interfaces from the linuxprinting.org website to connect many free drivers into several spooling systems. Once this project is complete, these interfaces will offer the best functionality: all styles of free software drivers are supported, user-settable options are available, and most common spooling systems are supported. Currently the foomatic print system is used in most modern distributions anyway. However, your distro may include a slightly outdated version of foomatic.
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.
Example 3. command-line examples
/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.1. Basic LPD configuration
The minimal setup for lpd results in a system that can queue files and print them. It will not pay any attention to whether or not your printer will understand them, and will probably not let you produce attractive output. But we have to start somewhere.
To add a print queue to lpd, you must add an entry in/etc/printcap, and make the new spool directory under /var/spool/lpd.
An entry in /etc/printcap looks like:
# LOCAL djet500
lp|dj|deskjet:\
:sd=/var/spool/lpd/dj:\
:mx#0:\
:lp=/dev/lp0:\
:sh:
|
Go now and read the man page for printcap.
The above looks very simple, but there a catch - unless I send in files a DeskJet 500 can understand, this DeskJet will print strange things. For example, sending an ordinary Unix text file to a deskjet results in literally interpreted newlines, and gets me:
This is line one. This is line two. This is line three. |
Clearly more is needed, and this is the purpose of filtering. The more observant of you who read the printcap man page might have noticed the spool attributes if andof. Well, if, or the input filter, is just what we need here.
If we write a small shell script called filter that adds carriage returns before newlines, the staircasing can be eliminated. So we have to add in an if line to our printcap entry above:
lp|dj|deskjet:\
:sd=/var/spool/lpd/dj:\
:mx#0:\
:lp=/dev/lp0:\
:if=/var/spool/lpd/dj/filter:\
:sh:
|
#!perl
# The above line should really have the whole path to perl
# This script must be executable: chmod 755 filter
while(<STDIN>){chomp $_; print "$_\r\n";};
# You might also want to end with a form feed: print "\f";
|
The only remaining problem is that printing plain text is really not too hot - surely it would be better to be able to print PostScript and other formatted or graphic types of output. Well, yes, it would, and it's easy to do. The method is simply an extension of the above linefeed-fixing filter.
Such a filter is called a magic filter. Don't bother writing one yourself unless you print strange things - there are a good many written for you already, and most have easy-to-use interactive configuration tools. You should simply select a suitable pre-written filter:
- foomatic-rip
foomatic-rip is a filter designed to use data from the LinuxPrinting.org printer database. It supports essentially all free software printer drivers, including regular Ghostscript drivers, Uniprint drivers, and the assorted filter programs floating around out there. foomatic-rip works with CUPS, LPRng, LPD, GNUlpr, PPR, PDQ, no spooler.
- APS Filter
apsfilter is a filter designed for use on a wide variety of Unices. It supports essentially all Ghostscript drivers. It, too, works with various strains of LPD, including stock BSD and LPRng.
- RHS-Printfilters
RHS-Printfilters is a filter system constructed by Red Hat. It shipped beginning, I think, in version 4 of Red Hat Linux, as the backend to the easy-to-use printtool GUI printer configuration tool.
The rhs filter system is built on an ASCII database listing distributed with it. This listing supports many Ghostscript and Uniprint drivers, but not filter-style drivers. The filters constructed also do not support much in the way of user-controllable options at print time.
The printtool places a configuration file named postscript.cfg in the spool directory. Inside this Bourne shell-style file, each setting is a variable. In unusual cases, you can make useful changes directly to the config file which the printtool won't allow; typically this would be the specification of an unusual Ghostscript driver, or a PPD filename for the VA rhs-printfilters version.
VA Linux has made some enhancements to the rhs-printfilters system under contract from HP. With the proper versions, it is possible to select options for Postscript printers under control of Adobe PPD files. I cover this system inSection 8.2.2.
There's one catch to such filters: older version of lpd don't run the if filter for remote printers, while most newer ones do (although often with no arguments). The version of LPD shipped with modern GNU/Linux and FreeBSD distributions does; most commercial Unices that still ship LPD have a version that does not. See the section on network printing later in this document for more information on this. If you only have locally-connected printers, then this won't affect you.
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:
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.
LPR passes the options to LPD as an extended attribute in the LPD control file.
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:
For the option PrintQuality, the possible values are Quick, Normal,Pres, or Image. You might give a command like:*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
% 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:
Other options are detailed in the ppdfilt man page.- 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.
8.2.3. File Permissions
By popular demand, I include below a listing of the permissions on interesting files on my system. There are a number of better ways to do this, ideally using only SGID binaries and not making everything SUID root, but this is how my system came out of the box, and it works for me. (Quite frankly, if your vendor can't even ship a working lpd you're in for a rough ride).
-r-sr-sr-x 1 root lp /usr/bin/lpr* -r-sr-sr-x 1 root lp /usr/bin/lprm* -rwxr--r-- 1 root root /usr/sbin/lpd* -r-xr-sr-x 1 root lp /usr/sbin/lpc* drwxrwxr-x 4 root lp /var/spool/lpd/ drwxr-xr-x 2 root lp /var/spool/lpd/lp/ |
Lpd must currently be run as root so that it can bind to the low-numbered lp service port. It should probably become UID lp.lp or something after binding, but I don't think it does. This is simply one more reason to avoid the stock BSD LPD.
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.