linuxserver/docker-code-server

Does the "bind-addr" only can be set at container create?

Closed this issue · 2 comments

dxkrs commented

Is this a new feature request?

  • I have searched the existing issues

What I see now

code-server has a default config file ~/.config/config.yaml(actually /config/.config/config.yaml in here). The recommended docker-compose show the comand of mouting the /config, so I try to edit the bind-addr in that config.yaml after I first create the container, then try to restart the container but it seems not work.

I tried to find the reason, the s6-supervise run the code-server during the container creating, the run script set the --bind-addr option on the code-server running command, for code-server, this maybe cover the config file setting then the config file looks like not work.

Suggestion

Like the PROXY_DOMAIN environment which is a optional setting in the docker cli or docker-compose, it will be set empty string if not set this environment in the run script. I think, the bind-addr should do that, and we can set the default value at the config file, not in the run script!
Analogously, the user-data-dir,extensions-dir which about the setting for the code-server, they can be default set in the config file, not in runing command. Of course, for keep using friendly, they also can be set in the code-server runing command when the user set these environment with not empy string in the docker cli or docker-compose.

github-actions commented

Thanks for opening your first issue here! Be sure to follow the relevant issue templates, or risk having this issue marked as invalid.

aptalca commented

We set it in the service file to make sure it binds to the correct address and port inside the container and works out of the box. If you need to customize it, you either are using it in an unsupported manner, or you have an edge case.

You can customize the service file yourself to override it: https://www.linuxserver.io/blog/2019-09-14-customizing-our-containers

But the answer to the question should it be user customizable? is No. That was not the intended design. We standardize the required settings to ensure it works out of the box and that we can provide adequate support. Optional features/settings (like the PROXY_DOMAIN) are left to the user to decide.