Firmware-Autoupdate

[cholin]

In Gluon gibt es einen Mechanismus Knoten automatisch auf eine neuere Firmware zu aktualisieren (siehe http://gluon.readthedocs.org/en/latest/features/autoupdater.html ). Die Packete dazu sind admin/autoupdate und gluon/gluon-autoupdater in https://github.com/freifunk-gluon/packages. Wollen wir auch so etwas in der berliner Firmware?

[booo]

Eine damit verbundene Frage ist z.B. wie wir die Konfiguration aus der alten Firmware in die neue übernhmen bzw. wie wir alte Knoten updaten.

[cholin]

I think the first migration from the old firmware to our new one can only be done by hand. But for the next releases an autoupdater can be handy. The updater needs to take care of updating the config if needed.

[SvenRoederer]

this also relates to #308

[sarumpaet]

#308 is unclear to me and (apparently) is about changing the root filesystem type to JFFS2 first and foremost.

In contrast, this issue is about automatically flashing new firmware images once they become available, sort of an automatic "sysupgrade", which is a different thing and quite simple to implement (at least for routers in standard configuration).

[SvenRoederer]

this seems to be an approach to build individual images: libremesh/chef#31 .
Even it helps not to push them onto the routers automatically.

[bobster-galore]

u have to fillet the dinosaur before u can eat it.
Do u think it's necessary to build individual images?
Otherwise if @sarumpaet knows about a simple solution to sysupgrade automagically we are close to kind of a working way.

[sarumpaet]

@bobster-galore See the very first comment by cholin. We just need to make buildbot release files discoverable (automatically) and set up some router-side script that does the updating. For Gluon, the "discovery" part is their manifest file (e.g., https://cccgoe.de/freifunk/stable/sysupgrade/stable.manifest - note the router type identifier - first column - is very similar to what we use in, e.g., https://util.berlin.freifunk.net/hardware?name=tp-wr842-v3 ), and the updating script is https://github.com/freifunk-gluon/packages/blob/master/admin/autoupdater/files/usr/sbin/autoupdater . We could probably just adapt our build process/add the manifest file and copy the Gluon autoupdater.

[bobster-galore]

@sarumpaet that would be really nice since we could get rid of really outdated fw like kathleen 0.0.0 etc. which is more a security risk than a nice memory.
Furthermore it would be a comfortable promise not to see ppl where u installed a freifunk-router. ;)

Perhaps there could be an early adopters mode to get rc-Versions installed? E.g. choosing only stable or rc also, ppl / installations who would care for a testing mode?

[aparcar]

Even it helps not to push them onto the routers automatically.

The is an app for that. Currently it still requires certs for https but could later just rely on usign. A cron could run the updater automatically to check for new releases or outdated packages

Do u think it's necessary to build individual images?

These images are only individual if you changed the default installed packages. If a package combination was build before, it's reused. This enables auto-upgrades even for users with modified firmwares and only builds actually requested images, not all, possibly never used, images.

Anyway, just my two cents.

[sarumpaet]

For the record: Gluon switch to a new autoupdater implemented in C some time ago: https://github.com/freifunk-gluon/packages/tree/master/admin/autoupdater/src

[SvenRoederer]

An other option might be the "Attendedsysupgrade"-suite (https://github.com/aparcar/attendedsysupgrade-server) based on a GSoC project.
It seems to be a generic project for OpenWrt-based firmwares.