1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
|
---
title: "Side-quest — migrate radar fetch from cremonde to stan"
date-created: "2026-06-10"
type: "side-quest"
status: "deferred"
author:
- "st33v"
- "claude-opus-4-7"
model:
- "claude-opus-4-7"
tldr: "BOM's anonymous FTP is intended for personal/in-organisation use. Cremonde is a Singapore VPS, which is harder to read as polite. Plan: move the fetch+composite step to stan (local AU pi), have stan push finished APNGs to cremonde over WireGuard, leave cremonde as the public TLS-terminating server. No urgency — only worth doing if BOM complains or if we want to be defensive in advance."
parent-thread: "doc/radar-four-cities-and-nav.md"
parent-doc: "doc/bom-radar-spec.md"
reader-targets:
- "claude-code"
- "st33v"
tags:
- "bom"
- "radar"
- "migration"
- "wireguard"
trigger-conditions:
- "BOM contacts re. FTP usage from cremonde"
- "decide to be defensive ahead of any contact"
- "moving more BOM-fetching jobs onto the same infrastructure"
---
# Migrate radar fetch from cremonde to stan
## Why
`bomsynoptic`'s radar job currently fetches BOM FTP every 6 minutes from cremonde (SG VPS, public IP). BOM's anonymous-FTP terms permit personal / in-organisation use; they explicitly don't promise availability and they reserve the right to throttle abusive clients. A residential AU IP (stan) hitting them is easier to read as polite than an offshore VPS doing the same.
This is **pre-emptive politeness**, not a fix for a known complaint. Don't act unless one of the trigger-conditions above hits.
## Design (agreed in chat)
Split fetch from serve:
- **stan** runs `radarFetch.sh` on the systemd timer. Composites APNGs locally.
- **cremonde** keeps the nginx vhost, TLS cert, certbot renewal, and the static HTML pages. Its `/srv/www/radar/*-loop.apng` files become a passive drop target.
- After each successful composite, stan rsyncs the published APNG to cremonde over WireGuard. Small file (~90 KB), atomic rename at the destination via rsync's default behaviour.
```
radarFetch.sh (stan)
→ /srv/www-staging/radar/idrXXX-loop.apng (local)
→ rsync -a idrXXX-loop.apng cremonde:/srv/www/radar/idrXXX-loop.apng
```
Only the APNGs travel. The HTML pages stay on cremonde permanently — they're stable, no reason to ship them across.
## Changes required
- **`radarFetch.sh`**: optional final `rsync` step, gated on `REMOTE_PUBLISH` env var (so the same script works in solo-host mode and split mode).
- **`setup.sh`**: split into two paths. On cremonde: install nginx, HTML, no radar timer. On stan: install fetch script, timers, no nginx. Could be one script with a `--role=fetch|serve|both` flag, or two scripts.
- **WireGuard**: cremonde's wg interface needs to accept ssh from stan (it presumably already does, since stan is a wg peer). Use a non-interactive key for the rsync user — separate key per direction, document in `doc/`.
- **cremonde-side**: a small `rsync`-only ssh key, restricted with `command="rsync --server …"` in authorized_keys to limit blast radius if stan's key is compromised. Or use a dedicated user.
- **Monitoring**: stan's rsync silently failing leaves stale APNGs on cremonde. Manifest file? Or use the existing pattern — APNG mtime stamped via `Last-Modified` header. A 15-min-stale check would catch it.
## Open questions
- WG topology: is stan already a peer of cremonde, or only client→VPS? If only client→VPS, rsync from stan → cremonde already works. If peer-mesh, fine too. If neither, set it up first.
- Does stan have the disk space + cpu for 4 radars × 6-minute composites? Pi 4 / 5 should be ample. Pi Zero might not.
- BOM's other products (synoptic chart, satellite) — should they migrate too? Synoptic is once-per-6-hours and tiny; less worth migrating. Same logic: only if defensive.
## Out of scope
- Re-architecting to "stan fetches, stan also serves" — defeats the point of having cremonde's public TLS termination.
- Failover (cremonde fetches if stan is down) — defeats the geo-rationale.
- Pushing HTML pages from stan to cremonde — they don't change often; deploy via the existing git-pull-and-setup.sh flow on cremonde.
## Cross-reference
- Original spec: `doc/bom-radar-spec.md` §10 (copyright/terms-of-use flagged for st33v).
- Rollout memoir: `doc/bom-radar-rollout.md`.
- Day-2 memoir: `doc/radar-four-cities-and-nav.md` — final exchange on this thread is the seed of this side-quest.
|
