129 lines
8.0 KiB
Markdown
129 lines
8.0 KiB
Markdown
# 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.
|