Public Key: 8BLLhtzUBU/XKAH4mep3p+IX4DSApe7qbAwNH9nv4yA= You can use docker environment variables to store the keys. If you provide no keys, hbbs will generate one for you, and it'll place it in the default location. Then the validity of the keypair is checked: if public and private keys doesn't match, the container will stop.
On container startup, the presence of the keypair is checked ( /data/id_ed25519.pub and /data/id_ed25519) and if one of these keys doesn't exist, it's recreated from ENV variables or docker secrets. You can obviously keep the key pair in a docker volume, but the best practices tells you to not write the keys on the filesystem so we provide a couple of options. Secret management in S6-overlay based images If set to "1" unencrypted connection will not be accepted The IP address/DNS name of the machine running this container 21119:21119 image: rustdesk/rustdesk-server-s6:latest environment:įor this container image, you can use these environment variables, in addition to the ones specified in the following ENV variables section: variable You can start these images directly with docker run with this command: The S6-overlay acts as a supervisor and keeps both process running, so with this image there's no need to have two separate running containers. You're strongly encouraged to use the multiarch image either with the major version or latest tag. Rustdesk/rustdesk-server-s6:latest-arm64v8 They're available on Docker hub with these tags: architecture These images are build against busybox:stable with the addition of the binaries (both hbbr and hbbs) and S6-overlay. (docker-compose credit goes to and S6-overlay based images You can also edit the volume lines (line 18 and line 33) if you need. 21119:21119 image: rustdesk/rustdesk-server:latest command: hbbr volumes:Įdit line 16 to point to your relay server (the one listening on port 21117). 21118:21118 image: rustdesk/rustdesk-server:latest command: hbbs -r :21117 volumes:
0 kommentar(er)
