jensandClaude Sonnet 5
f9e0f5221f
Implements the sketch from SYNC-PLAN.md item 2b. gitea dump (not raw rsync, to avoid grabbing the live SQLite DB mid-write) runs nightly on alpha via cron, into a dedicated read-only-chrooted SFTP account (giteabackup) reusing the existing ftp_jens/ftp_alex sshd pattern. vlda-01 pulls whatever's new via a User Scripts plugin entry (not a raw crontab - Unraid's / and /usr are RAM-backed and don't survive reboot, only /boot does), fetching only files it doesn't already have so a run after days offline catches up on everything missed. Found and fixed two real issues along the way: a default ACL on the backup directory doesn't actually grant read access to new dump files, since gitea dump creates them 600 and the resulting ACL mask neuters the inherited grant - fixed by applying the ACL explicitly per file. And the restricted account's ForceCommand internal-sftp blocks a real rsync invocation, so the transport is SFTP get, not rsync. Verified end-to-end through the actual scheduled-invocation path on both ends, including a second run correctly skipping an already-pulled file instead of re-fetching it. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
118 lines
5.8 KiB
Markdown
118 lines
5.8 KiB
Markdown
# alpha.jayfield.org — Intranet Sync Plan (vlda-01 → alpha)
|
|
|
|
**Status: item 1 (Gitea) done, the rest still planning-only.** 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 and Gitea did.
|
|
|
|
`vlda-01` itself, and anything else on the home LAN, lives under the
|
|
private `home.jayfield.org` namespace — not part of `alpha`'s public,
|
|
authoritative `jayfield.org` zone (see README.md's "Domain namespace").
|
|
|
|
## 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.
|
|
|
|
#### 2b. Ongoing backup: `git.jayfield.org` (alpha) → `vlda-01.home.jayfield.org`
|
|
|
|
**Status: built and verified, 2026-07-26 — see `README.md`'s "Gitea backup
|
|
to vlda-01" section for the full live setup.** Point-in-time backup, not a
|
|
hot standby/live mirror; explicitly out of scope: real-time replication,
|
|
automatic failover, DNS/traffic cutover — none of that fits a personal
|
|
git host's actual usage. Future consolidation candidate: if/when
|
|
Syncthing (item 1 above) gets built, it could carry these archives too
|
|
instead of a separate pull mechanism.
|
|
|
|
### 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.**
|