mirror of
https://github.com/rustdesk/rustdesk.git
synced 2026-06-22 10:02:20 +00:00
docs: initialize Vestra Support documentation and roadmap scaffolding
This commit is contained in:
Vestra Support Agent
parent
3c574a4182
commit
bce346f2a3
9 changed files with 579 additions and 0 deletions
30
README.md
30
README.md
|
|
@ -8,6 +8,36 @@
|
|||
<b>We need your help to translate this README, <a href="https://github.com/rustdesk/rustdesk/tree/master/src/lang">RustDesk UI</a> and <a href="https://github.com/rustdesk/doc.rustdesk.com">RustDesk Doc</a> to your native language</b>
|
||||
</p>
|
||||
|
||||
---
|
||||
|
||||
# Vestra Support Fork
|
||||
|
||||
This repository is a **Vestra Interactive** downstream fork of [RustDesk](https://github.com/rustdesk/rustdesk), the open-source remote desktop software. It is customized to deliver a secure, self-hosted, and branded remote support client for Vestra Platform customers and technicians.
|
||||
|
||||
### Current Project Status
|
||||
We are currently in **Phase 0 (Planning & Documentation)**. In this phase, we establish compliance guidelines, map infrastructure configurations, and define future branding overlays. No application code, network configuration, authentication flow, or encryption routines have been modified.
|
||||
|
||||
### Project Goals & Scope
|
||||
* **Dedicated Relay**: Anchor connections to Vestra-managed servers for improved connection routing, control, and privacy.
|
||||
* **Custom Branding**: Streamline the client interface, customize logos and icons, and target connection configurations for zero-configuration startup.
|
||||
* **Portal Integration**: Link remote support sessions to the Vestra Core API, Admin Portal, and support ticket dashboard.
|
||||
* **Maintain Compatibility**: Restrict all customizations to branding and configurations, maintaining complete compatibility with the upstream RustDesk code.
|
||||
|
||||
### Source Disclosure & Compliance
|
||||
As part of our commitment to open-source software and in compliance with the **GNU Affero General Public License (AGPL-3.0)**, we make the source code of Vestra Support publicly available. The code in this repository represents the source of truth for Vestra's downstream builds.
|
||||
|
||||
For detailed architecture, configuration, branding, and compliance documentation, see:
|
||||
* [Vestra Support Overview](docs/VESTRA-SUPPORT.md)
|
||||
* [Development Roadmap](docs/ROADMAP.md)
|
||||
* [Relay Infrastructure Setup](docs/RELAY-INFRASTRUCTURE.md)
|
||||
* [Branding & Customization Guide](docs/BRANDING-GUIDE.md)
|
||||
* [Compliance & Licensing Guidelines](docs/COMPLIANCE.md)
|
||||
* [Release Philosophy](docs/RELEASE-PHILOSOPHY.md)
|
||||
* [High-Level Architecture](docs/ARCHITECTURE.md)
|
||||
* [Project Backlog Tasks](docs/PROJECT-BACKLOG.md)
|
||||
|
||||
---
|
||||
|
||||
> [!Caution]
|
||||
> **Misuse Disclaimer:** <br>
|
||||
> The developers of RustDesk do not condone or support any unethical or illegal use of this software. Misuse, such as unauthorized access, control or invasion of privacy, is strictly against our guidelines. The authors are not responsible for any misuse of the application.
|
||||
|
|
|
|||
80
docs/ARCHITECTURE.md
Normal file
80
docs/ARCHITECTURE.md
Normal file
|
|
@ -0,0 +1,80 @@
|
|||
# High-Level Architecture Overview
|
||||
|
||||
This document presents the high-level architecture of the Vestra Support ecosystem, detailing how the custom desktop clients, self-hosted relay infrastructure, and internal portal components communicate.
|
||||
|
||||
---
|
||||
|
||||
## System Architecture Diagram
|
||||
|
||||
```mermaid
|
||||
graph TD
|
||||
subgraph Client Environment
|
||||
UserClient[Vestra Support Client]
|
||||
TechConsole[Technician Console]
|
||||
end
|
||||
|
||||
subgraph Vestra Support Infrastructure
|
||||
HBBS[hbbs: ID / Rendezvous Server]
|
||||
HBBR[hbbr: Relay Server]
|
||||
end
|
||||
|
||||
subgraph Vestra Management Platform
|
||||
Core[Core API Service]
|
||||
Admin[Unified Admin Interface]
|
||||
Ninja[Invoice Ninja]
|
||||
end
|
||||
|
||||
subgraph Third-Party Integrations
|
||||
RMM[Tactical RMM]
|
||||
end
|
||||
|
||||
%% Client communication with Relay
|
||||
UserClient -->|Register & Fetch ID| HBBS
|
||||
TechConsole -->|Lookup ID & Request Handshake| HBBS
|
||||
|
||||
%% Fallback data paths
|
||||
UserClient ==>|Encrypted Data Tunnel| HBBR
|
||||
TechConsole ==>|Encrypted Data Tunnel| HBBR
|
||||
|
||||
%% Management platform linkages
|
||||
Core -->|Sync Accounts / Subscriptions| Ninja
|
||||
Admin -->|Read Audit Logs & Status| Core
|
||||
|
||||
%% Future integration linkages
|
||||
RMM -->|Trigger support launch by ID| TechConsole
|
||||
UserClient -.->|Future: Verify Entitlements / Access| Core
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Core Components
|
||||
|
||||
### 1. Client (RustDesk Fork)
|
||||
The client application is compiled from our customized `vestrainteractive/vestra-support` repository:
|
||||
* **Custom Configs**: Preloaded with Vestra's rendezvous/relay server endpoints and the corresponding public encryption key.
|
||||
* **Branded Interface**: Stripped of standard upstream branding, presenting a simplified layout featuring the Vestra Support about info.
|
||||
* **Security Layer**: Leverages NaCl/libsodium cryptography to secure all control and video streams.
|
||||
|
||||
### 2. Relay Infrastructure (`hbbs` & `hbbr`)
|
||||
A dedicated, self-hosted server cluster:
|
||||
* **`hbbs` (Rendezvous Server)**: Assigns hardware IDs, listens for connection requests, and coordinates NAT hole punching.
|
||||
* **`hbbr` (Relay Server)**: Relays video and control streams when strict NAT constraints prevent a direct peer-to-peer (P2P) path between the operator and the client.
|
||||
|
||||
### 3. Support Portal & Core Backend
|
||||
The business engine of the Vestra Platform:
|
||||
* **Core API**: Houses client data, entitlements (support subscriptions, licenses), and authentication rules.
|
||||
* **Admin Portal**: Used by Vestra staff to view active support ticket context, link system events, and search client accounts.
|
||||
* **Invoice Ninja integration**: Acts as the customer authority, synchronizing accounting and subscription records with Core.
|
||||
|
||||
---
|
||||
|
||||
## Future Integrations
|
||||
|
||||
### 1. Tactical RMM Integration
|
||||
To support rapid technician response:
|
||||
* **Launcher Button**: Allows launching a support session directly from a machine view in the Tactical RMM console.
|
||||
* **Service Deployment**: Standardizes silent background client installation on managed endpoints.
|
||||
|
||||
### 2. Vestra Portal & Entitlements
|
||||
* **Verification**: In later phases, connection access can query the Core Entitlements API to verify that the target account has active support credentials before permitting remote sessions.
|
||||
* **Customer Interface**: Allows customers to view remote connection history, approve unattended access requests, and log service tickets directly.
|
||||
71
docs/BRANDING-GUIDE.md
Normal file
71
docs/BRANDING-GUIDE.md
Normal file
|
|
@ -0,0 +1,71 @@
|
|||
# Branding & Asset Customization Guide
|
||||
|
||||
This document defines the visual branding and identity specifications for the custom Vestra Support client build. These changes are planned for **Phase 2** of the project roadmap.
|
||||
|
||||
---
|
||||
|
||||
## What to Modify
|
||||
|
||||
To customize the client and distance it from standard RustDesk branding, the following modifications must be performed:
|
||||
|
||||
### 1. Application Name & Product Metadata
|
||||
Replace all instances of the product name **RustDesk** with **Vestra Support**:
|
||||
* **Cargo Configuration (`Cargo.toml`)**:
|
||||
* Update `[package]` metadata (`name`, `description`).
|
||||
* Update `[package.metadata.winres]` properties:
|
||||
* `ProductName = "Vestra Support"`
|
||||
* `FileDescription = "Vestra Support Client"`
|
||||
* `OriginalFilename = "vestra-support.exe"`
|
||||
* Update `[package.metadata.bundle]` configuration (`name`, `identifier = "com.vestrainteractive.support"`).
|
||||
* **Flutter Configs (`flutter/pubspec.yaml`)**:
|
||||
* Update application names, package names, and build descriptions for target platforms.
|
||||
|
||||
### 2. Branding Assets (Logos & Icons)
|
||||
Replace the default icons and visual logos located in the repository:
|
||||
* **Resource Directory (`res/`)**:
|
||||
* Overwrite standard header banners, logo SVGs, and icon PNGs.
|
||||
* Windows App Icon files: Replace `res/32x32.png`, `res/128x128.png`, and related multi-resolution icon profiles.
|
||||
* **Platform Assets**:
|
||||
* **Flutter Assets**: Replace assets in `flutter/assets/` and platform-specific resource folders (e.g. `flutter/android/app/src/main/res/` and `flutter/ios/Runner/Assets.xcassets/`).
|
||||
|
||||
### 3. Support & Project URLs
|
||||
Ensure the client redirects users to Vestra resources on action/error:
|
||||
* **Help & Website links**: Modify menu links pointing to `https://rustdesk.com` to point to Vestra support `https://support.vestrainteractive.com`.
|
||||
* **Download references**: Change self-update and direct download URLs.
|
||||
|
||||
### 4. Custom Default Settings
|
||||
To enable "zero-configuration" connections, the build configuration must pre-load Vestra's private network parameters. Hardcode the default values for:
|
||||
* **ID Server**: `id.support.vestrainteractive.com`
|
||||
* **Relay Server**: `relay.support.vestrainteractive.com`
|
||||
* **Public Key**: The public encryption key generated in Phase 1 (extracted from server `id_ed25519.pub`).
|
||||
|
||||
---
|
||||
|
||||
## About Dialog Specifications
|
||||
|
||||
The standard application About Dialog must be replaced with the following copy and links:
|
||||
|
||||
```text
|
||||
Vestra Support
|
||||
|
||||
Based on RustDesk Open Source Software
|
||||
|
||||
Source Code:
|
||||
https://github.com/vestrainteractive/vestra-support
|
||||
|
||||
License:
|
||||
AGPL-3.0
|
||||
```
|
||||
|
||||
*Ensure the Source Code link remains fully clickable and navigates to the public repository to fulfill AGPL source disclosure obligations.*
|
||||
|
||||
---
|
||||
|
||||
## What NOT to Modify
|
||||
|
||||
> [!CAUTION]
|
||||
> Under no circumstances should the following components be altered or modified:
|
||||
> 1. **Encryption & Cryptography**: Keep standard NaCl/libsodium implementations intact. Modifications risk breaking connection security.
|
||||
> 2. **Networking Protocols**: The custom client must communicate using standard RustDesk network protocols to maintain compatibility with upstream relay servers and official APIs.
|
||||
> 3. **Session Authentication Hooks**: The default access token, server public key validation, and password exchange routines must be preserved.
|
||||
> 4. **Third-Party Copyrights**: Original licensing tags, upstream source file headers, and copyright notices for RustDesk contributors must be preserved exactly as-is.
|
||||
64
docs/COMPLIANCE.md
Normal file
64
docs/COMPLIANCE.md
Normal file
|
|
@ -0,0 +1,64 @@
|
|||
# Open-Source Compliance Guidelines
|
||||
|
||||
This document provides compliance guidelines for the development and distribution of the Vestra Support client and relay server infrastructure.
|
||||
|
||||
> [!CAUTION]
|
||||
> **Disclaimer**: This document does not constitute legal advice. It is intended for operational and engineering guidance to ensure standard open-source license compliance. For specific legal inquiries regarding license liabilities, trademark rights, or proprietary integration constraints, please consult qualified legal counsel.
|
||||
|
||||
---
|
||||
|
||||
## License Context: AGPL-3.0
|
||||
|
||||
The upstream RustDesk project is licensed under the **GNU Affero General Public License version 3 (AGPL-3.0)**. As a downstream fork, Vestra Support is bound by all provisions, obligations, and copyleft triggers of the AGPL-3.0.
|
||||
|
||||
### Key AGPL Obligations
|
||||
|
||||
1. **Copyleft & Derivative Works**: Any modifications, updates, or integrations built directly into the RustDesk codebase are considered derivative works and must be licensed under the AGPL-3.0.
|
||||
2. **Network Interaction Trigger (Section 13)**: Unlike standard GPL, if you run a modified version of the software on a server and let users interact with it over a network (e.g., custom relays, web consoles, portal integrations), you **must** make the source code of that modified version available to those users.
|
||||
3. **Attribution**: Original copyright and author notices must be preserved in all modified source files.
|
||||
4. **No Additional Restrictions**: You cannot impose additional licensing terms, DRM, or proprietary wrappers that restrict the rights granted under the AGPL-3.0.
|
||||
|
||||
---
|
||||
|
||||
## Compliance Requirements
|
||||
|
||||
### 1. Source Disclosure
|
||||
To comply with Section 13 of the AGPL-3.0, Vestra Interactive must make the complete source code of the Vestra Support fork available to all end-users who download or interact with the client:
|
||||
* **Public Repository**: The repository `https://github.com/vestrainteractive/vestra-support` must remain public and contain all source modifications, build scripts, and configuration overrides.
|
||||
* **Prominent Links**: Clear and visible links to the source repository must be provided:
|
||||
* In the application's **About Dialog**.
|
||||
* On the download page of the Vestra Support portal.
|
||||
* In user documentation and onboarding materials.
|
||||
|
||||
### 2. Attribution
|
||||
Original copyright headers and licenses must remain intact:
|
||||
* **License File**: The root `LICENSE` or `LICENCE` file containing the AGPL-3.0 text must be preserved.
|
||||
* **Author Credit**: Copyright headers in files belonging to upstream RustDesk authors must not be removed or altered.
|
||||
* **Modification Notices**: New files or heavily modified source files should contain comments indicating that they are based on RustDesk and modified by Vestra Interactive.
|
||||
|
||||
### 3. Trademark Considerations
|
||||
To avoid trademark infringement and user confusion:
|
||||
* **Product Naming**: The application must not identify itself simply as "RustDesk" to end-users. All user-facing assets must be renamed to **Vestra Support**.
|
||||
* **Executables**: Executables must be compiled with a distinct name (e.g. `vestra-support.exe`) and configure distinct package IDs (e.g. `com.vestrainteractive.support` instead of `com.carriez.rustdesk`).
|
||||
* **Visuals**: Standard RustDesk icons and logos must be replaced with Vestra Support visual assets.
|
||||
* **Disclaimer of Affiliation**: The About dialog and documentation must state clearly that the product is *based on* RustDesk open-source software but is not affiliated with or endorsed by Purslane Ltd. (the creators of RustDesk).
|
||||
|
||||
---
|
||||
|
||||
## Release Checklist (Engineering Guidelines)
|
||||
|
||||
Before publishing any source release:
|
||||
- [ ] Ensure all local changes, including configuration files and assets, are pushed to the public GitHub repository.
|
||||
- [ ] Verify that no private credentials, database connection strings, or production signing keys are committed to the repository history.
|
||||
- [ ] Confirm the presence of the `LICENSE` file in the repository root.
|
||||
- [ ] Verify that all files containing modifications retain appropriate licensing notices.
|
||||
|
||||
---
|
||||
|
||||
## Binary Distribution Checklist (Production Guidelines)
|
||||
|
||||
Before distributing Vestra Support binaries to customers:
|
||||
- [ ] Verify the binary was compiled from a git commit that is pushed and publicly visible on the GitHub repository.
|
||||
- [ ] Confirm the About dialog displays the correct version, source link (`https://github.com/vestrainteractive/vestra-support`), and AGPL-3.0 license text.
|
||||
- [ ] Ensure binaries are code-signed with Vestra's developer certificates to prevent OS-level execution blocks.
|
||||
- [ ] Verify that the support portal download page contains a clear link to the public source code repository.
|
||||
87
docs/PROJECT-BACKLOG.md
Normal file
87
docs/PROJECT-BACKLOG.md
Normal file
|
|
@ -0,0 +1,87 @@
|
|||
# Project Backlog
|
||||
|
||||
This document defines critical backlog items and work specifications required to move Vestra Support through its roadmap phases.
|
||||
|
||||
---
|
||||
|
||||
## 1. Branding Layer Customization (Phase 2)
|
||||
|
||||
**Title**: Implement Vestra Support Branding Layer
|
||||
**Type**: Task / Feature
|
||||
**Target Milestone**: Phase 2
|
||||
|
||||
### Description
|
||||
Replace default RustDesk visual assets and metadata with Vestra Support branding across desktop configurations.
|
||||
|
||||
### Requirements
|
||||
* Modify `Cargo.toml` properties:
|
||||
* Update binary name and product metadata under `[package.metadata.winres]` and `[package.metadata.bundle]`.
|
||||
* Replace asset images in `res/` directory:
|
||||
* SVGs and PNG icon sizes (32x32, 128x128).
|
||||
* Update Flutter bundle and app settings for desktop (Windows/macOS).
|
||||
* Override standard About Dialog text:
|
||||
```text
|
||||
Vestra Support
|
||||
Based on RustDesk Open Source Software
|
||||
Source Code: https://github.com/vestrainteractive/vestra-support
|
||||
License: AGPL-3.0
|
||||
```
|
||||
* Ensure the repository link in the dialog matches our fork and is clickable.
|
||||
|
||||
---
|
||||
|
||||
## 2. Relay Infrastructure Deployment (Phase 1)
|
||||
|
||||
**Title**: Deploy Self-Hosted ID and Relay Servers
|
||||
**Type**: Infrastructure / DevOps
|
||||
**Target Milestone**: Phase 1
|
||||
|
||||
### Description
|
||||
Deploy self-hosted instances of `hbbs` (ID server) and `hbbr` (Relay server) to anchor all connections to private Vestra hardware.
|
||||
|
||||
### Requirements
|
||||
* Provision a public VPS or cloud instance for hosting.
|
||||
* Set up Docker containers for `hbbs` and `hbbr` or install standalone binaries.
|
||||
* Configure DNS A records:
|
||||
* `id.support.vestrainteractive.com` -> pointing to `hbbs` instance.
|
||||
* `relay.support.vestrainteractive.com` -> pointing to `hbbr` instance.
|
||||
* Configure Firewall security groups to expose necessary TCP/UDP ports:
|
||||
* TCP: 21115, 21116, 21117, 21118, 21119
|
||||
* UDP: 21116
|
||||
* Generate keypairs (`id_ed25519` and `id_ed25519.pub`) on startup and backup key assets.
|
||||
|
||||
---
|
||||
|
||||
## 3. First Internal Build (Phase 3)
|
||||
|
||||
**Title**: Establish Automated Multi-Platform Build Pipeline
|
||||
**Type**: DevOps / Build
|
||||
**Target Milestone**: Phase 3
|
||||
|
||||
### Description
|
||||
Create automated build configurations to compile, code-sign, and output signed Vestra Support client binaries.
|
||||
|
||||
### Requirements
|
||||
* Configure GitHub Actions workflows or local build runners for Windows and macOS.
|
||||
* Set up dependencies (vcpkg, rustup, Flutter SDK, Sciter dependencies where appropriate).
|
||||
* Pre-configure build parameters to embed target connection defaults:
|
||||
* Server DNS: `id.support.vestrainteractive.com`
|
||||
* Server Public Key: (Phase 1 public key string)
|
||||
* Integrate Vestra developer credentials to code-sign executables (`.exe`, `.msi`, `.dmg`) to prevent operating system security blocks on client launch.
|
||||
|
||||
---
|
||||
|
||||
## 4. Compliance Review (Phase 5 / Continuous)
|
||||
|
||||
**Title**: Complete Open-Source License and Compliance Audit
|
||||
**Type**: Operations / Compliance
|
||||
**Target Milestone**: Continuous
|
||||
|
||||
### Description
|
||||
Review the codebase, documentation, and distribution channels to guarantee absolute alignment with AGPL-3.0 license requirements and trademark protections.
|
||||
|
||||
### Requirements
|
||||
* Audit the public GitHub repository to confirm the presence of the complete matching source code for any distributed binaries.
|
||||
* Verify that copyright headers are preserved exactly as required by the AGPL-3.0 license.
|
||||
* Ensure all links pointing to source code (in About Dialogs, client portal pages, and emails) are functional.
|
||||
* Review build profiles to confirm "RustDesk" trademarks are not used in user-facing components, renaming all binary resources to "Vestra Support".
|
||||
90
docs/RELAY-INFRASTRUCTURE.md
Normal file
90
docs/RELAY-INFRASTRUCTURE.md
Normal file
|
|
@ -0,0 +1,90 @@
|
|||
# Relay Infrastructure Requirements
|
||||
|
||||
This document specifies the setup, requirements, and deployment parameters for the self-hosted Vestra Support relay server network.
|
||||
|
||||
---
|
||||
|
||||
> [!WARNING]
|
||||
> ## Current Status: Not Yet Implemented
|
||||
> The relay infrastructure details below are conceptual and planned for Phase 1. No production servers or public DNS endpoints have been configured. Unmodified clients cannot currently establish sessions using Vestra-dedicated endpoints.
|
||||
|
||||
---
|
||||
|
||||
## Server Components
|
||||
|
||||
RustDesk architecture utilizes two central daemon services. Both must be deployed on public-facing servers with low-latency network access.
|
||||
|
||||
```mermaid
|
||||
graph TD
|
||||
subgraph Client Network
|
||||
LocalClient[Local User Client]
|
||||
RemoteClient[Remote Operator Console]
|
||||
end
|
||||
|
||||
subgraph Vestra Relay Infrastructure
|
||||
HBBS[hbbs: Rendezvous / ID Server]
|
||||
HBBR[hbbr: Relay Server]
|
||||
end
|
||||
|
||||
%% Connection setup
|
||||
LocalClient -->|1. Register / Get ID| HBBS
|
||||
RemoteClient -->|2. Request Connection| HBBS
|
||||
HBBS -->|3. Route Connection| LocalClient
|
||||
|
||||
%% Active connection options
|
||||
LocalClient -.->|Direct P2P Connection if possible| RemoteClient
|
||||
LocalClient ==>|Relayed Connection fallback| HBBR
|
||||
RemoteClient ==>|Relayed Connection fallback| HBBR
|
||||
```
|
||||
|
||||
### 1. `hbbs` (ID / Rendezvous Server)
|
||||
* **Purpose**: Coordinates registration of support clients, maps hardware IDs to active network sockets, handles connection handshakes, and facilitates peer-to-peer (P2P) NAT traversal.
|
||||
* **Database**: Uses a light SQLite database locally to track registered client credentials and key mappings.
|
||||
|
||||
### 2. `hbbr` (Relay Server)
|
||||
* **Purpose**: acts as a fallback proxy. If direct peer-to-peer connection cannot be established between the operator console and target machine (due to symmetric NATs, strict firewalls, etc.), connection traffic is relayed through this service.
|
||||
|
||||
---
|
||||
|
||||
## DNS Requirements
|
||||
|
||||
To avoid hardcoding IP addresses and allow routing flexibility, Vestra Support requires two public DNS A records pointing to the relay hosts:
|
||||
|
||||
| Domain (Placeholder) | Target Component | Notes |
|
||||
| :--- | :--- | :--- |
|
||||
| `id.support.vestrainteractive.com` | `hbbs` (ID Server) | Used by clients to register and find peers. |
|
||||
| `relay.support.vestrainteractive.com` | `hbbr` (Relay Server) | Used to tunnel connection data. |
|
||||
|
||||
---
|
||||
|
||||
## Firewall & Port Configurations
|
||||
|
||||
The relay hosts must expose the following ports to the public internet. Ensure security groups and firewalls permit this traffic:
|
||||
|
||||
| Port | Protocol | Service | Purpose |
|
||||
| :--- | :--- | :--- | :--- |
|
||||
| **21115** | TCP | `hbbs` | NAT tunnel port test. |
|
||||
| **21116** | TCP | `hbbs` | Main connection handshake and routing service. |
|
||||
| **21116** | UDP | `hbbs` | NAT hole punching / registration query. |
|
||||
| **21117** | TCP | `hbbr` | Relay server control connection. |
|
||||
| **21118** | TCP | `hbbs` | Web client support (optional, reserved for future use). |
|
||||
| **21119** | TCP | `hbbr` | Web client relay connection (optional, reserved for future use). |
|
||||
|
||||
---
|
||||
|
||||
## Monitoring Recommendations
|
||||
|
||||
Operational health metrics should be actively monitored on the hosting server:
|
||||
* **Network Bandwidth**: Monitor egress/ingress bandwidth. Relayed connections (through `hbbr`) can consume significant network throughput depending on active session counts and screen resolutions.
|
||||
* **CPU and Memory**: Track resource spikes. Both `hbbs` and `hbbr` are written in Rust and are highly efficient, but excessive session volume can impact performance.
|
||||
* **Process Watch**: Use process monitors (e.g. systemd watchdog, supervisor, or Docker health checks) to ensure `hbbs` and `hbbr` services auto-restart on crash.
|
||||
* **Connection Metrics**: Track open socket connections on port 21116 and 21117 to estimate active session counts.
|
||||
|
||||
---
|
||||
|
||||
## Backup Recommendations
|
||||
|
||||
Although the relay servers do not store user database data, the following configuration states should be backed up regularly:
|
||||
* **Private/Public Key Pairs**: Located in the executable directory as `id_ed25519` and `id_ed25519.pub`. If these keys are lost or regenerated, all pre-configured client binaries will fail to authenticate with the server and will lock out remote connections.
|
||||
* **Rendezvous Database**: The SQLite file (usually `db_ip.db`) used by `hbbs` to track client metadata.
|
||||
* **Docker Compose Configurations**: Configuration environment variables and compose files.
|
||||
27
docs/RELEASE-PHILOSOPHY.md
Normal file
27
docs/RELEASE-PHILOSOPHY.md
Normal file
|
|
@ -0,0 +1,27 @@
|
|||
# Release Philosophy
|
||||
|
||||
This document defines the core principles governing the development, deployment, and operation of Vestra Support.
|
||||
|
||||
---
|
||||
|
||||
## Core Principles
|
||||
|
||||
### 1. Reliability > Features
|
||||
Remote support tools require absolute, predictable stability. A technician connecting to a client's server in an emergency must be certain the client will connect, authenticate, and display properly:
|
||||
* We prioritize fixing connection errors, memory leaks, and compilation warnings over implementing new feature hooks or client controls.
|
||||
* Every release must go through a rigid verification process matching our operational checklist.
|
||||
|
||||
### 2. Simplicity > Automation
|
||||
Avoid premature engineering or unnecessary automation complexity:
|
||||
* In the early stages of infrastructure setup and build pipelines, we prefer simple, clear, manually-triggerable steps (such as documented docker-compose commands and manual signing steps) over complex, magic scripts.
|
||||
* We only introduce automation (such as GitHub actions or automated testing loops) once the manual process has been validated, documented, and run consistently.
|
||||
|
||||
### 3. Transparency > Magic
|
||||
All operational configurations, security architectures, and log routes must be transparent and discoverable:
|
||||
* Pre-configured values (such as server endpoints and public keys) must be clearly documented in our files rather than hidden in compiled binaries or obfuscated variables.
|
||||
* Remote session logs, connection status notices, and data policies must be clear to both the customer and the operating technician.
|
||||
|
||||
### 4. Upstream Compatibility > Custom Forking
|
||||
Vestra Support is a downstream distribution of RustDesk, not a divergent product:
|
||||
* To maintain rapid access to security updates, bug fixes, and feature improvements from the open-source community, we must keep our codebase closely aligned with upstream RustDesk.
|
||||
* We enforce a strict policy of avoiding customization of core networking protocols, encryption loops, or GUI layout code. The custom branding must be implemented as a thin configuration overlay.
|
||||
51
docs/ROADMAP.md
Normal file
51
docs/ROADMAP.md
Normal file
|
|
@ -0,0 +1,51 @@
|
|||
# Project Roadmap
|
||||
|
||||
This document outlines the development phases, release path, and upstream alignment strategy for Vestra Support.
|
||||
|
||||
---
|
||||
|
||||
## Upstream Strategy
|
||||
|
||||
Vestra Support is intended to remain a **thin downstream distribution** of the official RustDesk project.
|
||||
To minimize maintenance overhead and ensure long-term stability:
|
||||
* **Prioritize Upstream Alignment**: Custom code changes should be restricted strictly to branding assets, configuration overrides (default server IP/DNS and keys), and minimal API integration hooks.
|
||||
* **Avoid Divergence**: We will avoid refactoring core application logic, custom UI layouts, or underlying protocol structures. Any divergence makes merging new upstream releases significantly more complex.
|
||||
* **Upstream Integration**: Critical bug fixes or performance enhancements discovered during development should, where appropriate, be contributed back to the upstream RustDesk repository rather than maintained locally.
|
||||
* **Continuous Merges**: The project team will schedule regular reviews to pull latest stable releases, security patches, and hotfixes from the upstream `rustdesk/rustdesk` repository.
|
||||
|
||||
---
|
||||
|
||||
## Release Phases
|
||||
|
||||
### Phase 0: Foundations & Scaffolding (Current Phase)
|
||||
* [x] **Fork Established**: Official RustDesk repository forked to `vestrainteractive/vestra-support`.
|
||||
* [x] **Licensing Reviewed**: Detailed analysis of AGPL-3.0 copyleft obligations and licensing implications.
|
||||
* [x] **Repository Initialized**: Workspace set up with initial monorepo scaffolding and project documentation.
|
||||
|
||||
### Phase 1: Relay Infrastructure & Validation
|
||||
* [ ] **Deploy Relay Server**: Set up self-hosted instances of `hbbs` (ID server) and `hbbr` (Relay server) in Vestra's infrastructure environment.
|
||||
* [ ] **Generate Server Keys**: Generate secure public/private key pairs for encryption and connection authentication.
|
||||
* [ ] **Stock Validation**: Verify that standard, unmodified RustDesk clients can connect, register, and establish sessions using the newly deployed Vestra relay server configuration.
|
||||
* [ ] **Define Deployment Checklist**: Document server setup and system configuration tasks for staging and production environments.
|
||||
|
||||
### Phase 2: Branding Layer & Custom Configuration
|
||||
* [ ] **App Name Customization**: Modify application and executable names to "Vestra Support".
|
||||
* [ ] **Visual Identity**: Replace all logos, window headers, icons, and status assets in the `res/` directory.
|
||||
* [ ] **Pre-configure Connections**: Embed default Vestra ID server, relay server, and public key configurations into the build configuration.
|
||||
* [ ] **About Dialog Update**: Implement the customized About dialog detailing the fork's basis, source code link, and AGPL-3.0 license.
|
||||
* [ ] **Support URLs**: Update client help links, error message directions, and manual downloads links to point to `support.vestrainteractive.com`.
|
||||
|
||||
### Phase 3: Build & Release Pipeline
|
||||
* [ ] **Multi-Platform Build Setup**: Establish automated build workflows (using GitHub Actions or local runners) for Windows (`.exe` / `.msi`) and macOS (`.dmg`).
|
||||
* [ ] **Code Signing**: Integrate Vestra's developer certificates to sign binaries, preventing operating system warnings (SmartScreen / Gatekeeper) on client machines.
|
||||
* [ ] **Automated Release Scaffolding**: Configure the release pipeline to generate downloadable assets when version tags are pushed.
|
||||
|
||||
### Phase 4: Helpdesk Portal Integration
|
||||
* [ ] **Core API Integration**: Hook the support client's status logs or registration calls into the Vestra Core backend.
|
||||
* [ ] **Technician Portal Dashboard**: Build a simplified console inside the Vestra Admin interface for staff to track active support IDs.
|
||||
* [ ] **Session Logs**: Record session timing and connection logs to enable tracking and support history.
|
||||
|
||||
### Phase 5: Tactical RMM Integration
|
||||
* [ ] **Launcher Script**: Create script utilities to launch Vestra Support sessions directly from the Tactical RMM workstation view.
|
||||
* [ ] **Unattended Configuration**: Package the Vestra Support client for silent installation and service setup via the RMM deployment manager.
|
||||
* [ ] **Bi-directional Mapping**: Sync machine status and hardware IDs between the RMM portal and Vestra support tables.
|
||||
79
docs/VESTRA-SUPPORT.md
Normal file
79
docs/VESTRA-SUPPORT.md
Normal file
|
|
@ -0,0 +1,79 @@
|
|||
# Vestra Support
|
||||
|
||||
This document outlines the project overview, goals, workflows, and status of the Vestra Support project.
|
||||
|
||||
---
|
||||
|
||||
## Project Overview
|
||||
|
||||
**Vestra Support** is a custom remote support application tailored for Vestra Interactive's client ecosystem. It is built as a lightweight, branded downstream fork of the open-source [RustDesk](https://github.com/rustdesk/rustdesk) remote desktop software. The project includes customized desktop client binaries and a dedicated, self-hosted relay infrastructure.
|
||||
|
||||
Vestra Support simplifies connection setup for customers and technicians by eliminating external third-party dependencies (such as TeamViewer or official RustDesk public relays) and routing all support traffic through Vestra-managed infrastructure.
|
||||
|
||||
---
|
||||
|
||||
## Business Goals
|
||||
|
||||
1. **Security & Data Privacy**: Retain complete control over connection logs and transit data by routing connections through Vestra's private relay network.
|
||||
2. **Simplified Branding & Trust**: Reduce customer confusion and security skepticism by presenting a clear, Vestra-branded application dialog instead of a generic remote access utility.
|
||||
3. **Optimized Support Workflows**: Integrate remote connection controls directly into Vestra's existing management platforms and helpdesk portal.
|
||||
4. **License & Cost Optimization**: Leverage robust open-source foundations (AGPL-3.0) to eliminate seat-based subscription fees associated with proprietary remote support software.
|
||||
|
||||
---
|
||||
|
||||
## Workflows
|
||||
|
||||
### 1. One-Time Support Workflow (Ad-hoc Session)
|
||||
|
||||
Designed for users requiring immediate, on-demand support who do not have pre-installed management agents:
|
||||
1. **Initiation**: The customer contacts Vestra support (via email or support portal).
|
||||
2. **Download**: The technician directs the customer to download the lightweight, pre-configured Vestra Support runner binary from the Vestra Support URL (`https://support.vestrainteractive.com/download`).
|
||||
3. **Execution**: The customer runs the application (no installation or administrative privileges required on standard systems).
|
||||
4. **Handshake**: The client automatically establishes a session with the Vestra `hbbs` (ID/rendezvous) server and displays a unique, pre-generated ID and password.
|
||||
5. **Connection**: The customer provides the ID and password to the Vestra technician, who connects using the technician's console.
|
||||
6. **Termination**: Once the session is closed, the client application terminates completely, leaving no background services running.
|
||||
|
||||
### 2. Future Managed-Services Workflow (Unattended Access)
|
||||
|
||||
For managed services and contract accounts that require proactive monitoring and background support:
|
||||
1. **Installation**: The Vestra Support client is installed as a system service during initial onboarding.
|
||||
2. **Registration**: The client registers itself persistently with the Vestra rendezvous server and associates its unique ID with the client's account records in the Vestra Core API.
|
||||
3. **Unattended Access**: Under strict access controls, Vestra technicians can launch remote sessions to the managed server or workstation without requiring active user confirmation, utilizing pre-configured encryption keys.
|
||||
4. **Auditability**: Every connection attempt and session duration is audited and logged back to the Core database for reporting and accountability.
|
||||
|
||||
---
|
||||
|
||||
## Tactical RMM Integration Concept
|
||||
|
||||
Vestra Support is designed with an integration path for [Tactical RMM](https://github.com/amidaware/tacticalrmm) (an open-source Remote Monitoring and Management tool):
|
||||
* **Direct Launcher**: Integrating a "Vestra Remote" action button directly into the Tactical RMM workstation details view.
|
||||
* **Command Line Launching**: Passing the client's unique hardware ID and target relay configuration via command-line arguments to the technician viewer, bypassing manual copy-paste steps.
|
||||
* **Cross-linking**: Linking the machine ID in the RMM database with the active customer account and support ticket in the Vestra Portal.
|
||||
|
||||
---
|
||||
|
||||
## Relationship to RustDesk
|
||||
|
||||
Vestra Support is a **downstream distribution** of RustDesk:
|
||||
* **Upstream Sync**: The codebase will regularly pull security patches, performance improvements, and feature updates from the upstream RustDesk repository.
|
||||
* **Compatibility**: The underlying communication protocol, video/audio encoding, and networking architecture remain fully compatible with standard RustDesk components.
|
||||
* **Pre-configuration**: The main difference is the client configuration; Vestra Support client binaries are compiled with hardcoded, secure defaults for Vestra's private `hbbs` / `hbbr` server endpoints and public keys, removing manual setup steps for the user.
|
||||
|
||||
---
|
||||
|
||||
## Non-Goals for Version 1 (v1)
|
||||
|
||||
To ensure rapid deployment and project stability, the following features are explicitly out of scope for v1:
|
||||
* **No Protocol Changes**: No modifications to the underlying networking, handshake, or video-streaming protocols.
|
||||
* **No Custom Encryption**: Strict reliance on RustDesk's existing security implementation (NaCl/sodium and standard TLS).
|
||||
* **No Authentication Modifications**: Rely on the default ID/password and API token mechanism built into RustDesk without custom auth server modifications.
|
||||
* **No Platform Porting**: Focus exclusively on Windows and macOS clients for initial releases (Linux/Android/iOS clients will remain stock or deferred).
|
||||
|
||||
---
|
||||
|
||||
## Current Project Status
|
||||
|
||||
* **Phase**: Phase 0 (Scaffolding & Architecture Planning).
|
||||
* **Code State**: Repository fork has been successfully established and initialized.
|
||||
* **Documentation**: Main architectural designs, open-source compliance guidelines, and branding rules have been drafted.
|
||||
* **Next Step**: Deploying the test relay server infrastructure and validating stock RustDesk client connections against it (Phase 1).
|
||||
Loading…
Add table
Add a link
Reference in a new issue