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 <linus.luess...@c0d3.blue> Reply-To: Deutschlandweite Liste für WLAN Themen Layer 1-7 <wlanw...@freifunk.net> To: Deutschlandweite Liste für WLAN Themen Layer 1-7 <wlanw...@freifunk.net>, Paul Spooren <spoo...@informatik.uni-leipzig.de> 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 -- Discuss mailing list Discuss@lists.funkfeuer.at https://lists.funkfeuer.at/mailman/listinfo/discuss
