jensandClaude Sonnet 5
d1902bb277
First item off SYNC-PLAN.md's build order. Full migration, not sync: stopped vlda-01's Gitea container, copied its entire data volume (SQLite DB, repos, LFS, SSH host keys - ~4GB) directly via a piped ssh tar stream, brought it up on alpha as a permanent container on the same web/cloud/portainer pattern (127.0.0.1-only, Apache reverse proxy, certbot). Remapped file ownership from the source's uid 1000 (which collides with vmail on alpha) to a dedicated 1010:1010. Fixed Gitea generating http:// clone URLs by adding X-Forwarded-Proto, same fix cloud.jayfield.org already needed. Verified end-to-end: all repos present via the API, a real git clone reproduces identical history, and this repo's own origin now points at git.jayfield.org with working push access. vlda-01's copy left stopped as a cold backup, not decommissioned. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
103 lines
5.0 KiB
Markdown
103 lines
5.0 KiB
Markdown
# alpha.jayfield.org — Intranet Sync Plan (vlda-01 → alpha)
|
|
|
|
**Status: planning only, nothing implemented yet.** This is a point-in-time
|
|
plan for later reference, not a live inventory (`README.md` is the live
|
|
inventory) and not a build runbook (`SETUP.md` is that). Update this file
|
|
as decisions get made and pieces get built; move finished work into
|
|
`README.md` once it's live, the way the KeePass/Nextcloud migration did.
|
|
|
|
## Problem
|
|
|
|
`vlda-01` (home intranet server, behind a home LAN, not 24/7 online) hosts
|
|
four things the household wants reliably available: plain files, Gitea,
|
|
Jellyfin, and a Dogecoin node/wallet used for daily transaction catchup.
|
|
Goal: use `alpha.jayfield.org` (public, 24/7, already running Docker +
|
|
Nextcloud) as the always-available side, without reproducing the failure
|
|
mode that got the old setup removed.
|
|
|
|
**Why not just revive the old WireGuard tunnel + CIFS mount** (see
|
|
`README.md`'s "Previously resolved" history — `alpha_at_moon` tunnel +
|
|
`192.168.22.0/24` CIFS mount, purged 2026-07-19, configs backed up to
|
|
`/root/removed-configs-backup/` if ever needed as a reference): that setup
|
|
required `vlda-01` to be reachable *at the moment alpha wanted the data* —
|
|
a live mount. That's structurally incompatible with "not 24/7 online." Each
|
|
service below instead either pulls data to alpha ahead of time or migrates
|
|
outright, so alpha's availability stops depending on vlda-01's.
|
|
|
|
## Per-service plan
|
|
|
|
### 1. Files → Syncthing
|
|
|
|
- Syncthing container on alpha, data lands at `/srv/intranet-data/<folder>`
|
|
(host-inspectable, matching the `/srv/nextcloud/data` pattern). Admin GUI
|
|
bound to `127.0.0.1:8384`, reverse-proxied through Apache like
|
|
Portainer/Nextcloud — never expose the setup UI directly.
|
|
- Syncthing client on `vlda-01` dials **out** to alpha — no inbound port
|
|
forwarding needed at home, unlike the old tunnel. Catches up automatically
|
|
whenever vlda-01 gets power + internet.
|
|
- Direction: start **send-only from vlda-01 → receive-only on alpha**
|
|
(vlda-01 stays authoritative, alpha is a live mirror). Revisit bidirectional
|
|
later once trusted.
|
|
- Firewall: open `22000/tcp` + `21027/udp` on alpha for Syncthing.
|
|
- Expose via Nextcloud: enable the built-in `files_external` app, mount
|
|
`/srv/intranet-data/<folder>` as local external storage — same web UI
|
|
(`cloud.jayfield.org`) already used for the KeePass vaults.
|
|
|
|
**Status: not started.**
|
|
|
|
### 2. Gitea → full migration, not sync
|
|
|
|
**Status: done, 2026-07-26 — see `README.md`'s "Gitea" section for the live
|
|
setup.** vlda-01's copy left stopped as a cold backup, not decommissioned.
|
|
|
|
### 3. Jellyfin → scoping question, not yet planned
|
|
|
|
Media libraries are often hundreds of GB to multiple TB, and local hardware
|
|
transcoding at home may not have an equivalent on the VPS. Before sketching
|
|
an approach, need:
|
|
|
|
- Approximate library size.
|
|
- Is the actual goal *remote* streaming (away from home), or is Jellyfin
|
|
only ever watched on the home LAN? If the latter, migrating buys nothing —
|
|
Jellyfin only needs to be up when someone's actually watching, which is
|
|
whenever vlda-01 would be on anyway. If remote access is wanted, next step
|
|
is sizing alpha's disk/bandwidth budget for it.
|
|
|
|
**Status: blocked on the above — no plan yet.**
|
|
|
|
### 4. Dogecoin node/wallet → security-conscious split, needs sign-off
|
|
|
|
**Do not migrate the wallet wholesale without explicit confirmation.** Per
|
|
the attacker report (`SendUserFile`'d 2026-07-19), this host takes on the
|
|
order of 10,000 automated SSH/scan attempts a month. Putting spending keys
|
|
on the same public, constantly-probed box is a materially different risk
|
|
than at home.
|
|
|
|
Recommended design:
|
|
- Run `dogecoind` on alpha as a Docker container with **`disablewallet=1`**
|
|
— blockchain sync only, no private keys, no funds at risk. Stays
|
|
permanently caught up with the network regardless of vlda-01's uptime.
|
|
- Keep the actual wallet (`wallet.dat`, spending keys) only on vlda-01.
|
|
Point vlda-01's `dogecoin-cli`/GUI at alpha's node as its backend
|
|
(`-connect=`), with RPC reachable **only** over an authenticated tunnel
|
|
(SSH-forwarded or WireGuard) — never bind RPC to a public interface; an
|
|
open Dogecoin RPC port is exactly the kind of thing scanners probe for.
|
|
- Result: "daily transaction catchup" becomes near-instant once vlda-01
|
|
turns on, since the chain is already synced — without private keys ever
|
|
touching the internet-facing box.
|
|
|
|
**Open question, needs the user's explicit answer before implementing**:
|
|
go with the wallet-split design above, or is the fund exposure small enough
|
|
to just run the wallet on alpha too, for simplicity? Do not proceed with
|
|
either without confirmation — this is the one piece of this plan with real
|
|
financial/security stakes.
|
|
|
|
## Suggested build order
|
|
|
|
1. ~~Gitea~~ — done, see above.
|
|
2. Files via Syncthing (validates the intermittent-sync approach before
|
|
trusting it with anything else).
|
|
3. Dogecoin node — **only after explicit sign-off on the wallet-split
|
|
question above.**
|
|
4. Jellyfin — **only after the scoping question above is answered.**
|