Printer Sharing - The Missing Link

by Scot Hacker



Thanks to an extremely gracious Apple employee, our home printer sharing issue has been solved. After posting Rock and a Hard Place last week, WebObjects/Enterprise support team member Henry Stukenborg contacted me with an offer to try and help sleuth out the source of the problem.




As it turns out, CUPS has a nifty http interface, which becomes available as soon as you enable printer sharing - just hit http://localhost:631 (and no, this doesn't mean people can control your printer remotely if they know your IP - CUPS restricts administrative access to localhost).




From there, click on Printers - you'll see all the shareable printers on your network. If all is well, you should be able to print test pages from here. More importantly, you'll be able to see the names by which CUPS sees the printers. This interface revealed that my print chain was breaking down somewhere between Print Center's identification of the remote printer - which is managed by Rendezvous - and the operating system's ability to actually send documents to it - which is managed by CUPS. CUPS will use either IP or hostname resolution to identify printers -- what was breaking down on my system was the resolution of hostname to IP address (nslookup helped here).




When pulling up the CUPS http interface from the host computer, the printer appeared as HL-1440_series@gong. But the same printer as viewed from the CUPS UI on her machine was HL-1440_series@betips.net. Neither idenfication was correct.




The kink in my setup is that I run a domain off the machine - betips.net - and allow my ISP to handle the DNS. But I've always called this machine "gong" - I had entered "gong" as the hostname in /etc/hostconfig and as the Computer and Rendezvous names in Sharing prefs. Thus, a subtle discrepancy between the "gong" hostname and "www" or "www.betips.net" had always been present - I had just never tried to do anything that exposed the discrepancy.







By returning the hostname entry in /etc/hostconfig back to -AUTOMATIC- and restarting both computers, OS X was able to identify machines on the network the way it saw fit. My wife practically blew a gasket of joy when the remote printer hummed to life from her workstation.




So as it turns out, the problem was fairly pedestrian and the fix was simple. It's one of those problems that seems almost obvious in retrospect, once you know the solution. But it's only obvious if you know where to look. The Apple Geniuses, Brother's support dept., and I all suspected either the printer driver or the CUPS layer. None of us thought to look at problems in hostname identification. As Wittgenstein said, "A man is imprisoned in a room forever if it never occurs to him to pull, rather than push the door." Henry thought to pull the door. I owe him one.




5 Comments

yvesde
2002-12-16 08:33:09
Here is another one
Has anybody tried to cancel printer-shared printing ?
In print center, delete commands are disabled on the client-side, and they don't give any results on server-side. CUPS admin interface lacks privileges and gets turned back. Any link ?
anonymous2
2002-12-16 10:33:44
So Thats Why...
I was wondering why my printer worked perfect every time. I run my own DNS server and have it configured correctly.
anonymous2
2002-12-16 19:16:41
Excellent find
Setting HOSTNAME to -AUTOMATIC- solved the problem that's been killing me since upgrading to 10.2.2. Huge thanks for finding this out.
anonymous2
2002-12-16 19:59:12
RE: Excellent Find
Actually, *ANY* change in the /etc/hostconfig file fixes the printer sharing issue for about five minutes, at which point, at least for me, the shared printer unceremonisouly drops off the network again. C'est la vie.


All I can think is that some other process starts up and conflicts. I wouldn't keep pressing this issue, but I think it's a 10.2.2 bug.

anonymous2
2003-07-30 21:20:09
Here is another one
A solution that worked for me!


http://docs.info.apple.com/article.html?artnum=25459