lpd

Hurricane Electric Internet Services: Accounts starting at $9.95/month
Hurricane Electric Internet Services

NAME

       lpd - line printer daemon


SYNOPSIS

       /usr/local/bin/lpd [-Llogfile] [-F] [-V] [-i] [-Ddebugopt]


DESCRIPTION

       The lpd program is the printer server program of the LPRng
       software suite.  This software is an enhanced and modified
       version of the Berkeley LPD software.


OPTIONS

       -L logfile
            specifies an alternate file to be  used  for  logging
            error and debugging messages.  The syslog(8) facility
            is used to log critical messages as well.

       -F   Under normal operation, the LPD server  will  run  in
            background  mode.   The  -F  flag forces it to run in
            forground mode, where it is more easily debugged.

       -V   Print program version information.

       -D debugopt
            Debugging is controlled using  the  -D  option.  This
            accepts a comma-separated list of debugging settings.
            These settings take one of two forms:  facility=value
            ,  or  value  to  set  an overall default value.  The
            available facilities can be  determined  by  invoking
            LPD with the -D= parameter.


OPERATION

       Lpd  is  the line printer daemon (spool queue handler) and
       is normally invoked at boot time from the rc(8)  file;  it
       can  also  be started by a user.  Note that the lpd server
       needs  only  run  on  systems  where  actual  printing  or
       spooling  is  taking  place.   lpr(1)  and  other  related
       programs transfer files using network  facilities  to  the
       lpd .

       When  started,  lpd  reads  a configuration file to obtain
       basic  operational   parameters   and   then   reads   the
       printcap(5)  database  information  to determine the which
       printers have spool queues and to start spool queue server
       processes.   If  running  as  a server, it will disconnect
       from its control terminal and run in the background, using
       the  system  calls  listen(2)  and  accept(2)  to  receive
       requests to print files in the queue,  transfer  files  to
       the spooling area, display the queue, remove jobs from the
       queue, or perform a spool queue control function.  In each
       case it creates one or more server processes to handle the
       request and the lpd process will listen for more requests.

       Sending  the  server  a SIGHUP signal causes the server to
       reread  the  various  configuration  and  inititialization
       files.   This  action  is similar to that of the INETD and
       other servers.  The same  action  is  taken  when  sent  a
       reread command by the lpc(1) program.

       LPD access control is provided by two means: the pathnames
       or   programs   specified   by    the    printer_perm_path
       configuration information and the printcap XU (check user)
       entry.  These entries consist of a list of files separated
       by colons and/or a set of filters.  For example:
            /etc/lpd.perms:|/usr/local/lib/perms

       would  specify a file and a filter.  The filter program is
       invoked  with  the   filter_options   specified   in   the
       configuration  information,  and  is  sent the name of the
       printer on the filter standard input.  The  filter  should
       respond  by  writing  a list of permissions entries on its
       standard output.

       Each LPD service request is check against the  entries  in
       the   permissions   file   and/or  filter  response.   The
       following is a typical permissions file:
              # Set default permissions
              DEFAULT ACCEPT
              # Reject any connections from outside our subnet
              REJECT SERVICE=X NOT IP=130.191.0.0/255.255.0.0
              # Only accept Printing (P) and spooling (LPR) from
              # Engineering Lab or the Dean's office
              REJECT SERVICE=P,R NOT REMOTEHOST=*.eng.sdsu.edu,dean.sdsu.edu
              # Do not accept forwarded jobs for printing
              REJECT SERVICE=P FORWARD
              # Allow only the administrators control access
              ACCEPT SERVICE=C,M REMOTEHOST=spooler.eng.sdsu.edu USER=root,papowell
              ACCEPT SERVICE=C,M SERVER REMOTEUSER=root,papowell
              # Allow only the user on the same host who spooled job to remove it
              ACCEPT SERVICE=M SAMEUSER SAMEHOST
              REJECT SERVICE=M,C


       Permission checking is done by using a  set  of  keys  (or
       fields)  with  associated  values to check for permission.
       The  SERVICE  key  has  value  P   for   printing   (i.e.-
       unspooling),  R  for spooling (i.e.- LPR request), C and S
       for printer control and  status  respectively  (i.e.-  LPC
       request),  M for removal (i.e.- LPRM request), Q for queue
       information (i.e.- LPRM request), and so forth.   The  key
       indicates  the  initial connection to the LPD spooler, and
       can be used to control connections  from  remote  systems.
       The  values  of the USER, HOST, and IP keys taken from the
       control file  which  is  being  received  or  checked  for
       permissions.  The REMOTEUSER, REMOTEHOST and REMOTEIP keys
       are those either sent as part of  a  command,  or  derived
       from  information  about  the  current network connection.
       Each line of the permissions file is scanned for key names
       and values, and these are matched against the request keys
       information.  When all matches on a line  are  made,  then
       search    terminates    with    the    specified    action
       (ACCEPT/REJECT).   If  no  match  is  found  the   default
       permission  value  is  used.   The  DEFAULT key is used to
       specify the current default  permission  to  be  used  for
       successful  matches or if there is no match after scanning
       the entire permissions database.

       The GROUP entry is  used  to  check  that  the  USER  name
       appears  in  a  group  entry  in  the  system  user  group
       database.  For example, GROUP=student*,staff* would  check
       to  see  if  any  of  the  group name matching student* or
       staff* have the specified user name in them.  If a  system
       has the I netgroups capability, a group name starting with
       a @P will be treated as a netgroup name, and current  user
       name  from  the job file will bechecked to see if it is in
       the group.  Similarly, the REMOTEGROUP entry will check  a
       remote  user  name.   The PORT entry can be used to ensure
       that a connection to the server orignates from a specified
       range of ports.

       The  permissions database is scanned in order of the fixed
       file entries and then by invoking  the  specified  filters
       for each of the permissions lists.  It is recommended that
       the filters be placed at the end of the permissions lists.
       The  user  name  is  one  of  the parameters passed to the
       filter, and can  be  used  to  determine  if  a  user  has
       permissions to print a file.

       Key          Match Connect Job   Job    LPQ  LPRM  LPC
                                  Spool Print
       SERVICE      S     'X'     'R'   'P'    'Q'  'M'   'C,S'
       USER         S     -       JUSR  JUSR   JUSR JUSR  JUSR
       HOST         S     RH      JH    JH     JH   JH    JH
       GROUP        S     -       JUSR  JUSR   JUSR JUSR  JUSR
       IP           IP    RIP     JIP   JIP    RIP  JIP   JIP
       PORT         N     PORT    PORT  -      PORT PORT  PORT
       REMOTEUSER   S     -       JUSR  JUSR   JUSR CUSR  CUSR
       REMOTEHOST   S     RH      RH    JH     RH   RH    RH
       REMOTEGROUP  S     -       JUSR  JUSR   JUSR CUSR  CUSR
       REMOTEIP     IP    RIP     RIP   JIP    RIP  RIP   RIP
       CONTROLLINE  S     -       CL    CL     CL   CL    CL
       PRINTER      S     -       PR    PR     PR   PR    PR
       FORWARD      V     -       -     SA     -    SA    SA SA
       SAMEHOST     V     -       SA    -      SA   SA    SA
       SAMEUSER     V     -       -     -      SU   SU    SU
       SERVER       V     -       SV    -      SV   SV    SV

       KEY:
          JH = HOST          host in control file
          RH = REMOTEHOST    connecting host name
          JUSR = USER        user in control file
          CUSR = REMOTEUSER  user from control request
          JIP= IP            IP address of host in control file
          RIP= REMOTEIP      IP address of requesting host
          PORT=              connecting host origination port
          CONTROLLINE=       pattern match of control line in control file
          FW= IP of source of request = IP of host in control file
          SA= IP of source of request = IP of host in control file
          SU= user from request = user in control file
          SA= IP of source of request = IP of server host

       Match: S = string with wild card, IP = IPaddress[/netmask],
          N = low[-high] number range, V = exact value match
       SERVICE: 'X' - Connection request; 'R' - lpr request from remote host;
           'P' - print job in queue; 'Q' - lpq request, 'M' - lprm request;
           'C' - lpc spool control request; 'S' - lpc spool status request
       NOTE: when printing (P action), the remote and job check values
          (i.e. - RUSR, JUSR) are identical.


       The  special key letter=patterns searches the control file
       line starting with the (upper case) letter, and is usually
       used  with  printing  and  spooling  checks.  For example,
       C=A*,B* would check that the class information (i.e.- line
       in  the control file starting with C) had a value starting
       with A or B.


PRINTCAP DATABASE

       Individual printer operations are controlled by values  in
       the printcap database.  See printcap(5) for details of the
       format and content of the various entries.  The  following
       are  typical  printer  entries  for  a  local  and  remote
       printer.

              # main or shared printcap file - usually /etc/printcap
              # remote postscript printer
              fullpage
                 |postscript
                 :lp=postscript@farside.sdsu.edu
              # give access to (remote) hosts
              t1|postscript2
                 :cm=Test Printer 1
                 :lp=postscript2@nearside.sdsu.edu

              # local printcap file
              # specification for local printer on nearside
              t1|postscript2
                 :oh=nearside.sdsu.edu
                 :cd=/usr/spool/LPD/safe
                 :sd=/usr/spool/LPD/t1
              #
              # /usr/spool/LPD/t1/printcap file -
              t1:
                 :lp=/dev/pr
                 :if=/usr/lib/pr/if
                 :of=/usr/lib/pr/if

       Printcap information  can  be  distributed  by  individual
       files  or  shared  using  NSF,  YP,  or other methods; see
       lpd.conf(5) for the  exact  details  of  the  location  of
       printcap  files  and  programs, given by the printcap_path
       and lpd_printcap_path configuration  information.   The  a
       common  printcap  configuration is to have a main (shared)
       printcap  database  which  is  used  by  all  hosts.   The
       printcap   information   is   usually   extremely  simple,
       consisting only of the  printer  name  and  host  (i.e.  -
       fullpage printer entry).

       On  hosts  which  have  printers  attached or which are to
       provide  spooling  queue   directories,   more   extensive
       printcap  information  is needed.  In the shared database,
       oh (options for specified host only) field  restricts  use
       of  this  entry  to  the  specified  host.  This entry can
       contain host specific information, such as the location of
       the  spool  queue  and/or  actual  device  to  be used for
       output.

       In the above example,  the  main  printcap  file,  usually
       /etc/printcap,  has  entries  for all printers.  Note that
       these entries do not specify the spool directories (sd and
       cd  fields), but this could be provided.  On a host with a
       printer specific information can be provided  in  serveral
       ways.   The  simplest is to simply put an additional entry
       in the shared printcap file, with the oh field set to  the
       support host name.  An alternative would be to specify the
       spool  directories  (sd  and  cd  fields)  in  the  shared
       information,  and  to put the printer specific information
       in a printcap file.

       The printcap information  is  obtained  in  the  following
       order.  All programs use the contents of the configuration
       printcap_path variable to  get  a  list  of  locations  of
       printcap  files.  In addition, the lpd program appends the
       contents   of    the    lpd_printcap_path    configuration
       information.   Next,  each  of these entries is processed,
       and the printcap information is extracted.  Entries  which
       have  oh  fields are only used by the specified host.  The
       files and information is processed in linear order,  later
       entries overriding preceeding ones.

       When  processing  jobs  or performing spool queue specific
       requests, the LPD server will check to see if there  is  a
       printcap file in the control directory for the spool queue
       and the contents will be processed.  Since  only  the  LPD
       server  has  access  to the spool and control queues, this
       information is processed only by the server.

       In addition to files, printcap information can be obtained
       from  programs or filters.  For example, the printcap_path
       of the form will use the contents of the  file,  and  then
       use  the  program  to  get  information  about  a specific
       printer.  When information about a particular spool  queue
       is  needed  and  one  or more filters are specified as the
       source of printcap information, then the  filter  will  be
       started  and  the  printer  name  written  on its standard
       input.  The filter must provide a printcap entry  for  the
       requested printer on its standard output.

       The  filter  can  be  used  to  interface  to databases or
       nonstandard  information  sources  which  do  not  produce
       printcap information in an acceptible form.


SPOOL DIRECTORY CONTENTS

       Each  spool  queue has a spool directory (sd) and optional
       control directory (cd)  where job and control  information
       is  kept.   Under  normal  operation the spool and control
       directories are identical, but if the spool  directory  is
       NFS exported for use by other printer spoolers which write
       files  directly  into  the  spool  queue,   then   it   is
       recommended  that  the  control  directory  be  a separate
       directory and not NFS mounted.  The  following  files  are
       used  for  printer operations.  Per job entries are marked
       with an asterisk (*).

       File Name         Dir  Purpose
       printer           CD   lock file and server process PID
       unspooler.printer CD   subserver process PID
       control.printer   CD   queue control information
       *sfAnnnHOST       SD   job hold file
       *cfAnnnHOST       SD   job control file
       *dfAnnnHOST       SD   job data file
       *filternnnn       SD   bounce queue filter temp file


       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.

       The  lock  file  is  used  to  prevent  multiple job queue
       servers from becoming active simultaneously, and to  store
       the  server process id.  The lock file name is the name as
       the printer name; all other control files have the printer
       name appended as indicated above.

       The   printer  spool  control  file  contains  information
       controlling the queue operations.  It consists of a series
       of  lines  with  keywords  and values to control printing,
       spooling,  and  automatic  job  holding  operations.   The
       following is an example of a typical control file.

              spooling_disabled 0
              printing_disabled 1
              autohold 0
              redirect p1@host2
              debug 10,log=/tmp/log
              class A


       The   spooling_disabled   and   printing_disabled  entries
       control spooling and printing; the  lpc  enable,  disable,
       start,  and stop command alter these values.  The autohold
       entry  will  prevent  jobs  from  being  processed   until
       released  with  the  lpc  hold or release comands; the lpc
       autohold and noautohold commands alter these values.

       The redirect entry causes the lpd server to  forward  jobs
       to  the specified remote printer; the lpc redirect command
       alters this field.  The class field controls the class  of
       jobs  being  printed.   By  default,  the class value is a
       pattern that matches  the  class  entry  in  a  job  file;
       however  a  entry  of  the form letter=patterns will print
       jobs whose control file line starting with letter  matches
       one  of  the  patterns.   The debug line provides a set of
       debugging parameters for diagnostic  information  for  the
       particular spool queue.

       Each  print job consists of a control file and one or more
       data files.  Lines in the control file  file  specify  the
       job  data  files or parameters for the job and the general
       format of the file is specified  by  RFC1179.   Each  line
       consists  of  a flag character and a parameter; upper case
       and  digit  characters  specify  options  and  lower  case
       letters  specify  the  printing  format  and names of data
       files.  The following is a list of the control  file  flag
       characters.


       A      Identifier   A  job  identifier  to  be  used  when
              displaying  job  information  and/or  status.   The
              insertion   of  this  line  is  controlled  by  the
              use_identifier printcap/configuration variable.


       C      Class String to be used for the class line  on  the
              burst page.

       H      Host  Name.   Name  of  the  machine  where lpr was
              invoked.

       I      Indent.  The number of  characters  to  indent  the
              output by (in ascii).

       J      Job  Name.   String  to be used for the job name on
              the burst page.

       L      Banner user name.  Information for banner page.

       P      Person.  Login name of the person who invoked  lpr.
              This is used to verify ownership by lprm.

       M      Send  mail  to  the specified user when the current
              print job completes.

       N      File name.  The original name of a data file  which
              is in the job.

       T      Title.   String  to  be used as the title for pr(1)
              when the LPR -p option was specified.

       U      Unlink.   Job  file   to   remove   when   printing
              completed.

       W      Width.  The  page width (in characters) to used for
              printing.

       Z      zoptions. Options passed by lpr -Zzoptions.   These
              are passed to output filters to aid in printing.

       f      Formatted  File.   Name of a file to print which is
              already formatted.

       l      Like ``f'' but passes control characters  and  does
              not make page breaks.

       p      Name of a file to print using pr(1) as a filter.

       t      Troff File.  The file contains troff(1) output (cat
              phototypesetter commands).

       d      DVI File.  The file  contains  Tex(l)  output  (DVI
              format from Stanford).

       g      Graph  File.   The  file  contains data produced by
              plot(3X).

       c      Cifplot File. The file contains  data  produced  by
              cifplot.

       v      The file contains a raster image.

       r      The  file  contains text data with FORTRAN carriage
              control characters.

       1      Troff Font R. Name of the font file to use  instead
              of the default.  (Obsolete)

       2      Troff  Font I. Name of the font file to use instead
              of the default.  (Obsolete)

       3      Troff Font B. Name of the font file to use  instead
              of the default.  (Obsolete)

       4      Troff  Font S. Name of the font file to use instead
              of the default.  (Obsolete)


       Each job in the spool queue can  have  an  associated  job
       hold  file  which is used by the server process to control
       the  printing  of  the  job.   The  status  file  contains
       information  controlling  the  job  hold  status and error
       status.  The spool server will attempt to print  a  job  a
       limited number of times before abandoning it or setting an
       error status in the job status file.  The following  is  a
       typical job hold file.
              hold          0   priority     0  active       2135
              redirect remove      0 error

       A nonzero hold entry  will  prevent  the  job  from  being
       processed;  the  lpc hold and release commands update this
       field.  The priority field overrides the  normal  first-in
       first-out  printing  priority; jobs with non-zero priority
       fields are printed first.  The lpc  topq  command  updates
       this  field.   If the active field is non-zero, the job is
       being printed by the server with the specified process id.
       The  redirect field allows individual jobs to be forwarded
       to a different printer; the lpc move command updates  this
       field.   Finally,  the remove and error fields are used to
       control printing of problem jobs.  The remove field is set
       when  a  job  should  be  removed; the error field records
       information that would prevent a job from being printed.


JOB SUBMISSION

       The LPR program is used to  submit  a  job  to  the  LPRng
       system.   The  LPR  program  opens a connection to the LPD
       server and then transfer the job  control  file  and  data
       files.   The  LPD  server checks to see if the remote host
       and  user  has  permissions  to  spool  to  the  requested
       printer,  and  then  checks  to  see  if  the  printer  is
       accepting jobs.  If both conditions are met,  the  job  is
       accepted and the control and data files are placed int the
       spool directory.  The LPRng  software  sends  the  control
       file first, followed by the data files.

       If  the  LPR  program  is  acting  as  a filter, it is not
       necessary to create a data file on the local machine.  The
       input  data  can  be  sent  directly to the LPD server for
       spooling.  However, some other LPD servers do  not  accept
       this  action,  even though it is specified by the RFC1179.
       The LPR -k (seKure) option allows this direct transmission
       mode.


FORWARDING OPERATIONS

       The  LPD  system can forward jobs from one spool directory
       to another.  This is controlled by the following  options.

       1.   The  forward  field  in  the spool control file has a
            value rp@rm.

       2.   The lp (line printer) printcap  entry  has  the  form
            rp@rm.

       3.   There  is  a  rm  (remote  machine)  and  optional rp
            (remote printer) printcap entry.

       The first of the above conditions to be met will determine
       the  destination.   If printing is enabled, then jobs will
       be forwarded to the remote destination.

       The LPD server uses the same algorithm for sending jobs as
       the  LPR  program.   A  connection  is  made to the remote
       server and the files are copied to the server.  A  set  of
       timeouts  is  used  to  control  error  recover  and retry
       operations.   The  printcap  and  configuration  variables
       connect_timeout,   connect_retry,   connect_interval,  and
       connect_grace control connecting to the remote host.  If a
       connection   is   not   completed  within  connect_timeout
       seconds, the connection is aborted,  and  then  after  the
       connect_interval  seconds it is retried.  This is done for
       connect_retry  times,  and  then  the  job  processing  is
       terminated.   A timeout value of 0 indicates no timeout; a
       retry value of 0 specifies infinite retries.  After a  job
       has  been  successfully  printed, the connection is closed
       and the server  waits  for  connect_grace  seconds  before
       trying to reconnect.


BOUNCE QUEUES

       A  bounce  queue is a special queue that allows jobs to be
       passed through various filters before  being  sent  to  an
       final  destination.   The  entry  must  specify the bounce
       queue name on the server.  This will force all jobs to  be
       passed to the bounce queue for processing.  The field must
       specify the final destination for  jobs  after  filtering.
       Data  files  are  passed  through  the  appropriate format
       filter before transfer to the destination.  If there is no
       format filter, then no processing is done and the original
       file is transferred.  See PRINTING OPERATIONS for  details
       about  filters.  For example, the following printcap entry
       will filter format f files.  testbq:sd=/usr/spool/testbq:
         :lp=testbq@host:bq=final@host
         :if=/usr/lib/filter_for_f
         :mf=/usr/lib/filter_for_m
         :pf=/usr/lib/filter_for_pr
         :translate_format=mfpf

       When using a bounce queue, it is  sometimes  desirable  to
       have  the  filters actually change the format types of the
       job as well as processing the data.  This  conversion  can
       be  forced  using the printcap entry.  This entry consists
       of pairs of lower case characters of the form  SdSd...;  S
       is  the  original  and d is the translated format.  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 command -
       the  filter  must  do  both  the  pr  processing  and  any
       necessary format conversions.


SPOOL QUEUE NAME OPTION

       The  printcap entry and the configuration entry causes the
       name of the spool queue to be placed in  the  job  control
       file.   This  value can be used by the filter to determine
       how to process a job.  When combined with the use  of  the
       Bounce  Queue,  this  can  be used to reformat jobs before
       sending to another printer spooler system.


PRINTING OPERATIONS

       When printing is enabled, the LPD  server  will  create  a
       spool  server  process  to  carry out printing operations.
       For each job in the queue, the spool server  process  will
       create  a  subserver  process  to  carry  out  the  actual
       printing operations.  If the subserver process fails,  the
       server  process  will  initiate  recovery operations.  Job
       will be attempted to be printed until all are  done  or  a
       subserver  returns  an  ABORT  indication; the server will
       then terminate operations.

       The server process  normally  scans  the  queue  once,  at
       initiation; if the spool control file is modified, usually
       by using the lpc command, the spool queue is rescanned.

       controlling job printing.  The overall algorithm  for  job
       printing   is:   open   the   print   device,   send  some
       initialization strings, send a banner to the device,  send
       the  job  data  files to the device, send some termination
       strings, and close the print device.  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.

       OF Filter
            The  'of'  filter  is used for initialization, banner
            printing and the termination  strings.   It  has  the
            peculiar  property  of  suspending itself when sent a
            special escape string, allowing other filters  to  be
            used to print the individual job files.

       Data Filters
            Each  data  file  in  a job has format specified by a
            lower  case  character  and  an   associated   filter
            specified in the printcap file.  For example, the 'g'
            format is printed by the 'gf' filter, and  so  forth.
            By  convention,  the 'if' filter is used to print 'f'
            (ordinary text) and 'l' (binary) format jobs.

       lp-pipe Filters
            If the printcap device  specification  has  the  form
            |program  then  the  output device is accessed by the
            specified program.  This allows the program  to  take
            care  of any required initialization or communication
            requirements.

       The following is a concise summary of the actual algorithm
       used  to print files.  Note that LP stands for the printer
       device or filter specified by the 'lp' printcap entry;  OF
       stands  for  the  'of'  printcap filter; IF is the default
       'if' filter; BP is the  banner  printing  filter;  and  ?F
       stands  for  the  filter  for  data file.  The '??' values
       stand for entries from the printcap file.

       LP = open( 'lp' );  // open device or filter
       OF = IF = LP;       // set defaults
       set up accounting according to 'af' entry;
       if( 'of' ) OF = filter( 'of' ) -> LP;// make OF filter
       if 'as' then record start of job accounting information.
       if 'achk' then check for accounting limits.
       if( leader on open 'ld' ) `ld` -> OF// send leader
       if( FF on open 'fo' ) `fo` -> OF    // send leader

       // print a banner
       // first check to see if required
       //   and then to see if not suppressed by printcap
       //   or by user
       do banner =
           (always banner 'ab'
               || (!suppress banner 'sb' && job has banner ));
       if( ! header last 'hl' && do banner ){
           BP = OF;
           if( banner program 'bp' ){
               BP = filter( 'bp' ) -> OF;
           }
           short banner info -> BP;
           if( BP != OF ) close( BP );
       }

       // now we suspend the OF filter, use other filters
       if( OF != LP ) suspend OF filter;

       for each data file df in job do
           // send FF between files of job
           if( !first job && ! no FF separator 'sf' ){
               if( OF != LP ) wake up OF filter;
               'ff' -> OF;
               if( OF != LP ) suspend OF filter;
           }

           // get filter for job
           format = jobformat;
           if( jobformat == 'f' or jobformat = 'l' ){
               format = 'f';
           }
           filter = check pc for filter for format;
           ?F = LP; // default - no filter
           if( filter ){
               ?F = filter( filter ) -> LP;
           }

           data file -> ?F;
           if( ?F != LP ) close( ?F )
       endfor

       // finish printing

       if( OF != LP ) wake up OF filter;
       if( header last 'hl' && do banner ){
           if( ! no FF separator 'sf' ){
               'ff' -> OF;
           }
           BP = OF;
           if( banner program 'bp' ){
               BP = filter( 'bp' ) -> OF;
           }
           short banner info -> BP;
           if( BP != OF ) close( BP );
       }

       if( ff on close 'fq' ){
           'ff' -> OF;
       }

       if( trailer on close 'tr' ){
           tr -> OF;
       }

       if 'ae' then record end of job accounting information.

       if( OF != LP ) close( OF );
       close( LP );


       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.

       After  the job print or transfer attempt, if the job is to
       be removed and  the  printcap  variable  save_on_error  is
       true, the job will not be removed from the spool queue but
       only flagged with an error.  The job can then  be  retried
       at a later time.  If the job is successfully printed it is
       usually removed from the spool  queue.   However,  if  the
       printcap  variable  save_when_done  is  true  the job will
       merely be marked as completed and  not  removed  from  the
       queue.


FILTERS

       As  described in the previous section, filters are created
       to handle output to devices or other filters.  The command
       line  to  invoke  a  filter  is generated in the following
       manner.

       1.   The printcap entry or  configuration  value  defining
            the filter command is obtained.

       2.   STDIN  (file descriptor 0) of the filter will be sent
            the file to be printed or in the case of OF filters a
            banner  line;  STDOUT   (file  descriptor  3)  of the
            filter will be either an output device or  /dev/null;
            STDERR  will  be  set  to  an error logging file.  If
            accounting is enabled, file descriptor 3 will be  set
            to  be  the accounting file or filter as indicated by
            the printcap af entry.

       3.   If the ROOT_PERMS_TO_FILTER_SECURITY_LOOPHOLE compile
            time  option  is  enabled, then filter specifications
            starting with ROOT filtername will  be  run  as  root
            (EUID = 0).  This can be a serious security loophole,
            and should only be used as a last resort for specific
            problems.

       4.   Options  have  the  form  $[0| ][-][']X.  The default
            option expansion has the form $X  ->  -X'value';  the
            form  $0X  or  $(space)X  adds  a space after the -X,
            i.e.- $0X -> -X 'value'; the form $-X suppresses  the
            -X,  i.e.  -  $-X  ->  'value';  and  the  form  $'X'
            suppresses the quotes around the  value.   Note  that
            the  0,-, and ' can be combined. For example, $-'X ->
            value.  The options will be exanded as follows:

            Key  Value
            a    Accounting file (printcap 'af')
            b    Job size, i.e.- total data file size, in bytes
            c    if binary (format 'l') expands to -c
            d    Control directory
            e    job data file
            f    original print file name
            h    Control file hostname
            i    Control file indent (I) field
            k    Control file name
            l    printcap Page length (pl) value
            m    printcap Cost factor (co) value
            n    Control file user name (P) field
            p    Printer name
            s    printer Status file (ps) value
            t    current time in simple format
            w    printcap Page width (pw) value
            x    printcap x dimension (px) value
            y    printcap y dimension (py) value
            F    data file format character
            P    Printer name
            S    printcap Comment tag (cm) value
            Other    control file line starting with key letter or number


       5.   If the command line does not have any entries of  the
            above   form,  then  the  options  specified  by  the
            filter_options configuration value will be added.  To
            suppress  adding  options,  you  can use the form '-$
            filter',  i.e.  -  of=-$/bin/cat.    If   the   'bkf'
            (backwards  compatible  filter options) printcap flag
            is set, the of filter is given the options  specified
            by  bk_of_filter_options  and  other filters those by
            bk_filter_options.  The following shows  the  various
            combinations  possible,  and  typical  values for the
            options.

            Options
            filter_options    $C $F $H $J $L $P $Q $R $Z $a $c $d $e $f $h $i \
                              $j $k $l $n $s $w $x $y $-a
            bk_filter_options $P $w $l $x $y $F $c $L $i $J $C $0n $0h $-a
            bk_of_filter_options $w $l $x $y


ACCOUNTING

       The LPRng software provides several methods of  performing
       accounting.  The printcap af (accounting field), as and ae
       (accounting start and end), and  achk  (accounting  check)
       provide a basic set of facilities.  The af field specifies
       a file, filter, or TCP network connection to an accounting
       server.   If  af has the form |filter or |-$ filter then a
       filter will be started and all accounting information will
       be  sent  to the filter.  The first form passes the filter
       the command line options specified by  the  filter_options
       configuration  variable  and  the second suppresses option
       passing.   If  af  has  the  form  host%port  then  a  TCP
       connection  will  be  opened  to the port on the specified
       host and accounting information  sent  there.   All  other
       forms  will be treated as a pathname relative to the queue
       spool directory.

       When af specifies a filter or network connection  and  the
       achk   flag  is  set,  then  after  writting  the  initial
       accounting information (see as printcap field  below)  the
       server  will  wait for a reply of the form ACCEPT from the
       filter or server.  If not received, the job  will  not  be
       printed.

       The  as  (accounting start) and ae (accounting end) fields
       can specify a string to be printed or a  filter.   Options
       in  the  string  will  be expanded as for filters, and the
       strings  printed  to  either  the  accounting  information
       destination.  If the as field specifies a filter, then the
       print server will wait  for  the  filter  to  exit  before
       printing  the  job.  If the exit status is 0 (successful),
       the job will be printed.  A non-zero JREMOVE  status  will
       remove  the  job,  while  any  other status will terminate
       queue printing operations.  After printing the job, the ae
       filter  will be started and the server will wait for it to
       complete before printing the next job.

       The as and ae filters will have STDOUT set to the printing
       device  and or filter, and the STDERR set to the error log
       file for the print queue, and fild descriptor 3 set to the
       destination specified by the af field.

       As  a convenience, all format filters for printing will be
       started with file descriptor  3  set  to  the  destination
       specified  by  the  af field.  This allows special filters
       which can query devices for  page  counts  to  pass  their
       information directly to an accounting program.


LOGGING INFORMATION

       In  order  to  provide  a centrallized method to track job
       status and information, the printcap/configurtion variable
       logger_destination  enable  the  send  of status and other
       information    to    a    remote     destination.      The
       logger_destination value has the form
       host[%port][,protocol]

       (R)Examples:

       taco%451,UDP
       dickory%2001,TCP
       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.
       IDENTIFIER jobid [PRINTER name] at timestamp
       STATUS | TRACE | FILTER_STATUS PID nnn
        ( status information)

       The status information format consists of an identifier line,
       followed by a specifier of the status type.
       The logging information entry is terminated by a line with a single period on it.
       Lines with a starting period have the period duplicated.


FILES

       The  files  used by LPRng are set by values in the printer
       configuration file.  The following are a commonly used set
       of default values.
       /etc/lpd.conf                                LPRng configuration file
       /etc/printcap                                printer description file
       /etc/lpd.perms                               printer permissions
       /var/spool/printer*                          spool directories
       /var/spool/printer*/printcap                 printer specific printcap information
       /var/spool/printer*/printer                  lock file for queue control
       /var/spool/printer*/control.printer          queue control
       /var/spool/printer*/active.printer           active job
       /var/spool/printer*/log.printer              log file


SEE ALSO

       lpd.conf(5),  lpc(8),  lpd(8),  lpr(1),  lpq(1),  lprm(1),
       printcap(5), lpd.perms(5), pr(1).


DIAGNOSTICS

       Most of the diagnostics are self explanatory.
       If you are puzzled over the exact cause of failure,
       set the debugging level on (-D5) and run again.
       The debugging information will
       help you to pinpoint the exact cause of failure.


HISTORY

       LPRng  is  a  enhanced  printer   spooler   system,   with
       functionality similar to the Berkeley LPR software, and is
       derived from  the  PLP  (Public  Line  Printer)  software,
       version  4.0.  LPRng has many advanced features, which are
       described in LPRng - An Enhanced Line Printer  Spooler  by
       Patrick     Powell,    San    Diego    State    University
       (papowell@sdsu.edu),  et  al.   It   is   available   from
       dickory.sdsu.edu:/pub/LPRng.

       The  LPRng  software  is  based  on  PLP4.0, supported and
       extended  by  Justin  Mason  (jmason@iona.ie),  which   is
       available   from   ftp://ftp.iona.ie/pub/PLP4.0.    Justin
       greatly aided in the design and development of many of the
       software  features, as well as contributing a large number
       of bug fixes, design reviews, and other suggestions.
Hurricane Electric Internet Services: Accounts starting at $9.95/month
Hurricane Electric Internet Services
Copyright (C) 1998 Hurricane Electric. All Rights Reserved.