• Keine Ergebnisse gefunden

How Does It Work?

Im Dokument apollo BSD (Seite 195-199)

Protection of Files and Directories

Chapter 6 Line Printer Management

6.1 How Does It Work?

Normally, only one node per Domain network will run the line printer daemon, /usr/libllpd. That node will usually start the daemon at boot time, by means of the /etc/rc file. When lusr/lib/lpd is started, the daemon goes through the printcap file and restarts any printers that have jobs in their queues. Then lpd listens for print requests from: nodes on your Domain network, nodes on another Domain network to which you're connected, and/or foreign hosts that are connected to your network.

When you submit a print request using the lpr command, lpd creates a copy of itself to process the request. (The original lpd process continues to listen for requests.) The lpr command places the actual material to be printed in the appropriate spool directory (/usrispoolllpd/*), and the copy of lpd then schedules the job's printing. If the printer you specified in the lp command line is unavailable for some reason, or if the machine to which it is connected is not operating, the request will remain in the spooling directory (or 'queue') until it is removed with the lprm command, or until the faulty printer or machine becomes available.

The file /etc/printcap is a database that describes the printers that are available to machines using the Jp commands. The manual entry printcap(5) defines the format of this data base, as well as default values for important items like the directory in which spooling is performed.

NOTE: At SR10, letc/printcap is a per-node file. To use BSD print spooling, you should make sure that everyone has the same printcap file. We suggest that you have one printcap file that

specifies all the printers (fer example,

/usr/spooJ/Jpd/etc.printcap), and link all user printcap files to the common printcap file.

The Apollo version of the printcap file can have one additional entry. which is explained more fully in the BSD Command Reference. The additional entry is pc, which provides an interface to print commands you can use instead of sending output to Jp or rp. In BSD, this is set to use the prf command sequence. If you want to communicate directly with the printer, set the Jp field (device name) to the actual device name, and set the if field

(input filter) to a filter appropriate for your application (for example, lusr/libllpf).

6-2 Line Printer Management

6.1.1 Prerequisites for BSD

From what we've said above, we can see that the lp system must have an lpd process running, and an entry in letc/printcap for the printer to which requests will be sent. We'll assume that the necessary Ip commands, like Ipc and Ipr, have been installed in the correct places on the system.

On Domain/OS, communication between a client (Ipr, lpc, etc.) and the server (lpd) is accomplished by using the Network Compuing System (NCS). As a result, a local location broker (letclllbd) must be running on the node providing the line printer daemon. To make sure an IIbd is running, create the file letc/daemons/llbd before rebooting.

To set up Ipd to run at boot time, uncomment (remove the # from the beginning of) the three lines in the letc/rc file that read:

# if [ -f jusrjlibjlpd ]; then

# jusrjlibjlpd

&

# fi

(Remember that the letc/daemons directory must contain an empty file named Ipd for the server to run.)

Shut down the node and restart it. The BSD implementation of Ipd includes an optional file lusrispoolllpd/servername that can be used if you want only one machine on your Domain network to run Ipd. If the file exists, it must contain the TCP host name of the one machine on the network that is allowed to run Ipd. If you attempt to start an Ipd process on a machine other than the one specified in lusrispool/lpd/servername, lpd will return an error message that specifies the name of the only machine that is allowed to run Ipd. If the file does not exist, any number of machines on the network can run lpd, but only one should run it at a time.

The letc/printcap file, as installed, contains several default descriptions for printer types.

You may need to create an entry for another printer type. In this case, use the discussion of printcap later in this document, as well as the BSD Command Reference manual pages for printcap(5) and termcap(5}, as your guide. Be certain not to leave a blank line between entries in the letc/printcap file, as this will cause the Ip system to think that there is a valid printer on the system with no name, and it may attempt to send requests there.

The letc/hosts.equiv file is a list of machine names. In general, this file allows all the machines named in it to be treated as equivalent; for example, if your machine name is in this file, you can rlogin to any other machine named in the file, without going through the normal user and password authorization procedures. In order to use the line printer system on your network, a machine must have its TCP/IP host name in this file. There should be only one letc/hosts.equiv file per network. (See Configuring and Managing TCPIIP for information on configuring TCP/IP correctly.

6.2 Commands

All of these commands, their options, and any arguments are explained fully on the BSD Command Reference.

6.2.1 Line Printer Daemon: Ipd

The program Ipd(8), usually invoked at boot time from the letc/rc file, acts as a master server for coordinating and controlling the spooling queues configured in the letc/printcap file. When Ipd is started, it makes a single pass through the letc/printcap database, restarting any printers which have jobs. In normal operation, Ipd listens for service requests from other Apollo modes by implementing an NCS remote procedure call interface.

Requests from foreign machines are handled on an Internet socket (under the "printer"

service specification) for requests for printer access; see socket(2) and services(5) for more information on sockets and service specifications, respectively.

To provide service to foreign machines, a TCP server (/etc/tcpd)must be running on the same mode providing the Ipd services. The Ipd command spawns a copy of itself to process the request; the master daemon continues to listen for new requests.

Clients communicate with Ipd using a simple transaction-oriented protocol. Remote clients are authenticated by means of the "privilege port" scheme employed by rshd(8C) and

output per queued job. Figure 6-1 is an example of the short format. In the long format, it shows the list of files which comprise a job, and their sizes. Figure 6-2 is an example of the long format.

% lpq Rank 1st

Owner Job Files Total Size

cass 18 memo, manual 4997 bytes

Figure 6-1. The /pq Short Format

% lpq -I

Warning: no daemon present cass: 1st

memo manual

[job 018apollo]

456 bytes 4541 bytes

Figure 6-2. The /pq Long Format

If lpr is the last command in a pipeline, lpq cannot distinguish which files comprise the job. If you request the long format in this case, the legend" (standard input)" is displayed instead of the file names.

6.2.3 Remove Jobs from a Queue: lprm

The Iprm(l) command deletes jobs from a spooling queue. If necessary, lprm will first kill off a running daemon that is servicing the queue, then restart it after the files are removed. When removing jobs destined for a remote printer, lprm acts like lpq, except that it first checks locally for jobs to remove and then tries to remove files in other queues off-machine. You must either be the owner of a job, or the super-user, to remove it.

6.2.4 Line Printer Control Program: lpc

The Ipc(8) program controls the operation of the line printer system. You must log in as the super-user to use Ipc and its associated commands. For each line printer configured in letc/printcap, Ipc can

• Disable or enable a printer

e Disable or enable a printer's spooling queue

• Rearrange the order of jobs in a spooling queue

.. Find the status of printers, and their associated spooling Queues and printer daemons

Im Dokument apollo BSD (Seite 195-199)