On 9/14/06, darren kirby <[EMAIL PROTECTED]> wrote: <SNIP>
OK, I just tried lpq on my system (on a local terminal) and it works fine.
As it did on mine before I took down the Mac. I may as well try turning the MAc on again this evening and see if this problem really changes when it's on the network.
Here's an idea, maybe the lpq command needs to have explicit access to: <Location /admin> </Location>
HEre is my admin section from /etc/cups/cupsd.conf: <Location /admin> AuthType Basic AuthClass System ## Restrict access to local domain Order Deny,Allow Deny From All Allow From 127.0.0.1 #Encryption Required </Location>
to access the queue...though this is a crapshoot, as I believe 127.0.0.1 is allowed this access by default. > I've seen this before, actually, when the Mac was turned off. > Linux/Gnome would only see the local CUPS server after it had seen the > remote server on the Mac. > > I'm thinking that the system (some part of it anyway) has cached > the fact that the Mac had a CUPS server somewhere. Now that the Mac is > gone it cannot move forward. I have no data to back up that idea > though and I have no idea how to prove it true or false... Hmm, I have not heard of a Cups 'printer cache' but that certainly doesn't mean there is not one... I assume you have removed all traces of the Mac printer/daemon through the Cups web administration interface and /etc/cups/client.conf?
I had thought so but it wasn't the case. client.conf had a pointer to to the Mac Mini. I removed it by hand and restarted cupsd here and now get different/better results: lightning ~ # lpq lpq: error - no default destination available. lightning ~ # After setting the local pronter as default using the Cups admin tool it now acts nice: lightning ~ # lpq HP is ready no entries lightning ~ # Thanks for the help! Cheers, Mark -- gentoo-user@gentoo.org mailing list