Penguin
Annotated edit history of lpd(8) version 3, including all changes. View license author blame.
Rev Author # Line
1 perry 1 LPD
2 !!!LPD
3 NAME
4 SYNOPSIS
5 DESCRIPTION
6 OPTIONS
7 OPERATION
8 PERMISSIONS, MULTIHOMED HOSTS, IPV6
9 PRINTCAP DATABASE
10 SPOOL DIRECTORY CONTENTS
11 JOB SUBMISSION
12 JOB TRANSMISSION
13 FORWARDING OPERATIONS
14 BOUNCE QUEUES
15 CHANGING FORMAT OF DATAFILES
16 LPR FILTER PROCESSING
17 ROUTING JOBS TO PRINTERS
18 REFORMATING CONTROL FILES
19 SPOOL QUEUE NAME OPTION
20 PRINTING OPERATIONS
21 FILTERS
22 ACCOUNTING
23 LOGGING INFORMATION
24 AUTHENTICATION
25 Client To Server Authentication
26 Server to Server Authentication
27 KERBEROS AUTHENTICATION
28 AUTHENTICATION PERMISSIONS
29 FILES
30 SEE ALSO
31 DIAGNOSTICS
32 HISTORY
33 AUTHOR
34 ----
35 !!NAME
36
37
38 lpd - line printer daemon
39 !!SYNOPSIS
40
41
42 __lpd__ [[-Llogfile] [[-F] [[-V] [[-Ddebugopt] [[-p
43 port]
44 !!DESCRIPTION
45
46
47 The lpd program is the printer server program of the LPRng
48 software suite. This software is an enhanced and modified
49 version of the Berkeley LPD software.
50 !!OPTIONS
51
52
53 __-L__ ''logfile''
54
55
56 specifies an alternate file to be used for logging error and
57 debugging messages. The syslog(8) facility is used to
58 log critical messages as well.
59
60
61 __-F__
62
63
64 Under normal operation, the LPD server will run in
65 background mode. The -F flag forces it to run in forground
66 mode, where it is more easily debugged.
67
68
69 __-V__
70
71
72 Print program version information.
73
74
75 __-D__ ''debugopt''
76
77
78 Debugging is controlled using the __-D__ option. This
79 accepts a comma-separated list of debugging settings. These
80 settings take one of two forms: __facility=value ,__ or
81 __value__ to set an overall default value. The available
82 facilities can be determined by invoking LPD with the -D=
83 parameter.
84
85
86 __-p__ ''port''
87
88
89 Bind to the specified port rather than port 515 specfied by
90 RFC1179.
91 !!OPERATION
92
93
94 ''Lpd'' is the line printer daemon (spool queue handler)
95 and is normally invoked at boot time from the rc(8)
96 file; it can also be started by a user. Note that the lpd
97 server needs only run on systems where actual printing or
98 spooling is taking place. lpr(1) and other related
99 programs transfer files using network facilities to the
100 ''lpd .''
101
102
103 When started, ''lpd'' reads a configuration file to
104 obtain basic operational parameters and then reads the
105 printcap(5) database information to determine the
106 which printers have spool queues and to start spool queue
107 server processes. If running as a background server, it will
108 disconnect from its control terminal and run in the
109 background. It uses the system calls listen(2) and
110 accept(2) to receive requests to print files in the
111 queue, transfer files to the spooling area, display the
112 queue, remove jobs from the queue, or perform a spool queue
113 control function. In each case it creates one or more server
114 processes to handle the request and the lpd process will
115 listen for more requests.
116
117
118 Sending the server a SIGHUP signal causes the server to
119 reread the various configuration and inititialization files.
120 This action is similar to that of the ''INETD'' and other
121 servers. The same action is taken when sent a ''reread''
122 command by the lpc(1) program. At an interveral
123 specified by the ''poll_time'' configuration variable,
124 ''lpd'' will check for spool queues with jobs and no
125 printing activity, and start printing.
126
127
128 LPD access control is done using a rule set and match
129 algorithm similar to a packet filter. Each request for
130 printing, status, or control operations is matched against
131 the rule set, and the first ACCEPT or REJECT value
132 determines if the operation can be performed. The following
133 is a typical permissions file:
134
135
136 # Set default permissions
137 DEFAULT ACCEPT
138 # Reject any connections from outside our subnet
139 REJECT SERVICE=X NOT IP=130.191.0.0/255.255.0.0
140 # Only accept Printing (P) and spooling (LPR) from
141 # the private network, the 10.0.0.0/8 network and fw
142 REJECT SERVICE=P,R NOT REMOTEHOST=*.private,10.0.0.0/8,fw.astart.com
143 # Do not accept forwarded jobs for printing
144 REJECT SERVICE=P FORWARD
145 # Allow only the administrators control access
146 ACCEPT SERVICE=C,M REMOTEHOST=spooler.astart.com USER=root,papowell
147 ACCEPT SERVICE=C,M SERVER REMOTEUSER=root,papowell
148 # Allow only the user on the same host who spooled job to remove it
149 ACCEPT SERVICE=M SAMEUSER SAMEHOST
150 REJECT SERVICE=M,C
151
152
153 Permission checking is done by using a set of keys (or
154 fields) with associated values to check for permission. The
155 SERVICE key has value P for printing (i.e.- unspooling), R
156 for spooling (i.e.- LPR request), C and S for printer
157 control and status respectively (i.e.- LPC request), M for
158 removal (i.e.- LPRM request), Q for queue information (i.e.-
159 LPRM request), and so forth. The key indicates the initial
160 connection to the LPD spooler, and can be used to control
161 connections from remote systems. The values of the USER,
162 HOST, and IP keys taken from the control file which is being
163 received or checked for permissions. The REMOTEUSER,
164 REMOTEHOST and REMOTEIP keys are those either sent as part
165 of a command, or derived from information about the current
166 network connection. Each line of the permissions file is
167 scanned for key names and values, and these are matched
168 against the request keys information. When all matches on a
169 line are made, then search terminates with the specified
170 action (ACCEPT/REJECT). If no match is found the default
171 permission value is used. The DEFAULT key is used to specify
172 the current default permission to be used for successful
173 matches or if there is no match after scanning the entire
174 permissions database.
175
176
177 The GROUP entry is used to check that the USER name appears
178 in a group entry in the system user group database. For
179 example, GROUP=student*,staff* would check to see if any of
180 the group name matching student* or staff* have the
181 specified user name in them. If a system has the
182 ''netgroups'' capability, a group name starting with a
183 @ will be treated as a netgroup name, and current
184 user name from the job file will bechecked to see if it is
185 in the group. Similarly, the REMOTEGROUP entry will check a
186 remote user name. The PORT entry can be used to ensure that
187 a connection to the server orignates from a specified range
3 perry 188 of ports. For more details, see the lpd.perm(5) man
1 perry 189 page.
190
191
192 The permissions database is scanned in order of the fixed
193 file entries and then by invoking the specified filters for
194 each of the permissions lists. It is recommended that the
195 filters be placed at the end of the permissions lists. The
196 user name is one of the parameters passed to the filter, and
197 can be used to determine if a user has permissions to print
198 a file.
199
200
201 Key Match Connect Job Job LPQ LPRM LPC
202 Spool Print
203 SERVICE S 'X' 'R' 'P' 'Q' 'M' 'C,S'
204 USER S - JUSR JUSR JUSR JUSR JUSR
205 HOST S RH JH JH JH JH JH
206 GROUP S - JUSR JUSR JUSR JUSR JUSR
207 IP IP RIP JIP JIP RIP JIP JIP
208 PORT N PORT PORT - PORT PORT PORT
209 REMOTEUSER S - JUSR JUSR JUSR CUSR CUSR
210 REMOTEHOST S RH RH JH RH RH RH
211 REMOTEGROUP S - JUSR JUSR JUSR CUSR CUSR
212 REMOTEIP IP RIP RIP JIP RIP RIP RIP
213 CONTROLLINE S - CL CL CL CL CL
214 PRINTER S - PR PR PR PR PR
215 FORWARD V - SA - - SA SA SA
216 SAMEHOST V - SA - SA SA SA
217 SAMEUSER V - - - SU SU SU
218 SERVER V - SV - SV SV SV
219 AUTH V - AU - AU AU AU
220 AUTHTYPE S - AU - AU AU AU
221 AUTHUSER S - AU - AU AU AU
222 FWDUSER S - AU - AU AU AU
223 KEY:
224 JH = HOST host in control file
225 RH = REMOTEHOST connecting host name
226 JUSR = USER user in control file
227 CUSR = REMOTEUSER user from control request
228 JIP= IP IP address of host in control file
229 RIP= REMOTEIP IP address of requesting host
230 PORT= connecting host origination port
231 CONTROLLINE= pattern match of control line in control file
232 FW= IP of source of request = IP of host in control file
233 SA= IP of source of request = IP of host in control file
234 SU= user from request = user in control file
235 SA= IP of source of request = IP of server host
236 SV= matches if remote host is the server
237 AU= authentication information
238 IFIP= IP address of remote end of connection
239 Match: S = string with wild card, IP = IPaddress[[/netmask],
240 N = low[[-high] number range, V = exact value match
241 SERVICE: 'X' - Connection request; 'R' - lpr request from remote host;
242 'P' - print job in queue; 'Q' - lpq request, 'M' - lprm request;
243 'C' - lpc spool control request; 'S' - lpc spool status request
244 NOTE: when printing (P action), the remote and job check values
245 (i.e. - RUSR, JUSR) are identical.
246
247
248 The special key ''letter=patterns'' searches the control
249 file line starting with the (upper case) letter, and is
250 usually used with printing and spooling checks. For example,
251 C=A*,B* would check that the class information (i.e.- line
252 in the control file starting with C) had a value starting
253 with A or B.
254 !!PERMISSIONS, MULTIHOMED HOSTS, IPV6
255
256
257 There is a subtle problem with names and IP addresses which
258 are obtained for 'multi-homed hosts', i.e. - those with
259 multiple ethernet interfaces, and for IPV6 (IP Version 6),
260 in which a host can have multiple addresses, and for the
261 normal host which can have both a short name and a fully
262 qualified domain name. In addition, a host can have multiple
263 IP addresses, depending on the complexity of its
264 configuration.
265
266
267 The IFIP (interface IP) field can be used to check the IP
268 address of the origination of the request, as reported by
269 the information returned by the accept() system call. Note
270 that this information may be IPV4 or IPV6 information,
271 depending on the origination of the system. This information
272 is used by gethostbyaddr() to obtain the orginating host
273 fully qualified domain name (FQDN) and set of IP addresses.
274 Note that this FQDN will be for the originating interface,
275 and may not be the cannonical host name. Some systems which
276 use the Domain Name Server (DNS) system may add the
277 cannonical system name as an alias.
278
279
280 When performing an IP address match, the entire list of IP
281 addresses for a system will now be checked. If one of these
282 matches, then success is reported. Similarly, the entire
283 list of host names and aliases will be checked. If one of
284 these matches, then success will be reported.
285
286
287 In addition, when checking for printing, if the name lookup
288 for the host reported in the control file fails, then we
289 assume that the host is unknown and all match checks for
290 names or IP addresses will fail. You can determine if a host
291 has an entry by using the following check, which will reject
292 all requests from a remotehost which does not have a DNS
293 entry.
294 REJECT NOT REMOTEHOST=*
295 !!PRINTCAP DATABASE
296
297
298 Individual printer operations are controlled by values in
299 the printcap database. See printcap(5) for details of
300 the format and content of the various entries. The following
301 are typical printer entries for a local and remote
302 printer.
303
304
305 # main or shared printcap file - usually /etc/printcap
306 # remote postscript printer
307 fullpage
308 |postscript
309 :lp=postscript@farside.astart.com
310 # give access to (remote) hosts
311 t1|postscript2
312 :cm=Test Printer 1
313 :lp=postscript2@nearside.astart.com
314 # local printcap file
315 # specification for local printer on nearside
316 t1|postscript2
317 :oh=nearside.astart.com
318 :cd=/usr/spool/LPD/safe
319 :sd=/usr/spool/LPD/t1
320 #
321 # /usr/spool/LPD/t1/printcap file -
322 t1:
323 :lp=/dev/pr
324 :if=/usr/lib/pr/if
325 :of=/usr/lib/pr/if
326
327
328 Printcap information can be distributed by individual files
329 or shared using NSF, YP, or other methods; see
330 ''lpd.conf''(5) for the exact details of the location of
331 printcap files and programs, given by the
332 ''printcap_path'' and ''lpd_printcap_path''
333 configuration information. The usual printcap configuration
334 is to have a main (shared) printcap database which is used
335 by all hosts. The printcap information is usually extremely
336 simple, consisting only of the printer name and host (i.e. -
337 fullpage printer entry).
338
339
340 On hosts which have printers attached or which are to
341 provide spooling queue directories, more extensive printcap
342 information is needed. In the shared database, ''oh''
343 (options for specified host only) field restricts use of
344 this entry to the specified host. This entry can contain
345 host specific information, such as the location of the spool
346 queue and/or actual device to be used for
347 output.
348
349
350 In the above example, the main printcap file,
351 /etc/lprng/printcap has entries for all printers. Note that
352 these entries do not specify the spool directories (sd and
353 cd fields), but this could be provided. On a host with a
354 printer specific information can be provided in serveral
355 ways. The simplest is to simply put an additional entry in
356 the shared printcap file, with the ''oh'' field set to
357 the support host name. An alternative would be to specify
358 the spool directories (sd and cd fields) in the shared
359 information, and to put the printer specific information in
360 a printcap file.
361
362
363 In addition to the ''oh'' flag, the ''server'' flag
364 indicates that this entry is for a the LPD server only. This
365 can be used to simplify the management of client and server
366 entries.
367
368
369 The printcap information is obtained in the following order.
370 If the lpd_printcap_path configuration value is nonblank
371 then the lpd server will proccess only this information
372 otherwise it uses the printcap_path information. All client
373 programs use the contents of the configuration printcap_path
374 variable to get a list of locations of printcap files. Each
375 of these entries in the path lists are processed, and the
376 printcap information is extracted. Entries which have
377 ''oh'' fields are only used by the specified host. The
378 files and information is processed in linear order, later
379 entries overriding preceeding ones.
380
381
382 When processing jobs or performing spool queue specific
383 requests, the LPD server will check to see if there is a
384 printcap file in the control directory for the spool queue
385 and the contents will be processed. Since only the LPD
386 server has access to the spool and control queues, this
387 information is processed only by the server.
388
389
390 In addition to files, printcap information can be obtained
391 from programs or filters. For example, the printcap_path of
392 the form
393 /etc/printcap:|/usr/lib/getpr will
394 use the contents of the
395 /etc/printcap file, and then use the
396 /usr/lib/getpr program to get
397 information about a specific printer. When information about
398 a particular spool queue is needed and one or more filters
399 are specified as the source of printcap information, then
400 the filter will be started and the printer name written on
401 its standard input. The filter must provide a printcap entry
402 for the requested printer on its standard
403 output.
404
405
406 The filter can be used to interface to databases or
407 nonstandard information sources which do not produce
408 printcap information in an acceptible form.
409 !!SPOOL DIRECTORY CONTENTS
410
411
412 Each spool queue has a spool directory (sd) and optional
413 control directory (cd) where job and control information is
414 kept. Under normal operation the spool and control
415 directories are identical, but if the spool directory is NFS
416 exported for use by other printer spoolers which write files
417 directly into the spool queue, then it is recommended that
418 the control directory be a separate directory and not NFS
419 mounted. The following files are used for printer
420 operations. Per job entries are marked with an asterisk
421 (*).
422
423
424 File Name Dir Purpose
425 printer CD lock file and server process PID
426 unspooler.printer CD subserver process PID
427 control.printer CD queue control information
428 *hfAnnn SD job hold file
429 *cfAnnnHOST SD job control file
430 *dfAnnnHOST SD job data file
431 *bfAnnn.* SD tempory files
432 The nnn in the file names stands for the job number. RFC1179 requires this to be a 3 digit number, but the longnumber printcap flag or a nonzero longnumber configuration variable will enable 6 digit numbers.
433
434
435 The lock file is used to prevent multiple job queue servers
436 from becoming active simultaneously, and to store the server
437 process id. The lock file name is the name as the printer
438 name; all other control files have the printer name appended
439 as indicated above.
440
441
442 The printer spool control file contains information
443 controlling the queue operations. It consists of a series of
444 lines with keywords and values to control printing,
445 spooling, and automatic job holding operations. The
446 following is an example of a typical spool control
447 file.
448
449
450 spooling_disabled 0
451 printing_disabled 1
452 holdall 0
453 redirect p1@host2
454 debug 10,log=/tmp/log
455 class A
456 The ''spooling_disabled'' and ''printing_disabled'' entries control spooling and printing; the lpc ''enable, disable, start,'' and ''stop'' command alter these values. The ''holdall'' entry will prevent jobs from being processed until released with the lpc ''hold'' or ''release'' comands; the lpc ''holdall'' and ''noholdall'' commands alter these values.
457
458
459 The ''redirect'' entry causes the lpd server to forward
460 jobs to the specified remote printer; the lpc
461 ''redirect'' command alters this field. The ''class''
462 field controls the class of jobs being printed. By default,
463 the class value is a pattern that matches the class entry in
464 a job file; however a entry of the form
465 ''letter=patterns'' will print jobs whose control file
466 line starting with ''letter'' matches one of the
467 patterns. The ''debug'' line provides a set of debugging
468 parameters for diagnostic information for the particular
469 spool queue.
470
471
472 Each print job consists of a control file and one or more
473 data files. Lines in the control file file specify the job
474 data files or parameters for the job and the general format
475 of the file is specified by RFC1179. Each line consists of a
476 flag character and a parameter; upper case and digit
477 characters specify options and lower case letters specify
478 the printing format and names of data files. The following
479 is a list of the control file flag characters.
480
481
482 A
483
484
485 Identifier A job identifier to be used when displaying job
486 information and/or status. The insertion of this line is
487 controlled by the ''use_identifier''
488 printcap/configuration variable.
489
490
491 C
492
493
494 Class String to be used for the class line on the burst
495 page.
496
497
498 H
499
500
501 Host Name. Name of the machine where ''lpr'' was
502 invoked.
503
504
505 I
506
507
508 Indent. The number of characters to indent the output by (in
509 ascii).
510
511
512 J
513
514
515 Job Name. String to be used for the job name on the burst
516 page.
517
518
519 L
520
521
522 Banner user name. Information for banner page.
523
524
525 P
526
527
528 Person. Login name of the person who invoked ''lpr''.
529 This is used to verify ownership by
530 ''lprm''.
531
532
533 M
534
535
536 Send mail to the specified user when the current print job
537 completes.
538
539
540 N
541
542
543 File name. The original name of a data file which is in the
544 job.
545
546
547 T
548
549
550 Title. String to be used as the title for pr(1) when
551 the LPR -p option was specified.
552
553
554 U
555
556
557 Unlink. Job file to remove when printing
558 completed.
559
560
561 W
562
563
564 Width. The page width (in characters) to used for
565 printing.
566
567
568 Z
569
570
571 zoptions. Options passed by ''lpr -Zzoptions.'' These are
572 passed to output filters to aid in printing.
573
574
575 f
576
577
578 Formatted File. Name of a file to print which is already
579 formatted.
580
581
582 l
583
584
585 Like ``f'' but passes control characters and does not make
586 page breaks.
587
588
589 p
590
591
592 Name of a file to print using pr(1) as a
593 filter.
594
595
596 t
597
598
599 Troff File. The file contains troff(1) output (cat
600 phototypesetter commands).
601
602
603 d
604
605
606 DVI File. The file contains ''Tex''(l) output (DVI format
607 from Stanford).
608
609
610 g
611
612
613 Graph File. The file contains data produced by
614 ''plot''(3X).
615
616
617 c
618
619
620 Cifplot File. The file contains data produced by
621 ''cifplot''.
622
623
624 v
625
626
627 The file contains a raster image.
628
629
630 r
631
632
633 The file contains text data with FORTRAN carriage control
634 characters.
635
636
637 1
638
639
640 Troff Font R. Name of the font file to use instead of the
641 default. (Obsolete)
642
643
644 2
645
646
647 Troff Font I. Name of the font file to use instead of the
648 default. (Obsolete)
649
650
651 3
652
653
654 Troff Font B. Name of the font file to use instead of the
655 default. (Obsolete)
656
657
658 4
659
660
661 Troff Font S. Name of the font file to use instead of the
662 default. (Obsolete)
663
664
665 Each job in the spool queue can have an associated job hold
666 file which is used by the server process to control the
667 printing of the job. The status file contains information
668 controlling the job hold status and error status. The spool
669 server will attempt to print a job a limited number of times
670 before abandoning it or setting an error status in the job
671 status file. The following is a typical job hold
672 file.
673
674
675 hold 0 priority 0 active 2135 redirect remove 0
676 error
677
678
679 A nonzero ''hold'' entry will prevent the job from being
680 processed; the lpc ''hold'' and release commands update
681 this field. The ''priority'' field overrides the normal
682 first-in first-out printing priority; jobs with non-zero
683 priority fields are printed first. The lpc ''topq''
684 command updates this field. If the ''active'' field is
685 non-zero, the job is being printed by the server with the
686 specified process id. The ''redirect'' field allows
687 individual jobs to be forwarded to a different printer; the
688 lpc ''move'' command updates this field. Finally, the
689 remove and error fields are used to control printing of
690 problem jobs. The ''remove'' field is set when a job
691 should be removed; the ''error'' field records
692 information that would prevent a job from being
693 printed.
694 !!JOB SUBMISSION
695
696
697 The LPR program is used to submit a job to the LPRng system.
698 The LPR program opens a connection to the LPD server and
699 then transfer the job control file and data files. The LPD
700 server checks to see if the remote host and user has
701 permissions to spool to the requested printer, and then
702 checks to see if the printer is accepting jobs. If both
703 conditions are met, the job is accepted and the control and
704 data files are placed int the spool directory. The LPRng
705 software sends the control file first, followed by the data
706 files.
707
708
709 If the LPR program is acting as a filter, it is not
710 necessary to temporarily store the print job on the local
711 machine. The input data can be sent directly to the LPD
712 server for spooling using an implicit job size of 0 and
713 sending data until the connection is terminated to the
714 server. However, some LPD servers do not accept 0 size jobs,
715 even though it is specified by the RFC1179, so by default
716 LPR will create a temporary file. The LPR -k (seKure) option
717 specifies this direct transmission mode be
718 used.
719 !!JOB TRANSMISSION
720
721
722 When LPR is to send a job to the server, it must determine
723 the location of the server. It does this by examining the
724 values of the specified printer and host.
725
726
727 If the printer and host are explicitly specified in the form
728 pr@host then the LPR program will
729 send the job to the specified spool queue
730 pr and to the server running on
731 host . This can be explicitly
732 specified by the PRINTER environment variable or by the LPR
733 -P option.
734
735
736 If the printer is specified only by a name, then the
737 information in the printcap database is used. The printcap
738 entry for the printer is searched for and the remote host
739 and printer information extracted. The job is sent to the
740 server running on the specified host.
741
742
743 This action can be modified by the following printcap or
744 configuration tags.
745
746
747 1. default_host=host
748
749
750 (Configuration) If there is no printcap entry for the
751 printer, the job is sent to the LPD server running on
752 host .
753
754
755 2. force_localhost
756
757
758 (Configuration or printcap) If this flag is specified, then
759 LPR and other client programs will send the job to the
760 server running on the localhost. This overrides the
761 default_host information.
762 !!FORWARDING OPERATIONS
763
764
765 The LPD system can forward jobs from one spool directory to
766 another. This is controlled by the following
767 options.
768
769
770 1.
771
772
773 The forward field in the spool control file has a value
774 rp@rm. This can be set using the LPC forward
775 command.
776
777
778 2.
779
780
781 The lp (line printer) printcap entry has the form rp@rm.
782 There is a rm (remote machine) and optional rp (remote
783 printer) printcap entry.
784
785
786 The first of the above conditions to be met will determine
787 the destination. If printing is enabled, then jobs will be
788 forwarded to the remote destination. Example:
789
790
791 # using lp=rp@host
792 test:sd=/usr/spool/test
793 :lp=test@host
794 test:sd=/usr/spool/test
795 :lp=test@host%port
796 # using :rp:rm:
797 test:sd=/usr/spool/test
798 :rp=test:rm=host
799 3.
800
801
802 The LPD server uses the same algorithm for sending jobs as
803 the LPR program. A connection is made to the remote server
804 and the files are copied to the server. A set of timeouts is
805 used to control error recover and retry operations. The
806 printcap and configuration variables ''connect_timeout,
807 connect_interval, connect_grace,'' and ''send_try''
808 control connecting to the remote host. A connection is
809 attempted to the remote server from a random port in the
810 range of ports specified by the ''originate_port''
811 variable. If a connection is not completed within
812 ''connect_timeout'' seconds, the connection is aborted,
813 and then after the ''connect_interval'' seconds it is
814 retried. The procedure repeated indefinately for printing,
815 but only once for status or control operations. A
816 connect_timeout value of 0 indicates no timeout; a value of
817 0 specifies infinite timeout After a job has been
818 successfully printed, the connection is closed and the
819 server waits for ''connect_grace'' seconds before trying
820 to reconnect.
821 !!BOUNCE QUEUES
822
823
824 Normally job files are forwarded to a printer without
825 modification. The flag makes the queue a ''bounce queue''
826 and allows banners to be generated and data files to passed
827 through the appropriate format filter. The entire output of
828 this process is then passed to the destination with the
829 format specified by the __bq_format__ option (default
830 __l__ or binary). See PRINTING OPERATIONS for details
831 about filters. For example, the following printcap entry
832 will filter format f files.
833
834
835 testbq:sd=/usr/spool/testbq:
836 :lpd_bounce
837 :bq_format=l
838 :lp=final@host
839 :if=/usr/lib/filter_for_f
840 :mf=/usr/lib/filter_for_m
841 :pf=/usr/lib/filter_for_pr
842 !!CHANGING FORMAT OF DATAFILES
843
844
845 Sometimes only the indicated format of the data files needs
846 to be changed. This can be done using the
847 __translate_format__ option. This entry consists of pairs
2 perry 848 of lower case characters of the form !SdSd...; S is the
1 perry 849 original and d is the translated format.
850
851
852 changeformat:
853 :sd=/usr/spool/changeformat:
854 :translate_format=mfpf
855 :lp=final@host
856 In the example above, the m format is processed by a filter, and then its format type is changed to f; the p format is processed similarly. Note that the lpr -p option specifies that the job will be processed by the /bin/pr command - the filter must do both the pr processing and any necessary format conversions.
857 !!LPR FILTER PROCESSING
858
859
860 The :lpr_bounce: printcap flag will
861 cause LPR to do bounce queue filtering before sending the
862 job to the remote queue. This can have unexpected effects if
863 the filters are not available on the local
864 host.
865
866
867 A typical entry which will cause LPR to do filtering is
868 shown below.
869
870
871 testbq:lpr_bounce
872 :lp=printer@host
873 :if=/usr/lib/filter_for_f
874 :vf=/usr/lib/filter_for_v
875 :mf=/usr/lib/filter_for_m
876 :translate_format=mfvf
877 This entry will force LPR to run jobs with formats f, m, and v
878 through the appropriate filter.
879 It will also rename the formats to the f format.
880 !!ROUTING JOBS TO PRINTERS
881
882
883 When a job is submitted for printing, sometimes it is
884 desirable to have it dynamically rerouted to another spool
885 queue, or multiple copies send to various destination. This
886 can be done by using a
887 routing_filter .
888
889
890 When a job is accepted by the LPD server, part of the
891 processing includes passing it to a program specified by the
892 printcap router entry. This filter
893 is invoked with the original control file as STDIN, and the
894 default set of filter options. The output of the routing
895 filter will be a set of directives used by LPD when
896 forwarding the job to another printer or in processing the
897 job. The environment and options flags are set as for a
898 standard filter. (See
899
900
901 t2|Test Printer 2
902 :sd=/var/spool/LPD/t2
903 :lf=log
904 :lp=t2@printserver
905 :bq=t1@localhost
906 :destinations=t1@localhost,t2@localhost
907 :router=/usr/local/libexec/filters/router
908 The routing filter exit status is used as follows:
909 0 (JSUCC) - normal processing
910 37 (JHOLD) - job is held
911 any other value - job is deleted from queue
912
913
914 The router filter returns one or more routing entries with
915 the following format. Note that entry order is not
916 important, but each entry will end with the 'end' tag. dest
917
918
919 Example of router output:
920
921
922 dest t1@localhost
923 copies 2
924 CA
925 end
926 dest t2@localhost
927 CZ
928 end
929 The above routing information will have copies of the job sent to
930 the t1 and t2 spool queue servers. If no valid routing information
931 is returned by the router filter the job will be sent to the default
932 bounce queue destination.
933 !!REFORMATING CONTROL FILES
934
935
936 Sometimes it is desirable to reformat a control file before
937 sending to a remote destination. If the
938 control_filter printcap entry is
939 present, then the control file is passed through the filter.
940 If the filter exits with status JSUCC, then the job is
941 process normally; status JABORT causes the job processing to
942 be aborted, status JREMOVE causes the job processing to be
943 removed, and any other status is treated as
944 JFAIL.
945
946
947 After passing the control file through the control_filter,
948 the LPD server will reread it, and transfer only the data
949 files specified in the new control file to the
950 destination.
951 !!SPOOL QUEUE NAME OPTION
952
953
954 The qq printcap entry and the
955 use_queuename configuration entry
956 causes the name of the spool queue to be placed in the job
957 control file. This value can be used by the filter to
958 determine how to process a job. When combined with the use
959 of the Bounce Queue, this can be used to reformat jobs
960 before sending to another printer spooler
961 system.
962 !!PRINTING OPERATIONS
963
964
965 When printing is enabled, the LPD server will create a spool
966 server process to carry out printing operations. For each
967 job in the queue, the spool server process will create a
968 subserver process to carry out the actual printing
969 operations. If the subserver process fails, the server
970 process will initiate recovery operations. Job will be
971 attempted to be printed until all are done or a subserver
972 returns an ABORT indication; the server will then terminate
973 operations.
974
975
976 The server process normally scans the queue once, at
977 initiation; if the spool control file is modified, usually
978 by using the lpc command, the spool queue is rescanned. The
979 overall algorithm for job printing is:
980
981
982 open the print device;
983 send some initialization strings;
984 send a banner to the device;
985 send the job data files to the device;
986 send some termination strings;
987 close the print device;
988 In order to handle the various device requirements, the subserver process in turn uses 'filter' programs specified in the printcap entry to carry out the individual steps.
989
990
991 OF Filter
992
993
994 The 'of' filter is used for initialization, banner printing
995 and the termination strings. It has the peculiar property of
996 suspending itself when sent a special escape string,
997 allowing other filters to be used to print the individual
998 job files.
999
1000
1001 Data Filters
1002
1003
1004 Each data file in a job has format specified by a lower case
1005 character and an associated filter specified in the printcap
1006 file. For example, the 'g' format is printed by the 'gf'
1007 filter, and so forth. By convention, the 'if' filter is used
1008 to print 'f' (ordinary text) and 'l' (binary) format
1009 jobs.
1010
1011
1012 lp-pipe Filters
1013
1014
1015 If the printcap device specification has the form
1016 ''|program'' then the output device is accessed by the
1017 specified program. This allows the program to take care of
1018 any required initialization or communication
1019 requirements.
1020
1021
1022 The following is a concise summary of the actual algorithm
1023 used to print files. Note that LP stands for the printer
1024 device or filter specified by the 'lp' printcap entry; OF
1025 stands for the 'of' printcap filter; IF is the default 'if'
1026 filter; BP is the banner printing filter; and ?F stands for
1027 the filter for data file. The '??' values stand for entries
1028 from the printcap file.
1029
1030
1031 LP = open( 'lp' ); // open device, filter, or network connection
1032 OF = IF = LP; // set defaults
1033 set up accounting according to 'af' entry;
1034 if( 'of' ) OF = filter( 'of' ) -
1035 When printing or transferring a job to a spool queue fails, it is retried the number of times specified by the ''rt'' (or ''send_try )'' printcap variable. A 0 value specifies an infinite number or retries. When the retry count is exceeded, then the ''send_failure_action'' printcap variable determines the action to be taken. The variable can be the values ''succ , fail , abort , remove , ignore ,'' or ''hold ,'' which will cause the job to be treated as normally completed, retried, aborted, removed, or ignored and retried at a later time respectively. These names correspond to the ''JSUCC , JFAIL ,'' etc. error codes returned by filters. If the variable has the form ''|/filter ,'' then the filter is run and passed the number of attempts on the standard input. The filter must exits with a ''JSUCC, JFAIL,'' etc., error code and the server will take the appropriate action as listed above.
1036
1037
1038 The print filters normally have their input provided by a
1039 process via a pipe. However, if the ''direct_read''
1040 printcap flag is set, then the filter input is taken
1041 directly from the job file. This is compatible with the
1042 vintage BSD method, but loses the ability to track the job
1043 progress.
1044
1045
1046 After the job print or transfer attempt, if the job is to be
1047 removed and the printcap variable ''save_on_error'' is
1048 true, the job will not be removed from the spool queue but
1049 only flagged with an error. The job can then be retried at a
1050 later time. If the job is successfully printed it is usually
1051 removed from the spool queue. However, if the printcap
1052 variable ''save_when_done'' is true the job will merely
1053 be marked as completed and not removed from the
1054 queue.
1055 !!FILTERS
1056
1057
1058 As described in the previous section, filters are created to
1059 handle output to devices or other filters. The command line
1060 to invoke a filter is generated in the following
1061 manner.
1062
1063
1064 1.
1065
1066
1067 The printcap entry or configuration value defining the
1068 filter command is obtained.
1069
1070
1071 2.
1072
1073
1074 The file to be printed or the banner line/file generated by
1075 the banner printer will be written to STDIN (file descriptor
1076 0) of the filter. The output device (or /dev/null if this is
1077 not a printing filter) will be be STDOUT (file descriptor 1)
1078 and STDERR (file descriptor 2) will be connected to the
1079 error logging file. If this is a printing filter, the error
1080 log will be determined by the :af: printcap field and FD 3
1081 will be opened and set to the either the file, remote host,
1082 or input of the filter program.
1083
1084
1085 3.
1086
1087
1088 Filter specifications starting with ROOT will be run as root
1089 (EUID = 0). This can be a serious security loophole and
1090 should only be used as a last resort for specific
1091 problems.
1092
1093
1094 4.
1095
1096
1097 The options for the filter command line will be replaced by
1098 appropriate values. Option specifications have the form $[[0|
1099 ][[-][[']X. The default option expansion has the form $X -
1100
1101
1102 Key Value
1103 a Accounting file (printcap 'af' entry)
1104 b Job size, i.e.- total data file size, in bytes
1105 c if binary (format 'l') expands to -c
1106 d Control directory
1107 e job data file
1108 f original print file name (control file N field)
1109 h Control file hostname
1110 i Control file indent (I) field
1111 j job number from control file name
1112 k Control file name
1113 l printcap Page length (pl) value
1114 m printcap Cost factor (co) value
1115 n Control file user logname (P) field
1116 p Remote Printer name for forwarded jobs
1117 r Remote Host name for forwarded jobs
1118 s printer Status file (ps) value
1119 t current time in simple format
1120 w printcap Page width (pw) value
1121 x printcap x dimension (px) value
1122 y printcap y dimension (py) value
1123 F data file format character
1124 P Printer name
1125 S printcap Comment tag (cm) value
1126 Upper Case control file line starting with letter
1127 Digit control file line starting with digit
1128
1129
1130 5.
1131
1132
1133 The options specified by the filter_options (for none OF
1134 filters) or of_filter_options (for the OF filter) will be
1135 appended to the command line and expanded. To suppress
1136 adding options, you can use the form '-$ filter', i.e. -
1137 of=-$/bin/cat. If the 'bkf' (backwards compatible filter
1138 options) printcap flag is set, the of filter is given the
1139 options specified by bk_of_filter_options and other filters
1140 those by bk_filter_options. The following shows the various
1141 combinations possible, and typical values for the
1142 options.
1143
1144
1145 Options
1146 filter_options $C $F $H $J $L $P $Q $R $Z $a $c $d $e $f $h $i \
1147 $j $k $l $n $s $w $x $y $-a
1148 bk_filter_options $P $w $l $x $y $F $c $L $i $J $C $0n $0h $-a
1149 bk_of_filter_options $w $l $x $y
1150 6.
1151 A printing filter which executes correctly and completely should
1152 exit with a 0 error status.
1153 A nonzero error status will be interpreted as follows:
1154 JFAIL 32 failed - retry later
1155 JABORT 33 aborted - do not try again, but keep job
1156 JREMOVE 34 failed - remove job
1157
1158
1159 The JFAIL will cause the job to be retried at a later time.
1160 A limit can be placed on the number of retries using the
1161 :rt: or :send_try: printcap entry. A retry value of 0 will
1162 cause infinite retries. The JABORT indicates serious
1163 problems and will cause printing operations on the job to
1164 stop until restarted by operator intervention. The JREMOVE
1165 status indicates problems, and the job should be removed
1166 from the spool queue.
1167
1168
1169 The environment variables for filters are highly restricted,
1170 due to the possibility for abuse by users. The following
1171 variables are set:
1172
1173
1174 USER and LOGNAME
1175
1176
1177 user name or daemon name.
1178
1179
1180 LOGDIR
1181
1182
1183 home directory of user or daemon.
1184
1185
1186 PATH
1187
1188
1189 from the ''filter_path'' configuration
1190 variable.
1191
1192
1193 LD_LIBRARY_PATH
1194
1195
1196 from the ''filter_ld_path'' configuration
1197 variable.
1198
1199
1200 SHELL
1201
1202
1203 set to ''/bin/sh''
1204
1205
1206 IFS
1207
1208
1209 set to blank and tab.
1210
1211
1212 TZ
1213
1214
1215 the TZ environment variable.
1216
1217
1218 SPOOL_DIR
1219
1220
1221 the spool directory for the printer
1222
1223
1224 CONTROL_DIR
1225
1226
1227 the control directory for the printer
1228
1229
1230 PRINTCAP_ENTRY
1231
1232
1233 the printcap entry for the printer
1234
1235
1236 CONTROL
1237
1238
1239 the control file for the print job
1240
1241
1242 pass_env environment variables
1243
1244
1245 Values of environment variables listed in the pass_env
1246 configuration variable.
1247 !!ACCOUNTING
1248
1249
1250 The LPRng software provides several methods of performing
1251 accounting. The printcap af (accounting field), as and ae
1252 (accounting start and end), and achk (accounting check)
1253 provide a basic set of facilities. The af field specifies a
1254 file, filter, or TCP network connection to an accounting
1255 server. If af has the form |filter or |-$
1256 filter then a filter will be started and all accounting
1257 information will be sent to the filter. The first form
1258 passes the filter the command line options specified by the
1259 filter_options configuration variable and the second
1260 suppresses option passing. If af has the form
1261 host%port then a TCP connection will be opened to
1262 the port on the specified host and accounting information
1263 sent there. All other forms will be treated as a pathname
1264 relative to the queue spool directory.
1265
1266
1267 If af specifies a file, then the accounting information is
1268 appended to an existing file; the accounting file will not
1269 be created.
1270
1271
1272 When af specifies a filter or network connection and the
1273 achk flag is set, then after writing the initial accounting
1274 information (see as printcap field below) the server will
1275 wait for a reply of the form ACCEPT from the filter or
1276 server. If not received, the job will not be
1277 printed.
1278
1279
1280 The as (accounting start) and ae (accounting end) fields can
1281 specify a string to be printed or a filter. Options in the
1282 string will be expanded as for filters, and the strings
1283 printed to either the accounting information destination. If
1284 the as field specifies a filter, then the print server will
1285 wait for the filter to exit before printing the job. If the
1286 exit status is 0 (successful), the job will be printed. A
1287 non-zero JREMOVE status will remove the job, while any other
1288 status will terminate queue printing operations. After
1289 printing the job, the ae filter will be started and the
1290 server will wait for it to complete before printing the next
1291 job.
1292
1293
1294 The as and ae filters will have STDOUT set to the printing
1295 device and or filter, and the STDERR set to the error log
1296 file for the print queue, and fild descriptor 3 set to the
1297 destination specified by the af field.
1298
1299
1300 As a convenience, all format filters for printing will be
1301 started with file descriptor 3 set to the destination (file
1302 or filter) specified by the printcap af field. This allows
1303 special filters which can query devices for page counts to
1304 pass their information directly to an accounting program.
1305 The descriptor will READ/WRITE, allowing filters to query
1306 the accounting program and/or update the information
1307 directly.
1308 !!LOGGING INFORMATION
1309
1310
1311 In order to provide a centrallized method to track job
1312 status and information, the printcap/configurtion variable
1313 logger_destination enable the send of status and other
1314 information to a remote destination. The logger_destination
1315 value has the form
1316
1317
1318 host[[%port][[,protocol]
1319 Examples:
1320 taco%451,UDP
1321 dickory%2001,TCP
1322 where host is the host name or IP address, port is an optional port number, and protocol is an optional protocol type such as UDP or TCP. The configuration variables default_logger_port and default_logger_protocol can be used to override the default port number (2001) and protocol (UDP) to be used if none is specified. Logging information has the format below.
1323
1324
1325 IDENTIFIER jobid [[PRINTER name] at ''timestamp'' \
1326 STATUS | TRACE | FILTER_STATUS PID nnn
1327 [[ status information]
1328
1329
1330 The status information format consists of an identifier
1331 line, followed by a specifier of the status type. The
1332 logging information entry is terminated by a line with a
1333 single period on it. Lines with a starting period have the
1334 period duplicated.
1335 !!AUTHENTICATION
1336
1337
1338 Rather than building authentication facilties into LPRng, an
1339 interface to authentication programs is defined, and will be
1340 used as follows. The printcap and configuration entries
1341 ''auth, auth_client_filter, auth_forward, auth_forward_id,
1342 auth_forward_filter, auth_receive_filter,'' and
1343 ''auth_server_id'' entries control authentication. The
1344 ''auth'' value specifies the type of authentication to be
1345 used for client to server authentication. Typical values
1346 would be pgp, kerberos, etc. If the authentication type is
1347 not built-in, the client programs use the
1348 ''auth_client_filter'' program to perform authentication.
1349 When a server gets and an authentication request, it will
1350 use the ''auth_receive_filter'' program to perform
1351 authentication. The ''auth_server_id'' is the remote
1352 server id used when a client is sending jobs to the server
1353 or when the server is originating a request. When a server
1354 forwards a request, it uses ''auth_forward'' value to
1355 determine if authentication is to be done, and the
1356 ''auth_forward_id'' as the destination server
1357 id.
1358 !!Client To Server Authentication
1359
1360
1361 1. The client will open a connection to the server and sends
1362 a command with the following format. The REQ_SECURE field in
1363 the command corresponds to the one-byte command type used by
1364 the LPR protocol.
1365
1366
1367 Commands:
1368 REQ_SECUREprinter C usern
1369 Print job transfers:
1370 REQ_SECUREprinter C user controfilenamen
1371
1372
1373 2. On reception of this command, the server will send a one
1374 byte success code as below. An error code may be followed by
1375 additional error information. The values used by LPRng
1376 include:
1377
1378
1379 ACK_SUCCESS 0 success, no error
1380 ACK_STOP_Q 1 failed; no spooling to the remote queue
1381 ACK_RETRY 2 failed; retry later
1382 ACK_FAIL 3 failed; job rejected, no retry
1383
1384
1385 3. If there is an error the connection will be terminated.
1386 The server will then start an authentication process, and
1387 provide the following open file descriptors for it. The
1388 authenticator process will run as the UID of the server
1389 (i.e.- usually daemon).
1390
1391
1392 FD Options Purpose
1393 0 R/W socket connection to remote host (R/W)
1394 1 W pipe or file descriptor
1395 for information for server
1396 2 W error log
1397 3 R pipe or file descriptor
1398 for responses to client
1399
1400
1401 The command line arguments will have the form:
1402
1403
1404 program -S -Pprinter -nuser -Rserver_user -Ttempfile
1405
1406
1407 The printer and user information will be obtained from the
1408 command line sent to the server. The authenticator can
1409 create additional temporary or working files with the
1410 pathnames tempfile.ext; these should be deleted after the
1411 authentication process has been completed.
1412
1413
1414 4. After receiving ACK_SUCCESS, the client starts an
1415 authenticator process, and provides the following open file
1416 descriptors for it. The authenticator process will run UID
1417 user.
1418
1419
1420 FD Options Purpose
1421 0 R/W socket connection to remote host (R/W)
1422 1 W pipe or file descriptor
1423 for responses to client
1424 2 W error log
1425
1426
1427 The command line arguments will have the form:
1428
1429
1430 program -C -Pprinter -nuser -Rserver_user -Ttempfile
1431
1432
1433 5. The authenticator can create additional temporary or
1434 working files with the pathnames tempfile.ext; these will be
1435 deleted after the authentication process has been completed.
1436 The client authenticator will be running as the client
1437 user.
1438
1439
1440 6. After exchanging authentication information, the client
1441 authenticator will transfer the contents of the temporary
1442 file to the server authenticator, using FD 0. It will then
1443 wait for reply status on FD 0. If the transfer step fails,
1444 or there is no reply status of the correct format, the
1445 client authenticator will print any recieved information on
1446 FD 1, error information on FD 2, and then exit with error
1447 code JFAIL.
1448
1449
1450 7. After receiving the files on FD 0, the server
1451 authenticator will perform the required authentication
1452 procedures and leave the results in tempfile. The server
1453 authentictor will write the following to FD 1, for use by
1454 the server:
1455
1456
1457 authentication_infon
1458
1459
1460 If the transfer step or authentication fails, then the
1461 server will write an error message to FD 2 and exit with
1462 error code JFAIL. The server will use this authentication
1463 information to determine if the remote user has permission
1464 to access the system.
1465
1466
1467 8. The server authentication process will read input from FD
1468 3 until and end of file, and then proceed to transfer the
1469 input to the client authenticator. If the data transfer
1470 fails, then the process will exit with error code JFAIL,
1471 otherwise it will exit with error code JSUCC.
1472
1473
1474 9. The client authenticator will read the status information
1475 from FD 0, and after performing authentication will write it
1476 to FD 1. If data transfer or authentication fails, the
1477 authenticator will write an error message to FD 2 and exit
1478 with error code JFAIL, otherwise it will exit with error
1479 code JSUCC.
1480 !!Server to Server Authentication
1481
1482
1483 The Server to Server authentication procedure is used by one
1484 server to forward jobs or commands to another server. It
1485 should be noted that this forwarding operation puts an
1486 implicit trust in the security of the client to server to
1487 server chain. In the description below, src and dst are the
1488 userid of the source and destination servers
1489 respectively.
1490
1491
1492 1. The originating host takes the part of the client, and
1493 will transfer a job acting like the client. The initial
1494 information transfer from the originating (src) server will
1495 have the format:
1496
1497
1498 Commands:
1499 REQ_SECUREprinter F usern
1500 Print job transfers:
1501 REQ_SECUREprinter F user controfilenamen
1502
1503
1504 After receiving a 0 acknowlegement byte, the src server will
1505 invoke its authenticator with the arguments below. The
1506 forward_user value will default to the server_user value if
1507 not explicitly provided.
1508
1509
1510 program -C -Pprinter -nserver_user \
1511 -Rforward_user -Ttempfile
1512
1513
1514 2. On the destintation server the authenticator is invoked
1515 with the arguments:
1516
1517
1518 program -S -Pprinter -nserver_user \
1519 -Rforward_user -Ttempfile
1520
1521
1522 The authentication is performed to determine that the
1523 transfer was between the two servers, rather than the user
1524 to server.
1525 !!KERBEROS AUTHENTICATION
1526
1527
1528 As a convenience, Kerberos 5 authentication has been built
1529 into the LPD clients and servers. If you are not familiar
1530 with Kerberos, then you should obtain other documentation
1531 and/or assistance before attempting to use this. The
1532 following facilities/configuration values are used to
1533 support Kerberos.
1534
1535
1536 A Kerberos principal is the name used for authentication
1537 purposes by Kerberos. For example, user principals have the
1538 form user@REALM; for example, papowell@ASTART.COM. Services
1539 and/or servers have the form service/host@REALM; for
1540 example, the lpd server on dickory would have the
1541 form:
1542
1543
1544 lpr/astart2.astart.com@ASTART.COM
1545
1546
1547 User to server authenticaiton process will use the user's
1548 principal name, and generate a service name for the server.
1549 The name generation is controlled by the following
1550 configuration and/or printcap values.
1551
1552
1553 service
1554
1555
1556 The name of the service to be used to identify the service.
1557 This is usually
1558
1559
1560 kerberos_keytab
1561
1562
1563 The location of the server keytab file. The keytab file
1564 corresponds to the user password, and must be considered a
1565 security risk. It should be owned by the LPD server user,
1566 and readable/writable only by the server.
1567
1568
1569 kerberos_life
1570
1571
1572 The lifetime of the authentication ticket used by the
1573 server. This usually defaults to 10 hours.
1574
1575
1576 kerberos_renew
1577
1578
1579 The renewal time of the ticket.
1580
1581
1582 In addition to the default values, an explicit server
1583 principal can be specified in the printcap file using the
1584 kerberos_server_principal This allows cross domain
1585 authentication to be done.
1586
1587
1588 When setting up Kerberos authentication, you will need to
1589 establish principals for each server, and to distribute and
1590 install the keytab files on each server.
1591 !!AUTHENTICATION PERMISSIONS
1592
1593
1594 The following permissions tags are available to check on
1595 authentication procedures.
1596
1597
1598 AUTH=[[NONE,USER,FWD] - authentication
1599 AUTH=NONE - no authentication
1600 AUTH=USER - authentication from a client
1601 AUTH=FWD - forwarded authentication from a lpd server
1602 AUTHTYPE=globmatch
1603 AUTHUSER=globmatch
1604 FWDUSER=globmatch
1605
1606
1607 1. The AUTH tag can be used to determine the type of
1608 authentication being done. The AUTHTYPE tag can be used to
1609 match the authentication type being used or requested by the
1610 client or remote server. The authentication process returns
1611 an authentication identifier for the user; this information
1612 can be matched by the AUTHUSER tag.
1613
1614
1615 2. For a command sent from a client or forwarded from a
1616 server, AUTHUSER matches the auth_user_id provided for the
1617 user when sent to a server. (This information will be
1618 forwared by a remote server). For a forwarded command,
1619 FWDUSER refers to the authentication information for the
1620 server doing the forwarding.
1621
1622
1623 3. For example, to reject non-authenticated operations, the
1624 following line could be put in the permissions
1625 file.
1626
1627
1628 REJECT AUTH=NONE
1629
1630
1631 4. To reject server forwarded authentication as well, we use
1632 REJECT AUTH=NONE,FWD. If a remote server with name
1633 ''serverhost'' has id information FFEDBEEFDEAF, then the
1634 following will accept only forwarded jobs from this
1635 server.
1636
1637
1638 ACCEPT FWDUSER=FFEDBEEFDEAF REMOTEHOST=serverhost
1639 REJECT AUTH=FWD
1640 !!FILES
1641
1642
1643 The files used by LPRng are set by values in the printer
1644 configuration file. The following are a commonly used set of
1645 default values.
1646
1647
1648 /etc/lprng/lpd.conf LPRng configuration file
1649 ${HOME}/.printcap user printer description file
1650 /etc/lprng/printcap printer description file
1651 /etc/lprng/lpd.perms permissions
1652 /var/run/lprng/lpd lock file for queue control
1653 /var/spool/lpd spool directories
1654 /var/spool/lpd/QUEUE/control queue control
1655 /var/spool/lpd/QUEUE/log trace or debug log file
1656 /var/spool/lpd/QUEUE/acct accounting file
1657 /var/spool/lpd/QUEUE/status status file
1658 !!SEE ALSO
1659
1660
1661 lpd.conf(5), lpc(8), checkpc(8), lpr(1), lpq(1), lprm(1),
1662 printcap(5), lpd.perms(5), pr(1).
1663 !!DIAGNOSTICS
1664
1665
1666 Most of the diagnostics are self explanatory.
1667 If you are puzzled over the exact cause of failure,
1668 set the debugging level on (-D5) and run again.
1669 The debugging information will
1670 help you to pinpoint the exact cause of failure.
1671 !!HISTORY
1672
1673
1674 LPRng is a enhanced printer spooler system with
1675 functionality similar to the Berkeley LPR software. The
1676 LPRng mailing list is lprng@lprng.com; subscribe by sending
1677 mail to lprng-request@lprng.com with the word subscribe in
1678 the body. The software is available from
1679 ftp://ftp.lprng.com/pub/LPRng.
1680 !!AUTHOR
1681
1682
1683 Patrick Powell
1684 ----
This page is a man page (or other imported legacy content). We are unable to automatically determine the license status of this page.