Files
hq/01-RESEARCH/027-the-system-layer-as-modules/01-what-the-machines-run.md
T
jochen de032e704c Research 026 (the graphical session) and 027 (the system layer)
Evidence from both workstations and all four machines, read-only, and the
questions each must answer: seats and gating for the display stack, who starts
the session with which environment, contributions beyond shells, sway as a
sibling session; the container runtime with docker-compose on workstations
only, software outside the official repositories, secrets in the account's
environment, and three security findings.
2026-10-04 11:17:34 +02:00

4.9 KiB
Raw Blame History

01 — What the machines run

Measured 2026-10-04 on four machines, read-only, including the host's own record of what it applied: two servers (the anchor and a home server) and two workstations (a laptop and a desktop). "Owned" means a module the mesh assigns declares it.

The container runtime

anchor home server laptop desktop
docker 29.8.2 29.8.2 29.7.2 29.7.2
compose 5.5.1 5.6.0 5.5.0 5.5.0
buildx 0.37.2 — — —
podman — 6.1.3 6.1.0 6.1.0
docker.socket disabled enabled enabled enabled
containerd.service disabled disabled disabled enabled
daemon.json beyond the shared keys direct routing, two more insecure registries log rotation (100 MB × 10) — —
docker group operator, a CI user operator operator operator

Ownership:

  • The docker package is owned on one machine only, by the installer's bootstrap, not by a module.
  • docker.service is declared indirectly, by the name resolver and the private-network modules, which each merge their own keys into daemon.json.
  • Nothing owns the socket, containerd, compose, buildx or the group.

Compose in use:

  • On the servers, no running container belongs to a compose project. Their compose files are pre-mesh trees under the operator's and root's homes, plus a dangling enabled unit for one of them.
  • On the workstations, compose runs development stacks, and pre-mesh service trees sit under a top-level directory.

The mesh marks its own containers with a host label. On the workstations, a handful of unlabelled development and test containers run beside its build agent.

Privilege

  • The operator account escalates without a prompt on all four machines. The mesh relies on this, but it is set by hand in /etc/sudoers (a wheel rule on two machines, the account named on two), and nothing declares it.
  • On the anchor, a CI user from the predecessor keeps passwordless sudo and docker membership, and a predecessor drop-in in sudoers.d survives.
  • On the desktop, the operator account is also in the root group.

The package manager

  • pacman.conf is stock except on one server (parallel downloads).
  • The mirror list was generated once by a tool that is no longer installed. On the anchor, it is the hosting provider's single mirror.
  • An AUR helper is installed everywhere.
  • Packages from outside the official repositories: 2 on the anchor, 21 on the home server, 67 on the laptop, 114 on the desktop. They include:
    • the agent CLI, which a catalogue module declares as a package and the host cannot install;
    • a VPN client;
    • a remote-access client;
    • printer drivers;
    • GPU tools;
    • a kernel module built from source (DKMS) for a storage filesystem;
    • a snap daemon.

Time, locale, kernel, boot

anchor home server laptop desktop
time zone, keymap another zone, a non-US console keymap local zone, unset local zone, unset local zone, unset
time sync timesyncd plus a provider drop-in timesyncd timesyncd ntpd, timesyncd disabled
bootloader grub (BIOS) systemd-boot and grub systemd-boot systemd-boot and grub
kernels one two, plus a DKMS filesystem module one one, plus a DKMS controller driver
microcode none yes yes none
swap RAID partition partition zram, a file and a partition partition
log rotation timer not found enabled not found not found

Daemons and services no module owns

  • All four: avahi.
  • Workstations:
    • a VPN client daemon (both);
    • virtualisation (incus) with a hand-made unit that inserts container-runtime firewall rules (both);
    • printing and bluetooth;
    • GPU and power tuning per model;
    • a remote-access daemon (laptop);
    • snap and flatpak (desktop);
    • the local model server, run from a hand-written unit although a catalogue module for it exists (desktop);
    • Samba sharing and a network filesystem mount from the home server (desktop). A second mount is failing, and its credential is written in clear in /etc/fstab.
  • Servers:
    • a storage pool (about 167 TB) with its import, mount and scrub units, an NFS server and Samba sharing (home server);
    • traffic and sensor monitoring (home server);
    • a DHCP client daemon the catalogue has a module for but does not assign there (home server);
    • cron, an entropy daemon, and the legacy iptables services, which run beside the mesh's own filter (anchor).
  • Not found anywhere: a backup agent, a monitoring agent, a second VPN mesh.

What is plain debris

  • Dangling enabled-unit links on three machines.
  • Predecessor blocks in /etc/hosts on both servers.
  • The CI user, and the predecessor sudoers drop-in, on the anchor.
  • Pre-mesh compose trees on the anchor, the home server and the desktop.
  • Unlabelled test containers on the workstations.