SLP_Software/slp-modular-cms
1
0
Fork 0
Code Issues Pull Requests Actions Projects Releases Wiki Activity

Fixes deployment docs to reverse-proxy on a separate Pi, not pi-main

Browse Source 
nginx and certbot were designed assuming they lived on the same host
as the app. They don't - a dedicated proxy Pi terminates TLS and
forwards plain HTTP over the LAN. Kestrel now binds 0.0.0.0 instead
of localhost, the whole certbot procedure moved to the proxy Pi's
side, and pi-main gets a firewall rule restricting the backend ports
to just the proxy Pi's address - otherwise binding all interfaces
would let anything on the LAN skip the proxy's TLS entirely.
This commit is contained in:
Sluijsens
2026-07-29 13:29:12 +02:00
parent d1b0d06568
commit 50c1a5106d
4 changed files with 85 additions and 18 deletions
Download Patch File Download Diff File Expand all files Collapse all files
aidlc-docs/features/gitea-deployment-workflow/aidlc-state.md
+21
View File
@@ -123,6 +123,27 @@ and the renamed Identity tables); both `SlpModularCms.Api` and `SlpModularCms.Ap
cleanly against it (`/health` → 200, `MigrateCoreDatabase()` logs "already up to date" on the
second run); full backend suite re-confirmed at 372/372 passed, 0 build errors.
### Reverse Proxy Topology Correction (2026-07-29)
Infrastructure Design's Q10 (`infrastructure-design.md` § 1) established that an nginx reverse
proxy exists — right about *that*, wrong about *where*: it runs on a **separate, dedicated Pi**
("the proxy Pi"), not on pi-main (where this deployment's release directories and systemd units
live). The proxy Pi terminates TLS and forwards plain HTTP to pi-main over the LAN.
**Corrected**:
- `ASPNETCORE_URLS` binds `0.0.0.0`, not `localhost` (`deployment-instructions.md` § 1.5) — the
proxy Pi must reach Kestrel over the network, not loopback
- pi-main runs **no nginx and holds no certificates** for these domains at all — the entire
nginx/certbot procedure in `deployment-instructions.md` § 1.7 happens on the proxy Pi instead
- Added a **firewall requirement on pi-main** (§ 1.7.1 step 4): since Kestrel now listens on all
interfaces, the backend ports must be restricted to just the proxy Pi's address, or the TLS
termination the whole design depends on is trivially bypassable by anything else on the LAN
hitting pi-main directly
Also corrected in `infrastructure-design.md` § 1 (erratum note, history preserved rather than
rewritten). No code changes — this is host topology and Operations documentation only, the
application itself has no opinion on where TLS terminates.
## Scope Decisions (from feature-selection.md)
- **Public website**: documentation/instructions only — where the website build lands in `wwwroot/`, how it coexists with `wwwroot/admin/`, and what a per-website workspace must deliver. The website's own build/deploy workflow stays out of scope (Q4 = A).
- **Environments**: local, test, production only.