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

WARNING

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

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