لطفا منتظر باشید ...
Configuring a BSD LPD
Server
Two files are most important for configuring a BSD LPD server:
/etc/hosts.lpd and /etc/printcap . The first of these controls
which clients may connect to the server for network operation. The second
defines the printers that are available to both local and remote users. Note
that /etc/printcap defines both
local and remote printers, and defines printers that are available both locally
and remotely. Therefore, it's possible for a remote user to submit a print job
to a queue that corresponds to a remote system. When this happens, the print
job comes in over the network and is immediately sent out again. Normally, this
is wasteful of bandwidth, but in some cases it might be desirable, as when the
print server uses Ghostscript to convert a PostScript file into a format that
the ultimate destination printer can understand.
Configuring
/etc/hosts.lpd
By default, a BSD LPD system doesn't accept print jobs that
don't originate on the local computerthat is, the software does not function as a networked print server. Changing
this configuration requires editing a single file: /etc/hosts.lpd . This file contains a list of computers, one
per line, that are allowed to access the local print queues. Computers may be
specified by hostname, by IP address, or by NIS netgroup. In the final case,
the netgroup name is identified by a leading at-sign ( @ ), which in turn must be preceded by a
plus sign ( + ). A plus sign alone
makes the server accept any print job, which is
a potentially major security hole. Preceding a name by a minus sign ( - ) indicates that the host is explicitly disallowed access. For instance,
assumed. The +@group1 line gives
access to all the computers in the NIS netgroup called group1 , but oak.threeroomco.com is denied access, even if
it's part of the group1
netgroup.Although you can place comments in the /etc/hosts.lpd file by beginning a comment
line with a pound sign ( # ), you
should not place comments on lines that also
contain client specifications. Instead, you should place comments on lines that
precede or follow the line you want to explain.
Listing
9.1 A Sample /etc/hosts.lpd File
gingko birch.threeroomco.com 192.168.1.7 +@group1 -oak.threeroomco.com
WARNING
align=left border=0> It's possible to use /etc/hosts.equiv
much as you can use /etc/hosts.lpd .
The /etc/hosts.equiv file,
however, has an effect far beyond that of printing; it provides access to
clients that use rlogin and
other protocols. I strongly recommend against using /etc/hosts.equiv ; you can configure the
servers that it controls individually, giving you much finer-grained control
over access to the computer. You might want to look for this file and, if
it's present, rename it and adjust the configuration of other files as
appropriate.
Specifying the Server on a
BSD LPD Client
The /etc/printcap file
controls the BSD LPD printing system's printer definitions ( printcap stands for printer capabilities ). This file
contains entries for each print queue on the system, whether it's a local queue
(that is, prints to a printer that's connected directly to the computer via a
parallel, RS-232 serial, or USB port), or a network queue (printing to another
LPD printer, or even a printer that uses SMB/CIFS, AppleTalk, or some other
protocol). In theory, each printer definition occupies one line, and options
are separated by colons ( : ). In practice, most /etc/printcap definitions use the
backslash ( \ ) line continuation character to allow a single entry to span
multiple lines, to make it easier to readevery line but the last one ends in a
backslash to indicate that it's continued on the following line.Most details of printer configuration via /etc/printcap are beyond the scope of this book; as noted at the start of this chapter, you
should consult your distribution's documentation or an introductory book on
Linux system administration to learn how to configure printers, including smart
filters, Ghostscript, and most /etc/printcap options. There are a few
options that require comment from the point of view of configuring a network
print client, however. These options are: lp The lp option points the BSD LPD system to the device file to which the
printer is attached. For instance, lp=/dev/lp0 tells the
system to use /dev/lp0 (the first parallel port). If you're configuring an LPD-style
network printer, you should omit this option, or leave it blank (as in lp= ). rm The rm option specifies the name of the LPD-style print server. For
instance, if oak is the print server for a given queue, you'd include the option rm=oak in the
queue's definition. Note that this isn't enough to print to a specific remote
queue; it only identifies the computer on which
the queue resides. You can specify the remote machine as a hostname (with or
without the domain name) or as an IP address. rp The rp option picks up where rm leaves off, specifying the name of the
remote print queue. For instance, if the remote queue is called inkjet on the print server, you'd include rp=inkjet in the client's /etc/printcap . Note that the name of the
remote queue need bear no resemblance to the name of the local queue. For
instance, the server's inkjet
printer might be known on the client as lp1
or canon . Particularly in a
large network, though, you might want to keep the names synchronized to avoid
confusion.In sum, if you have an existing local print queue, you can
convert it into a network print queue by replacing the lp option with an rm option and an rp option. Once this is done, the computer
will send its print job to the computer identified by rm and the queue specified by rp , rather than to the printer attached to
the device indicated by lp . On
the server, the queue will probably include an lp
specification, although it could include rm and rp
specificationsbut in this case, it's usually simpler to specify the ultimate
destination more directly in the ultimate print client. (Exceptions include
cases where you want to offload Ghostscript processing onto an intermediate
system or when network topologies prevent a direct connection between the
client and server, but where an intermediate system can connect to both.) If the print server doesn't accept LPD connections, you'll
need to use a more complex arrangement. For instance, the server might expect
SMB/CIFS or AppleTalk print jobs. In such cases, you'll need to write a script
that processes the print job using whatever tools are appropriate, and call
that script with the if option,
which sets up an input filter. The Samba and Netatalk documentation both
include examples of doing this.
