jens/docs-alpha.jayfield.org
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
master
docs-alpha.jayfield.org/SYNC-PLAN.md
T
jensandClaude Sonnet 5 f9e0f5221f Build the alpha -> vlda-01 Gitea backup strategy 
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>
2026-07-26 16:29:32 +02:00

5.8 KiB
Raw Permalink Blame History

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.
Reference in New Issue View Git Blame Copy Permalink