Automated build process for chronode system images
Current test systems were hand assembled on top of a narrowly specific version of Ubuntu Server (17.04), with a set of additional custom binaries. Since chronodes are effectively static appliance images, there is no need to include a bulky generic Linux operating installation, compilers, or online package management tools. The ideal artifact would include strictly only the minimal set of system administration, container management, process checkpointing/restoration, ZFS, and Chronostruct software.
Debian based distributions (inc. Ubuntu) have debootstrap
and multistrap
, which can populate a new root filesystem based upon a list of Debian repositories and desired packages (whose dependencies are automatically included). The Gentoo meta-distribution has comparable tools, such as catalyst
used by their release engineering team to produce installation stages and bootable ISOs, and crossdev
intended for cross-compiling root filesystems (though possibly usable for native architecture isolated non-crossed builds), likewise capable of ingesting specifications for desired packages.
The systemd
project has facilities for creating stateless, reproducible, and/or verifiable systems with largely read-only root filesystems, using designated procedures to populate traditionally mutable state directories (like /etc
and /var
): http://0pointer.net/blog/projects/stateless.html
The outline of action:
- Produce a read-only
SquashFS
root filesystem artifact roughly (or closely) following the design of "stateless"/"verifiable" models in systemd. This artifact should be dual-use: (1) directly bootable as an ISO CD-ROM or USB mass storage device, (2) bootable when splayed onto the start of a system's fixed storage device (e.g. HDD or SSD). - Upon boot-up, the system will examine attached storage devices looking for partitions or whole devices where ZFS storage pools could be located. If any pools are found, the system will load identity state, keys, and Chronostruct data from that pool. If no pool is found, the system will initialize a new pool in the largest free space (either by creating a partition, or utilizing and entire block device), and populate it with new identity state, keys, and Chronostruct data.
- Once Chronostruct storage state is initialized, the system will activate networking, and begin serving the Chronode user interface.
The root filesystem requires packages including, but not limited to:
- A compatible Linux kernel
- ZFS on Linux kernel modules
- ZFS on Linux userspace utilities
- Basic shell and system utilities (either
coreutils
orbusybox
based) - LXC binaries and dependencies (or static versions of the LXC binaries)
- CRIU binaries and dependencies (or static versions of the CRIU binaries)
- iproute2 and iptables for network configuration
- Chronode daemon binary