Archived

This repository has been archived on 2026-08-04. You can view files and clone it, but cannot push or open issues or pull requests.

Adam Moussa f56b8f3d4e

docs: decommission rustdesk-server (stack torn down 2026-07-27)

Stack rustdesk-server (328440206208/us-east-1) fully deleted: EC2, EIP
100.27.82.124 (released), SG, launch template, IAM roles, DLM policy,
both Route53 records. Orphaned data volumes deleted with no snapshot
(explicit owner decision — no backups exist). Secrets force-deleted,
SSM params deleted, OIDC deploy role + repo secret removed.

Removes all GitHub automation (workflows, dependabot) ahead of repo
archival; README carries the decommission banner, RUNBOOK marked
obsolete. Adds a repo-local suppression for the aws-cdk-lib-bundled
brace-expansion advisory (unfixable upstream, repo archived).

2026-07-27 12:14:26 -04:00

3.2 KiB

Raw Blame History

RustDesk Server — Runbook

Obsolete as of 2026-07-27 — the rustdesk-server stack no longer exists; this runbook is retained for historical reference only.

Operational procedures for the rustdesk-server stack. Account 328440206208, us-east-1.

Access

The instance is SSM-managed (no inbound SSH):

aws ssm start-session --target <instance-id> --region us-east-1

Find the instance: aws ec2 describe-instances --filters Name=tag:Name,Values=rustdesk-server.

The data volume (read this before any redeploy)

All durable state — the id_ed25519 server key pair and the sled database — lives on the standalone EBS volume rustdesk-data, mounted at /var/lib/rustdesk, attached at /dev/xvdf.

It is declared as a separate ec2.Volume with RemovalPolicy.RETAIN, not an inline blockDevice. This is deliberate: an inline data volume gets replaced whenever CloudFormation replaces the instance, which would destroy the server key and force every client to re-trust the host.
userdata/bootstrap.sh mounts the existing filesystem and only runs mkfs when blkid reports the device is blank, so reattaching to a fresh instance preserves data.
Before any change that may replace the instance (AMI bump, instance-type change), confirm a recent EBS snapshot exists and that the key pair is mirrored to rustdesk/server-key-pair.

Instance replacement

A replaced instance reattaches the same RETAINed volume and remounts it without reformatting, so the server key and DB are preserved. After replacement:

Confirm docker compose ps shows hbbs and hbbr healthy (cd /opt/rustdesk).
Confirm clients still connect without re-accepting a new key.

Server key pair

hbbs generates /var/lib/rustdesk/id_ed25519 (private) and id_ed25519.pub (public) on first boot. The public key is the fingerprint clients must trust.

Mirror after first deploy / after any intentional rotation. Read the key with fileb:// so it never lands in process argv (ps//proc), shell history, or the terminal (which SSM session logging would capture):

sudo aws secretsmanager put-secret-value \
  --secret-id rustdesk/server-key-pair \
  --secret-string fileb:///var/lib/rustdesk/id_ed25519 \
  --region us-east-1

Run this from an environment that holds secretsmanager:PutSecretValue — the instance role only has GetSecretValue, so either configure operator credentials on the box first, or pull the key off the host over SSM (without echoing it) and push it from your workstation. Never cat the private key to the terminal.

To rotate the key (forces all clients to re-trust): stop the containers, delete id_ed25519*, restart, re-mirror, redistribute the new public key.

Restore from snapshot

Create a volume from the desired snapshot in us-east-1a.
Detach the current rustdesk-data volume (stop the instance first).
Attach the restored volume at /dev/xvdf, tag Name=rustdesk-data, start the instance.
Verify the key pair and DB are present and containers come up healthy.

Pro license

Activated in the web console (http://rustdesk.seahaven.com:21114). Keep the key in rustdesk/pro-license.

Logs

cd /opt/rustdesk && docker compose logs -f hbbs hbbr

3.2 KiB Raw Blame History