| rlpr(1) | UNIX Reference Manual | rlpr(1) |
rlpr - remote off-line print
rlpr [-Hprinthost] [-Pprinter] [-Xproxyhost] [-#copies] [-Cclass] [-Jjob] [-Ttitle] [-Uuser] [-i[indent]] [-wwidth] [-1234cdfghlmnopqrstvNV] [--debug] [--port=port] [--hostname=hostname] [--send-data-first] [--timeout=seconds] [--tmpdir=dir] [--verbose] [--windows] [file ...]
rlpr uses TCP/IP to send print jobs to lpd servers anywhere on a network. Unlike lpr, it does not require that the remote printers be explicitly known to the local system (traditionally through /etc/printcap), and thus is considerably more flexible and requires less administration.
rlpr can be used anywhere a traditional lpr might be used, and is backwards compatible with traditional BSD lpr. If rlpr is invoked as lpr, it preserves all known lpr semantics.
rlpr can be installed and used in two different ways: (the same guidelines apply for rlpq(1) and rlprm(1))
1. Ideally, if the rlpr client can be installed setuid root, then rlpr can interact directly with other lpd's on the network. See EXAMPLES below.
2. If rlpr cannot be installed setuid root (in cases where one is not the administrator on the machine one needs to print from) then rlpr can be used in conjunction with an rlprd proxy agent. See CONFIGURING A PROXY and EXAMPLES below for details.
Traditional Berkeley lpr has one major drawback: the mortal user cannot lpr to a printer which is not listed explicitly in the /etc/printcap file.
This is especially annoying in scenarios where there is a central UNIX server which many users (using their own desktop computers) connect to in order to do their daily work; If those users wish to print files from the central server to their personal machines (assuming they had a local lpd), they cannot do this without the central server's /etc/printcap being edited to contain the host and printer of each user on the network - this scales horribly.
Instead of using -H, one can specify the hostname directly including it with the printer name with the printer@hostname syntax.
NOTE: instead of specifying the printer, printhost, or proxy variables
on the commandline, one can set up defaults through either environment
variables or rlprrc configuration files. For information on personal
or system-wide rlprrc files, see rlprrc(5).
-1 Print data using troff(1) R (times roman) font. -2 Print data using troff(1) I (times italic) font. -3 Print data using troff(1) B (times bold) font. -4 Print data using troff(1) S (special) font. -c Assume data has been produced by cifplot(1). -d Assume data has been produced by tex(1). -f Filter data assuming the start of each line has a fortran carriage control character. -g Assume data has been produced by the BSD plot library. -l Treat control characters as regular characters. -n Assume data has been produced by ditroff. -o Assume data is postscript. -p Print data using pr(1). -t Assume data has been produced by troff(1). -v Assume the data contains a raster image.
See OS-SPECIFIC EXTENSIONS below for details on these options.
In situations where the rlpr client cannot be installed
setuid root, rlpr often cannot directly talk to an lpd because
most lpd's require that requests come from privileged ports.
Unfortunately, rlpr cannot "come from a privileged port"
without having superuser status.
The privileged port requirement is part of RFC 1179.
That said, some lpd's, most notably some of the ones which have shipped with Windows NT, Solaris, and NCRunix, do not require requests to come from a privileged port. Before going through the work of configuring a proxy, you should make sure one is required for your situation. You can check by trying to run rlpr: if it is successful in spooling the job, you do not need to install rlpr setuid root. You should then pass the -N (or the more verbose --no-bind) to rlpr in the future to suppress rlpr's warning messages.
If your situation does not require a privileged port, do not use one. You can explicitly request a regular port, even when rlpr has been installed setuid root, by using the --no-bind option. This is a good idea because there are only 11 privileged ports that the RFC allows. This ends up having the practical implication of limiting your print requests to about 11 per every 3 minutes, which is often unacceptable.
The rest of this section assumes that rlpr cannot be installed setuid root in your situation, and that a remote lpd requires rlpr connect to it from a privileged port. It requires that you or someone you know has root access to another machine the network, so that you can use a proxy, known as rlprd, to get around the problem.
rlprd works by taking lpd requests on a non-privileged port, mapping them to a privileged port, and sending them out to the real lpd. The proxy and the lpd need not be on the same machine.
In the scenario provided in the motivation, if each user had root access on his own machine, it would be optimal for the user to start rlprd up on his own machine, in which case the proxy and the printhost are the same machine. The user would additionally have to make sure his own machine was listed in his local /etc/hosts.lpd so that his lpd would accept connections from his rlprd.
However, if the machine the user wants to print to is not running unix (but is running an lpd) (i.e. Windows, WinNT, etc) -- Then that user can configure his lpd to accept connections from an rlprd running somewhere on the network, and use that rlprd as a proxy for rlpr.
For more on this mess, see rlprd(8).
sun% rlpr --printer=hp4l@foo.bar.org foo.c
prints foo.c to the printer hp4l on the host foo.bar.org (assuming foo.bar.org has been configured to accept print requests from host sun in its /etc/hosts.lpd).
sun% who | rlpr --printer=hp4l@foo.bar.org
prints the output of who(1) to the printer hp4l on the host foo.bar.org.
sun% rlpr -Xfoo.bar.org --printer=hp4l@foo.bar.org foo.c
prints foo.c to the printer hp4l on the host foo.bar.org using foo.bar.org as a proxyhost. Under this configuration, foo.bar.org needs to be configured to accept print requests from the proxy (itself) and not from sun. In situations where the proxy and the printhost are not the same machine, this can lead to some security holes due to the original lameness of berkeley lpd's host-based security.
NOTE: if a proxyhost isn't specified anywhere, rlpr assumes one isn't necessary.
Some vendors have added features to their BSD-based lpr products, which are upwardly compatible with lpr but incompatible with one another. To support these extensions, rlpr allows the user to indicate what operating system to emulate and provide a string of OS-specific options, either through commandline arguments or environment variables.
Note that for correct operation, these extensions should be only used when interoperating with an lpd provided by the vendor for the indicated operating system.
The following environment variables are used by rlpr:
Note that one can also specify the host to print to by setting printer to be printer@hostname. This may be more convenient than setting RLPR_PRINTHOST, but will confuse the traditional BSD print commands.
~/.rlprrc Personal printer/host database $TMPDIR/cf* Temporary control files on local machine $TMPDIR/df* Temporary data file for jobs from stdin /var/spool/*/cf* Temporary control files on printhost /var/spool/*/df* Temporary data files on printhost /etc/hosts.lpd Host-based security on printhost /etc/passwd Personal identification /etc/rlprrc System-wide printer/host database (by default)
meem <meem@gnu.org>
Some evil applications have lpr hardcoded into them.
| 2000/12/30 | rlpr 2.04 |