no shell in latest version? (docker exec -ti hbbr /bin/bash not possible)

[kangaroo72]

I'm unable to enter the containers hbbr/hbbs in the latest version from rustdesk-server
Is it a bug or a feature?

[paspo]

a feature: it reduces attack surface.
The "classic" docker images are based on "scratch" images, which means there's practically zero overhead. We can do that because Rustdesk Server binaries are statically linked and don't need extra dependencies.
If for some reason a Rustdesk Server binary gets compromised/used to get into the server, there's no other binary in that image to exploit, so the effectiveness of the attack is greatly reduced.

[hueldoeu]

you should start an easy tutorial to start our own rustdesk-server. this week rustdesk was totally unuseable for the servers (2) being offline. i thought it was because of my router-configuration but no! it was your servers.

[kangaroo72]

I never used the public servers. This is the biggest advantage of RD - the selfhosted way.
Months ago, I used the native way, but today I'm using the docker-compose.yml
The guide is okay. All you need, is here

[hueldoeu]

I never used the public servers. This is the biggest advantage of RD - the selfhosted way. Months ago, I used the native way, but today I'm using the docker-compose.yml The guide is okay. All you need, is here

can i use your server so far until i have set up my own?

[kangaroo72]

Sorry, I don't want to use my server for public reasons.

[hueldoeu]

Sorry, I don't want to use my server for public reasons.

would you help me through skype and any remote desktop software? i can pay you.

[kangaroo72]

Where're you comin' from? I'm planning a guide in german. Maybe this will help you?
What Operating System/Hardware are you using?

[hueldoeu]

Where're you comin' from? I'm planning a guide in german. Maybe this will help you? What Operating System/Hardware are you using?

yes germany. Windows Server 2022. ryzen 7900x. 64 gb ram. i can use the same system with win10/11 too.

[kangaroo72]

Hmm... I don't have a glue from a windows-setup. Is there a running docker-system?
If so, U should use the yml-file above. But there're are various things. Maybe dyn-dns e. g.
Too many unknown variables, sorry.
I'm working only on Linux/Mac.
My guide is planned for Linux.

[hueldoeu]

Hmm... I don't have a glue from a windows-setup. Is there a running docker-system? If so, U should use the yml-file above. But there're are various things. Maybe dyn-dns e. g. Too many unknown variables, sorry. I'm working only on Linux/Mac. My guide is planned for Linux.

ok then. write it for linux, i will adapt it to the newest linux mint.

[kangaroo72]

I don't know when I'm writing (I'm very busy). But the most important is the yml-file above.
I will not explain, how to setup docker, 'cause it takes too much time to explain from scratch.
If you know how to run docker and how to open ports, that's it.
Btw. Mint is only a Ubuntu with GUI. RD-Server usually runs headless.

[alx-xlx]

a feature: it reduces attack surface. The "classic" docker images are based on "scratch" images, which means there's practically zero overhead. We can do that because Rustdesk Server binaries are statically linked and don't need extra dependencies. If for some reason a Rustdesk Server binary gets compromised/used to get into the server, there's no other binary in that image to exploit, so the effectiveness of the attack is greatly reduced.

@paspo because of no shell in it the docker healthchecks is completely unusable. Can you please include the shell with curl or wget so the healthchecks can be done ?

[paspo]

@paspo because of no shell in it the docker healthchecks is completely unusable. Can you please include the shell with curl or wget so the healthchecks can be done ?

You're parialtly right.

The healthchecks you see almost everywhere are based on curl to check if an URL is responding with an expected text. This is ok for a web application or for a diagnostic endpoint of a server, but we don't have either of those here.
So, even with a shell and curl available, you woulnd't get any meaningful information about the status of a running instance.

The best solution will be a diagnostic endpoint for each (hbbr and hbbs) binary, and a tool for checking these endpoints (curl or something else).

The faster (to implement) solution will be to add a healthcheck command to rustdesk-utils (or create a dedicated healthcheck binary, it's mostly the same) and include this binary in the final image.

The downside is that with this approach you can only test for running processes and open ports, which is "incomplete":

• if the main process is not running, the container is restarted anyway
• if the process is listening on the correct ports but the ports aren't exposed on the host, you can't see that from inside the container (that's why you should monitor your services with an external tool)
• you still can't check for key mismatch which seems to be one of the most frequent issues

Given all that, I'm not trusting container healthchecks for the health status of my rustdesk server; I check for open ports from an external system and I monitor container logs for these containers.
I hope someday we'll have a /diagnostics and a /metrics endpoint to have a more comprehensive status.

I'm still against having curl inside these images because in case of compromission it can be used to download extra binaries.
Please remember that a rustdesk server is a good candidate for malicious actors as it can give'em access to a lot of systems; security should be top priority.

[alx-xlx]

The faster (to implement) solution will be to add a healthcheck command to rustdesk-utils (or create a dedicated healthcheck binary, it's mostly the same) and include this binary in the final image.

I am using sablier which auto starts a docker container when it detects network queries. And it depends on the docker healthchecks.

Can you include a healthcheck command in the final image for both the ccontainers ??