OpenPrinting distribution in OCI containers

[Andrew Hayzen]

Hi,

I wondered if you have also considered using systemd's portable
services?

https://systemd.io/PORTABLE_SERVICES/

It looks interesting in that it can run an image with some sandboxing
and appears like a normal systemd service. However it's unclear to me
how the services should be distributed and how strong the sandboxing
options are, if the image could be distributed via OCI / ostree then
maybe it is a good fit.

Otherwise maybe the Quadlet route you suggested is better at generating
systemd services as it already has the OCI distribution sorted.

Thanks,

Andrew

On Mon, 2022-05-02 at 19:20 +0200, Robert McQueen wrote:
> 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
> 
>