Compared to setting up a Linux home or small business network, configuring your Linux network to share a printer is a piece of cake!

At first, setting up a printer to be shared on a network is somewhat daunting, not to mention confusing. There is an abundance of files, daemons, commands, and flags that can be used, configured, edited, created, and shared. The following is from HowTo! The premier Linux information resource center :

To allow remote machines to print to your printer, you must list the machines in /etc/hosts.equiv or /etc/hosts.lpd. (Note that hosts.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 main page for information on this.

With lpd

To print to another machine, you make an /etc/printcap entry like this:
# REMOTE djet500

Confusing at best. At worst… it doesn’t work. The files are all correct and the theory is solid, but the steps are missing and the details are non-existent. Let’s solve this mystery so you can set up your simple Linux network to share a single printer!

First, let’s recap the network we’ve set up. Our simple Linux network consists of two Linux machines. The first (primary) machine’s name is Buffy and has an IP address of The second machine (secondary) is named Angel and has an IP address of Most of the net configuration files are located in the \etc directory and consist of hosts, hosts.allow, and hosts.equiv.

The hosts file looks like: localhost Buffy Angel

hosts.allow looks like:
in.ftpd, telnetd: Angel, Buffy

and hosts.equiv is simply:

This setup is very simple. Buffy can communicate to Angel and Angel communicates to Buffy. Telnet, ftp, and rlogin are all allowed using simple names instead of IP addresses.

But what about printing? How do we set up Angel so it can print to Buffy? Let’s cover the basics!

First, we set up our printer (for this example we’ll use a Hewlett Packard LaserJet 5L) on our primary machine (Buffy) and made sure we could print successfully. As root (su), use the printtool command to check the printer setup and run a simple test. If you initialized your printer during the install of your OS, you should see it listed in the main window. If you didn’t set up your printer when you installed your OS, never fear! The printtool command not only makes it easy to run tests, but also to set up printers on the fly.

If you haven’t set up Samba (unnecessary for this installation), you’ll see two warnings when you open printtool—close them. Once in the main window, you will (depending on your setup) either see an entry or you won’t. If you do see an entry, highlight it and click Edit. Within the Edit menu, you’ll see the settings shown in Table A.

Table A
Names (name1|name2|…)   Lp
Spool Directory   /var/spool/lpd/lp
File Limit in KB (0 = no limit)   0
Printer Device   /dev/lp0
Input Filter [select] Auto—LaserJet4
  [suppress headers]  
[OK]   [Cancel]
Default settings in the Edit menu.

When creating a new printer setup, these are typical default settings—with the exception of the Input Filter. The Input Filter entry is where the type of printer is selected. For our demonstration, we’ll use the HP5L. For the HP5L, the closest entry (or driver) is the HP LaserJet 4/5/6 Series. This driver works perfectly for our printer. Many drivers will work with more than just the specified listing. The CanonBJC610 And Up driver works with many of the various Canon BJ printers (including color). If you don’t see your printer listed, select one that’s similar to it.

Once you have this set up, let’s run a print test. There are three types of print tests to run: Print ASCII Text Page, Print PostScript Test Page, and Print ASCII Directly To Port. To keep things simple, select Print ASCII Text Page. If the test page comes out correctly, you’ll see a page of simple text with a few exclamation points [!] that should line up. If the text doesn’t line up properly or if the page comes out with only a few random characters, choose the Print PostScript Test Page option and see if the text is better aligned.

Now that we’re printing on Buffy (we’ll call it the LOCAL machine), it’s time to set up Angel (we’ll call it REMOTE) to print to the printer on the LOCAL (Buffy) machine.

The printcap file
The printcap file is crucial to printing on your simple network. Only root can edit the printcap file, which resides in the \etc directory.

A default printcap for our network will look like this (this is the printcap file that rests on Buffy—our LOCAL machine):
# Please don’t edit this file directly unless you know what you are doing!
# Be warned that the control-panel printtool requires a very strict format!
# Look at the printcap(5) main page for more info.
# This file can be edited with the printtool in the control-panel.

##PRINTTOOL3## LOCAL ljet4 300×300 letter {} LaserJet4 Default {}

You’ll notice that the majority of this file consists of comments (lines that begin with the pound sign [#]). Comments are ignored by the system, so it’s safe to leave these. Yes, this file says, “Please don’t edit this file directly unless you know what you are doing,” so we’ll leave this one to printtool. However, we will edit the REMOTE printcap file. Put on your best leather and sunglasses and get ready to hack!

The file you’re about to hack will reside on your REMOTE machine (in our case, Angel). Let’s do this in true geek fashion… telnet to the REMOTE machine and hack the script without so much as picking our duffs off of our chairs. We’ll use the names we’ve given our machines—these names will vary depending on how you’ve set up your systems. The commands look like this:
from console: telnet Angel
password: PASSWORD

Once you’ve passed the login script, you’ll see a new prompt from the REMOTE computer.

To alter this script, you must be in root. So su to root and then cd to the \etc directory. Now that you are in /etc, you’ll want to use your editor of choice to edit the printcap file.

If you’ve never run printtool on the REMOTE machine, don’t fear! The printcap file below will do everything you need (for the specific printer we’re using in our example).

The printcap file should look like this:
# Please don’t edit this file directly unless you know what you are doing!
# Be warned that the control-panel printtool requires a very strict format!
# Look at the printcap(5) main page for more info.
# This file can be edited with the printtool in the control-panel.

##PRINTTOOL3## REMOTE ljet4 300×300 letter {} LaserJet4 Default 1

The primary difference is that this printer was set up as a remote printer (hence the line :rm=Buffy:\). The most important line, and a line that is not generated by printtool, is :rp=lp:\. This line (when working on Angel, or REMOTE) says the local printer is the remote printer, so it knows that all print jobs are to be sent to the remote printer spool (print spool on Buffy) instead of the local print spool (print spool on Angel). Without this line, the system won’t be able to send print jobs.

Once you’ve updated this file, save it and close your telnet connection. The next step requires you to physically move to Angel (the REMOTE machine). When you’re sitting in front of the REMOTE machine, we’ll issue a print test through printtool. Open printtool (as root), select a printer, and send a test through. Your printer should quickly begin printing. If it doesn’t, send a different type of print job through. Should that fail, you’ll need to check the status of the printer queue.

If you’ve performed a custom install and included KDE in the package, a good print queue tool is included in the Utilities menu. Open this menu and check the status. If you’re getting an error that says your REMOTE machine is waiting for the queue to be enabled, there’s a good chance an error exists in one of the printcap files. Check these files and run another test through.

Your Linux network is a nice way to share resources. The ability to share a printer not only cuts down on costs, but also on time. Enjoy!

Jack Wallen, the author of “Get Jack’d” and proud to be working on his third degree in the University of Louisville’s Computer Information Systems program. Jack is an expert on the many flavors of Linux, as well as other prominent operating systems. His columns offer up a weekly dose of the “attitude” so familiar with Linux, and he plumbs the deeper depths of technology by drilling down into the heart of the applications and systems.

And, much to everyone’s surprise, Jack is not permanently connected to his computer.

The authors and editors have taken care in preparation of the content contained herein, but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for any damages. Always have a verified backup before making any changes.