This is the only thing that it does. Just keep telling me I have no
Authentication data provided.
I have never provided authentication for the last three years that this was
working. There was an upgrade somewhere with the clients and server that has
just hosed everything up.
Depending on which way the wind is blowing the Firefox browser will work, but
it's 50/50 and with no other error reported than this.
Cups has no documentation regarding this problem and little in the way of Policy
or other areas that have much to do with this.
I've tried removing all the Auth statements in the conf file, changing
EVERYTHING to Allow localhost, 192.168.1.* and still it's not working.
I have been without a printer for far too long for this to be funny.
I've even tried the dumb-ass solution of purging Cups and reinstalling it fresh.
Nothing changed.
The printers absolutely work from test pages.
The printers absolutely do not work from remote clients.
I don't have sufficient software on the printer server to try printing as a
localhost client -- that's not the intention of this box.
All I can find is that a lot of people have this problem and no one seems to
have a fix for it. Does anyone any suggestions or is this one of those, "Oh
Yeah, you need to use unstable as test/stable have a bug" I'm pretty hosed.
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
[...]
> I've tried removing all the Auth statements in the conf file, changing
> EVERYTHING to Allow localhost, 192.168.1.* and still it's not working.
[...]
> The printers absolutely work from test pages.
Test pages triggered how, directly on the server or from the clients?
> The printers absolutely do not work from remote clients.
> I don't have sufficient software on the printer server to try printing as
> a localhost client -- that's not the intention of this box.
What do you find in /var/log/cups/error_log and /var/log/cups/access_log
on the server after such a failed print attempt? (You may have to set
the loglevel to debug and restart CUPS if you have not done so already.)
Can the client computers access the server's CUPS web frontend at port
631?
--
Regards, | http://users.icfo.es/Florian.Kulzer
Florian |
> What do you find in /var/log/cups/error_log and /var/log/cups/access_log
> on the server after such a failed print attempt? (You may have to set
> the loglevel to debug and restart CUPS if you have not done so already.)
>
Thanks for the help. I spent most of the day on this and finally cracked it.
I sent an email to the maintainers because I think it's tied to three bugs and
also to this list.
It comes down to this:
I picked up some upgrades that put me on "bad" code that couldn't handle
something. One line of reference has to do with the kernel, libgutenprint, and
cups. I went from Kernel 2.6.8 to 2.6.26 (everything went from stable to
testing - cups, gutenprint, foomatic) and it's working great now.
But the No Authentication Data Provided error continues, but it doesn't stop
anything from working. So my "care factor" is really now on that one.