Today, the new
cups interface for application Snaps being able print via the CUPS Snap got merged into snapd (to be released into edge tomorrow and into stable in snapd 2.55 in 2-3 weeks).
It is supposed to work as follows:
The CUPS Snap has a slot named
cups, defined as follows
slots: cups: interface: cups cups-socket-directory: $SNAP_COMMON/run
and in the directory
$SNAP_COMMON/run the socket
cups.sock is defined (note that this is not yet committed to the CUPS Snap as it requires snapd 2.55).
An application Snap, which wants to print simply needs to plug the
cups interface. When such a Snap gets installed from the Snap Store snapd will do the following:
- If the CUPS Snap is not installed (or a too old version), the CUPS Snap gets automatically installed in addition to the application Snap, like a package dependency.
- In the application Snap’ sandbox the CUPS Snap’s
$SNAP_COMMON/rundirectory gets mounted to
/var/cups, this way the application Snap has access to the CUPS Snap’s
- The application Snap’s
cupsplug gets auto-connected to the CUPS Snap’s
- In the application Snap the environment variable
CUPS_SERVER=/var/cups/cups.sockgets set, so that the application directs all its print requests to the CUPS daemon of the CUPS Snap.
The CUPS Snap will do the following then:
- If the system has already a classically installed CUPS (via DEB, RPM, source, …) the CUPS Snap will run in proxy mode, meaning that it will work as a proxy/firewall between the application Snaps and the system’s CUPS. It will replicate the system’s queues and pass jobs through to the system’s CUPS. So the user will have the same queues and printer drivers as he is used to for both printing from classically installed applications and application Snaps.
- If there is no CUPS installed on the system the CUPS Snap will run in standalone mode, listening not only on
$SNAP_COMMON/run/cups.sockbut also on
/run/cups/cups.sock. This way all applications, both classically installed or snapped, print via the CUPS Snap. Queues have to be created on the snapped CUPS, drivers have to be Printer Applications. Also here the user sees the same print queues for both classic and snapped applications.
- The CUPS daemon of the CUPS Snap does not accept administrative requests through the
cupsinterface (only through the
cups-controlinterface), so our application Snap cannot create or remove queues, change drivers pr permissions, remove anybody else’s jobs, … it can only print, not mess with CUPS. This is implemented in cupsd of upstream CUPS. So in both cases we can safely let developers upload applications which print as long as they only plug
For all this automatically and transparently to work, I am asking for the following permissions:
- Use of the
cups-socket-directoryattribute by the CUPS Snap
- For all Snaps which plug
cupsplug is auto-connected to the
cupsslot of the CUPS Snap. Here it needs to be taken into account that the CUPS Snap will be auto-installed along with the newly installed Snap if it was not installed yet.
Could you add these permissions/auto-connections? Thanks in advance.
Note that not all of the components are released yet, but if we could get the permissions already before, with the release all will work right away.