left4me/docs/superpowers/specs/2026-05-15-handoff-deployment-responsibility.md

Handoff — brainstorm deployment responsibility (left4me vs. ckn-bw)

Status

Resolved 2026-05-15 — the brainstorming session happened and produced docs/superpowers/specs/2026-05-15-deployment-responsibility-design.md. Read that for the answer. The runtime-state relocation (2026-05-15-runtime-state-relocation-design.md) shipped as a prereq; the design lands hardening drop-ins, sudoers, sysctl, and helpers as symlinks into the (now root-owned) /opt/left4me/src/deploy/... checkout, while base unit bodies and per-host shape stay bw-managed.

This doc is kept as the historical framing — the question that opened the brainstorm, the operator's leaning, and the candidate options that got evaluated. The actual landed answer is the design doc.

The question

How should left4me and ckn-bw split responsibility for the host's deployment?

Not a fresh question. The original deployment design at docs/superpowers/specs/2026-05-06-left4me-deployment-design.md already laid out the canonical shape: deploy/files/ in the left4me repo mirrors target filesystem paths for root-owned deployment artifacts (systemd units, sudoers, helpers, env templates); "production config management can own both env files directly" (line 91). The implicit model: left4me defines the deployment artifacts; ckn-bw integrates them onto the host. That spec also defined a self-contained deploy/deploy-test-server.sh so the deployment could be exercised without ckn-bw at all.

Over time, more and more of those artifacts migrated into ckn-bw's bundles/left4me/ — specifically:

• systemd unit definitions are now emitted by the systemd/units reactor in ~/Projekte/ckn-bw/bundles/left4me/metadata.py (the hardening refactor we just landed reinforced this).
• sysctl options ended up in ckn-bw bundles/left4me/metadata.py defaults (just landed too).
• sudoers exists in both repos (left4me deploy/files/.../sudoers.d/left4me
  • ckn-bw verbatim mirror).
• Privileged helpers moved BACK to left4me as part of deploy-dir-rethink (commit 5284e28) — scripts/{libexec,sbin}/. Pattern works: left4me defines, ckn-bw deploys via install_left4me_scripts.

So the trajectory has been mixed: helpers re-converged on left4me (good, matches 2026-05-06); systemd units + sysctl drifted into ckn-bw (away from 2026-05-06). The brainstorm reconciles this.

The question: should we return to the 2026-05-06 model end-to-end — every deployment artifact lives in left4me's deploy/files/, ckn-bw becomes a thin integrator — or is the current mixed shape the right answer for some artifact classes?

Operator's leaning

Security-related artifacts belong in the left4me repo, owned by the project; ckn-bw is responsible for integrating them into the host (deploying them to the right paths, restarting affected units, etc.) but doesn't author them.

Concretely the operator's preference (from session 2026-05-15): "security-related stuff should be bundled in this repo and ckn-bw is responsible for integrating it into the server."

Why we're doing this

Background from the hardening-refactor session (docs/superpowers/specs/2026-05-15-hardening-refactor-design.md, "Approach" section). We considered two shapes for the hardening landing:

• A — hardening directives inline in ckn-bw's systemd/units reactor (the path we took)
• B — hardening as drop-in .conf files living in left4me's deploy/files/etc/systemd/system/<unit>.d/, ckn-bw deploys them (consistent with 2026-05-06's deploy/files/ model)

We picked A for the hardening refactor because B implied a broader configmgmt responsibility reshape that deserved its own session. That session is this one.

The motivating arguments for B (this brainstorming session evaluates them seriously):

1. Hardening is application knowledge. Knowing srcds is i386, that MemoryDenyWriteExecute=true breaks Source's text relocations, that web's sudo path is incompatible with PrivateUsers=true — all of this is left4me's domain, not ckn-bw's. ckn-bw shouldn't need to understand the threat model.
2. Test-artifact = production-artifact. The Test 7 drop-in from the hardening test plan literally is the file we'd want deployed. With B, there's no translation step.
3. Repo self-containment for security review. A reviewer of left4me sees the threat model in code form without needing to read the configmgmt repo.
4. Easier coordination with the build-overlay-unit refactor (queued). That unit's hardening profile can ship in its own drop-in inline with the unit template.

The counter-argument:

• Coupling cost. A change to a directive may require redeploying via ckn-bw, which means a cross-repo coordination cycle (edit left4me → commit → push → ckn-bw bw apply). Today the same is true (edit ckn-bw → push → apply); just the which repo changes.

What "security-related" likely means

Enumerate during the brainstorm. Initial candidates:

• systemd unit hardening directives — currently in ckn-bw bundles/left4me/metadata.py HARDENING_COMMON / HARDENING_SERVER / HARDENING_WEB. Strong candidate for left4me.
• sysctl drop-ins — currently kernel.yama.ptrace_scope=2 in ckn-bw's left4me bundle defaults (sysctl/kernel/yama/ptrace_scope). Strong candidate for left4me.
• sudoers — already in left4me/deploy/files/etc/sudoers.d/left4me
  • a verbatim mirror in ckn-bw/bundles/left4me/files/etc/sudoers.d/left4me. Already mostly left4me-owned; redundancy worth resolving.
• Privileged helper scripts — already in left4me/scripts/{libexec,sbin}/, ckn-bw deploys them via install_left4me_scripts. Already left4me-owned. The pattern works.
• systemd unit BASE definitions (User=, ExecStart=, Restart=, resource limits) — currently in ckn-bw's reactor. Open question: is this application knowledge or infrastructure knowledge? They depend on the application's binary paths, env files, restart semantics — all application knowledge. Probably also belongs to left4me.
• AppArmor profiles (if we add them later — deferred from the defenses survey). Application knowledge.
• /etc/left4me/host.env / web.env templating — ckn-bw owns these today because they're templated via mako from node metadata (per-host overrides). Probably stays in ckn-bw.
• User/group creation — kernel-side infrastructure, no application knowledge needed. Stays in ckn-bw.
• Package installation (apt). Stays in ckn-bw.
• Firewall rules — depend on per-instance port ranges (LEFT4ME_PORT_RANGE_*); could be either. Worth discussing.
• Nginx vhost — same: depends on app-specific routes.

Mechanism: how does ckn-bw "integrate"?

Brainstorm the deploy mechanism. Candidates (already partially sketched in the hardening-refactor design doc's earlier draft, before it was reverted to the inline-in-reactor approach):

• Symlinks. ckn-bw creates symlinks like /etc/systemd/system/left4me-server@.service.d/10-hardening.conf → /opt/left4me/src/deploy/files/etc/systemd/system/.../10-hardening.conf. Editing the file in the repo + systemctl daemon-reload picks it up. Cleanest for "ckn-bw doesn't author."
• File copy via files entries. ckn-bw files = {...} reads from /opt/left4me/src/deploy/files/... (post-git_deploy) and copies to the target. Standard idiom. Two-place state.
• Glob-walker action. A small ckn-bw action walks deploy/files/ tree and mirrors paths to root.
• Bundle inclusion / left4me-as-bundle. Left4me's deploy/ becomes its own bundlewrap bundle that ckn-bw imports. Strongest decoupling; requires bundlewrap bundle conventions.

Each has different implications for: triggers (which units restart when which files change), drift detection, rollback semantics.

Migration / coexistence path

Brainstorm: how do we get from the current state to the new state without breaking things?

• Inventory: every artifact ckn-bw currently emits/ships for left4me (the systemd/units reactor entries, sysctl defaults, sudoers mirror, file deploy actions, etc.).
• For each: stays, moves, or split (some in each).
• Mechanism rollout: pick one (symlinks vs. file copy vs. ...) and apply it consistently.
• Test-driven: pick one artifact as the canary (probably the sysctl drop-in — smallest), validate the mechanism end-to-end, then migrate the others.

Key sub-questions for the brainstorm

1. Is the unit's BASE definition application knowledge? If yes, ckn-bw's systemd/units reactor shrinks dramatically — to maybe one line per unit ("ckn-bw, deploy this file as a unit"). If no, we have a more delicate split.
2. What about the user/group definitions? Infrastructure-side today. But the application defines that left4me (uid 980) exists; ckn-bw just creates it. Could move.
3. Per-host configuration (gunicorn worker count, port ranges, CPU pinning): these are per-host overrides ckn-bw computes from node metadata. Stays in ckn-bw (or whatever owns deployment-time parameterization).
4. Test infrastructure: deploy/tests/test_deploy_artifacts.py asserts left4me's reference units match the deployed form. If left4me starts owning the deployed form, those tests get stronger (no longer "reference vs. live" drift; the file in deploy/files/ is the live form).
5. Drift / observability: how do we know the deployed state matches the repo? Today bw apply + git diff is the source of truth. Same applies; mechanism details vary.
6. Rollback semantics: removing a drop-in is one rm away; the base unit is preserved. Same applies to reverting the left4me-side commit and re-applying.

Prereqs (must land before this brainstorming session)

• uid-collapse refactor — queued in docs/superpowers/plans/2026-05-15-uid-collapse.md. Settles the user model first so the deployment-responsibility brainstorm doesn't have to juggle a moving user definition.

Out of scope for the brainstorm

• The hardening composition itself (already settled, deployed, verified).
• The build-overlay-unit template unit refactor (docs/superpowers/specs/2026-05-15-build-overlay-unit-design.md) — both this brainstorm and the build-overlay-unit refactor benefit from settling responsibility first. Sequencing TBD; the brainstorm should consider whether to land before or after build-overlay-unit.
• The application code itself (l4d2web, l4d2host) — that's always been left4me-owned.

Pointers

• Original deployment design (the model to revisit): docs/superpowers/specs/2026-05-06-left4me-deployment-design.md
• Hardening refactor design (motivation; the deferred reshape): docs/superpowers/specs/2026-05-15-hardening-refactor-design.md
• Hardening refactor plan (what got landed): docs/superpowers/plans/2026-05-15-hardening-refactor.md
• Defenses survey (mentions AppArmor, deferred): docs/superpowers/specs/2026-05-15-hardening-defenses-survey.md
• Test plan + executed results: docs/superpowers/specs/2026-05-15-hardening-test-plan.md
• uid-collapse plan (prereq): docs/superpowers/plans/2026-05-15-uid-collapse.md
• deploy-dir-rethink (recent reshape that moved scripts into left4me; background on the current deploy/ tree): docs/superpowers/plans/2026-05-15-deploy-dir-rethink.md (or 2026-05-15-deploy-dir-rethink-design.md)
• Live ckn-bw bundle (the thing being rethought): ~/Projekte/ckn-bw/bundles/left4me/