Request: CUPS Snap to use the `cups-socket-directory` attribute and auto-connection of any Snap's "cups" plug to the "cups" slot of the CUPS Snap

store-requests
1

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/run directory gets mounted to /var/cups, this way the application Snap has access to the CUPS Snap’s cups.sock.
  • The application Snap’s cups plug gets auto-connected to the CUPS Snap’s cups slot.
  • In the application Snap the environment variable CUPS_SERVER=/var/cups/cups.sock gets 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.sock but 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 cups interface (only through the cups-control interface), 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 cups AND NOT cups-control.

For all this automatically and transparently to work, I am asking for the following permissions:

  1. Use of the cups-socket-directory attribute by the CUPS Snap
  2. For all Snaps which plug cups that the cups plug is auto-connected to the cups slot 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.

2

@ijohnson, did I describe everything correctly and did I make the correct requests? If not, please correct. Thanks.

3

Unfortunately the store cannot make this happen, we have to either manually enable this using a transitional placeholder content interface or adapt the default-provider setting to also work for the cups interface. I plan on doing the latter at some point soon so I don’t think that the former needs to be implemented, but in any case the store does not need to do anything for either of these options.

To be clear, snaps can still declare the cups-control interface, it just won’t be auto-connected and thus the snaps can’t do administrative changes. A user could manually decide they want to have their snap do admin stuff and connect cups-control if they so chose, but this would not be automatic.

Otherwise everything else looks good to me, thanks for summarizing it here. To be clear, I’m not a reviewer, but this matches our intended plan for cups from the snapd side so +1 from me.

4

@ijohnson Thanks for checking through my post. The items you are refering to are only part of the introduction to explain the Store team what I need, the actual requests are the “1. … 2. …” at the bottom.

5

Yes I was just clarifying, the requests in 1 and 2 look correct to me

6

+1 from me for granting the use of cups-socket-directory as a store override. +1 for global auto-connect of the cups slot as well from the cups snap.

1 Like
7

It is my understanding that we do not require any special declaration to use the cups-socket-directory attribute so this should work as soon as it is added. @till.kamppeter could you please check and let us know if you experience any issue?

I am +1 as well for for auto-connect the cups slot. +2 votes for, 0 votes against. Granting auto-connect of the cups slot to the cups snap. This is now live.

1 Like
8

Thank you very much.

9

@ijohnson has tested the auto-connection with a small test Snap and it is working as expected. Thanks again, @alexmurray and @emitorino!

1 Like