Distros SysAdmin Mobile Software Datacenter HPC Development LMTV
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. By AEleen Frisch Saturday, December 15th, 2001 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. feedback mail to a friend printer-friendly version        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 hp: :lp=/dev/lp0 :cm=HP Laser Jet printer :lf=/var/log/lpd.log :filter=/usr/local/lib/filters/ifhp :tc=.common laser: :lp=painters@matisse :tc=.common # Named group of items .common: :sd=/var/spool/lpd/%P :mx=0 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. feedback mail to a friend printer-friendly version << 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:

laser:

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

   :lp=/dev/lp0

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 10.0.0.4; for 10.0.0.4 itself, the printer points to the first parallel port:

color

   :oh=10.0.0.0/24,!10.0.0.4

   :lp=%P@10.0.0.4

   :tc=.common

color:

   :oh=10.0.0.4

   :lp=/dev/lp0

   …

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:

blots:server

   :sd=/var/spool/lpd/%P

   :filter=/usr/local/lib/filters/blotter

   :bq_format=l

   :bq=picasso@painters

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:

scribes:server

   :sd=/var/spool/lpd/%P

   :sv=lp1,lp2,lp3

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:

lp1:

   :sd=/var/spool/lpd/%P

   :ss=scribes

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.

smart:

   :sd=/var/spool/lpd/%P

   :destinations=matisse@printers,degas@france,laser

   :router=/usr/local/sbin/pick_printer 

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.

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:

ACCEPT SERVICE=M SAMEUSER

ACCEPT SERVICE=M SERVER REMOTEUSER=root

REJECT SERVICE=M

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:

• USER, GROUP, HOST, PRINTER: These items are compared to the ownership and other characteristics of the print job to which the desired command will be applied. In addition, the SERVER keyword requires the command to be executed on the local server.
• REMOTEUSER, REMOTEGROUP, REMOTEHOST: These items are compared to the user, group, and host from which the desired command originated. Note that the “remote” part of the name can be misleading, as it need not refer to a remote user or host at all. The preceding keywords all take a string or list of strings as their arguments. These items are interpreted as patterns, which are to be compared to the print job or command characteristics.
• SAMEUSER, SAMEHOST: These require that USER be the same as REMOTEUSER and HOST be the same as REMOTEHOST. For example, the following entry limits use of the lprm command to a user’s own job and requires the command to be run on the same host from which the print job was submitted:

ACCEPT SERVICE=M SAMEUSER SAMEHOST

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.

REJECT SERVICE=X NOT REMOTEHOST=*.ahania.com

REJECT SERVICE=X REMOTEHOST=dalton,hamlet

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.

ACCEPT SERVICE=C SERVER REMOTEGROUP=padmin

REJECT SERVICE=C

 ACCEPT SERVICE=C SERVER REMOTEGROUP=printop LPC=topq,hold,release

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:

ACCEPT SERVICE=R,M,C REMOTEUSER=chavez PRINTER=test

REJECT SERVICE=* PRINTER=test

REJECT SERVICE=R,C,M FORWARD

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.

DEFAULT ACCEPT

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.

Comments are closed.