This chapter used to the the `lpd-FAQ' then it became part of the
`Linux-FAQ' and now it is part of the Printing-HOWTO. Who knows where
it will go next?
* Menu:
* Setting up print services::
* What lpr & lpd do::
* Getting hold of lpd::
* lpd files and permissions::
* lpd not working::
* Where Do I Get A Printcap For Printer Model xxxxx?::
* The Semantics of /etc/printcap::
* The Syntax of /etc/printcap::
* An /etc/printcap gotcha::
* The Minimum /etc/printcap::
* The staircase effect::
* Resetting The Printer After Each Printout::
* Preventing FF each file::
* lpd via serial port::
* serial port cop out::
* Printers not in /dev::
* Burst/banner pages::
* Spooling text to a PS printer::
* Trunation of graphics files::
* Why lpr -i does not work::
* Why lpr -p does not work::
* "no daemon present"::
* lpr over a network::
* Writing lpd filters::
* Debuging filters::
* Output filters::
* Filters for given printers::
* Programs that do not read STDIN::
* Many filters::
* Magic Filters::
* Magic Filter Examples::
File: Printing-HOWTO.info, Node: Setting up print services, Next: What lpr & lpd do, Prev: LPR, Up: LPR
Setting up print services
=========================
This section was originally writen Karl Auer <Karl.Auer@anu.oedu.au>
1/11/93 and has now been included here because it was felt that the
Printing-HOWTO, being written in the style of a reference manual, was
not doing its job properly, since it did not describe in a
straightforward way what you need to do to set up print services on your
Linux machine.
So far it has been included with little modification and may
replicate or even contradict information elsewhere in the HOWTO. The
overview it gives should nevertheless be very useful to those new to
bsd print spooling.
* Menu:
* Remote Printing Vs. Local Printing::
* What You Need::
* How Printing Works Under Linux::
* The important programs::
* The lpr command::
* The lpq command::
* The lprm command::
* The lpc command::
* The important directories::
* The important files::
* More about /etc/printcap::
* Fields in /etc/printcap::
* More On The lp Field::
* More on the lf field::
* More on the if field::
* More on the rm and rp fields::
* More on the sh and sf fields::
* More on the mx field::
* A test printcap entry::
* Putting It All Together::
* More On Remote Printing::
* The Fiddly Bits::
* Troubleshooting::
File: Printing-HOWTO.info, Node: Remote Printing Vs. Local Printing, Next: What You Need, Prev: Setting up print services, Up: Setting up print services
Remote Printing Vs. Local Printing
----------------------------------
Remote printing is allowing people to send print jobs to your
computer from another computer. This will be needed if, for example,
you are running as a server in a network, or if a printer attached to
your machine is to be accessible from other Unix hosts.
Local printing is allowing users on your machine to send print jobs
to a printer attached to your machine.
There is a third combination too - your own use of remote printing
on other Unix machines. That is, where you wish to print on a printer
that is not attached to your own computer.
File: Printing-HOWTO.info, Node: What You Need, Next: How Printing Works Under Linux, Prev: Remote Printing Vs. Local Printing, Up: Setting up print services
What You Need
-------------
This document assumes you know how to edit a text file under Linux,
and that you have a basic understanding of file ownership and
permissions.
It also assumes that you have your Linux system set up and running
correctly. In particular, if you are going to use remote printing your
networking subsystems must be installed and operating correctly.
Check out the man pages on the commands `chmod' and `chown' for more
information.
File: Printing-HOWTO.info, Node: How Printing Works Under Linux, Next: The important programs, Prev: What You Need, Up: Setting up print services
How Printing Works Under Linux
------------------------------
The simplest way to print under Unix (and thus under Linux) is to
send the print data directly to the printer device. This command will
send a directory listing to the first parallel printer (LPT1: in DOS
terms):
ls > /dev/lp0
This method does not take advantage of the multitasking capabilities
of Linux, because the time taken for this command to finish will be
however long it takes the printer to actually physically print the
data. On a slow printer, or a printer which is deselected or
disconnected, this could be a long time.
A better method is to spool the data. That is, to collect the print
data into a file, then start up a background process to send the data
to the printer.
This is essentially how Linux works. For each printer, a spool area
is defined. Data for the printer is collected in the spool area, one
file per print job. A background process (called the printer daemon)
constantly scans the spool areas for new files to print. When one
appears, the data is sent to the appropriate printer or *despooled*.
When more than one file is waiting to be printed, they will be printed
in the order they were completed - first in, first out. Thus the spool
area is effectively a queue, and the waiting jobs are often referred to
as being "in the print queue", or "queued".
In the case of remote printing, the data is first spooled locally as
for any other print job, but the background process is told to send the
data to a particular printer on a particular remote machine.
The necessary information that the printer daemon needs to do its
job - the physical device to use, the spool area to look in, the remote
machine and printer for remote printing and so on - is all stored in a
file called `/etc/printcap'. The details of this file are discussed
below.
In the discussions that follow, the term "printer" will be used to
mean a printer as specified in `/etc/printcap'. The term "physical
printer" will be used to mean the thing that actually puts characters on
paper. It is possible to have multiple entries in `/etc/printcap' which
all describe one physical printer, but do so in different ways. If this
is not clear to you, read the section on `/etc/printcap'.
File: Printing-HOWTO.info, Node: The important programs, Next: The lpr command, Prev: How Printing Works Under Linux, Up: Setting up print services
The important programs
----------------------
There are five programs which comprise the Unix print system. They
should be in the locations shown, should all be owned by root and
belong to the group daemon and have the permissions shown here:
-rwsr-sr-x /usr/bin/lpr
-rwsr-sr-x /usr/bin/lpq
-rwsr-sr-x /usr/bin/lpc
-rwsr-sr-x /usr/bin/lprm
-rwxr-s--- /etc/lpd
The first four are used to submit, cancel and inspect print jobs.
`/etc/lpd' is the printer daemon.
(The locations, ownerships and permissions given here are a
simplification and may be wrong for your system *note lpd files and
permissions::.)
There are man pages for all these commands, which you should consult
for more information. The important points are that by default `lpr',
`lprm', `lpc' and `lpq' will operate on a printer called `lp'. If you
define an environment variable called `PRINTER', the name thus defined
will be used instead. Both these may be overridden by specifying the
printer name to use on the command line thus:
lpc -PMYPRINTER
File: Printing-HOWTO.info, Node: The lpr command, Next: The lpq command, Prev: The important programs, Up: Setting up print services
The `lpr' Command
-----------------
The `lpr' command submits a job to the printer, or "queues a print
job". What actually happens is that the file you specify is copied to
the spool directory (see above), where it will be found by `lpd', which
then takes care of moving the data to the physical printer. If you don't
specify a file, `lpr' uses standard input.
File: Printing-HOWTO.info, Node: The lpq command, Next: The lprm command, Prev: The lpr command, Up: Setting up print services
The `lpq' Command
-----------------
The `lpq' command shows you the contents of the spool directory for
a given printer. One important piece of information displayed by `lpq'
is the job id, which identifies a particular job. This number must be
specified if you wish to cancel a pending job.
`lpq' also shows a rank for each job in the queue - "active" means
the file is actually printing (or at least that `lpd' is trying to
print it). Otherwise a number shows you where in the queue the job is.
File: Printing-HOWTO.info, Node: The lprm command, Next: The lpc command, Prev: The lpq command, Up: Setting up print services
The `lprm' Command
------------------
The `lprm' command removes a job from the queue - that is, it
removes unprinted files from the spool directory. You can either specify
a job id (obtained by using the `lpq' command) or specify `-' as the
job id, in which case all jobs belonging to you will be cancelled. If
you do this as root, all jobs for the printer will be cancelled. If you
are root and want to remove all the jobs belonging to a specific user,
specify the user's name.
File: Printing-HOWTO.info, Node: The lpc command, Next: The important directories, Prev: The lprm command, Up: Setting up print services
The `lpc' Command
-----------------
The `lpc' command lets you check the status of printers and control
some aspects of their use. In particular it lets you start and stop
despooling on printers, lets you enable or disable printers and lets you
rearrange the order of jobs in a print queue. The following commands
disable printing on myprinter, enable the spool queue on yourprinter and
move job number 37 to the top of the queue:
lpc down myprinter
lpc enable yourprinter
lpc topq 37
If invoked without any command arguments, lpc will be interactive,
prompting you for actions to take. Read the man page for complete
instructions. Bear in mind that some `lpc' functions are restricted to
root.
File: Printing-HOWTO.info, Node: The important directories, Next: The important files, Prev: The lpc command, Up: Setting up print services
The Important Directories
-------------------------
There is really only one important directory - the spool area where
data to be printed is accumulated before `/etc/lpd' prints it. However,
typically a system will be set up with multiple spool directories, one
for each printer. This makes printer management easier. My system is set
up to use `/usr/spool/lpd' as the main spool area, with each separate
printer having a directory under that with the same name as the
printer. Thus I have a printer called `ps_nff' which has
`/usr/spool/lpd/ps_nff' as its spool directory and so on.
The spool directories should belong to the daemon group and be user
and group read/writable, and world -readable. That is, after creating
the directory make sure it has permissions "-rwxrwxr-x" (0775). For the
directory myprinter, the appropriate command would be:
chmod ug=rwx,o=rx myprinter
chgrp daemon myprinter
(The locations, ownerships and permissions given here are a
simplification and may be wrong for your system *note lpd files and
permissions::.)
File: Printing-HOWTO.info, Node: The important files, Next: More about /etc/printcap, Prev: The important directories, Up: Setting up print services
The Important Files
-------------------
Apart from the programs discussed above, each spool directory should
contain four files - `.seq', `errs'. `lock' and `status'. These files
should have the permissions "-rw-rw-r-". The `.seq' file contains the
job number counter for `lpr' to assign a and the `status' file contains
the message to be reported by `lpc stat'. The `lock' file is used by
`lpd' to prevent itself trying to print two jobs to the same printer at
once, and the `errs' file is a log of printer failures.
The file `errs' is not required and can actually be called whatever
you like - the name is specified in `/etc/printcap', but the file must
exist for `lpd' to be able to log to it, so it is usually created
manually when setting up the spool area. More on this later.
One very important file is the file `/etc/printcap', which is
described in detail in the following sections.
File: Printing-HOWTO.info, Node: More about /etc/printcap, Next: Fields in /etc/printcap, Prev: The important files, Up: Setting up print services
More About /etc/printcap
------------------------
The file `/etc/printcap' is a text file, which may be edited with
your favourite editor. It should be owned by root and have the
permissions "-rw-r-r-".
The contents of `/etc/printcap' are typically very cryptic-looking,
but once you know how it works they are much easier to understand. The
problem is compounded by the fact that in some braindead distributions
there is no man page for printcap, and the fact that most printcaps are
created either by programs or by people with no thought for
readability. For your own sanity, I recommend making the layout of your
printcap file as logical and readable as possible, with lots of
comments. And get the a man page from the lpd sources, if you don't
already have it.
One printcap entry describes one printer. Essentially a printcap
entry provides a logical name for a physical device, then describes how
data to be sent to that device is to be handled. For example, a printcap
entry will define what physical device is to be used, what spool
directory data for that device should be stored in, what preprocessing
should be performed on the data, where errors on the physical device
should be logged and so forth. You can limit the amount of data which
may be sent in a single job, or limit access to a printer to certain
classes of user.
It is perfectly OK to have multiple printcap entries defining several
different ways to handle data destined for the same physical printer.
For example, a physical printer may support both PostScript and HP
Laserjet data formats, depending on some setup sequence being sent to
the physical printer before each job. It would make sense to define two
printers, one of which preprocesses the data by prepending the HP
LaserJet sequence while the other prepends the PostScript sequence.
Programs which generate HP data would send it to the HP printer, while
programs generating PostScript would print to the PostScript printer.
Programs which change the data before it is sent to the physical
printer are called "filters". It is possible for a filter to send no
data at all to a physical printer.
*Note The Syntax of /etc/printcap::
# Sample printcap entry with two aliases
myprinter|laserwriter:\
# lp is the device to print to - here the first parallel printer.
:lp=/dev/lp0: \
# sd means 'spool directory' - where print data is collected
:sd=/usr/spool/lpd/myprinter:
File: Printing-HOWTO.info, Node: Fields in /etc/printcap, Next: More On The lp Field, Prev: More about /etc/printcap, Up: Setting up print services
Fields in `/etc/printcap'
-------------------------
There are too many fields to describe here in full, so I'll just
describe the most important ones. All fields in `/etc/printcap' (except
for the names of the printer) are enclosed between a pair of colons and
are denoted by a two-letter code. The two-letter code is followed by a
value that depends on the type of field. There are three types of field
- string, boolean and numeric *Note The Syntax of /etc/printcap::.
The following fields are the most common and most important ones:
lp string specify the device to print to, eg /dev/lp0
sd string specify the name of the spool directory for
this printer
lf string specify the file to which errors on this
printer are to be logged
if string specify the input filter name
rm string specify the name of a remote printing host
rp string specify the name of a remote printer
sh boolean specify this to suppress headers (banner pages)
sf boolean specify this to suppress end-of-job form feeds
mx numeric specify the maximum allowable print job size
(in blocks)
File: Printing-HOWTO.info, Node: More On The lp Field, Next: More on the lf field, Prev: Fields in /etc/printcap, Up: Setting up print services
More on The `lp' Field
----------------------
If you specify `/dev/null' as the print device, all other processing
will be performed correctly, but the final data will go to the bit
bucket. This is rarely useful except for test printer configurations or
with weird printers *Note Printers not in /dev::. When you are setting
up a remote printer (that is, you have specified `rm' and `rp' fields),
you should specify `:lp=:'.
Don't leave the field empty unless you are using a remote printer.
The printer daemon will complain if you don't specify a print device.
File: Printing-HOWTO.info, Node: More on the lf field, Next: More on the if field, Prev: More On The lp Field, Up: Setting up print services
More On The lf Field
--------------------
Whatever file you specify should already exist, or logging will not
occur.
File: Printing-HOWTO.info, Node: More on the if field, Next: More on the rm and rp fields, Prev: More on the lf field, Up: Setting up print services
More On The if Field
--------------------
Input filters are programs which take print data on their standard
input and generate output on their standard output. A typical use of an
input filter is to detect plain text and convert it into PostScript.
That is, raw text is its input, PostScript is its output. *Note Writing
lpd filters::.
When you specify an input filter, the printer daemon does *not* send
the spooled print data to the specified device. Instead, it runs the
input filter with the spooled data as standard input and the print
device as standard output. (For another use for input filters *note A
test printcap entry::.).
File: Printing-HOWTO.info, Node: More on the rm and rp fields, Next: More on the sh and sf fields, Prev: More on the if field, Up: Setting up print services
More On The `rm' and `rp' Fields
--------------------------------
Sending your print data to a printer attached to another machine is
as simple as specifying the remote machine `rm' and the remote printer
`rp', and making sure that the print device field `lp' is empty. Note
that data will still be spooled locally before being transferred to the
remote machine, and any input filters you specify will be run also.
File: Printing-HOWTO.info, Node: More on the sh and sf fields, Next: More on the mx field, Prev: More on the rm and rp fields, Up: Setting up print services
More On The `sh' and `sf' Fields
--------------------------------
Unless you have a lot of different people using your printer, you
will most likely not be interested in banner pages.
Suppressing form feeds is most useful if your printer is typically
used for output from wordprocessing packages. Most WP packages create
complete pages of data, so if the printer daemon is adding a form feed
to the end of each job, you will get a blank page after each job. If the
printer is usually used for program or directory listings, however,
having that form feed ensures that the final page is completely ejected,
