Software Distribution Platform: Difference between revisions

From
Jump to navigation Jump to search
(initial writing from discusison on 2004 11 17)
 
(restructured)
Line 2: Line 2:


The identified requirements are as follows:
The identified requirements are as follows:
* dynamic network of homogenous nodes (no privileged nodes)
* nodes may be turned off or disconnected for any period of time from the remaining network
** nodes may be turned off or disconnected for any period of time from the remaining network
⚫
* no centralized datastore (avoids single point of failure)
** network may be split for any period of time
⚫
* updates need to be reliable and cross-compatible beginning with version 1.0.0 (allow update of an node running 1.0.0 with a network of version 1.5.99 nodes around and also allow updates even with versions that have bad routing)
** nodes may be added at any time
⚫
* broken, untrustworthy and malicious nodes may not install software (or interfere with the updating process?)
* no centralized datastore
⚫
** avoids single point of failure
** less administration
* robust and reliable updates
** allow updates even with broken routing
⚫
** cross-compatible beginning with version 1.0.0 (e.g. allow update of a node running 1.0.0 with version 1.5.99)
⚫
* broken, untrustworthy and malicious nodes must not be able to install unwanted software (optional: not interfere with the updating process)
* trustworthy developer team and CA
* trustworthy developer team and CA
* all nodes should have the same software version running most of the time (ideally every second)
* all nodes should have the same software version running most of the time (ideally every second)
* implementation must fit into limited hardware (e.g. 32MB RAM + 8MB flash (optional: WRT54G))




The ideas to meet those requirements:
The ideas to meet those requirements:
⚫
* discovery mechanism for newer versions on neighbours
** push and/or pull
** broadcast(push) and/or query
⚫
* if newer version is available, fetch it (e.g. over existing TFTP)
* infection based distribution mechanism
⚫
** new version can be injected on any connected node
** distributed step by step to each connected node
* notification and update protocol never changes after 1.0.0 is released
* sign each software update package with a CA key
* sign each software update package with a CA key
* CA public key is preinstalled with the base system on every node to check authenticity
* CA public key is preinstalled with the base system on every node to check authenticity of new files
⚫
* synchronize system clocks over NTP (using UDP port 123) with neighbours
⚫
* discovery mechanism for newer versions on neighbours (push and/or pull (broadcast and/or query))
** guaranteeing similar system times
⚫
* if newer version is available, fetch it (e.g. over existing TFTP)
⚫
* infection distribution mechanism (new version can be injected on any connected node)
⚫
* synchronize system clocks over NTP (using UDP port 123) with neighbours, guaranteeing similar system times
* include software starting time (and end time for experimental software) in each update package
* include software starting time (and end time for experimental software) in each update package
* coordinated switch over to new version if system_time > start_time
* coordinated switch over to new version if system_time > start_time
* coordinated switch-back to non-experimental version if system_time > end_time
* coordinated switch-back to non-experimental version if system_time > end_time

[[User:Wiedemann|Wiedemann]] 19:02, 17 Nov 2004 (CET)

Revision as of 20:19, 17 November 2004

Conception for a software distribution platform for a distributed network of WRT54GS nodes.

The identified requirements are as follows:

  • dynamic network of homogenous nodes (no privileged nodes)
    • nodes may be turned off or disconnected for any period of time from the remaining network
    • network may be split for any period of time
    • nodes may be added at any time
  • no centralized datastore
    • avoids single point of failure
    • less administration
  • robust and reliable updates
    • allow updates even with broken routing
    • cross-compatible beginning with version 1.0.0 (e.g. allow update of a node running 1.0.0 with version 1.5.99)
  • broken, untrustworthy and malicious nodes must not be able to install unwanted software (optional: not interfere with the updating process)
  • trustworthy developer team and CA
  • all nodes should have the same software version running most of the time (ideally every second)
  • implementation must fit into limited hardware (e.g. 32MB RAM + 8MB flash (optional: WRT54G))


The ideas to meet those requirements:

  • discovery mechanism for newer versions on neighbours
    • push and/or pull
    • broadcast(push) and/or query
  • if newer version is available, fetch it (e.g. over existing TFTP)
  • infection based distribution mechanism
    • new version can be injected on any connected node
    • distributed step by step to each connected node
  • notification and update protocol never changes after 1.0.0 is released
  • sign each software update package with a CA key
  • CA public key is preinstalled with the base system on every node to check authenticity of new files
  • synchronize system clocks over NTP (using UDP port 123) with neighbours
    • guaranteeing similar system times
  • include software starting time (and end time for experimental software) in each update package
  • coordinated switch over to new version if system_time > start_time
  • coordinated switch-back to non-experimental version if system_time > end_time
Retrieved from "https://sarwiki.informatik.hu-berlin.de/index.php?title=Software_Distribution_Platform&oldid=253"