Download link for ResinOS after creating a device through the SDK

Product support
1

Hi, we have been trying to use the NodeJS SDK to create devices for our application.

We manage to create devices successfully - however

  1. is there a way to programatically return the download link for ResinOS so that our app can access it directly?
  2. given 1), can we also input the WiFi credentials programmatically through the SDK/ API etc. without having to go through the Resin console.

Thanks and appreciate any advice.

3

Hi @ycy88 – You’d be able to automate that using the resin cli.

https://docs.resin.io/reference/cli/#os-download-type- would enable you to download the image for the device type – Note: If you make a local copy of the file to do the rest of the modifications on, you wouldn’t have to re-download this every time

With https://docs.resin.io/reference/cli/#os-configure-image-uuid-deviceapikey- you can configure that image for the newly created device uuid

And with https://docs.resin.io/reference/cli/#config-generate and https://docs.resin.io/reference/cli/#config-inject-file- you are able to create a new configuration file for the device, and inject it into the image

Once that’s done you can write the resulting image file to the SD card / media you’re using, and boot the device from it

1 Like
4

Thanks @chrischabot for your help.

To further elaborate, we wanted to do it as a backend service, so that our non-technical folk can configure devices without installing the CLI, would there be a direct API that we can use?

Also, we are trying to run the operation as a NodeJS microservice on AWS Lambda, and it’s not quite feasible to invoke the CLI from there.

Have tried looking resin-device-init package (https://github.com/resin-io-modules/resin-device-init) which seems to allow us to do this. However, it runs post install scripts using Python to further configure, which will be tricky to run from a NodeJS microservice as well.

Would you have further suggestions on how we might do this?

Thanks again for your help!

7

@ycy88 We don’t currently have an API for pre-configuring images and make them available for download on our end. Also while using resin-device-init is certainly possible, we don’t really maintain that to be used as a public library, so there might be breaking changes somewhere along the line, making the CLI a far more dependable choice.

The good news is that Lambda does actually allow you to do, well, almost anything – It just doesn’t make it as visible for ease of use – however in the end it’s just a linux docker container that you can do anything with, as long as you keep in mind they’ll be spun up and destroyed as demand requires, so you can’t store state on them.

The way you’d go about implementing something like this would be to install the resin-sdk and all it’s dependencies in your project directory, and include them in the zip file you upload to Lambda – because all the dependencies are already there, you can just execute the CLI from NodeJS as a child process (https://nodejs.org/api/child_process.html#child_process_child_process).

You could either include the image you want to configure in the zip file you upload to Lambda, or store it in AWS S3 and download it from there every time the configuration micro service is called.

For some inspiration on how to build custom Lambda hacks, you could look at:


or
https://alestic.com/2016/11/aws-lambda-awscli/

to get you started.

Hope that helps!

8

Thanks again @chrischabot - super detailed and helpful explanation.

One more point to clarify, for image builds with a fairly large size, such as the RaspberryPi3 which stands about 1.8GB - the total size of the raw image file would exceed what Lambda can hold.

Could we otherwise implement the config CLI command on a zipped version of the file? Does not seem to be supported at the moment.

9

@ycy88 ah right you are – Unfortunately the CLI wouldn’t be able to work on a zipped image (not without decompressing it anyways, which would cause the same issue)

Thinking creatively here – The memory limit for a lambda function is about 3000mb (https://docs.aws.amazon.com/lambda/latest/dg/limits.html) – so maybe it would be possible to create a ramdrive to hold the file?

Otherwise having a small dedicated EC2 instance or Amazon Elastic Container Service instance to generate the image file and call that from the lambda function

1 Like
10

We decided to use the an EC2 instance eventually, but the ramdrive idea was really cool as well. Thanks!