| Purchase | Copyright © 2002 Paul Sheer. Click here for copying permissions. | Home |
|
|
| |
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 sendmail or other package, web by the apache package.
Here we examine how to obtain, install, and configure a package, using 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 cat <filename> | lpr -Plp). The `` lp'' in -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 lp, lp0, lp1, and so on, and any number of them may have been redirected to any other queue on any other machine on the network.
The command lprm removes pending jobs from a print queue; lpq reports jobs in progress.
The service that facilitates all this is called lpd. The 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 services. The 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):
|
rpm -qf /usr/sbin/lpd( dpkg -S /usr/sbin/lpd ) |
Returns lpr-0.nn -n (for RedHat 6.2, or LPRng-n .n .nn -n on 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:
|
rpm -qa | grep -i lpr( dpkg -l '*lpr*' ) |
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):
|
rpm -i lpr-0.50-4.i386.rpm( rpm -i LPRng-3.6.24-2 )( dpkg -i lpr_0.48-1.deb ) |
(Much more about package management is covered in Chapter 24.)
The list of files which the lpr package is comprises (easily obtained with rpm -ql lpr or dpkg -L lpr) is approximately as follows:
5 10 |
/etc/init.d/lpd /usr/share/man/man1/lprm.1.gz/etc/cron.weekly/lpr /usr/share/man/man5/printcap.5.gz/usr/sbin/lpf /usr/share/man/man8/lpc.8.gz/usr/sbin/lpc /usr/share/man/man8/lpd.8.gz/usr/sbin/lpd /usr/share/man/man8/pac.8.gz/usr/sbin/pac /usr/share/man/man8/lpf.8.gz/usr/bin/lpq /usr/share/doc/lpr/README.Debian/usr/bin/lpr /usr/share/doc/lpr/copyright/usr/bin/lprm /usr/share/doc/lpr/examples/printcap/usr/bin/lptest /usr/share/doc/lpr/changelog.gz/usr/share/man/man1/lpr.1.gz /usr/share/doc/lpr/changelog.Debian.gz/usr/share/man/man1/lptest.1.gz /var/spool/lpd/lp/usr/share/man/man1/lpq.1.gz /var/spool/lpd/remote |
(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 /etc/printcap 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). Note that 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 lpr package as an example. Refer to the list of files in Section 21.2.
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 into the /usr/share/doc directory. However, other packages, like rpm -ql apache, reveal a huge user manual (in /home/httpd/html/manual/ or /var/www/html/manual/), and rpm -ql wu-ftpd shows lots inside /usr/doc/wu-ftpd-? .? .?.
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 lprNG package. Go to The LPRng Web Page <http://www.astart.com/lprng/LPRng.html> 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 lpq, lpr, lprm, and lptest, as well as their associated man pages.
Daemon and administrator command will an sbin directory. In this case we can see lpc, lpd, lpf, and pac, as well as their associated man pages. The only daemon (background) program is really the lpd program itself, which is the core of the whole package.
The file /etc/printcap controls lpd. Most system services will have a file in /etc. 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 inconvenience ( printtool, which is especially for lpd, and 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 setup-2.3.4-1, and dpkg -S /etc/printcap shows it to not be owned (i.e., it is part of the base system).
The files in /etc/rc.d/init.d/ (or /etc/init.d/) are the startup and shutdown scripts to run lpd on boot and shutdown. You can start lpd yourself on the command-line with
|
/usr/sbin/lpd |
but it is preferably to use the given script:
|
/etc/rc.d/init.d/lpd start/etc/rc.d/init.d/lpd stop |
(or /etc/init.d/lpd). The script has other uses as well:
|
/etc/rc.d/init.d/lpd status/etc/rc.d/init.d/lpd restart |
(or /etc/init.d/lpd).
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
|
ls -al `find /etc -name '*lpd*'`find /etc -name '*lpd*' -ls |
showing,
5 10 |
-rw-r--r-- 1 root root 17335 Sep 25 2000 /etc/lpd.conf-rw-r--r-- 1 root root 10620 Sep 25 2000 /etc/lpd.perms-rwxr-xr-x 1 root root 2277 Sep 25 2000 /etc/rc.d/init.d/lpdlrwxrwxrwx 1 root root 13 Mar 21 14:03 /etc/rc.d/rc0.d/K60lpd -> ../init.d/lpdlrwxrwxrwx 1 root root 13 Mar 21 14:03 /etc/rc.d/rc1.d/K60lpd -> ../init.d/lpdlrwxrwxrwx 1 root root 13 Mar 21 14:03 /etc/rc.d/rc2.d/S60lpd -> ../init.d/lpdlrwxrwxrwx 1 root root 13 Mar 24 01:13 /etc/rc.d/rc3.d/S60lpd -> ../init.d/lpdlrwxrwxrwx 1 root root 13 Mar 21 14:03 /etc/rc.d/rc4.d/S60lpd -> ../init.d/lpdlrwxrwxrwx 1 root root 13 Mar 28 23:13 /etc/rc.d/rc5.d/S60lpd -> ../init.d/lpdlrwxrwxrwx 1 root root 13 Mar 21 14:03 /etc/rc.d/rc6.d/K60lpd -> ../init.d/lpd |
The `` 3'' in rc3.d is the what are interested in. Having S60lpd symlinked to lpd under rc3.d means that 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 update-rc.d command.
More details on bootup are in Chapter 32.
Systems services like lpd, innd, sendmail, and uucp create intermediate files in the course of processing each request. These are called spool files and are stored somewhere under the /var/spool/ directory, usually to be processed and then deleted in sequence.
lpd has a spool directory /var/spool/lpd, which may have been created on installation. You can create spool directories for the two printers in the example below, with
|
mkdir -p /var/spool/lpd/lp /var/spool/lpd/lp0 |
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 /var/log/.
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 /var/log/syslog. 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. sendmail, for example, uses /var/log/maillog. Actually, lpd does not have a log file of its own--one of its failings.
View the system log file with the follow option to tail:
|
tail -f /var/log/messagestail -f /var/log/syslog |
Restarting the lpd service gives messages like: [Not all distributions log this information.]
|
Jun 27 16:06:43 cericon lpd: lpd shutdown succeededJun 27 16:06:45 cericon lpd: lpd startup succeeded |
Log files are rotated daily or weekly by the logrotate package. Its configuration file is /etc/logrotate.conf. For each package that happens to produce a log file, there is an additional configuration file under /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 with a SIGHUP. Your /var/log/ may contain a number of old log files named .2, .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.
The printcap (printer capabilities) file is similar to (and based on) the termcap (terminal capabilities) file. Configuring a printer means adding or removing text in this file. 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.
5 10 |
lp:\ :sd=/var/spool/lpd/lp:\ :mx#0:\ :sh:\ :lp=/dev/lp0:\ :if=/var/spool/lpd/lp/filter:lp0:\ :sd=/var/spool/lpd/lp0:\ :mx#0:\ :sh:\ :rm=edison:\ :rp=lp3:\ :if=/bin/cat: |
Printers are named by the first field: in this case lp is the first printer and lp0 the 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 the device /dev/lp0 (first parallel port). lp0 refers to a remote print queue lp3 on the machine edison.
The printcap has a comprehensive man page. However, the following fields are most of what you will ever need:
On UNIX the standard format for all printing is the PostScript file. 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 showpage, 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 showpage.
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 gv (GhostView) program. A program called gs (GhostScript) 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, whereafter 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,
netscape's
menu selection shows
If you have chosen ``Print To: File,'' then you can view the resulting output with the 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 gv.
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 printcap file 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 /var/spool/lpd/lp/filter. Create the filter with
|
touch /var/spool/lpd/lp/filterchmod a+x /var/spool/lpd/lp/filter |
then edit it so that it looks like
|
#!/bin/bashcat | gs -sDEVICE=ljet4 -sOutputFile=- -sPAPERSIZE=a4 -r600x600 -q -exit 0 |
The -sDEVICE option describes the printer, in this example a Hewlett Packard LaserJet 1100. Many printers have similar or compatible formats; hence, there are far fewer 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):
The -sOutputFile=- sets to write to stdout (as required for a filter). The -sPAPERSIZE can be set to one of 11x17, a3, a4, a5, b3, b4, b5, halfletter, ledger, legal, letter, note, and others listed in the 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 enscript package. enscript is a program to convert plain text files into nicely formatted PostScript pages. The man page for enscript shows an enormous number of options, but we can simply try:
|
echo hello | enscript -p - | lpr |
You should be very careful about running lpd on any machine that is exposed to the Internet. lpd has 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, lpd 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:
|
192.168.3.8192.168.3.9192.168.3.10192.168.3.11 |
The file /etc/hosts.lpd does the same but doesn't give administrative control by those machines to the print queues. Note that other services, like sshd and rshd (or in.rshd), also check the hosts.equiv file and consider any machine listed to be equivalent. This means that they are completed trusted and so 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 /etc/lpd.perms 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 lpd.perms
5 |
ACCEPT SERVICE=* REMOTEIP=192.168.3.8ACCEPT SERVICE=* REMOTEIP=192.168.3.9ACCEPT SERVICE=* REMOTEIP=192.168.3.10ACCEPT SERVICE=* REMOTEIP=192.168.3.11DEFAULT REJECT |
Large organizations with many untrusted users should look more closely at the LPRng-HOWTO in /usr/share/doc/LPRng-n .n .nn. It explains how to limit access in more complicated ways.
Here is a convenient order for checking what is not working.
![[*]](crossref.png)
. Note that the
host command may
be ignorant of the file
/etc/hosts and may still fail.
Chapter 40 will explain name lookup configuration.
printtool is a graphical printer setup program that helps you very quickly set up lpd. It immediately generates a printcap file and magic filter, and you need not know anything about lpd configuration.
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 enscript instead of 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:
|
#!/bin/bashcat | mpage -4 | gs -sDEVICE=ljet4 -sOutputFile=- -sPAPERSIZE=a4 -r600x600 -q -exit 0 |
The package psutils contains a variety of command-line PostScript manipulation programs--a must for anyone doing fancy things with filters.
The 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 lpd to redirect ``print'' jobs to any kind of service imaginable.
Here, my_filter.sh is a script that might send the print job through an SMB (Windows NT) print share (using smbclient--see Chapter 39), to a printer previewer, or to a script that emails the job somewhere.
5 |
lp1:\ :sd=/var/spool/lpd/lp1:\ :mx#0:\ :sh:\ :lp=/dev/null:\ :if=/usr/local/bin/my_filter.sh: |
We see a specific example of redirecting print jobs to a fax machine in Chapter 33.