
Mender – An open-source OTA software updater for embedded Linux devices - ralphmender
https://www.mender.io/blog/announcing-the-production-ready-mender-release-1-0
======
currywurst
Neat :)!

In case the Mender folks are here, have you looked into incorporating the
concerns addressed bt The Update Framework (TUF)
[https://theupdateframework.github.io/](https://theupdateframework.github.io/)

~~~
theamk
Why? TUF is all about reimplementing SSL and PKI. Since mender can use regular
SSL with good-old PKIs, there is no reason to go with weird solutions.

~~~
aseipp
TUF protects against more attacks than just HTTPS or regular trivial signing
methods do (rollback attacks, freezes, mix and match attacks, and helps secure
mirrors), and has little to do with HTTPS or raw "transport layer encryption".
It absolutely compliments and suppliments HTTPS if you're using it for your
downloads, it is not obsoleted by it. (Though, the subtext on the introduction
page probably doesn't help this impression by saying "Like the S in HTTPS...")

~~~
theamk
Well, the reason TUF has to protect against all of the attacks is because it
is choosing to support a varying set of requirements, including lack of SSL
and insecure mirrors. Mender simply does not care about them, so it can be
dramatically simpler:

\- rollback attacks -- impossible since all comms are secure, and there are no
untrusted mirrors

\- freezes -- impossible, because SSL channel must be re-negotiated every time

\- mix and match attacks -- nothing to mix+match, mender only does one file
(rootfs)

\- helps secure mirrors -- mender does not support 3rd party mirrors, so no
need to secure them.

You can see it right on the TUF homepage: it claims to replace application,
library package and system package managers. This is a lot of work, which
requires a lot of complexity, and there is no need at all to pay that price if
you do not need to.

------
nrclark
This is kind of a stupid question, but why not just use .rpm/dnf or .deb/apt
and a custom repo?

~~~
kristoffer
Embedded Linux systems supporting OTA usually employs a dual root file system
(RFS) approach where the upgrade is placed onto the currently not used
partition and then after successful upgrade the RFS to boot into is replaced.

It is an easy solutions which ensures integrity and has few drawbacks for
typical embedded systems.

The output of a typical Embedded Linux CI build is a complete RFS, having to
care about individual packages would just be a headache, when you can replace
the entire RFS and be done with it.

~~~
Matthias247
That's true. I'm currently also involved in the development of an embedded
linux project for which we yet have to find out the perfect update story. We
thought about replacing individual packets too, but it looks like a hard way
from various perspectives:

\- Build system: Would need to figure out how to build all these packets (with
their requirements) in a reliable way.

\- Deployment: Deployments should be reproducable. All devices should get the
same version of all subcomponents. And a rollback to an older version (with
older versions of subcomponents) should be possible. Having some devices
floating around with untested configurations (because the device decided to
update on package but not the remaining ones) is not desirable, because you
want to only handover fully tested/qualified software versions to the
customer.

Building the whole RFS at once, storing it and flashing it at once currently
seems like the way to go. Will take a look at mender if it could help.

~~~
karmicthreat
I'm kind of in this boat now with a couple of products. The catch is I need to
do both local and OTA updates. This seems to be a rare feature that nobody is
doing.

I also am trying to get Resin.io like containers working. It seems like it
would be an easier way to test and deploy.

~~~
Matthias247
That's also a requirement for me - local updates (via connected USB stick,
triggered via reboot or web interface) should work also in addition to OTA.
_In fact local updates would have an even higher priority.

We fiddled around also a little bit with the container route. I liked it for
quick iteration times (rebuild a docker container, pull it from local image
registry to device and test it there). But we found out that we won't get by
with just container updates, and that most updates would also need to contain
a new kernel or kernel module versions.

~~~
eystein
It is not that uncommon for an updater to support both local and remote
updates. For example, Mender has two modes of operation: standalone and
managed [0].

Like you, many teams are still doing local updates, or transitioning from
local to OTA, at least for some products.

[0] [https://docs.mender.io/1.0/Architecture/Overview#modes-of-
op...](https://docs.mender.io/1.0/Architecture/Overview#modes-of-operation)

------
veli_joza
Can someone summarize the difference between Mender and OSTree? I see that
QtOTA chose OSTree as their underlying mechanism, which is significant in
embedded automotive industry.

~~~
mwcampbell
From my perspective as a curious observer of both projects, OSTree certainly
looks attractive, because it doesn't waste space on two rootfs partitions
which have to be oversized to accommodate future growth of the image. I
initially thought OSTree required btrfs, because Project Atomic used btrfs the
last time I looked at it. But according to the docs, while OSTree will take
advantage of btrfs features if btrfs is being used, OSTree itself will work
with a variety of filesystems including ext4.

Edit: An upside of the alternating rootfs partition approach is that the
rootfs can be cryptographically verified at the block level. Chromium OS
implemented this, and CoreOS also uses that implementation. This is probably
outside the scope of Mender itself, but the updating approach used by Mender
enables it.

~~~
eystein
Cryptographic signing and verification is in scope for Mender [0], and frankly
it should be in scope for all updaters -- too many hacks have happened due to
lack of codesigning.

[0]
[https://tracker.mender.io/projects/MEN/issues/MEN-1020](https://tracker.mender.io/projects/MEN/issues/MEN-1020)

------
PanosJee
What are the differences against Resin.io?

~~~
mpasinski
disclaimer: I work for Mender

Mender is basically full image update solution while resin is container based.
Mender is fully open source, both client and server, resin is having only
client open source. Mender is more lightweight, it provides a thin layer to be
integrated with the already existing stack, while resin is providing full
stack you need to use to be able to incorporate update mechanism.

~~~
karmicthreat
So is there any way to make Mender do local updates that are not OTA?

~~~
gregdistefano
[https://docs.mender.io/1.0/Getting-started/Standalone-
deploy...](https://docs.mender.io/1.0/Getting-started/Standalone-deployments)

------
mwcampbell
I'm curious about why you chose Yocto over buildroot for your official
integration. I figured buildroot would be better, because Yocto's opkg system
is superfluous on a device with full image updates.

~~~
eystein
Yocto has quite large community and is growing fast. That said, think of Yocto
as the first integration not the only - buildroot is surely interesting too
but we had to start somewhere. :)

------
brightball
Is Elixir's Nerves project using anything like this?

------
pjmlp
Cool!

I guess an over-the-air (OTA) software updater for embedded Linux devices
could be considered some kind of systems programming...

------
amq
Does Mender work with mbed OS?

~~~
amq
Figured the answer: no, you need Linux.

~~~
ingve
Strictly speaking you don't need Linux. As mentioned in the blog post, Mender
also works with IncludeOS [0]. A demo was shown at the OpenIoT Summit last
week, the video should be available in the near future.

[0] [http://www.includeos.org/](http://www.includeos.org/)

