We are happy to announce a new iteration of Mender, our over-the-air software updater for embedded Linux devices. It is available for testing, both client- and server-side. And it is all open source under the Apache License, Version 2.0!
As we still have a few more features to implement before we mark Mender production-ready, this iteration does not have an official version number. It is delivered in terms of a branch named stable in the code repositories. This branch may continue to change as we add features; it is a curated version of the master branch that has gone through manual testing (in addition to the automated tests that run at all times on every branch).
You can read more about the new features since the last iteration in October below.
In the past iteration of Mender, raw file system files (e.g. .ext4) were written to the inactive root file system partition during a deployment. In this iteration, the raw file system format is replaced by a new format, the Mender Artifact format, that contains the root file system as well as additional metadata. You can recognize Mender Artifacts by their .mender suffix.
The introduction of the Mender Artifact format is driven by the continued effort to make Mender the most robust and easy to use over-the-air updater, as it enabled support for these key features:
Integrity checking of the update prior to using it. There is a metadata attribute for the SHA-256 checksum of the root file system, so that Mender automatically detects and prevents booting into updates that have been corrupted during transmission or storage end-to-end.
Automatic integration with device types so that updates are only deployed to devices that are compatible with it, e.g. with respect to CPU architecture, hardware floating point support, or peripheral drivers. Each device has a Device type and an Artifact has a corresponding Device types compatible attribute. A device gets its Device type during provisioning of its disk image, while the Device types compatible is set during the build of an Artifact.
Support for a overarching Artifact name so that deployments are skipped if the update is already installed. This lowers the risk as no unnecessary updates are deployed. The Artifact name will typically correspond to the name of the release, build or revision contained in the Artifact. It is set during the build of an Artifact.
As all these attributes are built into the Mender Artifact file, manual input is eliminated, which vastly reduces the risk of spelling or copy-paste mistakes and makes Mender easier to use.
You can find more details in the Mender Artifact format documentation.
Right now we are working on implementing user authentication for the Mender server, so that a login is required in order to manage updates with the server.
We will also shortly introduce support for running Mender in different environments: production and test, so that security is taken into account for production environments while allowing easy testing in test environments.
A production-ready Mender 1.0 is expected to be released towards the end of Q1 2017. With this version you will also have the opportunity to purchase support with SLAs and guaranteed response times from Mender staff, which gives you a peace of mind in case you encounter any issues or have requests during your Mender deployment!
The Mender documentation is updated so that you can easily try the new features in this iteration. If you want to try Mender with the server, have a look at the tutorial to create a test environment. Testing the Mender client alone can be done by following the steps in standalone deployments.
We hope you enjoy the new features, and please let us know what you think at the Mender mailing list!