Redundant Printer Configuration


As laser printers become smaller and cheaper, many sites are installing multiple conveniently located slow printers rather than one or two central fast printers. With an increase in numbers of printers and hosts supporting printers comes an increase in failures. This paper describes a naming and /etc/printcap convention for BSD-based spooling systems that makes it simple to relocate printers and redirect print jobs when failures or changes occur. As a side benefit, it makes /etc/printcap files and queues easier to manage.


As the price of laser printers drops towards $1,000.00, many sites are buying a large number of cheap printers. This has many advantages: it lets printers be located conveniently, it provides redundant hardware on a network, etc, etc. Since these printers are usually located in areas close to those doing the printing, they are often attached to individual workstations or other small hosts.

When a printer or its supporting host fails, it is difficult to reconfigure the printers and network. The /etc/printcap files on all systems must usually be modified, and all affected queues halted and restarted. Even with automated tools this is a cumbersome and error-prone task.

We have developed some simple conventions which greatly ease the task of printer queue management. This technique works on all BSD-based spooling systems we have encountered (BSD, Ultrix, Gould/Encore, Sun) and may be useful in System V environments as well. The technique requires an easy way of modifying the host name database quickly, but may be useful even if such a feature is lacking.

The Conventions

The first requirement is to decouple the host name for the printer from any actual host name. Instead, host aliases and/or CNAME records should be installed so that every printer name (lw1, lw2, etc) is assigned a unique host name (lw1_host, lw2_host, etc).

Now a standard /etc/printcap file is created and distributed to all systems on the network. The file contains two entries for each printer, one defining a remote queue, and defining a local printer.

Remote entries for each printer should appear first. Each remote entry should point to a queue of the same name. The remote host alias should be used, not the true host name.

Local entries for each printer should follow the remote entries. The local entries should be commented out. (Note that in some versions of the BSD printer system it is not necessary to comment out extra entries with the same name; any entry after the first is ignored.)

On all hosts which actually have printers attached, the remote entries for those printers should be commented out and the matching local entries uncommented.

A simplified /etc/printcap example is shown below. We assume only two printers.

# # Standard Printcap File. # # Remote printers # lw1|LaserWriter 1|:\\ :lp=:rm=lw1_host:rp=lw1:\\ :sd=/usr/spool/lp/lw1:\\ :lf=/usr/spool/lp/lw1/log:sh: lw2|LaserWriter 2|:\\ :lp=:rm=lw2_host:rp=lw2:\\ :sd=/usr/spool/lp/lw2:\\ :lf=/usr/spool/lp/lw2/log:sh: # # Local printers # #lw1|LaserWriter 1|:\\ # :sd=/var/spool/lp/lw1:\\ # :px#2400:py#2400:\\ # ...etc... #lw2|LaserWriter 2|:\\ # :sd=/var/spool/lp/lw2:\\ # ...etc...

Basic Usage

Up to three actions are required when moving/repairing a printer. The hosts database must be modified to reflect the new or fill-in host for a given printer; the /etc/printcap on the old printer host may need to be modified; and the /etc/printcap on the new printer host will need to be modified.

Moving A Printer

When a printer moves from one host to another, the admin first stops and disables the queues on the old and new hosts. The host database should then be modified as needed, moving the alias or CNAME from the old printer host to the new.

On the host where the printer used to be attached, the admin comments out the local entry for the printer and uncomments the remote entry. On the host where the printer is now attached, the admin uncomments the local entry for the printer and comments out the remote entry.

The queues are then restarted and reenabled on both systems. No actions need to be taken on any other systems.

Redirecting From A Dead Printer

If a printer is out of service for a short time, one can redirect jobs by modifying only /etc/printcap on the host which originally was home for the printer. If we assume lw1 is down, the /etc/printcap entry for lw1 on lw1_home should be modified from the first form to the second:

lw1|LaserWriter 1|:\\ :lp=:rm=lw1_host:rp=lw1:\\ :sd=/usr/spool/lp/lw1:\\ :lf=/usr/spool/lp/lw1/log:sh:
lw1|LaserWriter 1|:\\ :lp=:rm=lw2_host:rp=lw2:\\ :sd=/usr/spool/lp/lw1:\\ :lf=/usr/spool/lp/lw1/log:sh:
Note that only the remote host name and remote queue name are modified. All jobs intended for lw1 will still route to lw1_host, but will then be forwarded by it to lw2_host for the lw2 printer.

This is an increase in network overhead, as each job intended for lw1 is handled twice, first by lw1_host, and then by lw2_host. For short term outages, this is an acceptable overhead.

Recovering Queued Jobs

Once the queue has been redirected, simply halting and restarting the queue on the old lw1_host will cause all pending jobs for lw1 to be redirected to lw2.

Queue Management

One unexpected benefit of this system was that for many tasks the admins no longer needed to know the host name of the host supporting the printer. Simply using the alias for rsh, rlogin or ping served just as well. Most queue status changes could be handled by rsh lwX_host lpc < action >.

Determining which host actually represented the printer was a simple as a grep of the /etc/hosts or using nslookup or ypmatch.

Some Cautionary Notes

As in any system, there can be abuse. Do not let yourself fall into the trap of chaining jobs from one print queue to another to another. This will eventually cause a problem, and you'll forget where all the changes were made.

Beware of circular references. Some spooler systems will merrily let you do

lw1|LaserWriter 1|:\\ :lp=:rm=lw1_host:rp=lw1:\\ :sd=/usr/spool/lp/lw1:\\ :lf=/usr/spool/lp/lw1/log:sh:
on lw1_host, resulting in lots of CPU usage and very little printing.

Future Work

This same method should be quite useful in other circumstances. In complex networks where static routing is desired host aliases such as net1_gateway and default_route would greatly ease network changes. Host names like news_host and yp_master have obvious utility.


We have used this facility at several installations where there were multiple printers of the same types spread across a number of hosts. It has both made administration easier and things more convenient for the users.

About the Author

At the time this was written, Steve Simmons was the System Support Manager at the Industrial Technology Institute and a consultant on system and network administration. He received his bachelors degree from the University of Michigan in 1980.

Back to Steve's home page.
Contact, License and Copy Issues.