Autoupdater Improvements - freifunk-gluon/gluon GitHub Wiki
tl;dr: Signed site/domain-config updates, using a site.conf-independent push (& pull) propagation
Concept
- Similar to firmware updates, provide a versioned and signed site-/domain-config, too.
- Provide an AP interface with a fixed, non-configurable, static ESSID and non-configurable, static IP address (similar to the local-node address, but not changeable via site.conf)
- Run some (web?) server on it capable of receiving and verifying signed site-/domain-config, as well as offering the own, current site-/domain-config.
Push update (for immediate propagation):
- One initial node gets "manually" infused with the new, signed site-/domain-config.
- It restarts its gluon-scheduled-domain-switch (if present) and checks if the new config contains a domain switch that is due now.4 If so, this switch is performed first (including device reboot)
- Then it scans for neighbor APs with the magic config-updater ESSID.
- Then for each such AP found:
- It connects to it in STA ("client") mode and uploads the signed site-/domain-config
- Receiving nodes validate the signature and check that the version number incremented.
- If those checks are ok, then this neighbor node installs the new site-/domain-config and performs the same push-steps again for its own neighbors.
- Finally, with some offset it reboots so that the newly installed site-/domain-config can take effect
Pull updates (for previously offline nodes or temporarily jammed channels):
- After (a re)boot plus jitter and in regular intervals plus jitter a node should scan for neighbor APs with the magic config-updater ESSID.
- Then for each such AP found:
- It connects to it in STA ("client") mode and downloads the signed site-/domain-config this neighbor currently uses.
- It then validates the downloaded and signed signature and checks whether the version number is higher.
- If those checks are ok, then this neighbor node install the new site-/domain-config.
- This node then switches from "pull-mode" to "push-mode" and follows the according push mode procedure.
- Finally, with some offset it reboots so that the newly installed site-/domain-config can take effect
Advantages
- Any potentially broken site-/domain.conf changes, including scheduled domain switches can be undone at any time. The site/domain-conf-updater itself is fully independent of any site-/domain.conf settings.
- Flash writes are minimized.
- A power-cut during this update process is harmless.
- site-/domain.conf are device and architecture independent and therefore easy and quick to propagate to and hold for neighbors: Each node is a site-/domain.config mirror on its own, no need for central update servers.
ToDo & Questions:
-
Always use public keys from the site.conf autoupdater section from the original version provided by the firmware? Instead of any new version provided by a signed site-/domain-config update. -> to avoid that such an update messes anything up irrevocably
-
How to best propagate an update over VPN and cable connections?
Option 1)
- Join a special, fixed IPv6 multicast address on VPN and cable interfaces
- To scan and discover, a node sends an ICMPv6 packet to this dedicated multicast address
- Use the IPv6 source addresses returned by the ICMPv6 Echo Replies as targets to connect to and to download/upload site-/domain-configs from/to as well
Disadvantage:
- Not revertable on broken VPN settings changes in new site-/domain-config
=> Maybe add a special "site update channel" VPN. For its settings, always use the parameters specified in the original site.conf provided by the firmware (similar to public keys for site-/domain.conf updates, as suggested above).
Option 2)
- Allow direct push to potential, global IPv6 address on WAN/uplink interface
- Might (temporarily) be memorized on the gateway server side from the previous VPN connections?
Option 3)
- Some central, last-resort web-server on the internet where an HTTP-GET with the own site-code might be send to over WAN/uplink interface?
Option 4)