Managing Printing with LPRng

Despite years of hype about the coming paperless office, printing has actually become more frequent and more complex as time has passed, not less so. Ordinary users now routinely print tens or even hundreds of pages a week, a significant fraction of which is high-end, photo-quality graphics.

Despite years of hype about the coming paperless office, printing has actually become more frequent and more complex as time has passed, not less so. Ordinary users now routinely print tens or even hundreds of pages a week, a significant fraction of which is high-end, photo-quality graphics.

Traditionally, Linux systems have used the BSD spooling system. However, some recent distributions are now providing the LPRng package as the default printing subsystem instead. LPRng is an enhanced version of the BSD print spooling system (the “ng” stands for “next generation”). It is available for virtually any Unix system.

In this month’s column, we will focus on the enhancements that LPRng provides over the standard BSD printing subsystem. The procedure for installing LPRng using a different spooling system is fairly simple and is well documented in the LPRng-HOWTO, which can be found online at http://www.lprng.com/LPRng-HOWTO/LPRng-HOWTO.html.

Enhancements of Standard Commands

LPRng changes and enhances the functions of many standard BSD printing-related commands. The most important of these (from an administrative point of view) are additional subcommands provided with the lpc administrative utility. We will consider a few of them in some examples.

To begin with, there are subcommands which can be used to hold and release individual print jobs:

# lpc hold picasso 10021

# lpc release picasso

The first command places the specified job in the picasso queue into a hold state, temporarily preventing it from printing. The second command releases all held jobs in the same queue, allowing them to print.

The holdall subcommand will place all jobs entering the picasso queue immediately into the held state:

# lpc holdall picasso

The noholdall subcommand will stop this behavior, though the held jobs will still need to be explicitly released:

# lpc release picasso

The move subcommand will transfer the job from gauguin to picasso:

# lpc move gauguin 10021 picasso

The second parameter of the move command (10021) may also be a username. It’s a nice shortcut for moving all of a user’s print jobs. The following command will cause all of the jobs that are spooled to gauguin to be sent to vangogh instead:

# lpc redirect gauguin vangogh

Specify off as the target queue to turn off redirection:

# lpc redirect gauguin off

You can use the active subcommand to determine whether a specified spool daemon is active and healthy or not. For example, these commands check to see if the daemon controlling the gauguin queue is active and if the one corresponding to the matisse queue on host painters is active:

# lpc active gauguin

# lpc active matisse@painters

Finally, the reread subcommand may be used to force the lpd daemon to reread its configuration files. The subcommand may be followed by a queue name to specify the desired server. The following command is used to force the local daemon to reread its configuration files:

# lpc reread

This operation is equivalent to the traditional killall -HUP lpd daemon reinitialization signal.


       page 1 2 3 4 5   next >>


Linux Magazine /
December 2001 / GURU GUIDANCE
Managing Printing with LPRng

Print Classes and Job Priorities

LPRng implements a very simple print job priority scheme. It is combined with its support for print job classes — print jobs that have a shared set of characteristics and need specific printer support. The most common use for classes is to designate print jobs requiring special paper.

A user can place a job into a specific class when submitting it using the -C option followed by the class name:

$ lpr -Cspecial -Plaser2 January

This job is placed into the class special on printer laser2.

The uppercased first letter of the class name is also used as the in-queue priority for the job. Priorities levels run from A (high) to Z (low). Thus, the preceding job would be assigned a priority level of S (the first letter of the class name special). The default value for jobs not specifying a specific class is class A (and therefore priority level A).

By default, a print queue allows jobs of any class to print, printing them in accord with the priority scheme. To limit printing to a specific class, use a command like:

# lpc class laser special

This will allow only jobs in class special to print; all others will be held. To allow any job to print, use:

# lpc class laser off

Using classes can be a bit tricky. For example, if you alternate between printing checks and regular output on a printer, you probably don’t want to turn off class special after all the checks are printed. Rather, you want check jobs to be held until the proper paper is again in place in the printer. In this case, the following command will be more effective:

# lpc class laser A

This sets the allowed class to class A (the default), so jobs spooled in class special will be held as desired.

Configuring LPRng

Printers and print queues are defined using a modified version of the standard BSD printcap file. Figure One shows two simple entries.

Figure One: Sample printcap Entries

:cm=HP Laser Jet printer


# Named group of items

The first entry is for a local printer named hp on the first parallel port. This printcap entry specifies a description for the printer, the path to its log file, and a filter with which to process jobs. The final field, tc, provides an “include” feature within printcap entries. In this case, the field says to include the settings in the printcap entry called .common within the current entry. Thus, it has the effect of removing any length limits on print jobs to printer hp and of specifying its spool directory as /var/spool/lpd/hp.

The second printcap entry creates a queue for a remote printer, matisse on host painters, which also has no job length limits and uses the spool directory /var/spool/lpd/laser. The last two items are again set using the tc include field.

The LPRng printcap file allows for variable expansion within entries. We saw an example of this in the sd field in the preceding example, where %P corresponded to the printer name.


<< prev   page 1 2 3 4 5   next >>


Linux Magazine /
December 2001 / GURU GUIDANCE
Managing Printing with LPRng

Using a Common printcap File for Many Hosts

One of LPRng’s most powerful features is the ability to construct a central printcap file that can be shared among many hosts. This flexibility comes from the oh (on host) setting. For example:

:oh=*.ahania.com, !astarte.ahania.com

This entry defines a printer named laser on every host in the domain ahania.com except astarte. ahania.com. The printer will always be located on the first parallel port.

The following entry will define a printer named color on every host in the 10.0.0 subnet. For most hosts, the printer points to the color queue on; for itself, the printer points to the first parallel port:



As these examples indicate, hosts can be specified by name or IP address.

Bounce Queues

Generally, queues corresponding to remote printers simply send jobs to the queue on the remote system as is. However, sometimes it is useful to process jobs locally before sending them on to be printed. This is accomplished via a bounce queue, as in this example:


This queue runs jobs through the program blotter, which is specified in the filter setting. It then sends them to queue picasso on host painters for printing.

Printer Pools

LPRng allows you to create a printer pool (a queue that feeds several printing devices), as in this example:


Here, the queue scribes sends jobs to queues lp1, lp2, and lp3 (which must be defined elsewhere in the printcap file), as each queue becomes free. This mechanism provides a simple form of load balancing. Here is part of the printcap entry for lp1:


The ss setting specifies the controlling queue for this printer. Note that it does not prevent jobs from being sent directly to queue lp1; the only effect of this setting seems to be to make queue status listings more readable.

Print job destinations can also be determined on a dynamic basis, as you can see in Listing One.

Listing One: Using a Router Program


The program specified to the router setting is responsible for determining the destination for each print job. The router program is a standard print filter program. Its exit status determines what happens to the job (by convention, 0 means print, 37 means hold, and any other value means delete the job), and it must write the queue destination and other information to standard output (where lpd obtains it). See the LPRng-HOWTO document (the section titled “Dynamic Routing”) for full details.


<< prev   page 1 2 3 4 5   next >>


Linux Magazine /
December 2001 / GURU GUIDANCE
Managing Printing with LPRng

Printer Access Control

The LPRng configuration file lpd.perms is used to control access to the print service and its printers. Each entry in the file provides a set of characteristics against which potential print jobs are matched and indicates whether such jobs may be accepted or not. The first entry that applies to a specific print job will be used to determine its access. Accordingly, the order of entries within the file is important.

The syntax of the lpd.perms file is explained best by examining some samples. For example, these entries allow users to remove their own print jobs and root to remove any print job:


The first keyword in an entry is always ACCEPT or REJECT, indicating whether matching requests are to be performed or not. These entries all apply to the M service, which corresponds to removing jobs with lprm. The various entries allow the command to succeed if the user executing and the user owning the print jobs are the same (SAMEUSER), or if the user executing is root (REMOTEUSER=root) on the local system (SERVER). All other lprm requests are rejected.

Available SERVICE codes include C (control jobs with lpc), R (spool jobs with lpr), M (remove jobs with lprm), Q (get status info with lpq), X (make connection to lpd), and P (general printing). More than one code letter can be specified to SERVICE by separating them with commas.

There are several keywords that are compared against the characteristics of the job and/or the command execution context:



<< prev   page 1 2 3 4 5   next >>


Linux Magazine /
December 2001 / GURU GUIDANCE
Managing Printing with LPRng

We’ll now examine some additional lpd.perms entries. Listing Two rejects all connections to the lpd server that originate outside of the ahania.com domain or from the hosts dalton and hamlet. Note that these entries could not be formulated as ACCEPTs. Hosts may be specified by hostname or by IP address.

Listing Two: Sample lpd.perms Entries — Part I


Listing Three allows only members of the group padmin to use the lpc command on the local host. The LPC keyword can be used to limit the lpc subcommands that can be executed. For example, Listing Four allows members of group printop to hold and release individual print jobs and move them around within a queue.

Listing Three: Sample lpd.perms Entries — Part II


Listing Four: Sample lpd.perms Entries — Part III


Listing Five prevents anyone except user chavez from printing to the printer test. User chavez can also remove jobs from the queue and use lpc to control it. The following command prevents print job forwarding on the local server:

Listing Five: Sample lpd.perms Entries — Part IV



The DEFAULT keyword is used to specify a default action for all requests not matching any other entry:

# Allow everything that is not explicitly forbidden.


The default access permissions in the absence of an lpd. perms file is to accept all requests.

Other LPRng Capabilities

LPRng has more capabilities than we had space to consider; these include more sophisticated user authentication using a variety of systems (including PGP and Kerberos) and a variety of global print spooler settings for communications efficiency and job logging (including to a central logging host). All of them are described in the package’s excellent documentation. For more information about LPRng, consult the project’s home page at http://www.lprng.com/.

Æleen Frisch is the author of Essential System Administration. She can be reached at aefrisch@lorentzian.com.


<< prev   page 1 2 3 4 5       


Linux Magazine /
December 2001 / GURU GUIDANCE
Managing Printing with LPRng

Comments are closed.

 Stick a Fork in Flock: Why it Failed
 CentOS 5.6 Finally Arrives: Is It Suitable for Business Use?
 Rooting a Nook Color: Is it Worth It?
System Administration
 Scripting, Part Two: Looping for Fun and Profit
 Command Line Magic: Scripting, Part One
 Making the Evolutionary Leap from Meerkat to Narwhal
 Extended File Attributes Rock!
 Checksumming Files to Find Bit-Rot
 What's an inode?
 Putting Text to Speech to Work
 Look Who's Talking: Android Edition
 Upgrading Android: A Guided Tour
 A Little (q)bit of Quantum Computing
 Emailing HPC
 Chasing The Number