Status: Planned (session start page)
Created: 2026-08-11
Related: Restore Test-Client VPS (original task),
Client VPS Setup,
On-boarding New Clients,
Client VPS Backups,
SIAAS Remaining Tasks
This page is the session entry point. A fresh session starts here, verifies the
current state below, then executes the plan. The two client VPSes are in very
different states, so treat them separately (Part A and Part B).
Per the SIAAS architecture (client_vps_setup + onboarding runbook), each client's
data must live on the client's own VPS, reached only through an SSH reverse tunnel.
| Client VPS | IP | SSH (port 22) | Reverse tunnel | Where the tenant DB lives | Monitoring |
|---|---|---|---|---|---|
| test-client | 77.68.97.101 |
Banner OK, key rejected | DOWN (no connection from this IP) | WRONG place — dsp_clinic_dev lives in VPS2's client_vps_postgres container |
Uptime FAIL (2,525+ since 2026-07-16); tunnel-health + capacity run but only via the VPS2 container |
| test-client-dental | 194.164.18.33 |
Banner OK, key rejected | ACTIVE (194.164.18.33 → VPS1, sshd pid 221832) |
Correct — test_client_dental on the client VPS itself (11 users) |
None at all (no uptime, no tunnel-health, no capacity, no ClientVPS record) |
client_vps_postgres =postgres:15-alpine on VPS2, 172.18.0.1:5435). The client VPS's own DBpractice_app_db per handover doc) is orphaned; its pg-tunnel.service (portdsp_clinic_dev / fh_app_user @172.18.0.1:5435 → resolved alias sector_client_test-client → VPS2 container.App (VPS2) → 172.18.0.1:5436 → ssh (VPS2→VPS1, -L 172.18.0.1:5436:127.0.0.1:5436)
→ VPS1 127.0.0.1:5436 (reverse tunnel, sshd pid 221832)
→ 194.164.18.33: client-postgres (PostgreSQL 15.18)
test-client-dental → test_client_dental /dental_app_user @ 172.18.0.1:5436.check-client-uptime.sh hardcoded to 77.68.97.101 onlycheck-tunnel-health.py hardcoded to ("test-client",) (tenant id 3)collect-capacity.py cron only runs --tenant-slug test-clientClientVPS record for 194.164.18.33127.0.0.1:5437 on VPS1 is a native postgres on VPS1 (pid 420492) — thedev-client tenant DB lives on VPS1 natively. Same "is the DB where it should be"client-credentials.json (test-client) documents DB dsp_clinic_dev / tunnel port5435; handover doc says practice_app_db / 15432 — documentation drift togit.veripath.co.uk registry works; client-postgres:ssh-v1.2.0/root/cloud-init-test-client.yml (old, WireGuard /v1.2.0 non-SSH) and /root/cloud-init-test-client-dental.yml (SSH-variant, portPhase 0 — Prepare artifacts (me, no impact):
cloud-init-test-client.yml (model on the dental one):
docker.io, ufwufw default deny incoming, ufw allow 22/tcp, ufw --force enabledocker login git.veripath.co.uk -u deploy --password-stdin (deploy token)docker run -d --name client_db --restart unless-stopped --network host with:CLIENT_DB=dsp_clinic_dev, CLIENT_USER=fh_app_user,POSTGRES_PASSWORD=<match the tenant's db_password>, TUNNEL_PORT=5435,TUNNEL_HOST=212.227.199.114 (VPS2 — the app host), and a new dedicatedSSH_PRIVATE_KEY (not the shared baked-in deploy key)clientadmin user with the monitoring public key/root/.ssh/authorized_keys:restrict,port-forwarding,permitlisten="127.0.0.1:5435",permitlisten="172.18.0.1:5435"client_postgres_data volume (rollback). Prepare socat unittenant-gateway@5435 pattern) to take over 172.18.0.1:5435 once the containerpg_dump dsp_clinic_dev from VPS2 container → restoredb_password so tenant config needs no change.Phase 1 — Console reinstall (YOU, external): Fasthosts console → reinstall
Ubuntu + paste the Cloud-Init script. Confirm when the IP is back.
Phase 2 — Restore tunnel (me): verify container + reverse tunnel up;
127.0.0.1:5435 and 172.18.0.1:5435 listeners present on VPS2.
Phase 3 — Data migration (short maintenance window): dump → restore → verify row
counts → retire VPS2 client_vps_postgres → start socat → verify
test-client.gp.veripath.co.uk login + data round-trip.
No data migration needed — DB is already correct. Work is monitoring + admin access:
/root/client-credentials-dental.json (db test_client_dental, userdental_app_user, password from cloud-init-test-client-dental.yml, tunnel port5436). Parameterise scripts to accept --credentials.check-tunnel-health.py: accept --tenant-slug and --credentials;test-client-dental (tenant id 4). Currently hardcoded to("test-client",).collect-capacity.py usage: add dental cron entry--tenant-slug test-client-dental --credentials /root/client-credentials-dental.json).check-client-uptime.sh to cover all client VPSesClientVPS record for 194.164.18.33 (status active, name test-client-dental).client-credentials.json, handover doc, wiki pagesclient_vps_setup — add "app on VPS2 → tunnel terminates on VPS2" note;tasks/siaas-remaining item 3 backup alerting if in scope).dev-client DB placement (127.0.0.1:5437 on VPS1) — flag, out of scope.