Issue 169: a machine shares its files, and the mesh does not know #215

Merged
mesh-admin merged 6 commits from issue/169-a-machine-shares-files-and-the-mesh-does-not-know into main 2026-10-01 09:24:12 +00:00
Showing only changes of commit 90b89aa1c9 - Show all commits
@@ -82,6 +82,30 @@ the catalogue beside the modules (a seat definition registered like a manifest),
saying which seats it implements. This is the first role with an obvious second implementation, saying which seats it implements. This is the first role with an obvious second implementation,
which is what makes it the exemplar for that mechanism. which is what makes it the exemplar for that mechanism.
## The consumer's half: the machine mounts it (2026-09-30, third round)
A binding tells a consumer *where* the share is; it does not put the files on its machine. A
consumer on another node needs the export **mounted by the host, at a directory the consumer
declares, before its container starts**, and unmounted when the requirement goes. That is a host
action, not something a container reads from a file.
**Not a client module.** A node-wide `nfs-client` with a list of mounts in its settings is fstab
with a manifest around it: consumers would stop requiring `nfs-share` and couple on a path again,
unassigning a consumer would leave its mount behind, and a person is back in the loop deciding
which machine mounts what — the thing the binding removes.
**A mount is a resource of the consuming module.** The vocabulary (directory, file, package,
container, service, process, network, archive, user, access) has no `mount`. It can be assembled
today — a `package` (nfs-utils), a `file` writing a systemd `.mount` unit with
`What=${bound:nfs-share:at}:${bound:nfs-share:path}` and `Where=${dir:library}`, a `service`
enabling it after the overlay is up — but the honest form is a **`mount` resource kind**: the host
mounts from the binding, refuses a mountpoint the module did not declare (ADR 0091's three ways a
path can be), and unmounts on undeclare. The nfs and samba modules are then the *server* side only.
**Identity crosses the wire.** `sec=sys` NFS trusts the client's uid, so a consumer must run as the
library's owner on the server (ace: `media`, 1001:2000) — hq 153's `${access:<id>:uid}` proposal
extended to a mount, `${mount:<id>:uid}`, read from the mounted tree.
## Open questions for the decision ## Open questions for the decision
- Whether an NFS export over the overlay is an `internal` reach of the same endpoint or a second - Whether an NFS export over the overlay is an `internal` reach of the same endpoint or a second