Add rustdesk server to dietpi-software

[JappeHallunken]

I added rustdesk server OSS version (https://github.com/rustdesk/rustdesk-server) which is somewhat requested from users

It creates 2 systemd services, one for the relay server and one for the signaling server.
Both services can be configured via env files, the available options are listed here: https://github.com/rustdes~k/rustdesk-server/blob/c6502179/README.md#env-variables and it need's to be in ini format, like PORT=22222. Sections can be ommited.
The env files are located in /mnt/dietpi_userdata/rustdesk, working directory is /opt/rustdesk.

On the first start, right after the installation, it will generate a private and public key, both located in the working directory. The public key is needed for the clients for connection to the signal and/or relay server.
It also comes with rustdesk-utils, it can generate new key pairs, validate them and can do a basic "health check". (It checks if the API is running, which the OSS version does not need. It can also check if the configured ports are reachable.)

I tested it on a RPi3B to connect a Windows PC to my Fedora Laptop. It works in both directions, but controlling the Laptop from the Windows machine is not really possible, wayland support is still experimental. But the installation is working tho.

Reinstallation does not overwrite the .env files, so configs are preserved. ✔️

To test that the environment files actually work, I changed the listening ports for both services. ✔️

Tomorrow I will config rustdesk to force-use the relay server, because I just tested inside my LAN and then it will use a P2P connection between the clients, no relay needed. So let's see how capabale a RPi3B is for this task. But I guess no problem with only 2 clients.

[JappeHallunken]

So, sending on 1440p display (while a video is playing) to my laptop, and force-using the RPi3B as relay (ALWAYS_USE_RELAY=Y), I get the following:

 PID USER     PROGRAM                                DEV         SENT      RECEIVED
    496 rustde.. /opt/rustdesk/hbbr                     eth0      307.171     303.360 kB/s

It uses around 5% CPU time and 8 threads.
VmRSS says 1856 kB, lol what? :D

I also got it working other way around today, with Fedora as host (but I didn't change anything so dunno what went wrong yesterday)
The Fedora host needs around 200mb of memory tho.

I will also install a desktop on the RPi 3B and will make a test, when itÄs the host.

[MichaIng]

Coincidentally @StephanStS and me were testing this pretty recently, and since it was so straight forward, I thought about adding it myself soon 😄. Great peace of software, and we should add the clients (maybe wrong word*) pretty soon as well.

*For everyone who used RustDesk already and is wondering what these servers are for: It is the optional signaling+relay servers that can be used instead of depending on the public ones provided by RustDesk. You will see some notice at the bottom of the GUI that this is suggested to increase bandwidth. The signaling server is used to establish the connection between the peers, in case authentication etc, and the relay server is used in case one of the peers is behind a (different) NAT: In that case they cannot do a P2P connection, but all data is relayed through the relay server instead. I.e. it is like a proxy, or what a TURN server does for WebRTC/video calls.

And yeah, pretty efficient thanks to Rust 🙂.

We tested the Docker container, their installer (which downloads the archives), and the deb packages they provide. @JappeHallunken any reason you did not use the deb packages?

[MichaIng]

@copilot please fix the indentation of the added code for us. Align it with the way it is done in surrounding code sections.

[Copilot]

@MichaIng I've opened a new pull request, #7843, to work on those changes. Once the pull request is ready, I'll request review from you.

[StephanStS]

Some more info (mainly for the docs) from my side:

1. Moving a rustdesk instance to a different hardware
   This can also be a different architecture, like moving a rustdesk instance from Raspberry Pi 5 to a Proxmox VM.
   You can preserve the relay server login keys by just copying the files /opt/rustdesk/id_ed25519 and /opt/rustdesk/id_ed25519.pub to the new server.
   Then you only have to restart rustdesk via systemctl restart rustdeskrelay rustdesksignal oder easily reboot.

2. Showing installed server versions
   This can be achieved via (a lousy script, e.g. named ShowRustdeskVersions.sh)

   #!/bin/bash
   /opt/rustdesk/hbbr -V
   /opt/rustdesk/hbbs -V

3. General architecture overview
   To understand the relay and signaling server and the connection establishment, just look there: https://github.com/rustdesk/rustdesk/wiki/How-does-RustDesk-work%3F

[JappeHallunken]

@copilot please fix the indentation of the added code for us. Align it with the way it is done in surrounding code sections.

Just out of curiosity:
The different "rendering" of the intendation is bc of my shiftwidth / tabstop settings in my editor? Bc on my machine the indentations look correct.

[MichaIng]

The pain with the tab indentation:

• You seem to have 2 spaces per tab
• The GitHub web UI shows 4 spaces per tab
• I use 8 spaces per tab in my notepad++ 😄

[MichaIng]

Annoying that the environment variables are nowhere documented anymore. Why the hack have they been removed from the readme? Only way is to search the code: https://github.com/search?q=repo%3Arustdesk%2Frustdesk-server%20%2Fstd%3A%3Aenv%3A%3Avar%2F&type=code
But this search skips too large files. Some of them earlier documented here are missing, not sure whether gone or in a too large file or what 😄.

[MichaIng]

Test installs: https://github.com/MichaIng/DietPi/actions/runs/19839816223
Will also add service and port tests to our CI later.

[StephanStS]

Used the branch feature/add-rustdesk in /boot/dietpi.txt and installed the rustdesk server on a VM with 1 CPU and 256 MB RAM. I then also took over the id_ed25519 files from my actual running system and switched over to the new installation.

Works fine at first sight.

[MichaIng]

ERROR [libs/hbb_common/src/config.rs:538] Failed to store  config: Failed to create directory

Looks like it tries to store the config in the executable's dir rather than the working dir.

EDIT: Nope, doesn't go away with /opt/rustdesk write access. Then maybe its /nonexistend home dir?

EDIT2: Jep:

root@VM-Trixie:~# l /mnt/dietpi_userdata/rustdesk/.config/rustdesk/RustDesk.toml
-rw------- 1 rustdesk rustdesk 145 Dec  2 01:16 /mnt/dietpi_userdata/rustdesk/.config/rustdesk/RustDesk.toml

But we can set the config path explicitly, so it is not that nested.

EDIT3: Nope, the -c option does not work. If set or not, if pre-created or not, it still keeps trying to create ~/.config/rustdesk/RustDesk.toml and use that.

EDIT4: Looks like the -c option is an obsolete option for the INI file used before env vars were possible, and not related to this TOML: rustdesk/rustdesk-server#453

[MichaIng]

INFO [src/relay_server.rs:84] Listening on websocket :21119
INFO [src/rendezvous_server.rs:103] Listening on websocket :21118

Looks like websockets work with OSS version as well? Signalling port 21116 is listened on UDP as well, and 21115 as additional NAT testing port, I guess to check whether the relay server is needed for a particular connection.

[JappeHallunken]

-c option only works for the hbbs binary, hbbr only supports env variables or an env file. That's why I set EnvironmentFile=$rd_data/hbbs.env, so we have both uniform, and not just one started with -c flag.

/opt/rustdesk/hbbs -h
hbbs 1.1.14
Purslane Ltd. <[email protected]>
RustDesk ID/Rendezvous Server

USAGE:
    hbbs [OPTIONS]

FLAGS:
    -h, --help       Prints help information
    -V, --version    Prints version information

OPTIONS:
    -c, --config <FILE>                   Sets a custom config file
    -k, --key <KEY>                       Only allow the client with the same key
        --mask <MASK>                     Determine if the connection comes from LAN, e.g. 192.168.0.0/16
    -p, --port <NUMBER(default=21116)>    Sets the listening port
    -r, --relay-servers <HOST>            Sets the default relay servers, separated by comma
    -R, --rendezvous-servers <HOSTS>      Sets rendezvous servers, separated by comma
    -M, --rmem <NUMBER(default=0)>        Sets UDP recv buffer size, set system rmem_max first, e.g., sudo sysctl -w
                                          net.core.rmem_max=52428800. vi /etc/sysctl.conf, net.core.rmem_max=52428800,
                                          sudo sysctl –p
    -s, --serial <NUMBER(default=0)>      Sets configure update serial number
    -u, --software-url <URL>              Sets download url of RustDesk software of newest version

/opt/rustdesk/hbbr -h
hbbr 1.1.14
Purslane Ltd. <[email protected]>
RustDesk Relay Server

USAGE:
    hbbr [OPTIONS]

FLAGS:
    -h, --help       Prints help information
    -V, --version    Prints version information

OPTIONS:
    -k, --key <KEY>                       Only allow the client with the same key
    -p, --port <NUMBER(default=21117)>    Sets the listening port

I also don't get why some stuff is only availble via flag, and other via env variable.
https://github.com/rustdesk/rustdesk-server/blob/c6502179/README.md#env-variables

[MichaIng]

Yeah, since hbbs also generates the TOML, I though the setting was related to that one. But instead it seems to be an obsolete alternative to the environment variables.

Clients connections do not produce logs, do they? Otherwise we could reduce the log level to warnings by default.

[JappeHallunken]

The signaling server does not log anything beside when it's sarted. I guess this only available in the pro version.
The relay server tho shows some info when it's in use.

[MichaIng]

What I would want to disable by default is log messages which contain IP or other identifying info about the connected peers. Warnings and errors make sense, also the startup info logs which contain info about version, parsed args/config, and used ports etc are good. But something like access logs can be seen as privacy concern, aside of bloating journalctl.

[JappeHallunken]

Here a sample output from hbbr log:

Dez 02 22:28:35 TestPi3B hbbr[498]: [2025-12-02 22:28:35.577053 +01:00] INFO [src/relay_server.rs:452] New relay request 12ed0175-8697-4e0b-9745-36b8e4727582 from [::ffff:192.168.178.43]:28737
Dez 02 22:28:35 TestPi3B hbbr[498]: [2025-12-02 22:28:35.580561 +01:00] INFO [src/relay_server.rs:436] Relayrequest 12ed0175-8697-4e0b-9745-36b8e4727582 from [::ffff:192.168.178.57]:41683 got paired
Dez 02 22:28:35 TestPi3B hbbr[498]: [2025-12-02 22:28:35.580622 +01:00] INFO [src/relay_server.rs:442] Both are raw

So it would contain IPs

[StephanStS]

Tested the version from today by executing this:

• backup of id_ed25519 and id_ed25519.pub
• uninstall my rustdesk installation
• check the uninstall (directories, services)
• update via dietpi-update -1
• install rustdesk new via dietpi-software install 12
• restore id_ed25519 and id_ed25519.pub
• restart services via systemctl restart rustdesksignal.service rustdeskrelay.service
  Works again at first tests.

[MichaIng]

Hmm, startup messages would be indeed entirely gone. What do you think, are they relevant enough to leave info logs enabled? On first connection of a peer, the signal server emits a log as well:

INFO [src/peer.rs:102] update_pk 230985751 [::ffff:192.168.1.34]:59622 b"e0d2d29e-97b9-4136-b0ac-1743040f8e9b" b"z\xca\xbb\xba\x14X\xfc\xc9\xc8\x03\xae_\xae\xba\xa6\xad=R\xf9Oe\x0bj\xd8\xbf\x17S\xa9H\x1d\xed?"

But I mean for testing and in case debugging, this is actually fine. I would just switch to RUST_LOG=warn once things work. But should be fine to just expose this option to users.

More points:

• Shall we change the syslog identifier (hbbs/hbbr) to e.g. rustdesksignal and rustdeskrelay, or even RustDesk Signal Server respectively? Sadly we cannot remove the doubled timestamps from the increasing log line length. That requires changing the Rust log builder options in the code, hence a dedicated setting, other than the native RUST_LOG.
• Shall we add the settings commented out, with defaults and description to the two env files?
• If we adjust the syslog identifier, we might also want to change the env file names, so we effectively banned those weird hbbs/hbbr names. I wonder what they stand for, other than "s" for signal and "r" for relay (which is also just my assumption 😄).

And some info regarding the websocket ports: While both servers bind to them, they cannot be used: when enabling the WebSocket option at the client, connection does not work anymore but hangs at "establishing connection ...", without any log message at the server(s). Weird that the OSS version builds bind to those ports at all, and that they cannot be changed or disabled in any way.

[JappeHallunken]

• Shall we add the settings commented out, with defaults and description to the two env files?

Yes, even though we will link the official documentation in the docs, questions about the options will still arise. It's a preventative measurement 😅

• Shall we change the syslog identifier (hbbs/hbbr) to e.g. rustdesksignal and rustdeskrelay, or even RustDesk Signal Server respectively?

Another yes from me, hbbs and hbbr is too unspecific for the average user.
Sometimes the devs use hbbs - RustDesk ID/Rendezvous server | hbbr - RustDesk relay server but sometimes also Signaling instead of ID/Rendevouz.
Since we do not plan to rename the binaries (right?) I would chose Signaling and Relay, so it's somewhat identifiable.

• If we adjust the syslog identifier, we might also want to change the env file names, so we effectively banned those weird hbbs/hbbr names. I wonder what they stand for, other than "s" for signal and "r" for relay (which is also just my assumption 😄).

Yea, to be consequent we would need to change this too.

---

And about the websockets:
TLDR;
You need the PRO version and build a custom client with websocket allowed option
https://github.com/rustdesk/rustdesk/wiki/FAQ#how-to-make-rustdesk-work-properly-in-restricted-network-with-80443-only

My guess is they started implementing a lot if this nice features and then made the decision to hid them in the PRO version. But Maybe websockets would be possible in the OSS version with custom client build?

---

Aaand about hbbr and hbbs 😅
My quick recherche found:

This is just a guess - I haven't been closely following the above discussion so it should be double-checked?
hbbs: heartbeat and broker server
hbbr: heartbeat and broker relay

rustdesk/rustdesk#594 (comment)

Another idea is, that it's a reference to the name of the Rustdesk founder, "Huabing".

[MichaIng]

Okay, I'll add the changes tomorrow if still open.

Good to know that others are wondering about these names as well, and sad to see that devs are not communicative at all on GitHub issues, discussion, and even discord. All seems pretty dead, if not multiple users discussing (and guessing around 😄). The abbreviations are still in their docs, but they are only of minimal use, the part about configuring the client. And the page about the DNS loopback, though we should cover this our end with 2 sentences instead of a whole page.

About websockets: yeah, all good that this is a Pro feature. But why do the OSS builds then startup two TCP listeners for those websocket ports? As if splitting OSS and Pro was still a WIP. I cannot hold back but will check their code and try to implement a bunch of changes 😅.

[JappeHallunken]

Done, but now I also found this very helpful comment in a discussion:
rustdesk/rustdesk-server#371 (comment)
But it's so late now and IDK if it's worth to add all of them as examples to the configs.

[MichaIng]

So, I researched a bit more about the env vars, added all defaults and clarified the meaning of some. E.g. this KEY setting was pretty unclear, but the code shows that in case of an empty value, -, or _, one is auto-generated (the id_ed25519.pub we know) and used. If any other value is given, the server generates a matching private key internally for that public key for encrypted traffic to work.

My goodness, their (open source) community caring is absolute zero 😄.

And I removed the RELAY_SERVERS variable, which seems to be relevant for the Pro variant only. Even if the OSS variant supports multiple relay servers, it does not make so much sense unless we separate relay and signal servers into dedicated software options.