[Discuss] Fwd: GSoC 2017 - Attended Sysupgrade

[Paul Fuxjaeger]

FYI: falls wir demnächst mal am Thema "Updates" ankommen: hier wird
scheinbar daran gearbeitet, unterstützt von Google.

http://lists.freifunk.net/pipermail/wlanware-freifunk.net/2017-May/003686.html

-------- Forwarded Message --------
Subject: Re: [WLANware] GSoC 2017 - Attended Sysupgrade
Date: Thu, 25 May 2017 18:02:01 +0200
From: Linus Lüssing <(spam-protected)>
Reply-To: Deutschlandweite Liste für WLAN Themen Layer 1-7
<(spam-protected)>
To: Deutschlandweite Liste für WLAN Themen Layer 1-7
<(spam-protected)>, Paul Spooren <(spam-protected)>

Hi,

On Tue, May 16, 2017 at 11:51:25AM +0200, Philipp Borgers wrote:
> There is some interest in an "auto" update in the Berlin community [1] too. We
> would benefit from a implementation that is independent of the libremesh
> project.

Yes, an implementation independent of a specific firmware would be
great!

Paul, you might also want to have a look at the autoupdater used in
Gluon [0]. While it currently does not feature "attended updates" per se
it tries to compensate this through three other safety measures:

* n-of-m signatures:
  - An image will be accepted/flashed only if there are n of m
    valid signatures in a manifest file
* Branches:
  - Supports configurable branches, so you can first role out
    an update onto nodes which are configured to use a "beta"
    branch for instance, or even have some nodes to test nightly
    builds. A user can also select the branch "None" to perform
    updates manually. Usually a branch named "stable" is the
    default.
* "Stretched updates":
  - By default, an update is distributed over a whole week. Nodes
    will probablistically choose to update or wait another day
    before updating. So if you notice after one or two days, that
    issues start to occur or in the worst case that nodes start to
    vanish, you can still react and remove the images or manifest
    file from the update server.
  - The default one week period can be overriden through a
    "PRIORITY" parameter in the manifest file.
  - By default, updates are performed in the night. However,
    if the one week period is over, nodes will start to try
    updating once they get online.

Currently, nodes fetch updates over the mesh network layer. A
feature we are currently desperately missing for the Gluon
autoupdater is the possibility to work independent of a working
mesh network to allow switching routing protocols, wireless
channels, wireless modes etc.

Currently, quite some Freifunk communities are stuck with an old
protocol version of batman-adv due to these shortcomings of the
autoupdater :-(.

The current idea to make the autoupdater protocol agnostic is to
make it connect to and iterate over open AP interfaces of
neighboring access points instead of trying to mesh with them.

Regards, Linus

PS: Jan-Philipp Litza is (was?) working on a rewrite in C for
the Gluon autoupdater core. Currently it is written in Lua.


[0]:
Documentation:
- https://gluon.readthedocs.io/en/v2016.2.5/features/autoupdater.html
Gluon independent core code:
- https://github.com/freifunk-gluon/packages/tree/master/admin/autoupdater
Gluon "glue code":
-
https://github.com/freifunk-gluon/gluon/tree/master/package/gluon-autoupdater
-
https://github.com/freifunk-gluon/gluon/tree/master/package/gluon-config-mode-autoupdater
-
https://github.com/freifunk-gluon/gluon/tree/master/package/gluon-web-autoupdater

[1]:
-
https://github.com/freifunk-gluon/packages/tree/c-autoupdater/admin/autoupdater