Currently the default behavior of entrypoint.sh is to exit with error when an MUMBLE_CONFIGURATION_ option is set in the docker-compose.yml file but is not existing in /etc/mumble/bare_config.ini which is copied from upstream /scripts/murmur.ini.
While I understand the rationale behind this approach, the problem with this behavior is that if a valid option is missing from /etc/mumble/bare_config.ini then it cannot be set in docker_compose.yml. From an end user perspective, this is quite annoying. I have currently two examples of missing configurations: listenersperchannel and listenersperuser.
IMHO a better approach would be to set provided options even if they are missing in /etc/mumble/bare_config.ini and instead of an error log a warning stating that as the configuration option is missing in the bare-config, it's not sure that it will be correctly applied and as such it's user's responibility to verify it.
This would allow to make mumble-docker more robust to this type of issues in upstream project.
Note: if I'm not wrong, if the user provides his own mumble configuration file instead of going the MUMBLE_CONFIGURATION_ way, not existing options in /etc/mumble/bare_config.ini are accepted anyway.
Krzmbrzl
commented
2 years ago
Currently the default behavior of entrypoint.sh is to exit with error when an
MUMBLE_CONFIGURATION_option is set in thedocker-compose.ymlfile but is not existing in/etc/mumble/bare_config.iniwhich is copied from upstream /scripts/murmur.ini.While I understand the rationale behind this approach, the problem with this behavior is that if a valid option is missing from
/etc/mumble/bare_config.inithen it cannot be set indocker_compose.yml. From an end user perspective, this is quite annoying. I have currently two examples of missing configurations:listenersperchannelandlistenersperuser.IMHO a better approach would be to set provided options even if they are missing in
/etc/mumble/bare_config.iniand instead of an error log a warning stating that as the configuration option is missing in the bare-config, it's not sure that it will be correctly applied and as such it's user's responibility to verify it.This would allow to make
mumble-dockermore robust to this type of issues in upstream project.Note: if I'm not wrong, if the user provides his own mumble configuration file instead of going the
MUMBLE_CONFIGURATION_way, not existing options in/etc/mumble/bare_config.iniare accepted anyway.