One of the features of most spoolers is that they support printing over the network to printers physically connected to a different machine, or to the network directly. With the careful combination of filter scripts and assorted utilities, you can print transparently to printers on all sorts of networks.
To allow remote machines to print to your printer using the LPD protocol, you must list the machines in/etc/hosts.equiv or/etc/hosts.lpd. (Note thathosts.equiv has a host of other effects; be sure you know what you are doing if you list any machine there). You can allow only certain users on the other machines to print to your printer by using the rs attribute; read the lpd man page for information on this.
To print to another machine, you make an/etc/printcap entry like this:
# REMOTE djet500
lp|dj|deskjet:\
:sd=/var/spool/lpd/dj:\
:rm=machine.out.there.com:\
:rp=printername:\
:sh:
Note that there is still a spool directory on the local machine
managed by lpd. If the remote
machine is busy or offline, print jobs from the local machine
wait in the spool area until they can be sent.You can also use rlpr to send a print job directly to a queue on a remote machine without going through the hassle of configuring lpd to handle it. This is mostly useful in situations where you print to a variety of printers only occasionally. From the announcement forrlpr:
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 machine you wish to print from, (e.g. 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.
The main power gained by rlpr is the power to print remotely *from anywhere to anywhere* without regard for how the system you wish to print from was configured. Rlpr can work as a filter just like traditional lpr so that clients executing on a remote machine like netscape, xemacs, etc, etc can print to your local machine with little effort.
Rlpr is available from Metalab.
There is a Printing to Windows mini-HOWTO out there which has more info than there is here.
It is possible to direct a print queue through the smbclient program (part of the Samba suite) to a TCP/IP based SMB print service. Samba includes a script to do this called smbprint. In short, you put a configuration file for the specific printer in question in the spool directory, and install the smbprint script as theif.
The /etc/printcap entry goes like this:
lp|remote-smbprinter:\
:sh:\
:lp=/dev/null:\
:sd=/var/spool/lpd/lp:\
:if=/usr/local/sbin/smbprint:You should read the documentation inside the smbprint script for more information on how to set this up.
You can also use smbclient to submit a file directly to an SMB printing service without involving lpd. See the man page.
The ncpfs suite includes a utility called nprint which provides the same functionality as smbprint but for NetWare. You can get ncpfs from Metalab. From the LSM entry for version 0.16:
"With ncpfs you can mount volumes of your NetWare server under Linux. You can also print to NetWare print queues and spool NetWare print queues to the Un*x print spooler. You need kernel 1.2.x or 1.3.54 and above. ncpfs does NOT work with any 1.3.x kernel below 1.3.54."
To make nprint work via lpd, you write a little shell script to print stdin on the NetWare printer, and install that as the if for an lpd print queue. You'll get something like:
sub2|remote-NWprinter:\
:sh:\
:lp=/dev/null:\
:sd=/var/spool/lpd/sub2:\
:if=/var/spool/lpd/nprint-script:
The nprint-script might look
approximately like:#! /bin/sh # You should try the guest account with no password first! /usr/local/bin/nprint -S net -U name -P passwd -q printq-name -
The netatalk package includes something like nprint and smbclient. Others have documented the procedure for printing to and from an Apple network far better than I ever will; see the Linux Netatalk-HOWTO.
Many printers come with an ethernet interface which you can print to directly, typically using the LPD protocol. You should follow the instructions that came with your printer or its network adaptor, but in general, such printers are "running" lpd, and provide one or more queues which you can print to. An HP, for example, might work with a printcap like:
lj-5|remote-hplj:\
:sh:\
:sd=/var/spool/lpd/lj-5:\
:rm=printer.name.com:\
:rp=raw:HP Laserjet printers with JetDirect interfaces generally support two built in lpd queues - "raw" which accepts PCL (and possibly Postscript) and "text" which accepts straight ascii (and copes automatically with the staircase effect). If you've got a JetDirect Plus3 three-port box, the queues are named "raw1", "text2", and so forth.
Note that the ISS company has identified an assortment of denial of service attacks which hang HP Jetdirect interfaces. Most of these have been addressed beginning in Fall 98. These sorts of problems are common in embedded code; few appliance-style devices should be exposed to general Internet traffic.
In a large scale environment, especially a large environment where some printers do not support PostScript, it may be useful to establish a dedicated print server to which all machines print and on which all ghostscript jobs are run. This will allow the queue to be paused or reordered using the topq and lprm commands.
This also allows your GNU/Linux box to act as a spool server for the printer so that your network users can complete their print jobs quickly and get on with things without waiting for the printer to print any other job that someone else has sent. This is suggested too if you have unfixable older HP Jetdirects; it reduces the likelihood of the printers wedging.
To do this, set up a queue on your linux box that points at the ethernet equipped HP LJ (as above). Now set up all the clients on your LAN to point at the LPD queue (eg lj-5 in the example above).
Some HP network printers apparently don't heed the banner page setting sent by clients; you can turn off their internally generated banner page by telnetting to the printer, hitting return twice, typing "banner: 0" followed by "quit". There are other settings you can change this way, as well; type "?" to see a list.
The full range of settings can be controlled with HP's webJetAdmin software. This package runs as a daemon, and accepts http requests on a designated port. It serves up forms and Java applets which can control HP printers on the network. In theory, it can also control Unix print queues, but it does so using the rexec service, which is completely unsecure. I don't advise using that feature.
Some printers (and printer networking "black boxes") support only a cheesy little non-protocol involving plain TCP connections; this is sometimes called the "AppSocket" protocol. Notable in this category are early-model JetDirect (including some JetDirectEx) cards. Basically, to print to the printer, you must open a TCP connection to the printer on a specified port (typically 9100, or 9100, 9101 and 9102 for three-port boxes) and stuff your print job into it. LPRng has built-in support for stuffing print jobs into random TCP ports, but with BSD lpd it's not so easy. The best thing is probably to obtain and use the little utility called netcat.
Failing that, it can be implemented, among other ways, in Perl using the program below. For better performance, use the program netcat ("nc"), which does much the same thing in a general purpose way. Most distributions should have netcat available in prepackaged form.
One oddity of older versions of lpd is that the if is not run for remote printers. (Versions after 0.43 or so have the change originated on FreeBSD such that the if is always run). If you find that you need to run anif for a remote printer, and it isn't working with your lpr, you can do so by setting up a double queue and requeueing the job. As an example, consider thisprintcap:
lj-5:\
:lp=/dev/null:sh:\
:sd=/var/spool/lpd/lj-5:\
:if=/usr/lib/lpd/filter-lj-5:
lj-5-remote:sh:rm=printer.name.com:\
:rp=raw:sd=/var/spool/lpd/lj-5-raw:
in light of this filter-lj-5 script:#!/bin/sh gs <options> -q -dSAFER -sOutputFile=- - | \ lpr -Plj-5-remote -U$5
The -U option to lpr only works if lpr is run as daemon, and it sets the submitter's name for the job in the resubmitted queue correctly. You should probably use a more robust method of getting the username, since in some cases it is not argument 5. See the man page for printcap.
Printing from a Windows (or presumably, OS/2) client to a Un*x server is directly supported over SMB through the use of the SAMBA package, which also supports file sharing of your Un*x filesystem to Windows clients.
Samba includes fairly complete documentation, and there is a good Samba FAQ which covers it, too. You can either configure a magic filter on the Un*x box and print PostScript to it, or run around installing printer-specific drivers on all the Windows machines and having a queue for them with no filters at all. Relying on the Windows drivers may in some cases produce better output, but is a bit more of an administrative hassle if there are many Windows boxes. So try Postscript first. Modern versions of Samba should support the automagical driver download mechanism offered by Windows NT servers to deal with this problem.
Netatalk supports printing from Apple clients over EtherTalk. See the Netatalk HOWTO Page for more information.
Really, though, any modern Mac can print over TCP/IP using the LPD protocol just fine. UVa provides a very nice support page detailing how to set this up.
The ncpfs package includes a daemon named pserver which can be used to provide service to a NetWare print queue. From what I understand, this system requires a Bindery-based NetWare, eg 2.x, 3.x, or 4.x with bindery access enabled.
For more information on ncpfs and it's pserver program, see the ncpfs FTP site.
Most networked printers support some method of remote administration. Often there are easy-to-use web pages for configuration. More usefully, there is often support for SNMP management. Typically you can find out interesting information on printer status like ink and paper levels, print volumes, and so forth, and you can usually change certain settings. SNMP printer control, and a number of other printing-related things, are being standardized by the IEEE's Printer Working Group
Npadminis a command-line program which offers an interface to the common SNMP functionality of networked printers. It implements the standard Printer MIB, as well as a few vendor-proprietary schemes used mainly for older devices. Both printer-discovery style actions and various printer status queries are supported.
npadmin has an excellent man page, and precompiled packages are distributed for a number of RPM and dpkg based distributions.
Besides npadmin, there are a number of SNMP tools that will be useful. snmptraplogd can log SNMP trap events. This is useful for observing printer jams, out of paper events, etc; it would be straightforward to retransmit certain events to a pager, or to send an email.
While npadmin provides simplified support for many network printers' SNMP interfaces, some printers may have vendor extensions which npadmin doesn't know about. In this case, you can use the CMU SNMP tools, which support arbitrary SNMP GET and SET operations, as well as walks and the like. With these, and a bit of work, you can make use of any SNMP feature offered by your printer's MIB. You may need to obtain a MIB from your vendor to figure out what all the variables are; sometimes vendors think that people actually use the proprietary tools they ship.
VA Linux's libprinterconf includes code to perform network printer discovery. Printers are identified against a compiled-in library of printer signatures; at the moment the library is not large, but does cover many common networked printer models.