I’m running an own image + gadget snap, which is based on stock pi3-gadget with very minor modifications. On it, snap changes shows me a long list of errored out attempts to “Initialize device”. The detail of each is along the lines of
error: cannot perform the following tasks:
- Request device serial (cannot deliver device serial request: Cannot process serial request for device with brand "<brand-id>" and model "<model>")
Is there a straightforward way to take care of these?
I read a few seemingly related threads (Gadget snaps, Not able to use serial-port interfaces, Getting a product serial number in prepare-device for amd64 classic) but am none the wiser as to how to deal with assignment of device serials, or indeed what their significance is in the grand scheme of things. What would be the potential benefit of setting up a “device service” and a serial vault? Are these things I would set up myself (i.e. my own API service for device registration), or are they available as part of the snap store/snapcraft infrastructure?
FYI, we do generate and use unique device identifiers in the software we’re running on these devices, but those are generated and managed within that software - which then talks to our API. If there’s meaningful benefit, I’d be open to switching to something that’s managed by the snap system.
Finally, I suppose on the RPi the serial from cat /proc/cpuinfo | grep Serial can be used as the device serial - but that currently seems like only a small piece of the overall puzzle.
Thanks! Helps indeed. My take-away is that if I want to use this I should set up my own Serial Vault (using source at http://github.com/ubuntu-core/identity-vault), and set up my devices to use this for registration (via snapctl set device-service.url="https://device-service" in the prepare-device hook on the gadget).
Is that more or less the story? The linked page does seem to put some emphasis on “contact your Canonical representative to have a Brand Store created for you”, but it’s not clear what the benefits of that would be, provided that I’m ok to play by the rules of the main store and don’t need customizations.
The benefits of the Brand Store are that it is invisible for devices using a global Ubuntu store giving the ability to provide a customized experience if that is desired by the business. An example of that coube be: a company X might want a Brand Store to offer snap(s) targeted only for their devices which are limited for those who purchased it.
The role of the Serial Vault in this picture is to provide a signed assertions required for setups with a secure Brand Store set up. In this context configuring the device service is to obtain the signed serial assertion during the “Initialize Device” phase.
Running a Serial Vault instance and using the Ubuntu global snap store does not quite match therefore could you elaborate a little bit more on what actually would you like to achieve. That would make it easier to give you a complete answer.
Hi @koza thanks for the prompt response. Let me try and give you a better idea of the situation.
Overall setup:
We’re building our own open-source software into snaps, and releasing that to the global store
We also create and deploy devices with the snaps pre-installed. The hardware consists of a Raspberry Pi + a cape, so we have a custom gadget for those, and some other configuration options set in the image.
There are also cases where we want to share these custom devices images, and allow others to run them themselves. So we don’t physically produce all of the devices running these images.
Why I was interested in the Serial Vault:
I wanted to understand why I was getting a string of errors relating to serial requests, and what I could do about it
I wanted to consider what sorts of device provisioning and (configuration) management functionality is available through the device service.
Regarding point (2), I thought that it may be similar to what AWS and Azure provide with their IoT hubs (which could be useful for us). But my current understanding is that it’s more geared to device initialization, and the deployment of Brand Store assertions - rather than any sort of ongoing device management.
well, in fact the brand store is typically the source for ongoing device management (gadget or custom kernel upgrades, more freedom and control regarding interfaces and command aliases of your snaps, etc …)
a full serial vault is needed to access a brand stores as others have said, also over time other features might also rely on device identity (for example some variations of optional snap features, where the store keeps tab of what is enabled (think IAPs)).
So far for operating just with the default store the error in the log is harmless (but will appear a few times per device per reboot and at least once a day).
We have plans (mostly related to development) to make it easier to get “weak” device identities, is just taking a while wrt other priorities: Opt-in accepting/distribution of 'generic'-signed serials Those kind of identities will stop the errors, will probably not be usable usually with brand stores.
Your impression is correct, the Serial Vault is not for ongoing device management. Instead please look at snapd API https://github.com/snapcore/snapd/wiki/REST-API and see if it provides what you would like to achieve.
Thanks all for the input - the purposes of and interplay between the different services/concepts makes sense now.
@koza thanks for the link to the snapd API - I hadn’t actually seen that, but it’s interesting to see the direction it’s going in - and indeed may be relevant.
In general, what I’m on the look-out for is a service that lets us provision new devices that are installed out in the field, and allows us to remotely deploy per-device configurations (JSON payload) on an ongoing basis. Having snap functionality gets us part of the way there - in that we can keep device software up-to-date across the fleet - but I’m yet to find a great solution for device configuration management; so for the moment we’re rolling with our own.
