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.
Note that the CUPS Snap has also a slot named "cups-server"witbis compatible with “cups-control” defined via
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.
cups snap already has the following declaration within
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?
@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.
So you can go ahead and change the auto-connection of
cups-control to auto-connect to the host system’s
@alexmurray any more thoughts on this request?
So looking at this again - I wonder if perhaps a better snap declaration would be simply:
Rather than adding a
deny-auto-connection attribute as I suggested earlier. I’ll give this a try.
Ok so I have updated the snap declaration to the following for the
cups-control plug of the
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-control plug which will cause
snapd to disconnect the plug from the
cups snap’s own
cups-control slot when it is refreshed?
@alexmurray thanks, but the CUPS Snap needs definitely NOT connect to its own
cups-control. So please change the definition that
- A fresh installation auto-connects to
cups-control of the host system.
- 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
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
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?
@alexmurray I could test that. I did not know that it can connect to both slots.
@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.
@alexmurray do you still need more info from my side? If so, please tell what is missing.
@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.
You are NOT wrong, it is all OK, please go ahead.
Ok thanks, we will remove this request from our internal list. Cheers.
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.
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).