Option A (validation):
- handlers_syncpairs.go: reject create/update when both SourceMachineID
and DestMachineID are set; clear error message explains the constraint
- engine.go: detect 'both remote' rsync error at runtime and surface it
as error_code=remote_to_remote_unsupported with a human-readable message
Option B (remote-to-remote support):
- rsync_runner.go: add RunRemote() method that SSHs to the source machine
and runs rsync locally there (src=local path, dst=user@host:/path),
streaming output back through the onLine callback
- engine.go: when both srcMachine and dstMachine are non-nil, use
RunRemote() instead of Run(), SSHing to srcMachine and running rsync
from there. Also wake dstMachine via WoL when both sides are remote.
Full-stack Go monolith with embedded React frontend for orchestrating
rsync-over-SSH file synchronization with Wake-on-LAN support.
Features:
- JWT auth (HS256) with bcrypt password hashing
- CRUD for machines (with WoL config) and sync_pairs
- Ed25519 SSH key generation and known_hosts management
- WoL magic packet sender + TCP-connect waiter with backoff
- Sync engine: rsync subprocess, per-pair job queue, progress parsing
- Homebrew cron parser for scheduled syncs
- SSE stream for live job status (queued/waking_up/running/success/failed)
- React+TS+Vite+Tailwind SPA embedded via embed.FS
- Debian packaging with systemd unit, postinst/prerm/postrm
Tech stack:
- Go 1.22+ (CGO_ENABLED=0, pure SQLite via modernc.org/sqlite)
- chi router for HTTP API
- TypeScript + React 18 + Tailwind CSS frontend
- Cross-compiled to Linux amd64 for Proxmox LXC deployment
Tests: wol (MAC parsing, magic packet), syncengine/queue, scheduler/cron
darroyo