Enable CreateIPPPrinterQueues by default

[raindev]

Hi,

I have noticed that in Fedora driverless printing wasn't working the way I used to expect from my experience with Ubuntu derivatives. It turned out the reason was simply that CreateIPPPrinterQueues not being set in /etc/cups/cups-browsed.conf.

I wonder what are the reasons for not having CreateIPPPrinterQueues All enabled by default in the configuration tempalte?

Accordingly to the Debian wiki, the config has been adopted as the default since bullseye. It would be nice to not have to patch the config in multiple distributions.

[raindev]

@tillkamppeter I would appreciate if you could share any feedback on the idea 🙏

[tillkamppeter]

If you package cups-filters for a distribution, you can simply call ./configure in the package build script with the --enable-auto-setup-driverless-only option or other --enable-auto-setup-... options to control which types of network printers get auto-created queues.

[raindev]

Thank you for the response. I'll send a pull request for the Fedora package.

[zdohnal]

@raindev @tillkamppeter looks like a misconfiguration, because cups-filters is built for Fedora with 'CreateIPPPrinterQueues All' by default (see link)

Snippet:

	all ipp printer auto-setup: yes
	only driverless auto-setup: no
	only local auto-setup: no

I've tested this configuration in my local network and my IPP printer was created correctly.

[raindev]

After spending some time yesterday to debug the configuration script and the handling of the configuration in cups-browsed.c I have concluded that it works as intended.

I don't use cups-browsed directly but rely on GNOME printer integration (default Fedora Workstation 36 set-up). My assumption that GNOME makes use of cups-browsed turned out to be incorrect. It was based on the fact that after setting CreateIPPPrinterQueues All in /etc/cups/cups-browsed.conf I've got the printer working correctly. Before that I would have the printer discovered but it was non-functional. Apparently GNOME is communicating with cupsd (via DBus) to discover IPP printers without involving cups-browsed. What's curious is that cups-browsed.conf is not read in in any other places in cups, except cups-browsed.c (as far as I can tell from a quick grep over the sources).

The issue looks similar to this Fedora bug report:
https://bugzilla.redhat.com/show_bug.cgi?id=1910908

If you point me into the right direction, I would be happy to do more debugging.

[raindev]

The same printer is detected automatically on Debian based systems. Those use a different set-up and rely on cups-browsed accordingly to the wiki.

[zdohnal]

Before that I would have the printer discovered but it was non-functional.

Do you mean 'by discovered' that you've entered GNOME and manually searched+installed the printer?

Apparently GNOME is communicating with cupsd (via DBus) to discover IPP printers without involving cups-browsed.

To be precise, if you manually search and install the printer, gnome-settings-daemon communicates with cupsd (for getting permanent printers etc.) and with scp-dbus-service (when it wants the best driver for printer), which uses pycups and pycups sends requests to cupsd.

What's curious is that cups-browsed.conf is not read in in any other places in cups, except cups-browsed.c (as far as I can tell from a quick grep over the sources).

That's expected - cupsd is a separate daemon and cups-browsed communicates with it via IPP requests.

The issue looks similar to this Fedora bug report: https://bugzilla.redhat.com/show_bug.cgi?id=1910908

IIUC the issue is the GNOME printer setup dialog gets incorrect driver - it can happen if 'driverless' driver times out and there isn't any other precise driver match by IEEE-1284 device ID in drivers, so if scp-dbus-service returns the closest drivers to the requested (similar model etc, with bottom line with generic driver or raw), which can or doesn't have to work (but sometimes better than nothing...).

cups-browsed on the other hand does IPP requests directly to the printer and composes the driver based on the response, so if the printer is capable of returning valid IPP response to some extent, the created printer is set with options directly from printer. The same thing does 'driverless' driver as well, but sometimes it doesn't return the driver itself, so GNOME tries to use a different driver.

In Fedora cups-browsed is disabled by default because it is not necessary with recent IPP printers and up-to-date print dialogs. If your printer supports IPP Everywhere and you set the printer to use IPP Everywhere (by opening its IPP port) and set the firewall (enable IPP and mDNS communication), there is no need for installing printer permanently for up-to-date print dialogs.

If your printer supports IPP Everywhere - there is a great chance it does, network printers support it since aprox. 2010, and don't see the printer in print dialog without manual installation, it would be great if you reported it to the application developers - it would be great if they started to support the feature - temporary queues.

If you point me into the right direction, I would be happy to do more debugging.

It would be great if you looked into issue why 'driverless list' doesn't sometimes return anything - in case you have IPP Everywhere supported printer.

[raindev]

First of all, thanks a lot for taking time to write the detailed explanations,
I appreciate it.

Do you mean 'by discovered' that you've entered GNOME and manually searched+installed the printer?

The printer was already added out of the box, before editing the config, I didn't have to search for it manually. He's how it looks like in the GUI:

comparing to the screen for a correctly functioning printer:

The printing options are broken in this state and attempting to print a test page fails silently:

comparing to a correctly functioning printer:

In cupsd logs I see: REQUEST localhost - - "POST /printers/Brother_HL_L2350DW_series HTTP/1.1" 200 429 Print-Job client-error-not-found

driverless list returns no results the first time I run it, but returns a
seemingly correct result the next runs:
"driverless:ipp://Brother%20HL-L2350DW%20series._ipp._tcp.local/" en "Brother" "Brother HL-L2350DW series, driverless, cups-filters 1.28.10" "MFG:Brother;MDL:HL-L2350DW series;CMD:PWGRaster,AppleRaster,URF,PWG;"

It seemed initially that I was able to resolve the issue by having
CreateIPPPrinterQueues option set in the config explicitly. I'm not sure it
was the actual trigger: I now have two machines, on one the printer is working
correctly with the unmodified configuration, on the second is not functioning
with CreateIPPPrinterQueues in the config.

[raindev]

In Fedora cups-browsed is disabled by default because it is not necessary with recent IPP printers and up-to-date print dialogs. If your printer supports IPP Everywhere and you set the printer to use IPP Everywhere (by opening its IPP port) and set the firewall (enable IPP and mDNS communication), there is no need for installing printer permanently for up-to-date print dialogs.

If your printer supports IPP Everywhere - there is a great chance it does, network printers support it since aprox. 2010, and don't see the printer in print dialog without manual installation, it would be great if you reported it to the application developers - it would be great if they started to support the feature - temporary queues.

It looks like I was digging in the wrong place than, as cups-browsed doesn't play a role in this set-up. Also the printer does show up both in Gnome Settings and in the system print dialog so this looks like an incorrectly selected driver.

[raindev]

I cannot really reproduce the problem reliably: on the same machine the same printer is configured correctly once and incorrectly after a restart, sometimes I can see the ink level and sometimes not. I guess the problem is non-deterministic (depending on the timing, state of the printer, request latency etc.). The approach leveraging cups-browsed does seem to be more reliable: the printer is always correctly configured on Debian derivatives. I'll update the thread if I find something interesting the next time the printer is unusable.