rustdesk-server/RUNBOOK.md

# 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):

```bash
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:

1. Confirm `docker compose ps` shows `hbbs` and `hbbr` healthy (`cd /opt/rustdesk`).
2. 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):

```bash
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

1. Create a volume from the desired snapshot in `us-east-1a`.
2. Detach the current `rustdesk-data` volume (stop the instance first).
3. Attach the restored volume at `/dev/xvdf`, tag `Name=rustdesk-data`, start the instance.
4. 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

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