Request: CUPS Snap auto connection to cups-control interface

store-requests
#1

With this thread I request auto-connection of the host system’s “cups-control” interface by the CUPS Snap (“cups” in Snap Store).

In the CUPS Snap there is one app named “cupsd” to run the CUPS daemon. The CUPS daemon can be run in standalone mode (Snap’s CUPS is the default printing environment), parallel (independent CUPS daemons of Snap and hos system, for development only), and proxy mode (Snap’s CUPS is a proxy for the system’s CUPS, to protect the system’s CUPS against administrative requests from the client).

In the proxy mode the Snap’s CUPS needs a clone of each queue on the system’s CUPS. The cloning is done by the auxiliary daemon cups-proxyd, also running as part of the “cupsd” app, and cups-proxyd knows about changes by DNS-SD notifications from network printers and D-Bus notifications of local (USB, socket, non-IPP) CUPS printers. For cups-proxyd (inside the CUPS Snap) subscribing to the system’s CUPS’ (outside the CUPS Snap) D-Bus notification service it need appropriate access to the system’s CUPS and therefore the “cupsd” needs to plug the system’s “cups-control”.

Therefore I want to request auto-connection to “cups-control”.

See also here.

New interface: "cups" for all Snaps which print
New interface: "cups" for all Snaps which print
#2

Note that the CUPS Snap has also a slot named "cups-server"witbis compatible with “cups-control” defined via

  cups-server:
    interface: cups-control

The “cups-control” plug of the “cupsd” app should not auto-connect to this slot, but it should auto-connect to the host system’s “cups-control” slot.

#3

Note the cups snap already has the following declaration within plugs:

{
  "cups-control": {
    "allow-auto-connection": {
      "slot-snap-id": [
        "m1eQacDdXCthEwWQrESei3Zao3d5gfJF"
      ],
      "slots-per-plug": "*"
    }
  }
}

Which (as far as I understand it) effectively says *allow the cups-control plug of the cups snap to auto-connect to the cups-control slot on the snap with id m1eQacDdXCthEwWQrESei3Zao3d5gfJF and do greedy connection (ie connect to all cups-control slots - but since this has the slot-snap-id then this is limited to just that snap. m1eQacDdXCthEwWQrESei3Zao3d5gfJF is the snap id of the cups snap itself - this was granted previously via Request: CUPS Snap (“cups”) auto connection to of cups:cups-control to cups:admin and also of the network-manager-observe interface

So I assume that what this new request is asking is to remove this slot-snap-id and the "slots-per-plug": "*" part so that this does not auto-connect to the cups snap’s own cups-control slot and then replace it with allow-auto-connection: true. Then we likely would need to add a deny-auto-connection: slot-snap-id: m1eQacDdXCthEwWQrESei3Zao3d5gfJF to stop it auto-connecting to itself.

Or does the cups snap need to connect to both the snapd/system cups-control slot as well as it’s own?

#4

@alexmurray, no, it does not need to connect to itself but it needs to connect to the system’s cups-control to get access to the D-Bus service of the system’s CUPS daemon.

I also have found out already that the CUPS Snap does not actually need to “bite into its own tail” for its command line utilities to work. In the apps: section of snapcraft.yaml I have removed the cups-internal plug from each of the command line utilities recently and they still work correctly. They also do not need to plug cups-control on the CUPS Snap for Snap mediation of CUPS, as longer time after the request you mentioned I have changed CUPS’s Snap mediation to also allow administrative tasks if the client is the CUPS Snap itself.

#5

So you can go ahead and change the auto-connection of cups-control to auto-connect to the host system’s cups-control slot.

#6

@alexmurray any more thoughts on this request?

#7

So looking at this again - I wonder if perhaps a better snap declaration would be simply:

    allow-auto-connection:
        slot-snap-type:
          - core

Rather than adding a deny-auto-connection attribute as I suggested earlier. I’ll give this a try.

#8

Ok so I have updated the snap declaration to the following for the cups-control plug of the cups snap:

{
  "allow-connection": {
    "slot-snap-type": ["core"]
  },
  "allow-auto-connection": {
    "slot-snap-type": ["core"]
  }
}

Which does now result in the cups snap being auto-connected to only the system provided cups-control slot when it is installed for the first time.

However, if the snap is refreshed, then it still remains connected to the cups-control slot provided by the cups snap itself - I had hoped specifying the allow-connection part would avoid that but sadly it does not. @till.kamppeter do you think this is likely to cause any issues? If possible, can you please test that the cups snap works as expected when it is connected to both of these slots? Note due to the new snap declaration having the allow-connection rule as above, snapd will not allow this to be connected manually so it seems to only be able to be created in this configuration due to a refresh.

@pedronis can you advise perhaps on a snap declaration for the cups snap’s cups-control plug which will cause snapd to disconnect the plug from the cups snap’s own cups-control slot when it is refreshed?

#9

@alexmurray thanks, but the CUPS Snap needs definitely NOT connect to its own cups-control. So please change the definition that

  1. A fresh installation auto-connects to cups-control of the host system.
  2. A refresh disconnects a connection to its own cups-control and auto-connects to the system’s cups-control, so it changes its connection to the system’s cups-control.

We need that the CUPS Snap is always reliably connected to the system’s cups-control so that the proxy mode reliably works. There are 2 first (niche) apps in the Snap Store which plug cups, having made the installed base of the CUPS Snap sky-rocket from ~4200 to ~42000, and in the Desktop Team is already worked on switching over Firefox, Chromium, and LibreOffice, which will really exercise the proxy mode of the CUPS Snap.

And, I have tested it, as I told earlier here, The CUPS Snap does not need to bite into its own tail. Its included command line utilities already work without the CUPS Snap plugging its own cups-control slot.

#10

Thanks for the clarification @till.kamppeter - unfortunately as I said above I am not sure how to make sure the existing connection to itself gets dropped on refresh - I need @pedronis to help advise on this.

Are you able to test/confirm though that if the cups snap is connected to both the system cups-control slot and it’s own slot, then it fails to work as expected?

#11

@alexmurray I could test that. I did not know that it can connect to both slots.

#12

@alexmurray I have tried it now and I can actually plug to the two slots simultaneously and the proxy mode actually works under these conditions. cups-proxyd can subscribe to the D-Bus notifications of the system’s cupsd and correctly updates the cloned queues triggered by the D-Bus notifications. So all OK here.

#13

@alexmurray do you still need more info from my side? If so, please tell what is missing.

#14

@till.kamppeter no I don’t think so - as far as I know this should be done - since you said it should work fine with both slots connected then I don’t think there is anything else we need to do. BUT perhaps I am wrong and if things aren’t working correctly, please let me know. Cheers.

#15

You are NOT wrong, it is all OK, please go ahead.

#16

Ok thanks, we will remove this request from our internal list. Cheers.

#17

Auto-connection of CUPS Snap to system’d cups-control on fresh installation of CUPS Snap (also as dependency of another Snap) is taking place now. Thank you very much.

#18

I asked @nteodosio (who discovered the problem initially) for testing and now all works perfectly for him. So the problem seems to be solved (thanks @nteodosio).