Printing and Linux, a cautionary rant
February 18, 2012
A perfect storm of user-infriendliness. Mr. Bazaar-vs-Cathedral ranted about this years ago, and nothing happened to address his gripes (I just had all the same problems he did, almost six years later).
The goal, in the end, is to get iPad printing to work. Printing stuff has been the least-friendly part of the Apple experience for years, too, perhaps because it is all routed through the same nasty software that is used on Linux, and you can only put so much lipstick on a pig. A friend of mine sent me a link that is supposed to help, and running it didn’t crash, and did produce output, all of which totally exceeded my expectations. I put the files where they were supposed to be, did the “kill -HUP” incantation (awesomely user friendly, everyone knows what that means, right?), the iPad saw the printer, but whoops, “no longer available”. Hmmmm.
Back to the instructions: “Your CUPS server should also have a working PDF filter.” (and that is all that is said on the subject).
Someone needs to rig up Google translate, so that it spots these opaque useless hints appearing in clueless-developer-ese, and translates them to something useful. Turns out yum (everyone knows about “yum”, right?) can find it, called “cups-pdf”, so I install that.
But no luck. iPad sees the printer, but when I print, still “no longer available”. Eventually I go looking at error logs, and see complaints about contacts from “amahibox.local”, as if it is not a real address (the local network hostname IS “amahibox”). I’m pretty sure that “avahi” (everyone knows what that is, right?) and “bind” (ditto) are using different names for the same machine. So I edit /etc/hosts (obvious, right?) and add “amahibox.local” as an alias, and now the iPad gets past no-longer-available, but nothing comes out. I go noodling in the logs again, and
Returning HTTP Forbidden for Validate-Job (ipp://amahibox.local.:631/printers/HP_color) from 192.168.0.112
I try “sharing” the printer using admin interface, but no matter what buttons I click, when I hit “save”, my changes vanish. So, I go whacking on /etc/cups/cupsd.conf, and take out all the restrictions (that I know how). I did it wrong the first time, and CUPS put them back, so I took them out differently, and this time they stuck.
And by-the-way, in case anyone doing security stuff is reading, if you give a user who has the root password non-functioning “administration” buttons, you had better assume that his or her next step is editing the configuration files, which always turns out well, right? And they’re never going to touch your fucking buttons again, because odds are they will mess up the configuration file that was tediously and carefully configured to make a printer actually print stuff.
Now, the iPad connects and claims it is printing, but nothing comes out, and there’s nothing funny looking in the log file — it just doesn’t work. And the CUPS web interface is hung, too. AWESOME! Fortunately, this is not really a problem, since I wasn’t using this box for printing anyway. Would have been nice, but oh well.