6 Commits

Include renames

Author	SHA1	Message	Date
jochen	37947ca4ee	Raise genesis on the bus the mesh runs on, from one bundle (hq issue 146, ADR 0331) ... The installer could not raise a first node: the old bundle's control plane had no MESH_BUS_NATS and crash-looped, and the NATS bundle was refused because rootsecrets only knew the previous broker's guest:guest@ template. One bundle now, the NATS one. rootsecrets makes the controller's bus account and puts it in both placeholders (the address and the bcrypt hash in the carried user list), kept with its hash so a re-run writes the same bundle. Preflight refuses a template naming no bus connection it knows, naming the placeholder, instead of waiting out the verify step. The broker step adopts the bus as the nats module and refuses, by name, a catalogue without it or a server that is not the foundation's container.	2026-10-12 22:49:49 +02:00
jschoubben	3964d9da0a	Take the foundation's ports as genesis inputs, check them free, and hand them to the controller as the node's settings (hq ADR 0100)	2026-09-22 17:28:36 +02:00
jschoubben	70d0f36896	Installer review: secrets are staged privately, and a bundle is 0600 whether or not it existed ... From review: the store and broker passwords genesis makes were carried into the controller through a world-readable file in /tmp, a bundle left at 0644 by an earlier installer kept that mode while now holding them, a mesh raised by the old installer would have been handed new passwords its servers do not have, and the broker-admin action's marker did not depend on the value. Secrets now stage in a 0700 directory owned by the controller's account; the bundle is chmod'd; an existing store or broker volume with no credential file is refused by name; the marker holds the password's fingerprint. Also: one install path for the store, broker and vault, no error-string matching for the operator key, and no unreachable fallback for the superuser.	2026-09-21 01:26:35 +02:00
jschoubben	ee0c8b856e	Genesis makes the root secrets, the operator key, and installs the vault ... The template raises the store with the password 'bootstrap' and the broker with its image's default administrator, and the installer carried both into the mesh as accepted secrets — permanent, and not secret (novox/hq issue 071). Now the installer makes both credentials, once, at the paths the postgres and lavinmq modules declare as their own secrets, rewrites the produced bundle to use them (the store reads its password from a file; the broker's default account is given the new password by an action before anything dials it), and writes the bundle at 0600 since it now carries them. Before the first secret is accepted it makes the operator's sealing key beside the bundle and gives the mesh the public half, so everything minted from there is sealed to it too (ADR 0085, amended). Phase three adopts the broker as the lavinmq module beside the store and installs mesh-vault as a foundation module; the run ends by writing the operator-sealed export beside the key.	2026-09-21 00:12:55 +02:00
jschoubben	1232031fb9	Correct store phrasing — a module gets a database only if it asks ... Not "every module's database"; a module requests one via requires postgres-database. The one server holds the controller's contexts and the database of each module that asks for one. Claude-Session: https://claude.ai/code/session_01D6qtiYU3P9jk3pnAXyAFyx	2026-09-16 21:20:00 +02:00
jschoubben	9109a8c178	Phase 3.1: adopt the foundation store as the postgres module ... InstallStore turns the mesh-store the foundation raised at genesis into the postgres module, adopted in place: it verifies the module's server names the same container and the same image the foundation is running (fail-fast on a drift, rather than tearing down the mesh's store), then registers, builds the provisioner, and carries the superuser in via secret accept — the mesh cannot invent a credential that already made the databases (mirroring the control plane's store-connection delivery, control.go). pinImage generalised to any module for reuse. Issue 051 (WBS 3.1). One server holds the controller's contexts and every module's database. Claude-Session: https://claude.ai/code/session_01D6qtiYU3P9jk3pnAXyAFyx	2026-09-16 21:04:06 +02:00