Docker, WebUI and API enhancement

[CygnusHyoga]

It would be great, add support for docker to perform updates. For example add persistent volumes, where we have the templates.

It would also be nice to add a Web GUI with API support to call the script from Jenkins or from another automation system.

[Lanchon]

sorry i don't use any of those automation systems. it's just a script, just configure it and call it.

[Lanchon]

i've got a main script that calls the per-router scripts and updates the firmware on all of my routers in one go, from furthest away to closest. it used to take me a lot of time to update the routers, but now it takes me a second to start the main script.

keep in mind that interrupted updates on most routers cause bricks. so IMO updates should always be manually triggered. it's inevitable to forget about cron jobs, so it's a matter of time until you power cycle a router while it's being cron auto-updated. or you cut the mains power to replace a faulty outlet. or the cleaning lady yanks the wires. etc...

no, you should manually trigger updates when there is controlled peace and quiet. so no automation beyond manual bulk updates of all routers for me.

[Lanchon]

to be able to really autoupdate, ddwrt should have a second stage bootloader and two slots for two firmwares instead of one. i was sort of in the process of designing that, but then decided it was just too much work.

many routers have lots of flash. others can be configured with usb drives. my design involved unpacking a normal firmware build to reuse the kernel but replace its boot ramdrive. this kernel and its new ramdrive (together form the bootloading firmware) would look for other firmware images to boot, in router flash, usb drive, etc. it would check integrity of the images and choose the right one, then switch to it via the linux kexec mechanism.

the bootloading firmware would be flashed manually only once and never updated. it would very probably not enable any network devices so it can't be hacked via the net. the update procedure would overwrite the firmware slot not currently in use, and after verifying it, would change a "current slot" variable so the next boot would load the new firmware. an interrupted or failed update would not affect the device.

if a buggy firmware is flashed and it doesn't boot, the bootloading firmware could have a mechanism where, by pressing a button during boot, one instructs it to boot the inactive slot, effectively rolling back the last update temporarily to reflash the device.

another option is to have a boot button to stop the bootloading firmware from chaining the next firmware and instead enable the network so that it can be reflashed.

[CygnusHyoga]

Thanks for the explanation Lanchon. Updates in ddwrt are messy, the mechanism is not ideally, and brick its a possibility we have to asume, but your script is very useful an alternative for the manual update process, thank for sharing and the time you take for detailed response!

[Lanchon]

thank you! (and sorry again for not supporting your OS :( )