[OneDev #8] feat(remote-access): unified deployment & management for Parsec, RustDesk, Sunshine/Moonlight, SSH #32

Open
opened 2026-05-24 04:46:40 +00:00 by joseph · 0 comments
Owner

Imported from OneDev issue #8 (id 35241)
Original project: internal-joseph
Original state: Open
Original submitterId: 5
Original submitDate: 2026-04-09T14:19:45.056+00:00
Original lastActivity: {'date': '2026-04-09T14:19:45.056+00:00', 'description': 'opened', 'userId': 5}

Original fields:

  • Type: New Feature
  • Priority: Normal
  • Assignees: None

Idea

One-shot deployment and ongoing management of all remote access tools (Parsec, RustDesk, Sunshine/Moonlight, SSH) across the fleet. Ansible orchestrates initial rollout (Win/Linux), Tactical RMM handles fallback execution and proactive patching, Chezmoi templates configs, Keeper CLI automates secrets/TOTP. One keypair per host, SSH-style distribution to the fleet.

Host/client matrix:

  • Full hosts: Windows desktops, Linux desktops, Android mobile
  • Clients only: iPad
  • Parsec: Windows hosting only; Linux/mobile as clients

Connectivity Matrix dashboard: accordion table with top-level RAG (Red/Amber/Green) status per host, expanding to peer-to-peer health and latency detail.

Why

Remote access is currently ad-hoc per tool and per machine. A unified playbook eliminates drift, makes new-host onboarding trivial, and the connectivity matrix gives at-a-glance fleet health instead of "try connecting and see."

Open questions

  • Sunshine/Moonlight pairing: Is it purely file-based (deploy server.key via Chezmoi) or does it require API/PIN interaction at pair time?
  • RustDesk silent setup: Exact config paths / registry keys for headless install + server-pointing; does custom branding require a fork?
  • Mobile automation scope: What's realistic for Android (ADB/Termux) vs. manual iPad config?
  • Dashboard data pipeline: How do Tactical RMM probers report status to the UI — central JSON, Prometheus/Grafana, or local status files polled by the dashboard?
  • Key distribution workflow: Design the "Central Key Store" flow — how Ansible retrieves a new host's pubkey and pushes it to the rest of the fleet.

Moved from int-infra#20 (closed).

Imported from OneDev issue #8 (id 35241) Original project: internal-joseph Original state: Open Original submitterId: 5 Original submitDate: 2026-04-09T14:19:45.056+00:00 Original lastActivity: {'date': '2026-04-09T14:19:45.056+00:00', 'description': 'opened', 'userId': 5} Original fields: - Type: New Feature - Priority: Normal - Assignees: None ## Idea One-shot deployment and ongoing management of all remote access tools (Parsec, RustDesk, Sunshine/Moonlight, SSH) across the fleet. Ansible orchestrates initial rollout (Win/Linux), Tactical RMM handles fallback execution and proactive patching, Chezmoi templates configs, Keeper CLI automates secrets/TOTP. One keypair per host, SSH-style distribution to the fleet. **Host/client matrix:** - **Full hosts:** Windows desktops, Linux desktops, Android mobile - **Clients only:** iPad - **Parsec:** Windows hosting only; Linux/mobile as clients **Connectivity Matrix dashboard:** accordion table with top-level RAG (Red/Amber/Green) status per host, expanding to peer-to-peer health and latency detail. ## Why Remote access is currently ad-hoc per tool and per machine. A unified playbook eliminates drift, makes new-host onboarding trivial, and the connectivity matrix gives at-a-glance fleet health instead of "try connecting and see." ## Open questions - **Sunshine/Moonlight pairing:** Is it purely file-based (deploy `server.key` via Chezmoi) or does it require API/PIN interaction at pair time? - **RustDesk silent setup:** Exact config paths / registry keys for headless install + server-pointing; does custom branding require a fork? - **Mobile automation scope:** What's realistic for Android (ADB/Termux) vs. manual iPad config? - **Dashboard data pipeline:** How do Tactical RMM probers report status to the UI — central JSON, Prometheus/Grafana, or local status files polled by the dashboard? - **Key distribution workflow:** Design the "Central Key Store" flow — how Ansible retrieves a new host's pubkey and pushes it to the rest of the fleet. _Moved from int-infra#20 (closed)._
Sign in to join this conversation.
No labels
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
joseph/internal-joseph#32
No description provided.