Can't delete print job: Error: client-error-forbidden

Message

disciple · #1 Post by **disciple** » Wed 18 Feb 2009, 08:06

A couple of other people have reported this problem, but I haven't seen a solution. When I try to delete a print job using the cups web interface, I get the message

Code: Select all

Error: 
client-error-forbidden

I know they can be deleted other ways, but can anyone using the standard CUPS in Puppy 4.x actually successfully delete a print job using the CUPS web interface?
If so, is there anyone using hplip who can?

smokey01 · #2 Post by **smokey01** » Wed 18 Feb 2009, 21:48

disciple,

I haven't manage to get this to work in CUPS either but this works.

To delete all print jobs from the console type "lprm -"

Not sure if this does though.

To delete a particular job type "cancel(1) for job number 1.

disciple · #3 Post by **disciple** » Thu 19 Feb 2009, 04:31

So it looks like a bug...
The CUPS dotpup package that we used to use by Pakt or someone worked fine

I wonder if this patch would fix it http://adam.rosi-kessel.org/weblog/2004/12/31/linux

Or maybe it is this. I'm not at home ATM, so I can't check if that section is in the config file...

disciple · #4 Post by **disciple** » Sat 21 Feb 2009, 01:57

Yes, that's the problem - stupid design

You can cancel jobs if you add

Code: Select all

AuthClass User

to the <Location /printers> section of /etc/cups/cupsd.conf, although it means you have to login

I wonder if it is possible to somehow login automatically...

Pakt's dotput didn't have this problem, so maybe it had that patch applied.

disciple · #5 Post by **disciple** » Sat 21 Feb 2009, 07:12

Darn - no, leafpad doesn't seem to be able to print now... what's wrong with these CUPS people?

vtpup · #6 Post by **vtpup** » Sun 22 Feb 2009, 01:16

Yup, wrestling with the same problem here.

vtpup · #7 Post by **vtpup** » Sun 22 Feb 2009, 02:33

Disciple, what do you think about this:

User
Examples

User lp
User guest

Description

The User directive specifies the UNIX user that filter and CGI programs run as. The default user is _lp.

Note:

You may not use user root, as that would expose the system to unacceptable security risks. The scheduler will automatically choose user nobody if you specify a user whose ID is 0.

There's a User root at the top of cupsd.conf.

disciple · #8 Post by **disciple** » Sun 22 Feb 2009, 02:51

Yes, I did notice that, but I don't think it is connected with our problem.

The old cups dotpup worked perfectly, and had the same cupsd.conf as in Puppy 4.x, so I'm guessing it had that patch applied to fix this.

#9 Post by **ttuuxxx** » Sun 22 Feb 2009, 03:17

try this
http://www.murga-linux.com/puppy/viewto ... h&id=15331
Just install it, then in the menu you'll have 2 new frontends for cups, One will allow you to monitor jobs, cancel current, cancel all jobs etc.

Menu/System/GTKLP
Menu/System/GTKLPQ
ttuuxxx

kirk · #10 Post by **kirk** » Sun 22 Feb 2009, 04:46

I patched cups-1.1.23 to fix that. A pet package is here:

http://puppylinux.asia/tpp/kirk/cups-1.1.23p.pet

Try it booting up ram only and installing it. Just in case your dog explodes or something else horrible happens

vtpup · #11 Post by **vtpup** » Sun 22 Feb 2009, 05:04

Thanks for the help, both of you. But I'm always curious about why something is wrong before just applying a patch. Can you tell me?

Obviously it is trying to authenticate when it shouldn't. I've tried AuthType=None, and AuthClass=Anonymous in every Location, each alone, and both together, with no effect. I've also tried to add location /jobs and used both, again with no effect. every time I try something new I just get in Cups error log:

Code: Select all

E [21/Feb/2009:23:54:31 -0500] Unable to open /etc/cups/passwd.md5 - No such file or directory
E [21/Feb/2009:23:54:31 -0500] cancel_job: "" not authorized to delete job id 1 owned by "root"!

I do stop and restart CUPS with every change, and even reboot to make sure.

Nothing affects its behavior.

vtpup · #12 Post by **vtpup** » Sun 22 Feb 2009, 05:16

Well, here's a workaround that seems simpler than the web interface.

If you want to cancel job number 1, just type:

Code: Select all

cancel 1

in the console.

Not too hard to remember that one.

EDIT: I now see smokey mentioned that one early on

disciple · #13 Post by **disciple** » Sun 22 Feb 2009, 07:11

But I'm always curious about why something is wrong before just applying a patch. Can you tell me?

Read about it in one of the links I posted at the top - basically the CUPS people decided it was too insecure to be able to delete jobs anonymously... rather than putting the onus on network administrators to configure things securely if they want security, they just made it impossible to make it insecure

vtpup · #14 Post by **vtpup** » Sun 22 Feb 2009, 17:38

Thanks for the reference, Disciple, I see it now, under the "here" in your post which is a bug report.

Actually the report was closed because the bug was supposedly fixed in Cups 1.20.

But we seem to have it here in a later version, so I'm wondering if they did solve it, but inadvertently re-enabled it in this version? What version in the dotpup worked?

Unfortunately, because the issue is closed, no further comments can be added to this particular issue.

disciple · #15 Post by **disciple** » Mon 23 Feb 2009, 02:53

That was a debian bug report - the way I read it the bug was fixed in Debian's Cups package, not in the upstream CUPS.

gymnart · #16 Post by **gymnart** » Mon 23 Feb 2009, 18:11

I don't know if this will work well in Puppy but I had to have my SuSE system (CUPS 1.1.23) set up this way in cups.d:

<Location /jobs>

AuthType None
AuthClass User
Allow From @LOCAL
</Location>

I also have the statement RunAsUser set to "No". I am able to cancel any print job this way. I haven't had to do that in a long time so I don't remember if it wants the root password for this or not.

Anyway, like I said, I don't know if this would work in Puppy. I learned about this from the linuxquestions.org forums.

vtpup · #17 Post by **vtpup** » Mon 23 Feb 2009, 19:32

Thanks for trying gymnart.

In Puppy's CUPS version, that stanza brings up a user/password authentication window when clicking on jobs in the web interface.

If either user or password fields are left blank and the enter button is pushed, the password challenge is repeated and you can't move to the jobs screen.

If any user name and any password are entered, they are accepted, and the jobs screen opens, but the user can't actually delete a job

If root is entered as user, and any password is entered, the user can delete a job.

So, it's possible to semi-authenticate using root, and any word for a password, and then delete a job.

It is a lot easier to just type cancel 1 (for job #1) in the terminal.

gymnart · #18 Post by **gymnart** » Mon 23 Feb 2009, 19:54

ok, but what about the statement RunAsUser and set it to "No"? What is it set to right now?

vtpup · #19 Post by **vtpup** » Mon 23 Feb 2009, 20:03

Hi gymnart, I tried it without the RunAsUser statement, with it set to No, and with and without User set to root. I didn't notice any difference. I killed and restarted CUPS with each try.

gymnart · #20 Post by **gymnart** » Mon 23 Feb 2009, 23:36

ok, thanks.

(old)Puppy Linux Discussion Forum

(old)Puppy Linux Discussion Forum

Can't delete print job: Error: client-error-forbidden

Can't delete print job: Error: client-error-forbidden