Remote printing allows different computers to share printers. To use remote printing facilities, the computers must be connected via the Transmission Control Protocol/Internet Protocol (TCP/IP) protocol and must support the required TCP/IP applications, such as the lpd daemon.
A remote print request is queued in the same manner as a local print request:
The following sections discuss how to configure, use and manage a remote printing environment:
The local queue set up to serve remote print requests must be configured to use rembak, the remote print backend command. When you set up the queue, the system prompts for a backend program path name. The entry at this prompt tells the qdaemon command which backend program to use to process print requests. To set up a queue to handle remote print requests, type /usr/lpd/rembak.
The rembak command also processes status requests, job cancel requests, and requests to kill a remote queuing system. Status requests such as qchk -A or lpstat query the status of local print queues and devices by analyzing the qconfig file and the local print spooling subsystem status files.
In a remote print environment, the qchk -A and lpstat commands use the rembak program to request queue status information from the print servers. The output of a queue status command shows two entries for each remote queue. The first entry is the status of the local queue to which remote jobs are sent. The second entry shows the status of the queue on the remote print server where the jobs are printed. In the following example, the queue name rq was used for both the queue on the local system and the queue on the remote print server:
Queue Dev Status Job Files User PP % Blks Cp ----- --- ------ --- --------------- ---------- --- -- ---- -- Iago Iago RUNNING 284 mileaf ann@arctur 15 13 1 1 Pro asc READY bsh bshde READY ps ps READY rq rqd READY rq ps1 RUNNING 297 .deskprint/dsktop sarah@alde 60 22 1 1 QUEUED 298 .deskprint/howtol sarah@alde 60 1 2
As the preceding example shows, any print jobs currently running or queued show up in the remote print server entry for the queue.
The rembak program also sends requests to cancel print jobs to the remote print servers. Each print job is assigned a number. As shown in the previous example, print queue status requests display the job numbers for currently queued or running print requests. To cancel a job on a remote queue, use the same commands used to cancel local print jobs. For example, to cancel job 298 from the queue rq, you can use Web-based System Manager (type wsm and then select Printers), or one of the following commands:
qcan -Prq -x298
lprm -Prq 298
Although local and remote print jobs are submitted with the same commands, they are processed differently. Once a print job has been transmitted to a remote host, it is no longer managed by the local print spooling subsystem.
The lpd daemon is part of the TCP/IP system group. Any host on a TCP/IP network can run the lpd daemon, and any host can send print requests to any other host on the network (if the host is currently running lpd). As a security measure, the lpd daemon forks a child process that checks each remote print request against two database files: the /etc/hosts.equiv file and the /etc/hosts.lpd file. If the name of the host submitting the print request is not in the /etc/hosts.lpd file, the print request is rejected.
Note: The /etc/hosts.equiv file defines which computers on a network are allowed to execute certain commands on a local host without supplying a password. The /etc/hosts.lpd file defines which computers on a network are allowed to execute print commands on a local host without supplying a password.
The lpd daemon on the remote print server monitors port 515 for print requests. When the lpd daemon receives a print request from a valid host, it places the request in the specified queue. The lpd daemon places files specified in print requests in the directory /var/spool/lpd. The print request is then managed by the qdaemon and the appropriate backend (usually piobe) on the remote server.
The /etc/locks/lpd file contains the process ID of the currently running instance of the lpd daemon. If a machine running the lpd daemon becomes inoperable, the ID for the lpd daemon may have to be removed before the system is restarted. The error messages lpd: lock file or duplicate daemon indicate that the ID must be removed.
Controlling the lpd daemon includes starting and stopping the lpd subsystem and changing the characteristics of the lpd subsystem. You can use Web-based System Manager (type wsm and then select Printers), or use the SMIT or System Resource Controller (SRC) commands to control the lpd daemon.
There are three ways to start the lpd daemon. If it is not currently running, you can start the daemon at any time. You also have the option of having the lpd daemon start at system restart or to have it start both at the current time and at system restart. The same options are available to stop the lpd daemon: stop now, stop at system restart, or stop both now and at system restart. You can run the lpd daemon with DEBUG, with SYSLOG, with both DEBUG and SYSLOG, or with neither.
To control the lpd daemon with Web-based System Manager, type
wsm and select Printers, then select the desired options
from the Printer Queues window menus. To control the lpd
daemon with SMIT,type smit lpd, then select the desired options
from the SMIT menus. To control the lpd daemon with the SRC,
use the following SRC commands:
|startsrc||Starts a subsystem, group of subsystems, or a subserver.|
|stopsrc||Stops a subsystem, group of subsystems, or a subserver.|
|lssrc||Gets the status of a subsystem, group of subsystems, or a subserver.|
|refresh||Causes the subsystem or group of subsystems to reread the appropriate configuration file.|
|traceson||Enables tracing of a subsystem, group of subsystems, or a subserver.|
|tracesoff||Disables tracing of a subsystem, group of subsystems, or a subserver.|