Over-the-Air Updates, Part 3: Repository Configuration and Handling

Part one of the blog post series introduced the challenges of implementing an update system. We looked at the OSTree project and how it can help us to bring system update functionality to Qt for Device Creation. The second part demonstrated the tooling and the API that is provided by the Qt OTA Update module. We ended the second blog post by demonstrating how to generate an update. In this blog post we will export the generated update on a static HTTP server and configure a client device to query this server for system updates. Following this will be a short history lesson on OSTree adoption in the Linux ecosystem. But first we will take a quick look at what’s new in the Qt OTA Update module since the Technology Preview release.

Status Update.

Starting with Qt 5.8 for Device Creation, the Qt OTA Update module is graduating from being a Technology Preview module to a fully supported module. Some of the new features and improvements in Qt OTA Update 1.0 are: initramfs no longer being a hard requirement for using the OTA update feature (desirable when optimizing boot time), new API for configuring how remote OSTree repositories are accessed, more status notifications from the update process for the convenience of users, some minor API renamings, improved demo application and new command line arguments for the qt-ostree tool (for fine-tuning the image and update generation).

Exporting Repository.

As mentioned earlier, we ended the second blog post by generating a new update. An update (or a system snapshot) is a commit into OSTree repository. By default, qt-ostree stores this repository in WORKDIR/ostree-repo/. For local testing you can pass --start-trivial-httpd to qt-ostree. This starts a simple HTTP server which is accessible on the local host at the address specified in the WORKDIR/httpd/httpd-address file. In a real world scenario you would want to export this repository on a production server. This is as simple as copying the contents of the WORKDIR/ostree-repo/ directory to a dedicated path on the server.

The --start-trivial-http does not have support for HTTPS so I have configured my own Apache web server. This server requires TLS client side authentication. A URL to the OSTree repository in my case is https://www.b2qtupdate.com/ostree-repo. Because the configured web server resides on my development machine, the ostree-repo/ directory from the URL is conveniently a symlink to WORKDIR/ostree-repo/. Whenever I generate a new system snapshot, it is immediately available on https://www.b2qtupdate.com/ostree-repo. The next step is to point client devices to this address.

Configuring Devices.

Extending on the demo from the previous blog post, we need to add a configuration that describes how to access the server:


OtaRepositoryConfig {
    id: secureConfig
    gpgVerify: true
    url: "https://www.b2qtupdate.com/ostree-repo"
    tlsClientCertPath: "/usr/share/ostree/certs/clientcert.pem"
    tlsClientKeyPath: "/usr/share/ostree/certs/clientkey.pem"
    tlsPermissive: false
    tlsCaPath: "/usr/share/ostree/certs/servercert.pem"
}

Here we are pointing the client device to the URL where we exported the generated OSTree repository. This configuration requires the update to be signed by a known GPG key. We also provide paths to the certificate files (on the device) which are used for client and server TLS authentication. A keyring with the trusted keys and certificate pinning should be done when creating the initial image (during the device integration step). The current configuration can be updated by calling:


OtaClient.setRepositoryConfig(OtaRepositoryConfig config)

The subsequent calls to the server (for example, fetching metadata about the remote snapshot) will use this updated configuration.

An alternative configuration could use unencrypted HTTP and look as follows:


OtaRepositoryConfig {
    id: basicConfig
    url: "http://www.b2qtupdate.com/ostree-repo"
}

If we exported the repository to scheme://host:port/my-product/system-updates/, we would point devices to that URL instead. The complete demo application is available here.

OSTree Adoption.


System updates are an everlasting area of interest. Just look at the talks dedicated to this topic on the Embedded Linux Conference this year (and the years before). OSTree was amongst the presented alternatives, receiving great feedback due to its outstanding approach. OSTree originated as a research venture in high speed continuous delivery and testing infrastructure for GNOME. It has been a well-received technology with expanding adoption in the Linux ecosystem. OSTree is being used at the core of new Linux distributions - Project Atomic, Endless OS, Papyros. Automotive Grade Linux is researching OSTree integration for the AGL reference platform. Flatpak (a framework for distributing Linux applications) is another interesting project that uses OSTree to distribute and manage applications and runtimes. As we can see, OSTree is hot technology, being adopted by a variety of projects on desktop, servers and embedded systems.

Want to have a robust and modern update system on your devices as well? The Qt OTA Update 1.0 module brings full OSTree support with convenient Qt APIs to Qt 5.8 for Device Creation.

Conclusion.


This concludes the series of the blog posts introducing the Qt OTA Update module. Try it yourself with Qt for Device Creation and let us know what you think. Feedback and feature requests are always welcome and appreciated.


Blog Topics:

Comments