The cups interface

The cups interface allows access to the CUPS socket for printing via the cups snap.

This interface is intended to be used by snap developers who wish to add safe printing functionality to their snapped applications without requiring their users to make make a manual interface connection. This is possible because the cups interface does not permit administration or configuration of printers via the CUPS socket, only the submission of print jobs and auxiliary tasks, such as listing available printers.

Formerly, to print from a snapped application, the cups control interface was required. This needs either a manual connection or Snap Store permissions to auto-connect. Alongside printer access, the cups control interface also allows any user to create and modify queues, and their permissions, and to read and delete anyone’s print jobs. This isn’t ideal in a multi-user environment.

The cups-control interface will continue to be available to allow printer setup tools (and general system admin tools, like this one) to be snapped.

Available since snapd 2.55.3.

On systems with a classically installed CUPS
(via a deb, RPM, or from source, for example)

The CUPS snap will run in proxy mode, working as a proxy or firewall between the application snaps and the system’s CUPS. The CUPS snap will replicate the system print queues and pass jobs through to the system’s CUPS. The user will be able to access the same queues and printer drivers when printing from classically installed applications and application snaps.

On systems with no CUPS installed (or using the CUPS snap)

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.

Interface documentation: See Interface management and Supported interfaces for further details on how interfaces are used.


Developer details

Auto-connect: not applicable

  • If you are snapping a new application that has print functionality, add the cups interface.
  • If you are maintaining an application snap currently using cups-control for printing, switch to the cups interfacea.
  • If you are creating or maintaining a snap of a printer setup tool, you have to plug cups-control interface and ask your users to manually connect the interface, or request an auto-connection from the Snap Store team.

The slot side of the interface is intended to be provided by a reference snap, such as the cups snap. The reference snap will permit any connecting snap to connect automatically, which snaps with the cups plug can auto-connect to the reference snap’s cups slot, and print, without any further action from the user.

On systems where this slot is provided by a snap application, the cups interface is the companion interface to the cups control interface.

However, the cups interface and the cups-control interface should not be used as plugs in the same snap.

The design of both of these interfaces is based on the idea that the slot implementation (eg. cupsd) is expected to query snapd to determine if the cups-control interface is connected or not for the peer-client process. The print service will then mediate admin functionality (ie, the rules in these interfaces allow connecting to the print service, but do not implement enforcement rules; it is up to the print service to provide enforcement).

Current requirements

As the CUPS interface is new, we currently recommend the following additions be made to the top level of your snapcraft.yaml.

  1. Adding assumes will ensure snapd is updated to a CUPS interface compatible version:

    # snapd 2.55 or later is needed for cups interface support
    assumes: [snapd2.55]
    
  2. The following will trigger the automatic installation of the cups snap:

    plugs:
      foo-install-cups:
        interface: content
        content: foo
        default-provider: cups
        target: $SNAP_DATA/foo
    

The above additions should only be temporary and can be removed after the CUPS interface becomes better established.

For background information and design discussions about this interface, see About the cups interface.

Code examples

See the test CUPS consumer snap:

The source code for the interface is in the snapd repository: https://github.com/snapcore/snapd/blob/master/interfaces/builtin/cups.go

1 Like

Some points to be corrected:

The cups interface is intended as the general interface for printing out of Snaps, not necessarily to print via the CUPS Snap. The CUPS Snap is made use of for Snap mediation.

So please replace

This interface is intended to be used by snap developers who wish their snap to print via the cups snap. Consequently, this interface does not permit administration or configuration of printers via the CUPS socket itself, only the submission of print jobs.

by something like

This interface is intended to be used by snap developers who wish their Snap to print in a safe way, so that they can easily upload the Snap into the Snap Store and the user can just print without any manual interface connection. This is made possible by the interface not permitting administration or configuration of printers via the CUPS socket, only the submission of print jobs and auxiliary tasks like listing available printers are allowed.

Also the cups interface is not successor of cups-control, the former does not replace the latter. cups is intended for Snaps of user applications with print functionality whereas cups-control is intended for snapping admin utilities.

So replace

The cups interface is the successor to the cups-control interface which required either manual intervention or Snap Store permissions to auto-connect. Alongside printer access, it also allowed any user to create and modify queues and their permissions, read and delete anyone’s print jobs, which isn’t ideal in a multi-user environment.

by something like

Formerly, to be able to print out of a Snap one had to use the cups-control interface which required either manual intervention or Snap Store permissions to auto-connect. Alongside printer access, it also allowed any user to create and modify queues and their permissions, read and delete anyone’s print jobs, which isn’t ideal in a multi-user environment.

The cups-control interface will continue to be available to allow printer setup tools (and general system admin tools, like this one) to be snapped.

Also replace

On systems with no CUPS installed

by

On systems with no CUPS installed or using the CUPS Snap

as there can be systems which are already using the CUPS Snap as their standard printing environment.

Under the “Code examples” the Ghostscript Printer Application is wrong. The cups interface is on the application end of the printing system, where the Printer Applications are on the printer end of the printing system. On the printer end there is no dedicated snapd interface. The communication is a simple IP communication covered by the network and network-bind interfaces used by the CUPS Snap and also by the Printer Application Snaps.

So the only valid example currently is the test-snapd-cups-consumer Snap which you already mention. I am eagerly waiting for first production applications adopting the new interface.

Thank you so much for taking the trouble to read through this document, especially after your own post covered many of the same points you’ve corrected here.

I’ve now been through and updated this page accordingly - thanks again.

Thanks for doing the corrections.

All is correct now, only these lines are duplicate, please remove:

Make sure to not remove the

1 Like