Record development recovery evidence

This commit is contained in:
SimpleTest 2026-07-23 22:51:15 +03:00
parent 564897cd3a
commit 1793258f97
2 changed files with 39 additions and 0 deletions

View File

@ -48,6 +48,37 @@ The deployment environment selects topology and database ownership:
There is no Redis dependency. Queues, rate-limit counters, Oban leadership, There is no Redis dependency. Queues, rate-limit counters, Oban leadership,
and durable application state use PostgreSQL. and durable application state use PostgreSQL.
### Development public route after a workstation restart
The current development gateway sends `whoneedhelp.imalto.site` to the
workstation's assigned OpenVPN address `10.8.0.14:4010`. If HTTPS connects to
the gateway but returns no response after a workstation restart, first verify
the local app and tunnel:
```bash
curl --fail --show-error --max-time 10 \
http://127.0.0.1:4010/healthz/ready
ip -brief address show tun0
nmcli --wait 30 connection up openvpn__toha_nobara_pc
curl --fail --show-error --max-time 15 \
https://whoneedhelp.imalto.site/healthz/ready
```
The observed profile requires `remote-cert-tls=server`; do not remove that
server-certificate check. NetworkManager documents that
`connection.autoconnect` is not implemented for VPN profiles and recommends a
base connection's `connection.secondaries` instead:
[NetworkManager connection settings](https://www.networkmanager.dev/docs/api/latest/nm-settings-nmcli.html).
The observed wired base profile currently has no secondary connection, so a
standalone `connection.autoconnect=yes` value on the VPN does not prove that
the development route will return after reboot.
Adding the VPN UUID as a wired/Wi-Fi secondary is a workstation networking
change: this profile currently installs the default route and DNS through the
VPN. Review that whole-host effect and obtain explicit approval before
configuring automatic activation. The manual command above changes no project,
test, production, or gateway configuration.
### Two independent checkouts and one `.env` in each ### Two independent checkouts and one `.env` in each
The server uses exactly these independent Git clones: The server uses exactly these independent Git clones:

View File

@ -48,6 +48,14 @@ edit, branch, or tag was made during this audit.
the database, test, public Git, and Devpost are excluded. An isolated offline the database, test, public Git, and Devpost are excluded. An isolated offline
fixture passed read-only plan, successful apply, and injected-edge-failure fixture passed read-only plan, successful apply, and injected-edge-failure
recovery, including restoration of the original image selection. recovery, including restoration of the original image selection.
- A current development database backup was created at
`output/backups/compose-20260723-194923.dump` with SHA-256
`4202a152751d588c19069eb46a25753901238729b47e6197945afdca20b65c2e`.
The checksum and archive catalog passed, and an isolated restore read 31
public tables and 1,717 rows, observed PostGIS 3.6.4 and all 18 migrations,
then removed the exact temporary database. The live counts remained 7 users,
12 requests, 15 messages, and 18 migrations; local and public DEV readiness
both continued to pass.
- Two web and two worker replicas, PostGIS, Mailpit, Traefik, and the scoped - Two web and two worker replicas, PostGIS, Mailpit, Traefik, and the scoped
Docker socket proxy were running after the audit. Both web replicas and both Docker socket proxy were running after the audit. Both web replicas and both
workers were healthy; public liveness and readiness returned `ok` and workers were healthy; public liveness and readiness returned `ok` and