Defining node update mechanisms

During the last days I've been working on defining the node storage layout at a finer grain, including the specific paths to be used in filesystems and how to manage them during the boot process and operation of the node, which turned to be challenging because we're talking about a system which will probably perform two root pivots while booting.

I also specified the behaviour of the programs to manage both the node images stored in it and the persistent data sets to be shared across node images so that the gory details of mounts, paths, symbolic links, etc. are isolated from the user. I have the impression that these could be separated in two independent packages for reusing outside of CONFINE. I wouldn't be surprised if some people at the Battle Mesh showed some interest in these developments. ;)

A couple of issues I plan to work on during the next week are: i) writing a replacement for the IPv6 overlay page that better captures the meaning and utility of the management network, which should allow more people to understand this fundamental piece of CONFINE testbeds, and ii) creating some simple script that generates tinc host files for a network island by collecting information from the testbed server's REST API, so that we can start deploying testbed gateways which may be required by some islands with conflicting IPv4 ranges like AWMN.