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.
By default, a BSD LPD system doesn't accept print jobs that don't originate on the local computer ”that 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, Listing 9.1 shows a completely functional /etc/hosts.lpd file. In the case of gingko , the server's own domain name is 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
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 read ”every 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:
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 specifications ”but 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.