Библиотека сайта или "Мой Linux Documentation Project"
|Purchase||Copyright © 2002 Paul Sheer. Click here for copying permissions.||Home|
Next: 22. Trivial Introduction to Up: rute Previous: 20. Advanced Shell Scripting   Contents
- 21.1 Using
- 21.2 Downloading and Installing
- 21.4 Package Elements
- 21.5 The
printcapFile in Detail
- 21.6 PostScript and the Print Filter
- 21.7 Access Control
- 21.8 Printing Troubleshooting
- 21.9 Useful Programs
- 21.10 Printing to Things Besides Printers
This chapter covers a wide range of concepts about the way UNIX services function.
Every function of UNIX is provided by one or another package.
For instance, mail is often handled by the
other package, web by the
Here we examine how to obtain, install, and configure
lpd as an example. You can then apply this
knowledge to any other package, and later chapters assume that
you know these concepts. This discussion will also suffice as an
explanation of how to set up and manage printing.
Printing under UNIX on a properly configured machine is as
simple as typing
lpr -Plp <filename> (or
<filename> | lpr -Plp). The ``
-Plp is the
name of the printer queue on the local machine you
would like to print to. You can omit it if you are printing to
the default (i.e., the first listed) queue. A queue
belongs to a physical printer, so users can predict where
paper will come spewing out, by what queue they print to.
Queues are conventionally named
lp1, and so on, and any number of them may have been
redirected to any other queue on any other machine on the
lprm removes pending jobs from
a print queue;
lpq reports jobs in progress.
The service that facilitates all this is called
lpr user program makes a network connection to the
lpd background process, sending it the print job.
lpd then queues, filters, and feeds the job until it
appears in the print tray.
Printing typifies the client/server nature of UNIX
lpd background process is the server
and is initiated by the
root user. The remaining commands
are client programs, and are run mostly by users.
The following discussion should relieve the questions of ``Where do I get xxx service/package?'' and ``How do I install it?''. Full coverage of package management comes in Section 24.2, but here you briefly see how to use package managers with respect to a real system service.
Let us say we know nothing of the service except that it has something
to do with a file
/usr/sbin/lpd. First, we use our package managers
to find where the file comes from (Debian commands are shown in parentheses):
-n (for RedHat 6.2, or
RedHat 7.0, or
lpr on Debian). On RedHat
you may have to try this on a different machine because
rpm does not know about packages that are not installed.
Alternatively, if we would like to see whether a package
whose name contains the letters
lpr is installed:
If the package is not present, the package file will be on your CD-ROM and is easily installable with (RedHat 7.0 and Debian in braces):
(Much more about package management is covered in Chapter 24.)
The list of files which the
lpr package is comprises (easily
rpm -ql lpr or
dpkg -L lpr) is approximately as follows:
(The word legacy with regard to software means outdated, superseded, obsolete, or just old.)
RedHat 7.0 has now switched to using
LPRng rather than the legacy
lpr that Debian and other distributions use.
LPRng is a
more modern and comprehensive package. It supports the same
file and identical binaries as did the legacy
lpr on RedHat 6.2.
The only differences are in the control files created in your spool
directories, and a different access control mechanism (discussed below).
LPRng has strict permissions requirements on spool
directories and is not trivial to install from source.
A package's many files can be loosely grouped into functional elements.
In this sectiom, each element will be explained, drawing on the
package as an example. Refer to the list of files in Section
Documentation should be your
first and foremost interest. Man
pages will not always be the only documentation provided.
Above we see that
lpr does not install very much
/usr/share/doc directory. However, other
rpm -ql apache, reveal a huge user manual (in
rpm -ql wu-ftpd
shows lots inside
Every package will probably have a team that maintains it as
well as a web page. In the case of
lpd, however, the
code is very old, and the various CD vendors do maintenance on
it themselves. A better example is the
Go to The LPRng Web Page <
with your web browser. There you can see the authors,
mailing lists, and points of download.
If a particular package is of much
interest to you, then you should become familiar with these
resources. Good web pages will also have additional
documentation like troubleshooting guides and FAQs
(Frequently Asked Questions). Some may even have archives
of their mailing lists. Note that some web pages are geared
more toward CD vendors who are trying to create their own
distribution and so will not have packages for download that
beginner users can easily install.
User programs are found in one or another
bin directory. In this case,
we can see
as well as their associated
Daemon and administrator command will an
sbin directory. In this case
we can see
well as their associated
man pages. The only
daemon (background) program is really the
program itself, which is the core of the whole package.
lpd. Most system
services will have a file in
printcap is a plain
text file that
lpd reads on startup. Configuring any
service primarily involves editing its configuration file. Several
graphical configuration tools are available that avoid this
printtool, which is especially for
linuxconf), but these actually just silently produce the
same configuration file.
Because printing is so integral to the system,
printcap is not
actually provided by the
lpr package. Trying
rpm -qf /etc/printcap gives
dpkg -S /etc/printcap shows it to not be owned (i.e., it is part of
the base system).
The files in
/etc/init.d/) are the
startup and shutdown scripts to run
lpd on boot and shutdown. You
lpd yourself on the command-line with
but it is preferably to use the given script:
/etc/init.d/lpd). The script has other uses as well:
To make sure that
lpd runs on startup, you
can check that it has a symlink under the appropriate run level.
The symlinks can be explained by running
rc3.d is the what are interested in.
S60lpd symlinked to
lpd will be started when the system enters
run level 3, which is the system's state of usual operation.
Note that under RedHat the command
setup has a menu option
System Services. The
Services list will allow you to
manage what services come alive on boot, thus creating the symlinks
automatically. For Debian, check the man page for the
More details on bootup are in Chapter 32.
Systems services like
uucp create intermediate files in the course of
processing each request. These are called spool files
and are stored somewhere under the
usually to be processed and then deleted in sequence.
lpd has a spool directory
which may have been created on installation. You can create
spool directories for the two printers
in the example below, with
UNIX has a strict policy of not reporting error messages to the user
interface whenever there might be no user around to read those messages.
Whereas error messages of interactive commands are sent to the terminal
screen, error or information messages produced by non-interactive
commands are ``logged'' to files in the directory
A log file is a plain text file that continually has one-liner status
messages appended to it by a daemon process. The usual
directory for log files is
/var/log. The main log files are
/var/log/messages and possibly
It contains kernel messages and
messages from a few primary services. When a service would
produce large log files (think web access with thousands of hits
per hour), the service would use its own log file.
for example, uses
does not have a log file of its own--one of its failings.
View the system log file with the
lpd service gives messages
like: [Not all distributions log this information.]
Log files are rotated daily or weekly by the
Its configuration file is
/etc/logrotate.conf. For each package
that happens to produce a log file, there is an additional configuration
/etc/logrotate.d/. It is also easy to write your own--begin
by using one of the existing files as an example. Rotation means that the log
file is renamed with a
.1 extension and then truncated to zero
length. The service is notified by the
logrotate program, sometimes
/var/log/ may contain a number of old
log files named
.3, etc. The point of log file rotation
is to prevent log files from growing indefinitely.
Most user commands of services make use of some environment variables.
These can be defined in your shell startup scripts as usual. For
lpr, if no printer is specified on the command-line, the
PRINTER environment variable determines the default print
queue. For example,
export PRINTER=lp1 will force use of the
lp1 print queue.
(printer capabilities) file is similar to (and
based on) the
(terminal capabilities) file.
Configuring a printer means adding or removing text in this
printcap contains a list of one-line entries, one for each printer.
Lines can be broken by a
\ before the newline. Here is an
example of a
printcap file for two printers.
Printers are named by the first field: in this case
lp is the first printer and
second printer. Each printer usually refers to a different
physical device with its own queue. The
lp printer should
always be listed first and is the default print queue used when
no other is specified. Here,
lp refers to a local printer on
/dev/lp0 (first parallel port).
to a remote print queue
lp3 on the machine
printcap has a comprehensive
However, the following fields are most of what you will ever need:
- Spool directory. This directory contains status and spool files.
- Maximum file size. In the preceding example, unlimited.
- Suppress headers. The header is a few informational lines printed before or after the print job. This option should always be set to off.
- Line printer device.
- Input filter. This is an executable script into which printer data is piped. The output of this script is fed directly to the printing device or remote machine. This filter will translate from the application's output into the printer's native code.
- Remote machine. If the printer queue is not local, this is the machine name.
- Remote printer queue name. The remote machine will have its
printcapfile with possibly several printers defined. This specifies which printer to use.
On UNIX the standard format for all printing is the PostScript
.ps files are graphics files representing
arbitrary scalable text, lines, and images. PostScript is actually
a programming language specifically designed to draw things on
a page; hence,
.ps files are really PostScript programs.
The last line in any PostScript program is always
meaning that all drawing operations are complete and that the page
can be displayed. Hence, it is easy to see the number of pages
inside a PostScript file by
grepping for the string
The procedure for printing on UNIX is to convert whatever you
would like to print into PostScript. PostScript files can be
viewed with a PostScript ``emulator,'' like the
(GhostView) program. A program called
is the standard utility for converting the PostScript into a
format suitable for your printer. The idea behind PostScript is
that it is a language that can easily be built into any printer. The
so-called ``PostScript printer'' is one that directly interprets a
PostScript file. However, these printers are relatively
expensive, and most printers only understand the lesser PCL
(printer control language) dialect or some other format.
In short, any of the hundreds of different formats of graphics
and text have a utility that will convert a file into PostScript,
gs will convert it for any of the hundreds of
different kinds of printers. [There are actually many
printers not supported by
gs at the time of this writing.
This is mainly because manufacturers refuse to release
specifications to their proprietary
printer communication protocols]. The print filter
is the workhorse of this whole operation.
Most applications conveniently output PostScript whenever
printing. For example,
menu selection shows
lpr. All applications without their own printer drivers will do the same. This means that we can generally rely on the fact that the print filter will always receive PostScript.
gs, on the other hand, can convert PostScript for any printer, so all that remains is to determine its command-line options.
If you have chosen ``Print To: File,'' then you can view the resulting output
gv program. Try
gv netscape.ps, which
shows a print preview. On UNIX,
most desktop applications do not have their own preview facility
because the PostScript printer itself is emulated by
Note that filter programs should not be used with remote filters;
remote printer queues can send their PostScript files ``as is'' with
:if=/bin/cat: (as in the example
above). This way, the machine connected to the device need be
the only one especially configured for it.
The filter program we are going to use for the local
print queue will be a shell script
Create the filter with
then edit it so that it looks like
-sDEVICE option describes the printer, in
this example a Hewlett Packard LaserJet 1100. Many printers
have similar or compatible formats; hence, there are far
DEVICE's than different makes of printers. To get
a full list of supported devices, use
gs -h and also
consult one of the following files (depending on your distribution):
-sOutputFile=- sets to write to stdout (as required
for a filter). The
can be set to one of
note, and others listed in
man page. You can also use
-g<width>x<height> to set the exact page size in pixels.
-r600x600 sets the resolution, in this case, 600 dpi
(dots per inch).
-q means to set quiet mode, suppressing any
informational messages that would otherwise corrupt the
PostScript output, and
- means to read from
stdin and not from a file.
Our printer configuration is now complete. What remains
is to start
lpd and test print. You can do that on the
command-line with the
is a program to convert plain text files into nicely formatted
PostScript pages. The
man page for
an enormous number of options, but we can simply try:
You should be very careful about running
on any machine that is exposed to the Internet.
had numerous security alerts [See Chapter 44.]and should really only be used within a trusted LAN.
To prevent any remote machine from using your printer,
first looks in the file
/etc/hosts.equiv. This is a simple
list of all machines allowed to print to your printers. My own file
looks like this:
/etc/hosts.lpd does the same but doesn't give
administrative control by those machines to the print queues. Note that
other services, like
hosts.equiv file and consider any machine listed to be
equivalent. This means that they are completed trusted
rshd will not request user logins between machines to be
authenticated. This behavior is hence a grave security concern.
LPRng on RedHat 7.0 has a different access control
facility. It can arbitrarily limit access in a variety of ways,
depending on the remote user and the action (such as who is allowed to
manipulate queues). The file
contains the configuration. The file format is simple, although
LPRng's capabilities are rather involved--to make a long
story short, the equivalent
hosts.equiv becomes in
Large organizations with many untrusted users
should look more closely at the
It explains how to limit access in more complicated ways.
Here is a convenient order for checking what is not working.
- Check that your printer is plugged in and working. All printers have a way of printing a test page. Read your printer manual to find out how.
- Check your printer cable.
- Check your CMOS settings for your parallel port.
- Check your printer cable.
echo hello > /dev/lp0to check that the port is operating. The printer should do something to signify that data has at least been received. Chapter 42 explains how to install your parallel port kernel module.
- Use the
lpcprogram to query the
status lp, and so on.
- Check that there is enough space in your
/tmpdevices for any intermediate files needed by the print filter. A large print job may require hundreds of megabytes.
lpdmay not give any kind of error for a print filter failure: the print job may just disappear into nowhere. If you are using legacy
lpr, then complain to your distribution vendor about your print filter not properly logging to a file.
- For legacy
lpdand remove all of
lpd's runtime [At or pertaining to the program being in a running state.] files from
/var/spool/lpdand from any of its subdirectories. (New
LPRngshould never require this step.) The unwanted files are
lpd.lock, and any left over spool files that failed to disappear with
lprm(these files are recognizable by long file names with a host name and random key embedded in the file name). Then, restart
- For remote queues, check that you can do forward and
reverse lookups on both machines of both machine's
host names and IP address. If not, you may get
Host name for your address (ipaddr
) unknownerror messages when trying an
lpq. Test with the command
host <ip-address>and also
host <machine-name>on both machines. If any of these do not work, add entries for both machines in
/etc/hostsfrom the example on page . Note that the
hostcommand may be ignorant of the file
/etc/hostsand may still fail. Chapter 40 will explain name lookup configuration.
- Run your print filter manually to check that it does,
in fact, produce the correct output. For example,
echo hello | enscript -p - | /var/spool/lpd/lp/filter > /dev/lp0.
lpdis a bit of a quirky package--meditate.
printtool is a graphical printer setup program that helps
you very quickly set up
lpd. It immediately
printcap file and magic filter, and
you need not know anything about
apsfilter stands for any to PostScript filter.
The setup described above requires everything be converted to
PostScript before printing, but a filter could foreseeably use the
file command to determine the type of data coming in
and then invoke a program to convert it to PostScript before
piping it through
gs. This would enable JPEG, GIF, plain text,
DVI files, or even
gzipped HTML to be printed
directly, since PostScript converters have been written for
each of these.
apsfilter is one of a few such filters, which are
generally called magic filters. [This is because the
file command uses magic numbers. See page .]
I personally find this feature a gimmick rather than a genuine
utility, since most of the time you want to lay out the graphical
object on a page before printing, which requires you to preview it,
and hence convert it to PostScript manually. For most
situations, the straight PostScript filter above will work
adequately, provided users know to use
lpr when printing plain text.
mpage is a useful utility for saving the trees.
It resizes PostScript input so that two, four or eight
pages fit on one. Change your print filter to:
psutils contains a variety of
command-line PostScript manipulation programs--a must for anyone
doing fancy things with filters.
printcap allows anything to be specified as the
printer device. If we set it to
/dev/null and let our filter
force the output to an alternative device, then we can use
to redirect ``print'' jobs to any kind of service imaginable.
my_filter.sh is a script that might send the print
job through an SMB (Windows NT) print
Chapter 39), to a printer previewer, or
to a script that emails the job somewhere.
We see a specific example of redirecting print jobs to a fax machine in Chapter 33.
Next: 22. Trivial Introduction to Up: rute Previous: 20. Advanced Shell Scripting   Contents
Только зарегистрированные пользователи могут оценивать и комментировать статьи.