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 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.
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.
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.
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:
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.
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.
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.
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
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.