This section gives information on restricting printer usage. The LPD system lets you control who can access a printer, both locally or remotely, whether they can print multiple copies, how large their jobs can be, and how large the printer queues can get.
The LPD system makes it easy for users to print multiple
copies of a file. Users can print jobs with lpr -#5
(for example) and get five copies of each file in the job.
Whether this is a good thing is up to you.
If you feel multiple copies cause unnecessary wear and
tear on your printers, you can disable the -# option
to lpr by adding the sc capability to the
/etc/printcap file. When users submit jobs
with the -# option, they'll see
lpr: multiple copies are not allowed
Note that if you've set up access to a printer remotely
(see section
Printers Installed on Remote Hosts
), you need the
sc capability on the remote /etc/printcap
files as well, or else users will still be able to submit
multiple-copy jobs by using another host.
Here's an example. This is the /etc/printcap
file for the host rose. The printer rattan is quite
hearty, so we'll allow multiple copies, but the laser
printer bamboo's a bit more delicate, so we'll
disable multiple copies by adding the sc capability:
# # /etc/printcap for host rose - restrict multiple copies on bamboo # rattan|line|diablo|lp|Diablo 630 Line Printer:\ :sh:sd=/var/spool/lpd/rattan:\ :lp=/dev/lpt0:\ :if=/usr/local/libexec/if-simple: bamboo|ps|PS|S|panasonic|Panasonic KX-P4455 PostScript v51.4:\ :sh:sd=/var/spool/lpd/bamboo:sc:\ :lp=/dev/ttyd5:fs#0x82000e1:xs#0x820:rw:\ :if=/usr/local/libexec/psif:\ :df=/usr/local/libexec/psdf:
sc capability on the
host orchid's /etc/printcap (and while we're at
it, let's disable multiple copies for the printer
teak):
# # /etc/printcap for host orchid - no multiple copies for local # printer teak or remote printer bamboo teak|hp|laserjet|Hewlett Packard LaserJet 3Si:\ :lp=/dev/lpt0:sd=/var/spool/lpd/teak:mx#0:sc:\ :if=/usr/local/libexec/ifhp:\ :vf=/usr/local/libexec/vfhp:\ :of=/usr/local/libexec/ofhp: rattan|line|diablo|lp|Diablo 630 Line Printer:\ :lp=:rm=rose:rp=rattan:sd=/var/spool/lpd/rattan: bamboo|ps|PS|S|panasonic|Panasonic KX-P4455 PostScript v51.4:\ :lp=:rm=rose:rp=bamboo:sd=/var/spool/lpd/bamboo:sc:
sc capability, we prevent the use of
lpr -#, but that still doesn't prevent users from
running lpr multiple times, or from submitting the
same file mutliple times in one job like this:
lpr forsale.sign forsale.sign forsale.sign forsale.sign forsale.sign
You can control who can print to what printers by using
the UNIX group mechanism and the rg capability in
/etc/printcap. Just place the users you want to
have access to a printer in a certain group, and then name
that group in the rg capability.
Users outside the group (including root) will be greeted with
lpr: Not a member of the restricted group
As with the sc (suppress multiple copies) capability,
you need to specify rg on remote hosts that also have
access to your printers, if you feel it's appropriate (see
section
Printers Installed on Remote Hosts
).
For example, we'll let anyone access the printer
rattan, but only those in group artists can use
bamboo. Here's the familiar /etc/printcap
for host rose:
# # /etc/printcap for host rose - restricted group for bamboo # rattan|line|diablo|lp|Diablo 630 Line Printer:\ :sh:sd=/var/spool/lpd/rattan:\ :lp=/dev/lpt0:\ :if=/usr/local/libexec/if-simple: bamboo|ps|PS|S|panasonic|Panasonic KX-P4455 PostScript v51.4:\ :sh:sd=/var/spool/lpd/bamboo:sc:rg=artists:\ :lp=/dev/ttyd5:fs#0x82000e1:xs#0x820:rw:\ :if=/usr/local/libexec/psif:\ :df=/usr/local/libexec/psdf:
/etc/printcap file
(for the host orchid) alone. Of course, anyone on orchid
can print to bamboo. It might be the case that we
only allow certain logins on orchid anyway, and want them
to have access to the printer. Or not.
Note: there can be only one restricted group per printer.
If you have many users accessing the printers, you probably need to put an upper limit on the sizes of the files users can submit to print. After all, there's only so much free space on the filesystem that houses the spooling directories, and you also need to make sure there's room for the jobs of other users.
LPD enables you to limit the maximum byte size a file in a
job can be with the mx capability. The units are in
BUFSIZ blocks, which are 1024 bytes. If you put a zero
for this capability, there'll be no limit on file size.
Note that the limit applies to files in a job, and
not the total job size.
LPD won't refuse a file that's larger than the limit you place on a printer. Instead, it'll queue as much of the file up to the limit, which will then get printed. The rest will be discarded. Whether this is correct behavior is up for debate.
Let's add limits to our example printers rattan and
bamboo. Since those artists' PostScript files tend
to be large, we'll limit them to five megabytes. We'll
put no limit on the plain text line printer:
# # /etc/printcap for host rose # # # No limit on job size: # rattan|line|diablo|lp|Diablo 630 Line Printer:\ :sh:sd=/var/spool/lpd/rattan:\ :lp=/dev/lpt0:\ :if=/usr/local/libexec/if-simple: # # Limit of five megabytes: # bamboo|ps|PS|S|panasonic|Panasonic KX-P4455 PostScript v51.4:\ :sh:sd=/var/spool/lpd/bamboo:sc:rg=artists:mx#5000:\ :lp=/dev/ttyd5:fs#0x82000e1:xs#0x820:rw:\ :if=/usr/local/libexec/psif:\ :df=/usr/local/libexec/psdf:
mx capability in the remote /etc/printcap
files as well. See section
Printers Installed on Remote Hosts
for
more information on remote printing.
There's another specialized way to limit job sizes from remote printers; see section Restricting Jobs from Remote Printers .
The LPD spooling system provides several ways to restrict print jobs submitted from remote hosts:
You can control from which remote hosts a local LPD
accepts requests with the files
/etc/hosts.equiv and /etc/hosts.lpd.
LPD checks to see if an incoming request is from a
host listed in either one of these files. If not, LPD
refuses the request.
The format of these files is simple: one host name per
line. Note that the file /etc/hosts.equiv is
also used by the ruserok(3) protocol, and affects
programs like rsh and rcp, so be careful.
For example, here's the /etc/hosts.lpd file
on the host rose:
orchid violet madrigal.fishbaum.de
You can control how much free space there needs to
remain on the filesystem where a spooling directory
resides. Make a file called minfree in the
spooling directory for the local printer. Insert in
that file a number representing how many disk blocks
(512 bytes) of free space there has to be for a remote
job to be accepted.
This lets you insure that remote users won't fill your
filesystem. You can also use it to give a certain
priority to local users: they'll be able to queue jobs
long after the free disk space has fallen below the
amount specified in the minfree file.
For example, let's add a minfree file for the
printer bamboo. We examine
/etc/printcap to find the spooling directory
for this printer; here's bamboo's entry:
bamboo|ps|PS|S|panasonic|Panasonic KX-P4455 PostScript v51.4:\
:sh:sd=/var/spool/lpd/bamboo:sc:rg=artists:mx#5000:\
:lp=/dev/ttyd5:fs#0x82000e1:xs#0x820:rw:mx#5000:\
:if=/usr/local/libexec/psif:\
:df=/usr/local/libexec/psdf:
sd
capability. We'll make three megabytes (which is 6144
disk blocks) the amount of free disk space that must
exist on the filesystem for LPD to accept remote jobs:
echo 6144 > /var/spool/lpd/bamboo/minfree
You can control which remote users can print to local
printers by specifying the rs capability in
/etc/printcap. When rs appears in the
entry for a locally-attached printer, LPD will accept
jobs from remote hosts if the user submitting the
job also has an account of the same login name on the
local host. Otherwise, LPD refuses the job.
This capability is particularly useful in an
environment where there are (for example) different
departments sharing a network, and some users
transcend departmental boundaries. By giving them
accounts on your systems, they can use your printers
from their own departmental systems. If you'd rather
allow them to use only your printers and not your
compute resources, you can give them ``token''
accounts, with no home directory and a useless shell
like /usr/bin/false.