state: the composer replaced the placeholder; open the public ingress question

PROCESS.md section 8 requires host changes to reach STAGING-STATE.md before a session ends. mechcomp-placeholder.service was disabled and stopped on 2026-09-11 and mechcomp.service took 10.20.0.10:8770 in its place. nginx on CT 101 needed no change because the real service took the address the placeholder occupied. The placeholder unit stays on disk, disabled, as the rollback.

Section 5 items closed: mechcomp.service, and replacing the placeholder. Application runtime acceptance is marked partial rather than done, because no acceptance criteria have been written for the composer and it is not reachable from outside.

WORK-ORDER-004 publishes the composer at dev.mechcomp.kane-il.us. The srv-b half needs no change, verified: forwarding on, FORWARD policy ACCEPT, a direct route on vmbr1, and none of the three FORWARD rules matches hub initiated inbound traffic. The single gate is AllowedIPs on the hub peer entry for srv-b, because WireGuard drops by cryptokey routing before consulting any routing table.

Design decision recorded: the public name terminates on the hub and proxies to CT 100 directly rather than through CT 101. Routing it through CT 101 would make the public path depend on a locally signed leaf that expires 2028-11-18 with nothing renewing it. The tunnel already provides the encryption that hop would add. CT 101 keeps serving the internal name.

Section 4 not now decision on the hub route is reopened. It was correct while there was no application to reach. The consequence of leaving it closed is that the operator cannot see the application at all.
This commit is contained in:
2026-09-11 06:59:53 -05:00
parent 14514b0bac
commit a8081e17dc
2 changed files with 261 additions and 4 deletions
+35 -4
View File
@@ -4,7 +4,7 @@ Live state of the Mechanical Compiler staging instance on `srv-b`.
| | |
|---|---|
| Updated | 2026-08-18, after repository seeding and container standardisation |
| Updated | 2026-09-11, after the composer replaced the placeholder |
| Instance | Staging / development |
| Specification | `ENVIRONMENT.md` revision 5 |
| Failure log | `FAILURES.md` |
@@ -238,6 +238,19 @@ Restart=on-failure, hardening set applied, enabled at multi-user.target
Exists solely to prove the proxy chain independently of the application. It is
removed when the real service arrives.
**Retired 2026-09-11.** `mechcomp-placeholder.service` is disabled and stopped.
`mechcomp.service` holds `10.20.0.10:8770` in its place, running
`/var/www/mechcomp/venv/bin/python -m mechcomp.web` as `mechcomp`, reading
`/etc/mechcomp/mechcomp.env` for its binding. nginx on CT 101 required no
change: the real service took the address the placeholder occupied.
The placeholder unit file is left on disk, disabled. It is the rollback:
`systemctl disable --now mechcomp.service` then
`systemctl enable --now mechcomp-placeholder.service`.
Proven end to end from `srv-b` at commit `14514b0`: `HTTPS 200` for the page
and a real JSON build payload through the TLS chain.
### Rollback copies on disk
```
@@ -452,6 +465,19 @@ so SSH adds no privilege — but **every path to a container runs through
Direct WireGuard-side access to the catalogue would be a route addition for
`10.20.0.0/24` on the hub. Not now.
**Reopened 2026-09-11 by `WORK-ORDER-004`.** That decision was correct while
there was no application to reach. There is one now, and the consequence of
the decision is that CIVICVS cannot see it: `mechanical-compiler.dev.infra`
resolves only on `srv-b`, CT 100 and CT 101, and `10.20.0.0/24` sits behind a
portless bridge with LAN traffic dropped.
The `srv-b` half needs no change, verified 2026-09-11: `ip_forward=1`,
`FORWARD` policy `ACCEPT`, a direct route on `vmbr1`, and none of the three
`FORWARD` rules matches hub-initiated inbound traffic. The single gate is
`AllowedIPs` on the hub's peer entry for `srv-b`, currently `10.110.0.0/22` --
WireGuard drops by cryptokey routing before consulting any routing table, so a
route without that entry does nothing.
No DHCP anywhere. Two containers with fixed addresses on a portless bridge is the
entire address space.
@@ -477,11 +503,15 @@ None of the following can be honestly completed, and none may be fabricated by
provisioning:
- [x] ~~Dependency install from committed manifests~~ — done 2026-08-18
- [ ] `mechcomp.service`, `mechcomp-worker.service`
- [x] ~~`mechcomp.service`~~ — done 2026-09-11, `deploy/mechcomp.service`
- [ ] `mechcomp-worker.service` — no worker exists yet; `src/mechcomp/worker/`
is still a stub
- [ ] Reference toolchain image `mechcomp/reference-toolchain:8.0.0`
- [ ] Fixture reproduction against `ddd0f154...`
- [ ] Application-runtime acceptance
- [ ] Replacing the placeholder with the real service
- [ ] Application-runtime acceptance — partial. The composer serves and is
reachable through CT 101; no acceptance criteria have been written for
it, and it is not reachable from outside (see section 6, question 4)
- [x] ~~Replacing the placeholder with the real service~~ — done 2026-09-11
**Applied 2026-08-18:** `venv/` is in `.gitignore`, along with `.cache/`,
`.local/`, `.ssh/`, `.gitconfig` and `.lesshst` — the service user's home is
@@ -499,6 +529,7 @@ The Shapely port gates all of the above.
| 1 | Should `wg-pk` `mynetworks` narrow to explicit hosts? | F-025 estate half |
| 2 | What is the backup strategy? | all backup work |
| 3 | Where is the 3+ TB USB disk attached? | gold redundancy step |
| 4 | Public ingress for the composer at `dev.mechcomp.kane-il.us` | `WORK-ORDER-004`; anyone outside `srv-b` seeing the application at all |
All three need CIVICVS.