Lecture 32

Printers and Spooling

Elements of a Spooling System

Any spooling system comprises the following parts:

Commands to initiate printing: The user decides what files to print, which printers to use, and other parameters of the printing process. BSD calls the spooled data jobs, Sys V refers to them as requests.
Queues: FIFO queues used store the print jobs/requests
Spooling directories: Under BSD, the file is copied to a spooling directory. Under System V, a request file is generated and the file is accessed in its original location at the time printing takes place.
Server process(es) (Spooling software): Used to receive jobs, store them, and transfer a job/request from the spooling directories to the appropriate printing device
Administrative commands: Let the administrator start and stop the printing subsystem or specific printers, and manage individual print jobs

Types of Printers

Serial and Parallel printers requires extra configuration of devices. For serial devices, the system needs to know about issues such as baud rate and other options to set the printer port. Only PCs provide parallel ports which are easily confifigured. USB is available on many systems (such as your Netras) but I don't know squat about USB printer configuration.
Network Printers sit directly on your network and accept jobs through one or more ports. This introduces some gaps in administrative control because, without special configuration, any network attached host can communicate with the printer.
In most instances, only a few hosts on your network should control printing (send jobs to the printer). Other machines should transfer jobs to these printers. This simplifies the task of debugging when things go wrong.
Postscript is the language that most Unix printing software prefers. If other types of printers (for example HP PCL printers) are used, it may be necessary to provide some mechanism of converting from postscript to the appropriate page description language (PDL). Ghostscript is a popular free program for doing such conversions.

Internet Printing Protocol

This is a relatively new (born in 1996) attempt to develop an Internet standard for printing that includes core functions for a user to :

find out about a printer's capabilities
submit print jobs to a printer
find out the status of a printer or a print job
cancel a previously submitted job

The Common Unix Print Server (CUPS) is a cross-platform implementation of IPP.

BSD Printing

lpr: Adds a job to the print queue by copying the file into the spool directory. When submitted, a job ID (number) is associated with the file to be printed and is reported to the user, for future reference.
lpq: Lists jobs that reside in the print queues
lprm: Removes a job or jobs from print queues. Users can typically remove only those jobs they have spooled. Only root can delete someone else's job from a print queue.
lpd: The printer daemon. It sends data from the spool directories to the actual printer devices.
lpc: The printer control program. It allows root to enable and disable spooling, remove jobs from a queue, change the order of jobs in the queue, view printer status information, and start or stop the lpd process.
/etc/printcap: The printer configuration file. It contains entries describing the salient parameters of each printer device available to the system, whether local or remote.

Printcap file entries

The printcap file is like unto the termcap file in that it describes capabilities of a device as a collection of colon separated variable=value pairs. Here are a couple of sample entries (from Frisch):

lp|line printer:\
  :sd=/var/spool/lp:if=/usr/lib/lpf:lf=/var/adm/llpd-errs:\
  :lo=lp0LOCK:lp=/dev/lp:pl=66:pw=132:af=/var/adm/lpacct

ps|3rd Floor Laser Printer:\
  :sd=/var/spool/ps:br#9600:rw:sh:lo=lock:mx1000000:\
  :af=/var/adm/ps_acct/lp3:lf=/var/spool/ps/log:\
  :lp=/dev/ps:cf=/usr/lib/pscif:df=/usr/lib/psdvi:\
  :gf=/usr/lib/psgraph:if=/usr/lib/pspf:\
  :nf=/usr/lib/ips:rf=/usr/lib/psfort:\
  :tr=/usr/lib/pscat:vf=/usr/lib/ps:

Variables:

af: Account file path
br: baud rate
lf: Error log file path
lo: Lock file name
lp: Printer device file
mx: Max file size (0=unlimited)
pl: Page length (in lines)
sd: Spool directory
sh: Suppress headers/banners page
sb: Use a short (one-line) header/banner
df, gf, if, nf, rf, tf, vf: Filters (programs) to convert input from Tek dvi format, plot format, any arbitrary format, ditroff, fortran text format, troff format, and versatek format plot files

Each printer will have its own spool directory in /var/spool. The spool directories are owned by the daemon user and the group daemon with permissions 755. This forces users to employ lpr to insert files into the directory for printing. The spooling daemon lpd normally resides in /usr/lib.

System V Printing

System V printer control software is widely regarded as a piece of junk. It rated low marks after its introduction and has never been heralded as an icon of progress since that time.

One benefit of SysV printing is the use of printer classes. A user can queue a job to a printer class which is supported by a number of different devices. The specific device to receive the job can be dynamically determined to achieve a reasonable system load. This is primarily useful in settings where operators manage a number of similar print devices. You don't generally want the user to have no idea of the final destination of output.

SysV printing provides the following user commands:

lp: initiate print requests
cancel: remove a request
lpstat: list contents of a queue

The spooling daemon on SysV is lpsched. It can be administered with the following commands:

accept: Start accepting requests for a given printer.
reject: Stop accepting requests for a given printer.
enable: Allow jobs from the queue to be sent to the printer.
disable: Stop allowing jobs from the queue to be sent to the printer.
lpadmin: Configure the printing environment (lots of options).
lpmove: Transfer a job from one printer to another (usually a bad idea unless requested by the user).
lpshut: Turn off the lpsched daemon.

SysV uses the /etc/printers.conf file to serve the same much the same purpose as the printcap file of BSD.

LPRng (LPR: the Next Generation)

LPRng is maintained by Patrick Powell at http://www.lprng.com/. It is a complete printing system that provides all the common BSD printing commands and the most important SysV commands (i.e. those employed by users).

LPRng offers several security benefits. It eliminates the BSD requirement that the system run as root. This is a significant benefit since the lpr client and the lpd filters are potential security holes when executed as root. LPRng stops the effect of any compromise of the printing system to the printing system alone. LPRng supports Kerberos 5, SSL, and PGP authentication for host authentication.

Finally, LPRng provides some of the beneficial queue management features that are provided by SysV.

The AIX Queueing Facility

The IBM System designers developed an alternate approach to printing. Their model is to provide a more general queueing system that has specific support for printing.

AIX supports the BSD and System V user print commands lp, cancel, lpstat, lpr lpq, and lprm.

AIX monitors the queues with the qdaemon server. This server handles the queueing and send jobs to the backend program. For printing this is /usr/lpd/piobe, however, any program can be used for processing jobs in any given queue.

The file /etc/qconfig has an entries for queu names and queue devices. The general form of the file is

queue-name:
  device = qdev1[,qdev2 ...]
  attribute1 = value1
  ...

qdev1:
  backend = program_path
  attribute = value

  ...

Here's a sample

lp0:
  device = dlp0

dlp0:
  backend = /usr/lpd/piobe

laser:
  device = dlas1,dlas2
  acctfile = /var/adm/qacct

dlas1:
  backend = /usr/lpd/piobe

dlas2:
  backend = /usr/lpd/piobe

The queue attributes are the following:

acctfile
discipline, selected from fcfs (first come, first server) or sjn (shortest job next)
up

The queue device attributes include these:

backend
align (tells whether to send a formfeed before starting a job
header chosen from never, always, group.
trailer
file (if FALSE the file is linked. if TRUE, the file is copied.)

/etc/qconfig can be editied with a text editor, but usually one uses smit or

mkque, mkquedev, chque, chquedev,
rmquedev

, or rmque to create, delete, and change queue and queue device configurations.

Although support for BSD and SysV interface programs is available, the native programs for AIX is enq (for enqueue). It can be called with lots of different parameter combinations to do just about everything you want to do. The simplest way to call it is

enq -P queuename filename

To use the AIX queueing system as a batch service, one merely needs to add an appropriate queue and queue device:

batch:
  device = batdev
  discipline = fcfs

batdev:
  device = /bin/sh

This simple model must dealing with several issues:

It assumes that the user has enqueued a shell script. This may not always be appropriate.
It is not clear what happens with the uid of the process. For print jobs, the process should run suid to a user who has access to the printer. But for batch jobs, the process should run suid to the user who submitted the job.