Urgent solutions for inter-snap communication

We are building a gadget snap and custom image for a PoC and we need one of our snaps (snap A) to, when appropriate, automatically configure a third-party snap (snap B) via B’s configure hook.
This simple task is becoming a challenge per itself in Ubuntu Core. :disappointed_relieved:

Initially we tried our snap A to invoke snap set <snap-b> conf=..., as provided by snap B. It turns out Snap A has no permission to run snap set against another snap.

In another attempt, we tried to use snapd REST API /run/snapd.socket. This also turned out as a frustration, as we need to use the interface snapd-control, which is apparently only available if we use brand-store.

So what is the solution proposed to this? (Sorry, but for a PoC project getting a $16,000 brand store is a joke and not a solution).

Is this apparent simple scenario not possible in Ubuntu Core?

why does it need to be the snap hook ? there are many non-snap ways of inter-process communication that work even in snaps :wink:

  • change your third-party snap to provide its own socket via a content interface
  • use dbus
  • use a localhost network socket between the snaps

How am I supposed to change a third-party snap from the store? :thinking:
This third-party snap is on the store (aws-iot-greengrass). It offers its own configuration option (call snap set ...).
What we want is for our configuration gadget snap to prepare it and then configure aws-iot-greengrass automatically.
IMHO this should be a simple setup, which does not seem easily supported.

I know we can use defaults in gadget snap. However the configuration process is not immediate, requires hitting servers etc., only when ready we should configure the Greengrass snap.

Yeah, in that case snapd-control would be your only option (you could indeed try to re-pack the greengrass snap, its just a downloadable squashfs file that you can re-assemble with snap pack and add via the --snap option to ubuntu-image , but i doubt any of the interface auto-connections it uses would work then)…

Not that it helps but there was a less strict variant of snapd-control in discussion in the past that i.e. could allow access to config options (but not to start/stop/add/remove snaps), not sure what happened to it though…

1 Like

IMHO this is an omission from the aws-iot-greengrass snap in that it doesn’t offer any kind of local API or anything to configure it. As I’ve seen it used, that snap doesn’t usually need reconfiguration, it’s more of a set up config so the snap can talk to the cloud once on the device and then do everything else from the cloud. If you need to configure other things then it sounds like the aws-iot-greengrass snap should be improved to support this use case, perhaps you can reach out to AWS about your use-case and they can expose something else for your snap A to use to configure it repeatedly.

1 Like

If you just need static configuration of the other snap, then you should be able to do that from your gadget snap with no special interfaces, you could do that via the gadget.yaml file in your gadget snap. There is also a prepare-device-hook that you could use to copy some configuration to a location the other snap can read.

That doesn’t handle the case of dynamically reconfiguring the system, but would let you flash an image to a device and have it boot up in a configured state.

Sure, that works. Snap A uses install hook just fine too.
However there is a dynamic step and Snap A needs to communicate with a third party Snap B when an event occurs.
This interaction between independent snaps needs to be better thought out and not require a brand store, specially when it is a very expensive one.

For instance, our snaps are all private. Why cannot private snaps use snap-control interface? I understand the legitimate importance of security but it seems there is some room to allow more permissions to snaps, which are not public, and without the need for super expensive brand store.

that would require some additional intelligence on the store side i believe (not being a store person though)…

in todays setup under such a policy you could upload a private snap with snap-control … and then it is just one click to make it public …

the checks are performed at upload time, there are no checks if you do something evil when changing the snap from private to public, so that would be a security hole … i also dont think private snaps have ever been considered as something that can be use in products, they have been designed for non-public group collaboration during development …

1 Like