Jobs can be held without any explanation available to the user

[afcady]

I have a cups installation that was working OK printing over the network, but then it stopped working for reasons I haven't been able to discover. All new print jobs become "held."

Neither the web UI, nor even the logs in /var/log/cups/error_log, give any explanation whatsoever of what caused the jobs to become "held."

The UI should explain the reason for the hold in the same place that it says that the job is held.

[michaelrsweet]

@afcady What version of CUPS are you using?

What operating system/Linux distro?

Do you have the CUPS log level set to debug (run "cupsctl --debug-logging" to enable it)?

[afcady]

Debian with cups 2.2.1-8+deb9u3. (It's the current Debian stable version.)

After posting before, I did enable debug, and I found the relevant line to be Backend returned status 2 (authentication required). The backend is ipp.

Incidentally, I also edited the configuration on the server (also cups), making the following edit to cupsd.conf

diff --git a/cups/cupsd.conf b/cups/cupsd.conf
index d467b93..0566623 100644
--- a/cups/cupsd.conf
+++ b/cups/cupsd.conf
@@ -11,8 +11,9 @@ WebInterface Yes
 <Location />
   # Allow shared printing...
   Order allow,deny
   Allow @LOCAL
+  Allow 192.168.0.0/24
 </Location>

This made the printer work again, and to my mind suggests an unrelated bug, since @LOCAL should be sufficient. I spent a bit of time investigating that, looking at scheduler/auth.c which shows that @LOCAL is actually equivalent to @IF(*)... only local interfaces are ever matched by interface name. Nothing is really documented in cupsd.conf(5) btw. There is a function is_local that checks the interfaces, which is a possible source of that problem. I didn't look at it.

But of course none of that belongs on this bug. I will probably file another bug. Might put some more logging into auth.c/cupsdCheckAuth() first. Stopped looking at it for now though.

[michaelrsweet]

@afcady The @LOCAL macro only maps to the local networks/masks your system is on. So for example if your system is on 192.168.0.x then it should allow any client on that same subnet. But if your system is on 192.168.1.x and you want a client on 192.168.0.x, you'll need to allow a different subnet besides "@Local".

I'm happy to add some more details to the cupsd.conf man page, although even when we had more information in the old System Administrator's Manual the name "@Local" was still confusing.

[master 242b4b9] Update the cupsd.conf man page to better explain what @if(name) and @Local do (Issue #5604)

As for the job status, I've updated the jobs template for the web interface. The "long" form of the lpstat output already would show "cups-held-for-authentication".

[master 4e104fb] The web interface did not show that a job was held for authentication (Issue #5604)

And finally I've updated the logging code to treat "held" jobs as an error to be logged:

[master 9c13b7d] Log held job messages as errors so that is it clear why a job was held (Issue #5604)

[afcady]

Thanks a lot for making those changes. That's great.

I had another look at the cupsdCheckAuth function. It is iterating through the interfaces and for each interface, it gets an IP address/mask and checks the connection IP against that. That can't ultimately be right, since an interface could have any number of IP addresses/networks.

[michaelrsweet]

@afcady Indeed, that's why the cupsdCheckAuth code checks all of the matching cupsd_netif_t entry addresses (one is created for every address for each interface).

[afcady]

Huh. Well I have to say, then, that the need to put an IP subnet in there remains a mystery to me. (It wasn't an IP on another network.)