Skip to content

Latest commit

 

History

History
84 lines (56 loc) · 4.7 KB

architecture.md

File metadata and controls

84 lines (56 loc) · 4.7 KB
Raw

Architecture

TODO Make this the repo's root README, once this is actually fully implemented and everything adapted.

Linux Distro Tools

arch-install (and similar scripts; e.g. debootstrap) create the root FS in a directory on the host. These tools usually require to run as root1 (but note pacstrap -N), and produce a directory tree with files owned by root, and some but not all files readable rootless.

build-image builds QEMU disk images from such a root FS directory. This tool needs to run as root1. One of its arguments is the UID of a non-root user which will own the built disk image. It also copies the /boot Kernel and initramfs to files owned by the non-root user.

run-serial-linux & run-gtk-linux such an image (without boot loader) with KVM using qemu* -kernel ... -initrd .... The serial variant opens a new terminal window which displays the VM's serial console, the gtk variant displays the VM's video output in a GTK window. This MAY not work for some basic VMs! (This tool runs rootless1.)

build-syslinux-bios (TBD) converts a disk image to another image with Syslinux for BIOS as the boot loader. This image can then be booted on bare metal or in a VM. (This tool requires root1.)

run-bios (TBD) runs a disk image with a BIOS launching a boot loader in a KVM VM.

build-efistub (TBD) converts a disk image to another image with an ESP2.

run-uefi (TBD) runs a disk image with an ESP2 with UEFI in a KVM VM.

TODO Introduce a Makefile like this with targets for each command above, and respective dependencies, so that e.g. make run xxx builds and runs. (Or use bazel for this? Or start be?)

LATER? Never?? build-tgz (TBD) builds a userland root filesystem from a Dockerfile3. We prepare it in /mnt, to separate it from the build container to avoid4 conflicts, and then export that as a tgz. This cannot be booted on bare metal. (This tool runs rootless1.) This is a PITA; see e.g. archlinux-pacstrap.Dockerfile.

Root Tools

virt ... runs the remaining arguments inside a isolated VM. It can launc a default lightweight fast starting one, or your custom kind of VM built using the tools above. This VM has access to all files under the current working directory of the host on a /work mount, but none outside of it. This is a safer alternative to sudo and non-rootless containers. TODO Study systemd-machined and podman machine; also note the (now deprecated) boot2podman.

suco ..., like sudo, runs the remaining arguments inside a --privileged --cap-add SYS_ADMIN container. (TODO This may never get implemented. As far as I understand, this is basically inherently insecure, by design?)

TODO Once implemented, and root checks are added to start of the tool, both requiring as well as informing users when not needed, remove the "This tool runs rootless / requires root" doc above.)

File Formats

  • Unused: tgz is the /mnt directory from a container image (docker export, not save). It contains a Kernel and initrd in /boot, and a "userland" in /. This is not a "disk" or a "partition" nor a "filesystem".

Inspirations

Footnotes

Footnotes

  1. Rootless tools do not require sudo to run as root. They CAN start rootless (!) containers or VMs. Rootful tools however require root, and cannot run in rootless containers. We can run them either: (1) on the host using sudo ..., or (2) in a --privileged --cap-add SYS_ADMIN container using suco ..., or (3) in a VM using virt. ↩ ↩2 ↩3 ↩4 ↩5

  2. EFI (Extensible Firmware Interface) system partition, or ESP; see e.g. [Wikipedia's] (https://en.wikipedia.org/wiki/EFI_system_partition) or ArchLinux's descriptions. ↩ ↩2

  3. Or Containerfile, which is AKA Dockerfile, but not yet very well known. ↩

  4. In a container, directories such as /dev and /proc and /sys or /run and some files in /etc are set-up by the container runtime, which would interfere with building a clean new userland root filesystem. ↩