hq/01-RESEARCH/027-the-system-layer-as-modules/02-candidates-and-questions.md

02 — Candidates and questions

Decided by the operator on 2026-10-04

• docker holds the container runtime seat on every machine, as ADRs 0165 and 0166 propose. Those records are promoted from proposed when it is built.
• docker-compose is a module of its own, the distribution's package and nothing else. It is assigned only to the two workstations, for development work. The servers run nothing through compose.

Later the same day, on the candidates below:

• Yes, all of them: docker, docker-compose, sudo, pacman, an AUR helper (question 1), time-sync, kernel (with boot and microcode), logrotate, avahi, cups with the printer's driver, and every server-only candidate.
• Locale, time zone and keymap are one module, localization.
• snapd and flatpak are modules, on the two workstations only.
• incus is the lab's, whose module depends on it. It is not a module of its own beside the lab.
• The agent's and the local model server's modules are still being developed, and are not assigned until they are.
• The predecessor's CI user is retired. It was removed from the anchor the same day, with its sudoers line, its docker membership and a dangling unit link; the backup is on the machine.

Candidate modules

On every machine:

module	owns	first reason
docker	the packages (runtime, containerd), the service and socket, daemon.json's base keys (live restore, log rotation), the docker group's members	four machines, four configurations, one owner on one
sudo	the operator account's escalation as a drop-in, declared	the mesh's tools rely on it (to-be 38 WP4) and nothing states it
pacman	pacman.conf's few keys, the mirror list and its refresher, cache cleaning	mirrors generated once and never again
time-sync	timesyncd and its drop-ins	two daemons across four machines
localization	locale, time zone, console keymap (one module, the operator's choice)	one machine differs, with no record why
kernel	the kernel packages, microcode, initramfs presets	two machines without microcode
logrotate	the timer and the base configuration	rotation runs on one machine of four
avahi	the daemon and name-service switch entry	on all four, owned by none

On the workstations only:

• docker-compose;
• lemurs, the login manager (research 026);
• a VPN client module;
• incus with its forward unit (the lab module declares the package on one workstation only);
• cups with the printer's driver;
• bluetooth;
• per-model hardware modules: GPU, power, vendor keys, brightness. These are the same modules research 026 needs for the desktop's fragments.

On the servers only:

• zfs with its scrub timer, and the long-term kernel it builds against;
• nfs-server;
• samba;
• vnstat, lm_sensors.

cron on the anchor serves one stock file and can go. So can the entropy daemon on a modern kernel.

Retire, not model: the legacy iptables services on the anchor. They duplicate the mesh's filter, which is ADR 0100's ground.

Questions this effort has to answer

1. Software outside the official repositories. The host's package shape installs from the official repositories only. A catalogue module already declares an AUR package (the agent CLI), which no machine could install, and the workstations carry 181 such packages between them.

   	option	for	against
   P1	ADR 0205's pinned vendored archive, per piece	exists	wrong for packages that build native code or kernel modules
   P2	The build machine builds AUR packages into a package repository the mesh serves from its artifact store. The host then installs them as packages, signed	one shape for every package; pinned, reviewed and built once	a repository to serve and a signing key to keep
   P3	An AUR helper on each machine, driven by the host	nothing to serve	builds on every machine, unpinned: the predecessor's git clone in another form

   Starting position: P2, for anything with native code. ADR 0205 stays for plain files such as a theme.

2. Secrets in the account's environment. A predecessor file feeds package-registry and API tokens to the session. ADR 0203 refuses secrets in contributed values, because they travel in the clear. The candidate is ADR 0182's third class: a module's own process writes a mode-0600 file of exports, from secrets the vault hands it over the bus, and the shell and the session source it. This needs its own record.

3. Per-machine sizing and drivers. The swap layout, the GPU, the storage pool and the boot loader are facts of one machine's hardware. They belong in hardware modules, or in settings (issue 168), not in the shared ones.

4. What a module may leave behind. Compose is installed on both servers, unowned. The mesh removes nothing it did not make. The choice is between an operator's one-off removal and a server-side absent declaration.

5. The hosts file. ADR 0199 (decided on an open change, not yet merged) gives /etc/hosts to one module through a seat, node-hosts-file, with an operator region and three verbs. It is not built. Today the private network's foundation writes only its own block, and the rest of each file is a predecessor's stale blocks (both servers) or the operator's development names (both workstations). The candidate module is that seat's first holder. It takes the private-network block as a contribution, and its operator region replaces the hand-kept lines.

6. Mounts. The host has no shape for a filesystem mount; ADR 0091 is about what a container mounts. One workstation mounts a share of the home server over NFS, and a second share over SMB. That second one fails, and its credential sits in clear in /etc/fstab.

   	option	for	against
   M1	A module owns /etc/fstab and other modules contribute lines	one file, as people know it	the file also carries the root and boot filesystems the installer wrote, which no module should rewrite; a slot contribution into a file that can stop a machine booting
   M2	Each client module writes its own systemd mount (and automount) unit, which is the service manager's drop-in for exactly this. The nfs-client or smb-client module declares the unit file and the service shape enables it. /etc/fstab stays the machine's	no new host shape, and no shared file; the unit names its own dependencies (network online, the private network) and an automount does not hang a boot when the server is away; unassigning removes the mount	a mount reads as a unit, not a line
   M3	A new mount shape in the host	the host knows what a mount is	a second way to say what M2 says

   Starting position: M2. The credential an SMB mount needs is a secret, written by the module's own process from the vault, mode 0600, which is question 2's mechanism. The pair is a server module exporting (nfs-server, samba) and a client module mounting. The client requires the share the server provides, so the mount is resolved, not hand-typed.

7. Two DHCP clients on one interface. The home server runs dhcpcd, a DHCP client (no machine runs a DHCP server), next to the network manager, which is its assigned networking module. Both lease an address on the same interface, which therefore carries two LAN addresses. The catalogue's dhcpcd module is assigned nowhere, and this unit is a leftover. The network manager is the machine's one DHCP client, and dhcpcd should be disabled there.

Security findings, independent of any module

1. A filesystem credential in clear text in a workstation's /etc/fstab, for a mount that is failing anyway.
2. A predecessor CI user with passwordless sudo and docker membership on the anchor, and a predecessor sudoers drop-in. The user was removed on 2026-10-04; the drop-in remains.
3. The operator account in the root group on one workstation.

Each is one small change. None waits for a module.