additional-config-options #3
Reference in New Issue
Block a user
No description provided.
Delete Branch "additional-config-options"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Adding passwords and various config options from https://github.com/mumble-voip/mumble/blob/master/auxiliary_files/mumble-server.ini .
Passwords
mumble-docker reads certain config values from
/run/secrets/, so we set the SuperUser password and server password using this method.server-config.ini
mumble-dockeralso reads config values from env variables namedMUMBLE_CONFIG_*. Importantly, when a variable is set but empty, the corresponding config value is overwritten with an empty string. Therefore we have to provide default values incompose.yml.The following options are not included, for now:
*ssl*: adding support for certificates needs to be a larger project, it's non-trivialdatabase,*db*,*sqlite*: as above, for databases*ice*: I'm unclear how ZeroC Ice works, decided to skip for now*log*: logs aren't visible outside the containerThe following options should probably never be included:
port,host,uname,pidfile: unneccessary in a container environmentlegacyPasswordHash: unsecure (could be set with a custom compose file if someone really needs it)forceExternalAuth: undocumentedChecklist
abra.shlooks great!
nice to have the full set of configs too and server password as a secret in its own compose file
my only stylistic question would be that because MUMBLE_ was removed from all the config values, there is more of a possibility of a collision with another environment variable set by something else. for example if abra injected an environment variable that happened to collide. but I don't think its a necessary change or one I would even recommend, but it did pop into my head while looking at the diff. from looking at a couple other recipes, it doesn't look like other recipes prefix env vars very often, so maybe since its within an app-specific container, there are just not many chances of a collision