Modron: migrate deployment to deploy-rs with a hardened node profile #30

Closed

opened 2026-08-06 05:11:27 +00:00 by agent.odin · 1 comment

agent.odin commented

2026-08-06 05:11:27 +00:00

Collaborator

Stable ID: FM-MODRON-DEPLOY
Source: owner directive 2026-08-06; deploy law (ratified design session, not yet on wiki); outputs/hosts/modron/configuration.nix
Source status: new user story, owner-requested
Disposition: open — deploy-rs input absent, hardening scope undefined
Blocked by: #14 (FM-AUDIT-06 — sudo posture decision defines what "hardened" means)

Problem

Modron deploys via nixos-rebuild --remote --use-substitutes — the fleet's
fallback path (justfile nixos-rebuild private recipe, lines 160–200).
The deploy law says stateless hosts go to deploy-rs (magic rollback),
stateful to nixops4, nixos-rebuild as fallback only.

Modron is stateless: auth proxy (CLIProxyAPI container + selector), secrets
sops-rendered at activation, no database, no persistent stateful service.
By the deploy law it belongs on deploy-rs, not the fallback.

The cost of staying on nixos-rebuild:

No rollback safety. A bad activation (eval passes, runtime fails) leaves
modron broken until a human re-deploys. deploy-rs magic rollback auto-reverts
on health-check failure.
No deploy profile. Modron's hardening is ad-hoc:
security.sudo.wheelNeedsPassword = false (line 55 — same blanket NOPASSWD
as every server, #14). A deploy-rs node profile is the natural home for
fleet-standard hardening applied as a group.
No deployment group. Modron deploys as an island. Other stateless servers
(bifrost's edge, heimdallr's identity, tamiel's monitoring) have the same
shape and could share a hardened profile.

Scope

deploy-rs input. Add deploy-rs (github:serokell/deploy-rs,
inputs.nixpkgs.follows = "nixpkgs"). Define deploy.nodes.modron in flake
outputs — via a flake-parts module, consistent with the import-tree pattern.
Hardened node profile. A reusable deploy-rs profile applying fleet-standard
hardening:
- policies/sudo (currently odin-only — #14) or its resolved successor
- Firewall scoping (modron already does mesh-only — line 134; keep it)
- systemd unit hardening where applicable
- The profile is a group, not modron-specific: other stateless servers
  can select it.
justfile integration. A deploy verb invoking deploy-rs for the target
host, replacing nixos-rebuild --remote for stateless hosts.
Health check. deploy-rs magic rollback needs a probe confirming modron is
actually serving post-activation — the selector or auth-manager health
endpoint.

Non-scope

bifrost and odin stay HITL-only (deploy law). This US does not change
their deploy path.
Stateful hosts (if any emerge) go to nixops4, not here.
Selector/headroom/ingress work (plans/modron-auth-manager-ingress.md) is
separate — it changes what modron serves, not how it deploys.

Open questions for the owner

Pilot or fleet-wide? Does deploy-rs become the mechanism for all
stateless servers, or is modron a one-off? The deploy law's
"stateless→deploy-rs" reads as a rule, suggesting fleet-wide.
What defines "hardened"? #14 is unresolved. Is "hardened" just the sudo
policy, or a broader set (kernel, systemd, network)?
vpsAdminOS container. Modron is a vpsFree container
(vpsadminos.nixosModules.containerUnstable). deploy-rs activates over SSH —
does the container's activation path differ from bare NixOS? Needs a live
check before relying on it.
Substitution. #2 (FM-SERVER-SUBSTITUTERS) means closures built from
flake inputs can't substitute on the target. Same class — does deploy-rs's
equivalent handle this, or does #2 need to land first?
Migration plan interaction. deploy-rs is a deploy-mechanism change, not
an aspect migration. Is it independent of the Phase 0→1→3→2 sequence, or
blocked behind Phase 3 (architecture validation)?

Acceptance

deploy-rs is a flake input; deploy.nodes.modron evaluates
just deploy modron activates via deploy-rs, not nixos-rebuild
Magic rollback fires on health-check failure (demonstrated — bad config
auto-reverts)
Hardened profile applied: sudo policy per #14's resolution, firewall
scoped to mesh interface
just check green
Profile is reusable — a second stateless host can select it without
modron-specific code

Provenance

Owner request 2026-08-06. Deploy law from ratified design session (not yet
recorded on wiki — belongs with #22's build queue or its own wiki page).
Modron host config at outputs/hosts/modron/configuration.nix.

Deploy law (verbatim from session): "stateless→deploy-rs (magic rollback),
stateful→nixops4 (spike-gated, never deploy path), fallback=nixos-rebuild;
colmena struck. HITL-only bifrost+odin."

Stable ID: FM-MODRON-DEPLOY Source: owner directive 2026-08-06; deploy law (ratified design session, not yet on wiki); `outputs/hosts/modron/configuration.nix` Source status: new user story, owner-requested Disposition: open — deploy-rs input absent, hardening scope undefined Blocked by: #14 (FM-AUDIT-06 — sudo posture decision defines what "hardened" means) ## Problem Modron deploys via `nixos-rebuild --remote --use-substitutes` — the fleet's **fallback** path (justfile `nixos-rebuild` private recipe, lines 160–200). The deploy law says stateless hosts go to **deploy-rs** (magic rollback), stateful to nixops4, nixos-rebuild as fallback only. Modron is stateless: auth proxy (CLIProxyAPI container + selector), secrets sops-rendered at activation, no database, no persistent stateful service. By the deploy law it belongs on deploy-rs, not the fallback. The cost of staying on nixos-rebuild: - **No rollback safety.** A bad activation (eval passes, runtime fails) leaves modron broken until a human re-deploys. deploy-rs magic rollback auto-reverts on health-check failure. - **No deploy profile.** Modron's hardening is ad-hoc: `security.sudo.wheelNeedsPassword = false` (line 55 — same blanket NOPASSWD as every server, #14). A deploy-rs node profile is the natural home for fleet-standard hardening applied as a **group**. - **No deployment group.** Modron deploys as an island. Other stateless servers (bifrost's edge, heimdallr's identity, tamiel's monitoring) have the same shape and could share a hardened profile. ## Scope 1. **deploy-rs input.** Add `deploy-rs` (`github:serokell/deploy-rs`, `inputs.nixpkgs.follows = "nixpkgs"`). Define `deploy.nodes.modron` in flake outputs — via a flake-parts module, consistent with the import-tree pattern. 2. **Hardened node profile.** A reusable deploy-rs profile applying fleet-standard hardening: - `policies/sudo` (currently odin-only — #14) or its resolved successor - Firewall scoping (modron already does mesh-only — line 134; keep it) - systemd unit hardening where applicable - The profile is a **group**, not modron-specific: other stateless servers can select it. 3. **justfile integration.** A `deploy` verb invoking deploy-rs for the target host, replacing `nixos-rebuild --remote` for stateless hosts. 4. **Health check.** deploy-rs magic rollback needs a probe confirming modron is actually serving post-activation — the selector or auth-manager health endpoint. ## Non-scope - **bifrost and odin** stay HITL-only (deploy law). This US does not change their deploy path. - **Stateful hosts** (if any emerge) go to nixops4, not here. - **Selector/headroom/ingress work** (plans/modron-auth-manager-ingress.md) is separate — it changes *what* modron serves, not *how* it deploys. ## Open questions for the owner 1. **Pilot or fleet-wide?** Does deploy-rs become the mechanism for all stateless servers, or is modron a one-off? The deploy law's "stateless→deploy-rs" reads as a rule, suggesting fleet-wide. 2. **What defines "hardened"?** #14 is unresolved. Is "hardened" just the sudo policy, or a broader set (kernel, systemd, network)? 3. **vpsAdminOS container.** Modron is a vpsFree container (`vpsadminos.nixosModules.containerUnstable`). deploy-rs activates over SSH — does the container's activation path differ from bare NixOS? Needs a live check before relying on it. 4. **Substitution.** #2 (FM-SERVER-SUBSTITUTERS) means closures built from flake inputs can't substitute on the target. Same class — does deploy-rs's equivalent handle this, or does #2 need to land first? 5. **Migration plan interaction.** deploy-rs is a deploy-mechanism change, not an aspect migration. Is it independent of the Phase 0→1→3→2 sequence, or blocked behind Phase 3 (architecture validation)? ## Acceptance - [ ] `deploy-rs` is a flake input; `deploy.nodes.modron` evaluates - [ ] `just deploy modron` activates via deploy-rs, not nixos-rebuild - [ ] Magic rollback fires on health-check failure (demonstrated — bad config auto-reverts) - [ ] Hardened profile applied: sudo policy per #14's resolution, firewall scoped to mesh interface - [ ] `just check` green - [ ] Profile is reusable — a second stateless host can select it without modron-specific code ## Provenance Owner request 2026-08-06. Deploy law from ratified design session (not yet recorded on wiki — belongs with #22's build queue or its own wiki page). Modron host config at `outputs/hosts/modron/configuration.nix`. Deploy law (verbatim from session): *"stateless→deploy-rs (magic rollback), stateful→nixops4 (spike-gated, never deploy path), fallback=nixos-rebuild; colmena struck. HITL-only bifrost+odin."*

agent.odin closed this issue

2026-08-06 05:22:03 +00:00

agent.odin commented

2026-08-06 05:22:29 +00:00

Author

Collaborator

Mistaken architecture read — this was filed against the wrong repo with the wrong shape.

The actual model: modron is an independent flake (lar.ad/modron) that becomes a self-deployable building group. flake-ops provisions a staging VPS for it; flaky-mesh stops owning the host.

This issue treated modron as a flaky-mesh host migrating internally to deploy-rs. Closed as wrong. Corrected issue(s) filed on the right repos.

Mistaken architecture read — this was filed against the wrong repo with the wrong shape. The actual model: **modron is an independent flake (`lar.ad/modron`)** that becomes a self-deployable building group. flake-ops provisions a staging VPS for it; flaky-mesh stops owning the host. This issue treated modron as a flaky-mesh host migrating internally to deploy-rs. Closed as wrong. Corrected issue(s) filed on the right repos.

Commenting is not possible because the repository is archived.