Request: CUPS Snap ("cups") auto connection to avahi-control, raw-usb, cups-control, and system-files interfaces

I am maintaining the CUPS Snap. Formerly it had the name “printing-stack-snap” but now I have renamed it to “cups” after agreement on the OpenPrinting phone meeting and with Michael Sweet.
The former “printing-stack-snap” GitHub repository at OpenPrinting I have renamed to “cups-snap” (not to “cups” so that no one thinks I have a fork of CUPS in that repo):

I have also reserved the name “cups” in the Snap Store and activated the build service so that the Snap gets automatically built for several architectures whenever something gets committed.

As a next step I need some interfaces to get connected automatically.

First, there are the interfaces which are set to auto-connection in the former “printing-stack-snap”: avahi-control and raw-usb. As “cups” is simply a renamed “printing-stack-snap” they probably will not need a formal vote. The original voting for them happened in this thread.

With the further development of the CUPS Snap additional interfaces will be needed to get auto-connected:

"cups-control"

This interface is to allow the command line utilities (lpadmin, cupsenable, cancel, …) included in the CUPS Snap to do administrative operations (creating print queues, canceling other user’s jobs, …) on the CUPS daemon. See the thread where we have designed this interface.

"system-files"

CUPS needs to access some files in the host system to get full functionality. For this the snapcraft.yaml defines two interfaces based on the “system-files” interfaces:

plugs:
  system-config:
    interface: system-files
    read:
        - /etc/passwd
        - /etc/group
        - /etc/shadow
        - /etc/shadow-
        - /var/lib/extrausers/passwd
        - /var/lib/extrausers/group
        - /var/lib/extrausers/shadow
  cups-domain-socket:
    interface: system-files
    write:
        - /run/cups
        - /var/run/cups

The “cups-domain-socket” plug allows the snapped CUPS daemon to use the standard CUPS domain socket /run/cups/cups.sock or /var/run/cups/cups.sock. So clients, independent of classically installed or snapped can print via the standard domain socket. In Ubuntu the two versions are linked together (/var/run is symlink to /run), so either works, but I allow both to get universal compatibility with all distributions.

The “system-config” plug gives read-only access to user/group/password database files to authenticate users, especially to determine whether they are in an administrator group (“lpadmin” or “adm”) and therefore are allowed to do administrative tasks, via the command line utilities or the CUPS web interface (http://localhost:631/).

So all in all, I need for the CUPS Snap “cups” the “avahi-control” and “usb-raw” interfaces which “printing-stack-snap” already automatically connects and in addition “cups-control” and the two plugs to “system-files” automatically connecting.

One additional question: If I want to add a migration script to migrate from classically installed CUPS to snapped CUPS, I need to access /etc/cups. Which part(s) of my CUPS Snap actually have to access? Should I simply add read access to /etc/cups to the “system-config” plug or do I need to create an additional plug based on “system-files”? This plug also needs automatically connected, so that migration goes smoothly when the distro update installed the CUPS Snap as replacement of the classically installed CUPS.

My suggestion would be to add the following third plug based on “system-files”:

plugs:
  cups-migration:
    interface: system-files
    read:
        - /etc/cups

and then let only the “cupsd” app in the “apps:” list plug this. The scripts/run-cupsd script would then perform the migration, which would require that this plug gets automatically connected when installing the CUPS Snap.

WDYT?

+1 from me for cups snap to auto-connect avahi-control, raw-usb, cups-control and system-files for both cups-domain-socket and cups-migration variants. However I wonder if these should be named to more accurately reflect what they provide access to - ie. perhaps cups-migration should be called cups-config?

@alexmurray, thnaks for your answer.
@alexmurray, there are 3 system-files plugs. You overlooked system-config. This also needs to get auto-connected for authentication of administrative tasks (or print queues which are only allowed for selected users).
The cups-migration name is not hammered in stone yet, it was simply a quick write-up of what is needed. No problem for me to use cups-config instead. So I will add:

plugs:
  cups-config:
    interface: system-files
    read:
        - /etc/cups

to snapcraft.yaml and let the cupsd app plug this interface.

All in all, following 6 interfaces need to get auto-connected by the “cups” Snap:

  • avahi-control
  • raw-usb
  • cups-control
  • system-config
  • cups-domain-socket
  • cups-config

The first two are already automatically connecting in printing-stack-snap, the third is designed here, and the last three are all based on system-files and defined in snapcraft.yaml.

@alexmurray - I’ll take a look at this since I’m making updates to the cups-control interface. We may be able to drop some of the system-files usage.

I’ve been working on changes to the cups-control interface so that the cups snap can slots cups-control and we should be able to remove the need for system-files for system-config and cups-domain-socket.

Use of and auto-connection for system-files for read-only access to /etc/cups is natural for this snap, though please adjust the snap to use (which follows established interface reference patterns):

plugs:
  etc-cups:
    interface: system-files
    read:
    - /etc/cups

+1 for ‘cups-control’ for both slots and plugs, but we should hold off on granting it until I submit a PR to snapd.

+1 for auto-connecting avahi-control.

@reviewers - can others please vote on what I voted on?

@till.kamppeter - I will provide you with recommended changes to your snap, a patched snapd deb and submit a PR in the coming days. There is a wrinkle that we didn’t consider in your snap-mediation patches (we need to mediate ‘interface query’ permissions on the snapd.socket so we don’t have to grant ‘snapd-control’ to your snap. Don’t worry about it just yet though; just have cupsd plugs snapd-control for now. We won’t grant cups a snap declaration for that, but you can at least test it locally).

Thanks for the update. I have done some changes according to your suggestions now:

Note, adding ‘snapd-control’ will cause your snap to fail automated review also (but it already is for its use of system-files, so not a big deal atm). We’ll sort this all out soon once the PR is up.

@reviewers - can other please vote on what I voted on (skip snapd-control; a new interface will be introduced for this).

+1 from me @jdstrand - makes sense for a functional cups snap to have those interfaces connected.