PLP is a portable, reliable implementation of the BSD Line Printer
Spooler (LPD) system. Some features that improve on most BSD-based
LPD implementations:

*   Configurability: a configuration file is used, and additional
    features are turned on or off from there; additional configuration
    files are also specified there. See the file "examples/plp.conf.nfs"
    for a sample configuration file.

*   The PLP software can be used with NFS spool directories,
    in which there is a common set of spool queues, as well as the
    usual environment where each host transfers print jobs to a
    common host.

*   several methods of simplifying administration of a network of
    printers: printcap entries are taken from more than one file,
    printcap files can include other files, and printer names
    can be qualified on a per-host basis. These, in conjunction with
    a plp.conf file and NFS spool queues, greatly simplify spooler
    administration in a networked environment.

*   instead of outputting directly to a device, PLP can output to
    a filter-like process called an LP-pipe, which handles talking
    to the printer device. The PLP distribution includes three
    ready-to-use LP-pipes: tcp-lp, for TCP sockets; annex-lp,
    for Annex ports; and hpnp-lp, for the HP Network Peripheral
    toolkit's `hpnpf' (used to talk to HP LaserJets which are
    fitted with a JetDirect card).

*   Input-filters can be used in a remote-printer printcap entry,
    ie. one where the file is forwarded to another host for printing.
    In addition, remote-printer sequences ("rm", "rp" printcap entries)
    with more than two entries are possible.

*   PLP supports Sun LPD-style free space monitoring, where jobs
    will be temporarily delayed if a spool directory's filesystem
    becomes full.

*   Jobs can be moved from queue to queue, can be held without affecting
    other jobs, and the order of jobs in a queue can be changed. A
    queue can be "attached" to another queue, causing jobs submitted
    to the first queue to be rerouted to the second.

*   The EUCS PLP functionality has been integrated, including:

*   printcap lookups can use Hesiod and NIS databases instead of files.

*   "Cost codes", extended job size limitation functionality,
    See doc/README.Edinburgh for more details.

*   The PLP daemon can run from inetd, resulting in reduced virtual
    memory usage and more reliability at the expense of request
    turn-around time.

*   Verbose error and diagnostic messages have been added.  These
    greatly ease debugging and installation.  In addition, the
    "checkpc" utility can be used to set file permissions and other
    items for use by the PLP software.  The PLP daemon can also fix
    some common permissions problems on-the-fly.

*   Security: environment variables are completely sanitized before
    exec()s. PLP checks any command lines before exec()ing, logging an
    error message if shell metacharacters are embedded in them in such
    a way as to create a security hole.  "root" and "daemon"
    permissions are used only when they are explicitly needed; "user"
    permissions are used at all other times, thereby reducing the
    window of opportunity for hackers. Care has been taken to avoid the
    possibility of users overflowing buffers to create a security
    breach. Atomic-exclusive-open emulation is implemented for NFS
    filesystems.

*   Specific security holes avoided: PLP is immune to the [8lgm]
    Advisory 3 hole, and the symlink race condition.

*   Access and permission to use PLP functions is controlled by
    entries in a printer permissions file which can restrict use by
    user name, host, spooler, page useage, and a host of other
    factors.  The printcap file is used to specify the printer queues
    and their operation.

*   Jobs can now be prioritized. The maximum priority a user can
    specify is set in the printer permissions file.

*   In addition to the general printer permissions file, each spool
    queue can have its own additional printer permissions file.

*   Line printer control functions can be exercised from a remote host.
    Hosts and users with remote control permissions are specified
    by entries in the printer permissions file.

*   The unspooling of jobs can be performed by a user defined program,
    rather than the spooler.  This allows the spooler to be used to
    send jobs to remote sites using various file transfer protocols.

