Torizon image update options (if not OTA)

Hi

Our product will often be placed in local networks, were it is not allowed or not possible to get them on the Internet (OTA not possible). They can also be placed were they are difficult to access physically.

We will from time to time need to update the products, with a new custom Torizon image.

We are using Verdin iMX8 Mini on custom hardware with a custom Torizon image. There is an Ethernet and an USB OTG avaialble. Application will be using Docker.

What are my options for doing image update in the field?

I could use torizonecore-builder “deploy” command over a Ethernet connection?

Is it possible to use OTA on premises or make the product “fetch” the new image form a local network location itself? Either by user interaction or by the application to starting an update procedure on request?

Or

Use a USB pen drive and than to the image update?

Thomas

Greetings @TJO,

Given your limitations there’s still a couple of options here. Let me run down the list that comes to my mind and let me know what you think.

  • If your product is connected in a local network a traditional OTA may still be possible. However this would require setting up an OTA server on this local network. This method would require serve infrastructure and such which may not be suitable/practical for your needs. This option may need to be discussed further since it’s not so straightforward.
  • We are currently working on a new feature called “Offline Updates”. This would allow a user to put an update package on a USB/SD drive and plug it into the device to deliver the updates. This would offer a similar level of security as our traditional online OTA option. This feature is still in progress with an initial version planned for Q1 2022.
  • You could technically use torizoncore-builder deploy to deliver OS based updates. Provided whatever machine is running torizoncore-builder is on the same network and reachable by the devices. You wouldn’t be able to update containers this way however only the OS. Also there’s no security guarantee here like with our normal OTA, since we didn’t design torizoncore-builder to be used as an update tool.

Outside of this there are definitley other options to deliver an update. However I just listed the ones that came to mind that are more Toradex “supported”. Take a look at the list above and let me know your thoughts so that we may discuss further.

Best Regards,
Jeremias

Hi Jeremias

Thanks for you reply. He is my thoughts.

All our unit do connect to a server gateway on the local network. Today, we can actually from the server software, send updates to our products on request.

Due to the fact, that they can be places in difficult to access places(High up so you might need at ladder) using an USB disk would be a hasle. But still a very usable feature. Specially when they are used without network as standalone units (This may also be the case)

Our “dream” scenraio would be to send a request to our application, that a new system update is ready. Than the system get this update and install it.

When using the update feature of torizon builder. Does it push the update to the module or does the module pull the update from the development PC? Would it be possible to execute that command in torizon, by the application, to do the pull?

Thomas

Hi @TJO

The torizoncore-builder deploy command is a push from the machine running the builder. I believe it uses an ssh connection as its transport. @jeremias.tx can correct me if that is wrong.

In your dream scenario, how would the system get the update? Can it route a connection through the gateway? As long as there is connectivity it should work with the standard update model. But we don’t have an on-premise solution so you would have to connect to our server for this to work. We have discussed supporting an on-premise option but there are no concrete plans for it.

Is your gateway connected to the internet? Even if you can’t route the traffic from the device directly, there may be options, with some effort, to proxy the connection.

Drew

The torizoncore-builder deploy command is a push from the machine running the builder. I believe it uses an ssh connection as its transport.

To be more precise. The deploy command sets up a HTTP server on the host to serve the OSTree that contains your changes. It then uses ssh to run commands on the device to pull this from the server.

Given your feedback it sounds like a more ideal situation would be some mechanism locally on the closed network the devices are on. So something more on-prem as Drew has described.

Are there any other considerations/desire here for your update system?

Best Regards,
Jeremias

Hi Drew and jeremias

Our equipment and servers has never internet access. Our units has connection to a server in a local network with no internet connection.
So to update we get the new release to the server and send the new software to the connected units when needed. That is how we do today with the current products. The customer only updates the product if there is a need for it. New needed features or bug fixes. So no monthly biulds where we need to push the update to all out customr.

1 solution is to go to one unit at a time, insert an USB disk and do the update. But there are usally many units in hard to get to places, so this would be a hasle and expensive for the maintanance todo.

So if the updated image is located on the local server (the local server the unit application connects to), the update could be send to the units. As I understand the only possible way is to use torizoncore builder and SSH to deploy it to the unit?

But it would be nice if that could be initialized from the unit itself from the software. Than we could send a request from our server to the unit and the application can initiate the update of the system. This could ex. be running a script that makes Torizon pull’s the new update. But I dont know if that is possible with Torizon ?

This “need for internet access” also makes it difficult to use dockers. It is planned that the units application is running inside a Docker Container along side a Weston and a Chrom browser container. This application is probally the thing that get updated most often, compared to the Torizone system. Again it would be nice that we from the local server can control when the docker container must be updated. But is it still unclear for me how we make a local Docker Repository on that local server, how we push a new released Docker image to that with no Internet connection and how we can control when the new Docker container is pulled/pushed from/to the units.? As I understand dockers container can udate to the latest when started, but I would like to control when and which unit. But Im sure it is possible.

Thomas

Given your description and situation here’s what I’d suggest/recommend. But of course this isn’t the only solution.

For OS/System updates it’s clear that an ideal solution would be something running local on your internal server where these devices can access. The most ideal solution would be to run an OTA server similar to our own on-prem in your setup. However, as we’ve said we don’t have a defined solution for this yet.

One idea could be to work with OSTree directly instead of our entire update stack. If you’re not familiar OSTree is the software that composes the upgrade system. It’s possible to work with it by itself, however keep in mind you do lose some features/security from not using our entire OTA stack. Though given your network is essentially isolated it might not be that big of an issue.

What I was thinking is that on your internal server you could host a repository of OSTrees. Then the devices can pull these OSTrees down to update their system. You can see the article here for more details on this idea: OSTree

Now regarding Docker, you can actually do something similar. On your local server you should be able to setup a container registry. Then your devices can pull from this registry instead of Docker Hub.

Anyways these are my quick thoughts of how you can have everything to update your system on these local servers. A lot of this would be pretty unique to your situation. But, it’s at least an approach that could be done Today I believe.

Best Regards,
Jeremias