|
 |
|
| |
8.3. Large Installations
8.3. Large Installations
Large installations, by which I mean networks including more than
two printers or hosts, have special needs. Below are some tips.
CUPS has some nice features that make a good choice for a large network. Printer classes, access control and automatic client configuration to name a few.
If you use LPD, for really large environments, merely distributing printcap/filter
information becomes a difficult problem; the Cisco Enterprise Print
System addresses this and is probably either a good starting
point or a nearly complete solution, depending on your needs.
Medium to large environments can be well supported by native LPRng
features.
-
Each printer should have a single point of control, where an
administrator can pause, reorder, or redirect the queue. To
implement this, have everyone printing to a local server,
which will then queue jobs and direct them to the proper
printer. For large campuses or distributed networks, have one
server per building or other suitable network subset.
-
Use CUPS or LPRng, at least on servers; the BSD LPD is too buggy for
"real" use. But don't take my word for it—you should test a number of
spoolers and see which suits you best.
-
Client systems should not have unique printing configurations. CUPS provides automatic client configuration of printers on the same subnet. You can even configure CUPS (BrowsePoll) to poll servers on other subnets for available printers. These features limit the amount of configuration that needs to take place at the client.
To implement a uniform printing configuration with LPRng, use LPRng's extended printcap syntax so
that you have one printcap to use everywhere. CEPS provides
for this by building atop a lightweight distributed database
instead of traditional printcap files.
-
Print queues should not be named for make or model; name print
queues for something sensible like location (floor2_nw)
or capability (color_transparency). Three years from
now, when a printer breaks, you will be able to replace it
with a different make or model without causing confusion.
-
Operate a web page which shows detailed information on each
printer, including location, capabilities, etc. Consider
having it show the queue and include a button to remove jobs
from the queue. Complex networked environments are
unmanageable for users without proper documentation.
-
On Windows and Apple systems, use either the platform-specific
drivers everywhere (Samba supports the
Windows automagical driver-download mechanism) or, better, use
generic Postscript drivers everywhere. Do
not mix and match; primitive word processors often produce
different output when the installed printer driver changes;
users cannot deal with output that varies depending on the
particular client/printer pair.
-
If at all possible, buy a large-volume printer for
large-volume printing. If on a budget, use LPRng's multiple
printers/one queue facility or CUPS printer classes and assign a babysitter; printers
are complex mechanical devices that will often jam and run out
of paper in such configurations.
-
Do not feel that printers must be plugged into workstations;
Ethernet "print servers" now cost under $100. The ability to
locate printers anywhere you can network is a big improvement
over forced location near a host; locate printers in sensible,
central locations.
-
Use any SNMP trap or other monitoring/alert facility available
to you - someone should be tasked with running around and
fixing printers with no ink or paper. Npadmin (see Section 11.10.1) can be used to do some management
operations with SNMP printers.
|
|
|
