Request: CUPS Snap (“cups”) auto connection to of cups:cups-control to cups:admin and also of the network-manager-observe interface

@igor, sorry, I started the thread for asking for interface auto-connections and my requested auto-connections got voted on and approved, but ptobably not applied, as the third and last voter, @popey, did not tell that he has applied the changes, perhaps he has only voting but not admin rights. Then @diddledani came up with a question, me and @jamesh answered and then @jamesh gave me some hints for improvement and we started a discussion, working out the correct solution for the CUPS interfaces, covering both situations of the system’s CUPS being the CUPS Snap or classically (DEB) installed.

Up to now we concluded that the CUPS Snap needs the following auto-connections:

sudo snap connect cups:cups-internal cups:cups-control
sudo snap connect cups:network-manager-observe

and application of slots-per-plug: * so that cups and cups-control plugs of user application Snaps can connect and auto-connect to both the CUPS Snap’s and the system’s slots.

@till.kamppeter I haven’t voted because I was waiting for this (now 43 post) thread to calm down. I’m not an admin, I’m a reviewer like others. I just didn’t want to wade into an already lengthy and confusing thread.

1 Like

@jamesh, now I have copied my last CUPS Snap over to a more “neutral” machine, and here the cups.lpinfo -v gets always Forbidden due to the fact that it does not plug cups-control. For these tools to work with the cupsd in the CUPS Snap I need to change the check in CUPS or put back in the cups-internal. Only if the classic CUPS (with Snap admin check) is used I MUST put back in the cups-internal as a classic CUPS is never “in the same Snap” as a tool from the CUPS Snap.

I agree with @popey that this thread is becoming lengthy (although the discussion is very useful to move forward with the review process).

@till.kamppeter: I can help with the auto-connection grants but based on the last comment it seems you are still working on making the last suggestions work. Whenever you are satisfied please ping me and I will be happy to grant the auto-connections provided the votes still apply.

Thanks!

1 Like

@emitorino, thank you very much, the auto-connections which I need for the CUPS Snap are:

sudo snap connect cups:cups-internal cups:cups-control
sudo snap connect cups:network-manager-observe

They are already approved by three positive votes near the beginning of the thread, so they can be put life (note that the first one looks different as the plugs and slots got renamed, but it is functionally equivalent to the original one for the CUPS Snap’s internal cups-control connection).

1 Like

@emitorino, we also concluded that cups and cups-control plugs of user applications need to auto-connect to BOTH the slots of the CUPS Snap (cups:...) and of the system (:...), using slots-per-plug: * to generally work independent whether on the user’s system the CUPS Snap is installed or the classic CUPS (for example from DEB packages) is used. Can this be set up, too?

@jamesh, I have removed only the slots: [cups-control, cups] but kept cups-internal in for now, as the latter is needed for the utilities being able to access external CUPS daemons (with admin-from-Snap check).

Thanks @till.kamppeter.

The only one I was able to grant was network-manager observe, so:
+3 votes for, 0 votes against, granting auto-connect of network-manager-observe to cups. This is now live.

I will come back as soon as I have further info about the remaining requests.

@emitorino thank you very much.

1 Like

@jamesh, interesting, for the utilities which come with the CUPS Snap no connection of the cups-internal plug is needed in order to access and also manage the Snap’s own CUPS. For the tools to manage a remote (unsnapped) cupsd (with admin-from-Snap checking) they need to plug cups-internal to any cups-control slot, either the one of the CUPS Snap or the one of the system, it does not matter which one. For non-admin tasks on the external cupsd also no plugging is needed.

@jamesh now when the client is from the same Snap as my cupsd I directly grant access without calling snapctl, simply via the AppArmor label (commit in CUPS).

@till.kamppeter I have just adjusted the cups snap declaration to allow connecting to itself via the cups-control slot and made both cups and cups-control slots slots-per-plug: * so apps will be able to connect to both slots simultaneously.

Could you please confirm this is all working as expected?

Thanks!

@emitorino, thanks for your updates on the auto-connections.

I did the following tests and they look correct for me:

$ sudo snap install --edge cups
$ sudo snap connections | grep cups:
avahi-control                         cups:avahi-control                        :avahi-control                                        -
cups-control                          cups:cups-internal                        cups:cups-control                                     -
home                                  cups:home                                 :home                                                 -
network                               cups:network                              :network                                              -
network-bind                          cups:network-bind                         :network-bind                                         -
network-manager-observe               cups:network-manager-observe              :network-manager-observe                              -
raw-usb                               cups:raw-usb                              :raw-usb                                              -
system-files                          cups:etc-cups                             :system-files                                         -
$ cups.cupsctl
_debug_logging=1
_remote_admin=0
_remote_any=0
_share_printers=1
_user_cancel_any=0
[...]
$ sudo snap install --dangerous cups-admin-test_0.1.0_amd64.snap
$ sudo snap connect cups-admin-test:avahi-observe
$ sudo snap connect cups-admin-test:cups-control
$ sudo snap connect cups-admin-test:cups-control cups:cups-control
$ sudo snap connect cups-admin-test:cups
error: snap "snapd" has no "cups" interface slots
$ sudo snap connect cups-admin-test:cups cups:cups
$ snap connections | grep cups-admin-test:
avahi-observe                         cups-admin-test:avahi-observe             :avahi-observe                                        manual
cups                                  cups-admin-test:cups                      cups:cups                                             manual
cups-control                          cups-admin-test:cups-control              :cups-control                                         manual
cups-control                          cups-admin-test:cups-control              cups:cups-control                                     manual
home                                  cups-admin-test:home                      :home                                                 -
network                               cups-admin-test:network                   :network                                              -
$

The cups-admin-test Snap is from this example thread.

I hope that this is all correct behavior.

Strange is now that the utilities of cups-admin-test are only able to access the system’s CUPS, not the Snap’s one whereas the utilities of the CUPS Snap can access both, the one of the Snap by default and the one of the system when using the CUPS_SERVER environment variable:

$ cups-admin-test.lpstat -v
[Works: Queue list of system's CUPS]
$ CUPS_SERVER=/var/snap/cups/common/run/cups.sock cups-admin-test.lpstat -v
lpstat: Bad file descriptor
$ cups.lpstat -v
[Works: Queue list of CUPS Snap]
$ CUPS_SERVER=/run/cups/cups.sock cups.lpstat -v
[Works: Queue list of system's CUPS]
$ lpstat -v
[Works: Queue list of system's CUPS]
$ CUPS_SERVER=/var/snap/cups/common/run/cups.sock lpstat -v
[Works: Queue list of CUPS Snap]
$

For me it is strange that the lpstat of cups-admion-test cannnot access the CUPS Snap though both its plugs are connected to the CUPS Snap.

@emitorino I got 4 upload rejection messages from the Snap Store only today (Saturday), due to the “slots-per-plug”, on the architectures armhf, arm64, ppc64el, and s390x (builds finished 2 hours ago) and the remaining architectures (i386, amd64) did not even start to build.

On the pages like (for revisions 254, 255, 256, and 257

https://dashboard.snapcraft.io/snaps/cups/revisions/255/review/

I get two rejects with following messages:

declaration malformed (unknown constraint ‘slots-per-plug’) declaration-snap-v2_valid_slots (cups-control, slots-per-plug)
declaration malformed (unknown constraint ‘slots-per-plug’) declaration-snap-v2_valid_slots (cups, slots-per-plug)

I have found out that my tests from the post above are of revision 252 (my system is amd64). So are they without your changes?

Could you check and fix this? Thanks.

@emitorino, now the build of the two remaining architectures (i386, amd64, revisions 258 and 259) completed and got also rejected with the same “slots-per-plug” problem.

This was failing review since the snap declaration specified the slots-per-plug attribute for the slots - however, this is only valid when specified against a plug for a given snap, so I have reworked the declaration to instead specify this attribute against the appropriate plugs (cups and cups-control) instead.

These subsequent revisions now pass automated review - @till.kamppeter could you please re-test and confirm the cups snap is working as expected?

@alexmurray Thank you very much. I have done the tests of my posting above again (after sudo snap remove --purge cups), the auto-connections work, most test commands, too, except these ones:

$ CUPS_SERVER=/var/snap/cups/common/run/cups.sock cups-admin-test.cupsctl
cupsctl: Unable to connect to server: Bad file descriptor
$ CUPS_SERVER=/var/snap/cups/common/run/cups.sock cups-admin-test.lpstat -v
lpstat: Bad file descriptor
$

Seems that the interfaces cups and cups-control do not cover /var/snap/cups/common/run/cups.sock which they should do, especially as we will need the CUPS Snap running in parallel to a system’s CUPS in production, see here.

I tried to replicate this by installing the cups snap as per Call for testing: OpenPrinting's CUPS Snap but there doesn’t seem to be a /var/snap/cups/common/run/cups.sock:

amurray@sec-hirsute-amd64:~$ sudo systemctl stop cups-browsed
amurray@sec-hirsute-amd64:~$ sudo systemctl disable cups-browsed
amurray@sec-hirsute-amd64:~$ sudo systemctl stop cups
amurray@sec-hirsute-amd64:~$ sudo systemctl disable cups
amurray@sec-hirsute-amd64:~$ sudo snap install --edge cups
amurray@sec-hirsute-amd64:~$ snap info cups
name:      cups
summary:   The CUPS Snap - The Printing Stack for Linux
publisher: OpenPrinting✓
store-url: https://snapcraft.io/cups
contact:   webmaster@openprinting.org
license:   unset
description: |
  The official Snap of CUPS, the standard printing environment for Linux
  operating systems
commands:
  - cups.accept
  - cups.cancel
  - cups.cupsaccept
  - cups.cupsctl
  - cups.cupsdisable
  - cups.cupsenable
  - cups.cupsfilter
  - cups.cupsreject
  - cups.cupstestppd
  - cups.driverless
  - cups.gs
  - cups.ippeveprinter
  - cups.ippfind
  - cups.ipptool
  - cups.lp
  - cups.lpadmin
  - cups.lpc
  - cups.lpinfo
  - cups.lpoptions
  - cups.lpq
  - cups.lpr
  - cups.lprm
  - cups.lpstat
  - cups.reject
services:
  cups.cups-browsed: simple, enabled, active
  cups.cupsd:        simple, enabled, active
snap-id:      m1eQacDdXCthEwWQrESei3Zao3d5gfJF
tracking:     latest/edge
refresh-date: today at 10:20 ACDT
channels:
  latest/stable:    –                           
  latest/candidate: –                           
  latest/beta:      –                           
  latest/edge:      0.1.0 2021-03-22 (258) 60MB -
installed:          0.1.0            (258) 60MB -
amurray@sec-hirsute-amd64:~$ snap connections cups
Interface                Plug                          Slot                      Notes
avahi-control            cups:avahi-control            :avahi-control            -
cups                     cups-admin-test:cups          cups:cups                 manual
cups-control             cups-admin-test:cups-control  cups:cups-control         manual
cups-control             cups:cups-internal            cups:cups-control         -
home                     cups:home                     :home                     -
network                  cups:network                  :network                  -
network-bind             cups:network-bind             :network-bind             -
network-manager-observe  cups:network-manager-observe  :network-manager-observe  -
raw-usb                  cups:raw-usb                  :raw-usb                  -
system-files             cups:etc-cups                 :system-files             -

amurray@sec-hirsute-amd64:~$ ls /var/snap/cups/common/run/cups.sock
ls: cannot access '/var/snap/cups/common/run/cups.sock': No such file or directory

So then it is not surprising that the cups-admin-test snap cannot access it :slight_smile: - is there something else I need to do for the cups snap to create this socket?

@alexmurray, sorry, I did not tell you that I investigated the mode where the CUPS Snap and the system’s CUPS run in parallel, in preparation to implement the plans described here.

If you have no classic CUPS running and install the CUPS Snap, it creates the socket at the standard position, /run/cups/cups.sock, only if there is a classic CUPS running, the socket is created at /var/snap/cups/common/run/cups.sock.

To determine which socket the CUPS Snap is currently using, run

cups.lpstat -H
1 Like

@till.kamppeter so it sounds like the cups-control and the cups interfaces in snapd need updating then to include this new path. Given this use-case of running both the classic distro installed cups and the cups snap is less likely to be used in practice, this sounds like it can be followed up via a PR to snapd rather than anything else here on the forum, so unless there is anything else, I think this request is complete from what I can see.