A lot has been said and written about the adaptability of
Linux to mundane tasks such as file and print serving. Writers have related
anecdotes about Linux boxes running unattended for months (and for years with
no license upgrade costs). When I needed to add a third printer to my network
of seven test and development machines, I decided to take the plunge.

I had already gone the self-education route with Linux,
starting with an old Slackware CD and progressing through Red Hat versions 6.0,
7.3, and 9.0. I also have file servers and Web development machines running on
my network using Samba to integrate with Windows. How hard could a simple print
server be?

The hardware/software upgrade spiral

I started with an old 486 with a 450-MB hard drive and a
minimal install of Red Hat 6. I was able to set up the Samba shares necessary
for network printing fairly easily. This can be done by modifying the smb.conf
file or using the old SWAT tool and restarting SMB services. I could get the
printer to print a test page from the Linux machine, but could not get it to
make a noise from a Windows machine over the network.

After talking to some colleagues and doing some research on
the Internet, I became convinced that a newer distribution of Linux and CUPS
(Common UNIX Printing System) might be the answer. The old 486 motherboard was
swapped for a low-end Pentium, more RAM and a 1-GB drive. Red Hat 7.3 seemed
promising, but after all the setup chores the result was the same: Jobs
appeared to be there in the print queue, but no noises from the printer.

CUPS, BSD, printcap files, lpr, lpd—my head was beginning to
spin, and there were still the other two printers to consider. I was ready to
try Red Hat 9 on a 2-GB drive plus more RAM when I stopped myself. This was
exactly the sort of software/hardware upgrade vicious-circle scenario that I
was supposed to be avoiding. Why did I need all that power and complexity just
to handle a few lousy print jobs?

Nicholas Fong to the rescue

Luckily, a more concerted Web search turned up Nicholas
Fong’s wonderfully detailed Linux Print Server Project and the answer to my problems. Fong’s
pages offer a comprehensive manual for transforming a surplus 486 into a
dedicated print server running a very stripped-down Linux kernel. It was
exactly what I needed for this project.

The old 486 went back together using an old drive controller
card with a parallel port, a second parallel port on an old ISA card of
indeterminate lineage, a third parallel port on a newer ISA card from Lava Computer MFG Inc. that I
found for five bucks at a surplus store, and an old 10-Mbps ISA network card.

I went with a 250-MB hard drive and 16 MB of RAM, although
Fong includes instructions on building an extremely stripped-down machine with
no hard drive that boots from a floppy only. All the necessary files for
creating floppies to configure the network card and create a boot image on the
hard drive are included for download. However, you’ll need WinZip, WinImage, a Windows machine, and
some info about your router.

It works!

The print server uses Raw Socket API to send print jobs to
port 9100. This is the same technology used by HP’s Jetdirect network printers.
The IP address of the print server is set during the creation of the boot image
and network card configuration and depends on your brand of router. Because I
am using a D-Link router, the address of my print server is set as
192.168.0.252 (the router is 192.168.0.1). If I were using a LinkSys router,
the address of the print server would be created as 192.168.1.252 (the third
octet in the router address is 1 instead of 0).

The three parallel ports I have on my print server are
identified on the network as 192.168.0.252:9100, 192.168.0.252:9101, and
192.168.0.252:9102. It might take some fiddling with the BIOS setup and jumpers
on the cards, if so equipped, to get all three ports working with no conflicts.
Once that is done, I found it easiest to use trial and error to discover which
physical port corresponds to which IP address and port number and then label
them.

If you’re using Windows 98, you’ll need to download and
install AXIS Print Monitor and then create a local RAW AXIS printer port when
setting up a printer. If you’re using Windows 2000, you can use a local
Standard TCP/IP Port. For Red Hat 9, you’ll have to use System Settings | Printing
and select New in Printer Configuration. After naming the new printer, select Networked
Jetdirect for queue type, then enter the IP address of the print server under Printer
followed by the appropriate port number. Fong’s Web site lists a number of
other possible setup scenarios and gotchas.

Once all the setup is out of the way, the system performs
almost flawlessly. Throughput seems very fast and the printer starts up within
seconds, even when printing large jobs. The only problems I’ve had are with
Epson’s Print Status Monitor. It is unable to establish a two-way communication
with the printer and immediately reports a Communication Error, even though
printing continues. The simple solution is to turn off Epson’s Status Monitor
under Printer | Properties | Utility. I assume that most modern inkjet printers
with cartridge reporting software will behave in a similar manner.

If anything undesirable happens, the print server is so
simple that all you need to do is turn it off and then turn it on again. I have
mine connected to a KVM, but it is really unnecessary. No mouse is required, and
the machine will start up just fine without a monitor or keyboard attached,
although this may not be the case with all motherboards.

The spirit of open source

Nicholas Fong should be applauded for coming up with this
simple, inexpensive, low-tech solution to a common problem. In my mind, his
approach is the very essence of the whole open source concept. Afer this
experience, I’m looking forward to experimenting with and reporting on his
Linux Router Project.