Cups Won't Print PDF, and Other Config

Symptom:

Starting with an update to cups-2.3.3op2-6.1, some annoying symptoms cropped up. First, executing on Diamond (where cupsd is running), the Financial Manager views a PDF with Evince (uses Cairo as its PDF backend) and tries to print it. The file is sent, Cupsd creates a credible-looking pipeline to render it, but there is no visible reaction from the printer. On the other hand, if I do lp -d lp2 /etc/os-release (a short file of text/plain), it is printed.

When I try to investigate with the Cups web GUI, executing on my laptop, the browser gets 403 Forbidden. When I try the above test print command, tcpdump reveals that it also gets 403 Forbidden.

Investigating on Diamond, the browser reports that the server's X.509 certificate for TLS is signed by an unauthorized certificate authority.

What's happening with the TLS certificate:

Cups is using a self-signed certificate, hiss, boo. The following lines in cups-files.conf switched it over to the correct cert and key:

ServerCertificate /etc/ssl/hostcerts/host.crt
ServerKey /etc/ssl/private/host.key
CreateSelfSignedCerts no

The latter line (CreateSelfSignedCerts no) was the tricky one: the default is yes, and in that case it ignores the provided paths. Cupsd runs as root (and there is no sign that it's capable of dropping privileges), so it has permission to read the host key; no need to add user lp to group hostcert. Now the browser has no complaints about Cupsd's TLS certificate.

What's happening with my laptop's access:

It's not that Diamond is rejecting everyone but itself; it's specifically rejecting the laptop. Because the laptop solves a routing problem by connecting to the local LAN by a VPN, whether or not it's roaming. In the Location configurations for Cups directories, they say Allow from @LOCAL (and in addition, my firewall excludes the global hacking community). However, @LOCAL does not include point-to-point interfaces like a VPN, so my laptop gets excluded. I changed to these authorizations (IP ranges changed to protect the guilty):

Allow from 192.168.1.0/24
Allow from [fd18:fedc:ba98:1::]/64

Now my laptop can print and connect to the web GUI.

What's happening with the non-printing PDFs:

The first symptom found in /var/log/cups/error_log was the message: CreateProfile failed: org.freedesktop.DBus.Error.ServiceUnknown:The name org.freedesktop.ColorManager was not provided by any .service files, which is no lie and is the immediate cause of the failure.

Modern printing is deeply tied up with color management. Cups has now outsourced the color issue to a suite of packages centered on colord, and in particular, the dependent package argyllcms will use the color profile for the specific printer (which Cups actually has and registers with colord) to render the device-independent PDF and to tweak the colors so they are printed as they were when the document was created. Without argyllcms the rendering doesn't happen and nothing can be printed.

To get past this problem I installed colord and its dependencies. I also installed gnome-color-manager, a GUI for managing colord's color profiles, but it's not required and I haven't tried it yet. Evince also uses colord and complains if it is missing; in other words, it needs to be installed on all hosts for users, plus the print server.

Colord is dbus-activated; it will start when needed and doesn't have to start at boot. It could, but doesn't, exit if no longer used.

But the PDFs still don't print. The error message is now: Grayscale/monochrome printing requested for this job but Poppler is not able to convert to grayscale/monochrome PostScript. Use 'pdftops-renderer' option (see cups-filters README file) to use Ghostscript or MuPDF for the PDF to PostScript conversion. The file mentioned is /usr/share/doc/packages/cups-filters/README .

I followed the instructions in the README (search for pdftops-renderer)) and was able to print PDFs. Specifically:

• Per job: lp -d lp2 -o pdftops-renderer=gs -P 1 ./file.pdf
• Per queue: lpadmin -p printer -o pdftops-renderer-default=gs
• To revert: lpadmin -p printer -R pdftops-renderer-default

In the README they recommend Ghostscript (gs) as a good general purpose color renderer, except Evince (which I use most of the time) uses Cairo to generate PostScript, except when I tried pdftocairo as the renderer it didn't print and I didn't try to debug it.

So the fallout from this modernization of color management has been brought to a successful conclusion.