My wife uses a Laptop running Mac OS X, and occasionally needs to print stuff. The laptop is used at various places in the house (most often the kitchen table) where it's inconvenient to locate a printer. We'd like to print from this laptop over the network to a printer located in an office.
"Network printers" are not a consumer item. Printer companies realized the Big Buck$ were to be made selling ink, not the printers (razor/blades biz model). The printers became incredibly cheap, and consumers typically just bought another rather than futz with networking to share one. "Network" printers became the domain of the professional ("my, what deep pockets you have!") office. The prices are absurd; a network printing card for an Epson inkjet runs about $280 - if you can find one. And it doesn't work with Mac OS X. For comparison, a network card for a PC is around $15.
On Ebay I found an "Axiom SBC8242VE Half Size All-in-One 486 CPU card" selling for $10. Brand new, in box with manual. Yes, for ten bucks you get the equivalent of a mid 90's PC motherboard, with VGA, keyboard, IDE, serial, parallel, 64Mb of ram, on a circuit board about the size of a paperback book. Whatta deal. I knew the card had enough oomph to run Linux, and if it ran Linux it could run CUPS and voila! You've got a print server.
Turning the CPU card into a working computer requires a bunch of additional parts - disk drive, power supply, and (eventually) a case. In lieu of a disk drive, the board has a socket for a "Disk on chip", but these are pretty pricey (nearly $1/Mb). Since I had a an old 1.5G laptop drive about, I got an adapter ($10, Ebay) to connect it to the standard IDE cable included with the Axiom board. I temporarily hooked up an old CD-ROM drive to initially boot and install Linux. For power, I opened up an old external SCSI drive case and used the power supply from that. The original power cable was hooked up to the laptop drive and (via a spare "Y" cable) the CD-ROM. To power the CPU card, I discovered the "ID select" connector from the old SCSI drive more or less fit the CPU card's power connector, so I soldered the wires from that onto the base of the disk drive power connector. Although the CPU power connector has pins for -5V and -12V, it runs fine without them. I suspect the +12V supply is only needed for the serial ports. I temporarily hooked an old monitor and keyboard up to it so I could configure the BIOS and and install the OS.
Getting Linux (Debian 3.0) running was straightforward install off the CD's, except it couldn't find the Ethernet. To fix this, you locate the Ethernet chip (hint, it's close to the Ethernet jack) and type in the part number on it (RTL8019) into Google. After fishing around for a while you learn that the "ne2000/ne1000 driver" works with that chip. Then you fiddle around for a while longer until you discover the base I/O address is 0x220 instead of the driver's default of 0x300. Tech support? Who needs tech support?
A side effect of opening up the old SCSI drive case to use the power supply was discovering it had - just barely - enough room to hold the CPU and the disk. A trip to the hardware store produced some 6-32 screws and bolts, along with some nylon nuts that worked well as standoffs. The hard disk was secured with a single 4-48 screw I found in a junk drawer (these aren't sold in stores). Grim discovery: It's nearly impossible to drill mounting holes accurately without a real drill press.
I had to remove one of the auxiliary power sockets to get the board to fit. Fortunately the Ethernet, VGA and keyboard jacks lined up with one of the SCSI port cut-outs. The printer port I simply threaded out the other SCSI cut-out (had I a drill press I would have secured the mounting plate there).
Cool! For about $40 in scavenged parts you've got a Linux machine on the network! Put a larger laptop drive in it, load SAMBA, and you've got a mini-network file server.
But where were we? Oh yeah, building a print server. I installed the CUPS distribution included on the Debian CD's, along with the "GIMP drivers". As with most things Unix, configuration consists of tweaking files in /etc/cups/. In cupsd.conf I left most of the settings at their defaults, except for changing the "Location" settings to make sure anything on the local house network has access. I configured the server's hostname as prince, so once the server is configured you control it over the web via http://prince:631/ From there you can use the CUPS web interface to add your printer, configure it, print test pages, check print job status, etc.
I found using the GIMP-print driver in the "180 default dpi draft" mode worked the best. Some of the other print modes were unstable, and would print hyper-slow, overprint the same thing many times, or just not work at all. To be blunt, the quality of the GIMP drivers is nowhere near the native Epson ones, and they offer no support for Epson specific tasks (clearing print heads, checking ink levels, etc.). The speed in the draft mode isn't bad, but it's still off from what I've seen on the PC. I haven't investigated to see what the bottleneck is; the server's CPU speed, the parallel port, or the non-Epson driver are all candidates.
On the Mac side, I had hoped the printer would just magically appear in the "Print Center" application. No such luck. I had to go looking for it, and that proved the hardest bug to work out. The native Mac OS X "Print Center" app doesn't offer much in the way of configuration details, so I opted for the back door and used http://localhost:631/ from the Mac's web browser. This brings up the CUPS interface (just like the one on the server), and printers added that way also show up in the Print Center app. The catch is you must get the URL for the printer exactly right, and if you don't, the diagnostics are non-existent. Even turning on the debug flags in cupsd.conf and fishing the log files for clues isn't that helpful. For the record, the URL the Mac needed to find the printer was
(I had set the printer name on prince to "Epson900"). On the Mac side, using the "EPSON New Stylus Color Series CUPS v1.1" setting seemed to work the best. With this URL fixed, printing from the Mac to the server works great.
If the server is left on most of the time, it should keep the disk spun down, since that's the component most likely to wear out first. Using hdparm and noflushd can minimize this (I haven't figured out the details yet).
With the basic problem solved, I can move on for a while, but there's more that could be done. As an appliance, the server isn't all that friendly. You have about a minute's wait for the POST and Linux boot up after you turn it on, and turning it off (properly, at least) involves a remote login as super-user to issue to shutdown command, then carefully listening for the disk activity to stop before you flip off the power switch. There's no visual indication of its status, other than a simple power LED. Unfortunately the most obvious way to control a few more status LEDs would be to drive them via the parallel port, but that's already used by the printer. I suspect the serial ports could be used to add a couple of blinking lights to at least give some indication it's up and running (the SCSI case has an extra disk-access light that could be used for this). The ultimate would be to find a one or two line LCD display and drive it via the serial ports, but I currently lack the tools for mounting one.
Shortly after I got this all working, I discovered Hawking Technologies has a "PN7127P 1-Port Mini-Internet Print Server" that's just slightly larger than a printer connector. You plug it into the printer, plug the network cable into it, and it runs the Internet Printing Protocol (not sure if it's Mac OS X compatible, their web site doesn't say). It sells for roughly what I invested in the scheme mentioned above. But hey, I learned a lot building prince, and have no regrets about solving the problem "the hard way". I also discovered one of the very few benefits of being a pack rat. I was amazed at how many previously useless pieces of "junk" computer parts could be revived and turned into something useful.
According to some postings in TidBits TALK, the Hawking deviced doesn't work well with Mac OS X. However, somebody mentioned success with a DLink DP-101P+.
My problems with the ethernet card were twofold. First, for reasons I'm not sure of, I accidently installed a Debian with an older Linux kernel (2.2) instead of the more modern Linux 2.4. The older kernel isn't "smart" about reading the I/O information directly off the card, and thus needs to be told the base manually (io=0x220 which I did with modconf for the ne driver, which put this in /etc/modutils/ne, which update-modules then put it in /etc/modules.conf).
Later when I wanted to experiment with the smbfs, I discovered I needed the newer kernel. The new kernel installed easily enough with apt-get install kernel-image-2.4.18-bf2.4, it even politely kept the old one around. But the ethernet card vanished again. After many hours of searching the net and poking around (I even downloaded the kernel sources...) I discovered that the new 2.4 kernel was smart enough to properly discover the ethernet card on its own using a new module called "isa-pnp", but(!) the configuration line I had left over from the previous kernel confused the ne driver and prevented it from finding the card. I guess it didn't know who to believe, so it just gave up. I finally found a posting with the major clue: remove the io=0x220 line and it finally worked. Just tell modconf to load ne and isa-pnp and do not specify any options.
A couple months ago the 1.5Gb drive died. First, I tried getting a refurb D-Link DP-101P+, as mentioned above. Although it went through the motions correctly, I couldn't get it to print from the Mac. Without any detailed log or diagnostics on the dongle, I was pretty well stuck.
So back to fixing Prince.. Reload Debian from scratch. Ugh This time I knew to select the "bl24" kernel to get the modern one, and had no trouble with the Ethernet showing up. However, apt-get started croaking with "Dynamic MMap Ran out of room". Adding:
To /etc/apt/apt.conf fixed it (thank you Google).
For some reason tasksel left CUPS out of the mix, so CUPS needed to be re-installed. And then it didn't have the flaky GIMP drivers, so that needed to be installed. And then it mysteriously failed because (fishing for clues from the logfile) "EPS Ghostscript" was not installed. Debian calls this "gs-eps". Installing that finally produced a test page (but restart cupsd with "kill -HUP <cupsd-pid>" first).
I worry about the printer (an Epson Stylus Color 900) dying. A new printer would not support the parallel port (most are USB only). I'd either have to update the board in Prince to a new one with a USB port. Or better yet, just punt and replace it with a Mac Mini, which has real software.