OpenPrinting distribution in OCI containers

[Robert McQueen]

Dear Till,

Great to meet you at the Linux App Summit last week. As promised, a
mail with some thoughts/links about distributing CUPS and Printer
Applications on systems where there is a minimal (potentially
immutable) OS and applications are predominantly distributed as
Flatpaks.

My understanding is that you've been working on the OpenPrinting team
directly distributing CUPS as a Snap, including the necessary few
filters required to use driverless printers, and are also publishing
separate standalone IPP Printer Applications for several other driver
stacks such as PPDs for Postscript printers, Ghostscript raster
printers, HPLIP, etc. This is appealing as it allows the printer system
to be distributed directly by OpenPrinting, updated independently of
the OS and updated in a timely manner to support new devices, and in
the most common driverless cases, removes the overhead and complexity
of non-IPP printers/drivers from CUPS.

I've copied the Flatpak mailing list as there are a number of
individuals there who represent / work on systems such as Endless OS,
Fedora Silverblue, SUSE MicroOS, GNOME OS, etc who could potentially
chime in on whether my ideas are any good, to what extent the proposed
suggestions may be relevant/valuable to them, and if they have any
better ideas!

As we discussed, the main challenge is that Flatpaks are simply not
designed to run system services. They are designed to run user-facing
applications, within the context of a particular user session,
connecting to that user's D-Bus, display server, cgroups managed by
systemd --user, etc. There is no mechanism for executing Flatpaks as
system services. In the case of multiplexing/queueing jobs destined for
a device not able to spool jobs by itself, multiple CUPS instances (or
Printer Application instances) on one machine running as different
users trying to access the same device seems undesirable. (And, not
being able to access port 631, seems like discovery, network sharing,
etc, would be broken as well.)

A second lesser challenge is that currently Flatpaks cannot provide
systemd units even in a user context. Although if we did want to
consider systemd units, or socket or port activated services, this
might be possible to specify and implement as it's conceptually not too
dissimilar to D-Bus service activation, but I believe it would still be
undesirable for CUPS due to the above.

My best/least worst idea for installing/managing CUPS and Printer
Applications on such Flatpak-based minimal/atomic OS base systems would
be to publish OCI container images which correspond to the CUPS and
several Printer Application snaps you already produce. These can be
downloaded, updated and run with docker, podman or other OCI-compatible
container runtimes (which may include systemd but I am slightly out of
date here?) and share access with the host system as necessary - e.g.
connecting to the D-Bus system bus, exporting ports, accessing device
nodes, etc.

There is prior art in as much as there are two very popular CUPS images
on Docker Hub, which you can find
at https://hub.docker.com/search?q=cups - these are likely to be used
on NAS and other light server devices which don't ship with their own
printing system but provide a mechanism for user-configured OCI
containers. The top two with 1M+ downloads each are built from Debian
packages, which can be seen at
https://gitlab.com/ydkn/docker-cups/-/blob/master/Dockerfile and
https://github.com/olbat/dockerfiles/blob/master/cupsd/Dockerfile -
official OpenPrinting builds might prefer to do this from source
otherwise you have a long lead time between releasing, packaging, etc
and being able to offer new OCI images.

The challenge there is that docker/podman are lower-level and do not
really provide a standardised user experience for installing,
automatically checking for updates, providing desired
persistent/transient volumes for configuration/state, configuring
exported ports, etc. This is where Kubernetes or similar container
orchestration tools fit in for larger deployments, but are huge
overkill for a single system. A typical OCI image will come with a
"serving suggestion" for how to execute it with "docker run", and more
complex cases a YAML file for docker-compose to run multiple containers
together with shared networking/volumes.

Something that might assist in bridging this gap which Alex Larsson
mentioned is a tool he wrote called Quadlet, which reads simple
systemd-style declarative files and generates systemd units which
manage the containers with podman.
https://blogs.gnome.org/alexl/2021/10/12/quadlet-an-easier-way-to-run-system-containers/

This isn't a "complete solution" but more of a rough direction to
consider heading in. I'm interested to hear what the Flatpak folks
think? Has anyone from Silverblue, SUSE MicroOS, Endless or others
considered containerising the print system?

Many Thanks,
Rob