Giter VIP home page Giter VIP logo

mumble-docker's Introduction

Mumble Docker

Mumble is a free, open source, low latency, high quality voice chat application.

Mumble WebsiteMumble Source

This is the official code of the Mumble Docker image for self-hosting the Mumble server. The image is available for download on Dockerhub.


Quick Start Guide

  1. Running the container
  2. Configuration
  3. Building the container

Running the container

Requirements

This documentation assumes that you already have Docker installed and configured on your target machine. You may find it more convenient to set up the Docker container using docker-compose. Thus, we also provide instructions for that scenario (see below).

In order for Mumble to store permanent data (most notably the database file (by default Mumble uses SQLite)), the image will use a volume which is mapped to the /data/ path inside the image. By default the image uses a user with UID 1000 and GID of also 1000 but either can be adapted when building the image yourself (see below). You will have to make sure that all file permissions are set up accordingly.

Running the container

Using docker:

$ docker run --detach \
             --name mumble-server \
             --publish 64738:64738/tcp \
             --publish 64738:64738/udp \
             --volume ./data/mumble:/data \
             --restart on-failure \
             mumblevoip/mumble-server:<tag>

For possible values of <tag> see below.

Using docker-compose:

services:
    mumble-server:
        image: mumblevoip/mumble-server:<tag>
        container_name: mumble-server
        hostname: mumble-server
        restart: on-failure
        ports:
            - 64738:64738
            - 64738:64738/udp
#       expose:
#           - 6502

For possible values of <tag> see below.

The additional port 6502 could for instance be used to expose the ICE interface. You'll obviously have to adapt the used port for whatever you configured in the server's configuration file.

Tags

For an up-to-date list of available tags, see Dockerhub. Generally, you can either use latest to always fetch the latest version or tags of the form vX.Y.Z corresponding to the respective stable releases of Mumble, e.g. v1.4.230.

Configuration

The preferred way of configuring the server instance in the Docker container is by means of environment variables. All of these variables take the form MUMBLE_CONFIG_<configName>, where <configName> is the name of the configuration to set. All config options that can be set in the regular Mumble server configuration file (historically called murmur.ini) can be set. For an overview of available options, see here.

<configName> is case-insensitive and underscores may be inserted into the respective config name, to increase readability. Thus, MUMBLE_CONFIG_dbhost, MUMBLE_CONFIG_DBHOST and MUMBLE_CONFIG_DB_HOST all refer to the same config dbHost.

The container entrypoint will use these environment variables and build a corresponding configuration file from it on-the-fly, which is then used the spun-up server.

You can specify these environment variables when starting the container using the -e command-line option as documented here:

$ docker run -e "MUMBLE_CONFIG_SERVER_PASSWORD=123"

As an alternative to environment variables, docker or podman secrets can be used to read configuration options from files which follow the MUMBLE_CONFIG_<config_name> name pattern and are located in the /run/secrets directory at runtime. The same rules to naming environment variables apply to these files as well.

Please consult the documentation of docker or podman on how to use secrets for further details.

Example: Running the container with secrets using podman

To set the server password and superuser password using podman secrets, the following series of commands can be used:

# Create the secrets
echo -n "secretserver" | podman secret create MUMBLE_CONFIG_SERVER_PASSWORD -
echo -n "supassword" | podman secret create MUMBLE_SUPERUSER_PASSWORD -

# Run the server with these secrets mounted
podman run --detach \
           --name mumble-server \
           --publish 64738:64738/tcp \
           --publish 64738:64738/udp \
           --secret MUMBLE_CONFIG_SERVER_PASSWORD \
           --secret MUMBLE_SUPERUSER_PASSWORD \
           --volume ./data/mumble:/data \
           --restart on-failure \
           mumblevoip/mumble-server:<tag>

Additional variables

The following additional variables can be set for further server configuration:

Environment Variable Description
MUMBLE_ACCEPT_UNKNOWN_SETTINGS Set to true to force the container to accept unknown settings passed as a MUMBLE_CONFIG_ variable (see note below).
MUMBLE_CUSTOM_CONFIG_FILE Specify a custom config file path - all MUMBLE_CONFIG_ variables are IGNORED
(it's best to use a path inside the volume /data/)
MUMBLE_SUPERUSER_PASSWORD Specifies the SuperUser (Admin) password for this server. If this is not given, a random password will be generated upon first startup.
MUMBLE_VERBOSE Set to true to enable verbose logging in the server

Note: In the unlikely case where a <configName> setting is unknown to the container, startup will fail with the following error.

mumble-server  | [ERROR]: Unable to find config corresponding to variable "<configName>"
mumble-server exited with code 1

The root cause of this error is the fact that this setting is incorrectly registered in the Mumble server code. You can workaround this error by setting the MUMBLE_ACCEPT_UNKNOWN_SETTINGS environment variable to true and spelling <configName> exactly as written in the Murmur.ini documentation.

Building the container

After having cloned this repository, you can just run

$ docker build .

in order to build a Mumble server from the latest commit in the upstream master branch.

If you prefer to instead build a specific version of the Mumble server, you can use the MUMBLE_VERSION argument like this:

$ docker build --build-arg MUMBLE_VERSION=v1.4.230 .

MUMBLE_VERSION can either be one of the published tags of the upstream repository or a commit hash of the respective commit to build.

Note that either way, only Mumble versions >= 1.4 can be built using this image. Mumble versions 1.3 and earlier are not compatible with the build process employed by this Docker image.

Using a different UID/GID

Additionally, it is possible to specify the UID and the GID of the mumble user that is used inside the container. These can be controlled by the MUMBLE_UID and MUMBLE_GID build variables respectively. This is intended to allow you to use the same UID and GID as your user on your host system, in order to cause minimal issues when accessing mounted volumes.

Using custom build options

It is also possible to pass custom cmake options to the build process by means of the MUMBLE_CMAKE_ARGS build variable. That way, you can customize the build to your liking. For instance, this could be used to enable the Tracy profiler (assuming you are building a version of the server that has support for it):

$ docker build --build-arg MUMBLE_CMAKE_ARGS="-Dtracy=ON"

For an overview of all available build options, check the build instructions of the main project.

Common build issues

Should you see the error

Got permission denied while trying to connect to the Docker daemon socket

you most likely invoked docker as a non-root user. In order for that to be possible, you need to add yourself to the docker group on your system. See the official docs on this topic for further information.

mumble-docker's People

Contributors

azlux avatar d3adb5 avatar fgma avatar krzmbrzl avatar maweil avatar pawlakm avatar restitux avatar tomcraft avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

mumble-docker's Issues

Remove PGID PUID Limitations

Broken bind mount access for Syn&QTS even with PGID=0, PUID=0, 
MUMBLE_GID=0, MUMBLE_UID=0, /data:770 (normally 660) and owned (docker running under UID=0, GID=0, forced requirement). Why is every docker trying to force running as 1000:1000+ when you can let the end user do what they need? So much hand-holding...*sigh* Breaking usability.

/entrypoint.sh: line 77: /data/mumble_server_config.ini: Permission denied

Simple Compose additions/ example

Hi,
thanks for the Re-Release!

I am currently struggeling with the Mumble LDAP Authenticator. The Server is currently Running 1 Release behind on Static x86.
In this Setup, i Build murmur & the LDAP Authenticator from the Git Tag of the Latest Release.

I have used the following Configs, but it doesn't seem to work.

The LDAP seems to can't connect to the murmur server and i cant figure out why. I have tried switching up the IPs (172.16.238.2 / 172.16.238.3) but that doesn't help at all.

docker-compose.yaml

version: "3.7"
services:
  murmur:
    build: ./mumble
    volumes:
    - $PWD/conf/murmur.ini:/etc/murmur/murmur.ini:ro
    - $PWD/murmur.sqlite:/var/lib/murmur/murmur.sqlite:rw
    - $PWD/log/murmur.log:/var/log/murmur/murmur.log:rw
    ports:
    - 6502:6502
    networks:
      ice:
        ipv4_address: 172.16.238.3
  murmur-ldap:
    build: ./mumble-scripts/Authenticators/LDAP
    volumes:
    - $PWD/conf/LDAPauth.ini:/app/LDAPauth.ini:ro
    - $PWD/log/LDAPauth.log:/var/log/murmur/LDAPauth.log:rw
    - $PWD/mumble/src/murmur/Murmur.ice:/app/Murmur.ice:ro
    networks:
      ice:
        ipv4_address: 172.16.238.2

networks:
   ice:
      driver: bridge
      ipam:
        config:
        - subnet: 172.16.238.0/24

LDAPauth.ini

. . . 
;Ice configuration
[ice]
host            = 172.16.238.3
port            = 6502
slice           = Murmur.ice
secret          = 4MST5yDtefksy3oLWMMNN
watchdog        = 30
. . . 

LDAPauth Dockerfile

FROM python:slim-bullseye
WORKDIR /app
COPY LDAPauth.py LDAPauth.py
RUN apt-get update -y && apt-get install -y libsasl2-dev python-dev libldap2-dev libssl-dev build-essential libbz2-dev
RUN pip3 install python-daemon python-ldap zeroc-ice
ENTRYPOINT python3 LDAPauth.py
EXPOSE 6502

murmur.ini

. . .
ice="tcp -h 172.16.238.2 -p 6502"
icesecretread=***********************
icesecretwrite=***********************
;identical

Could you Provide Official examples on how to set it up?

Unable to build when https://mumble.info is down

Hello, I tried building the image myself and I was unable to complete the build resulting in an infinite wait during the /mumble/repo/scripts/mumble-build-number.py command because the http://mumble.info/ website is down and never timing-out.

It would be great to not hard-depend on a service like this, possible solutions I see are:

  • be able to provide a build-number via build-args
  • quickly timeout to default to 0

Thank you for your work and have a nice day ! :)

ICE endpoint errors when used with mumo

Hi!

So I set up a stack with mumo and murmur, and with the default ice configuration to the loopback interface, mumo was not able to connect to the murmur ice instance.

I changed the ice config variable to the following, and mumo was now able to connect:
ice="tcp -h * -p 6502"

However, when I connect with a client that tries to register a callback with a mumo plugin, I get the following error:

Added Ice ServerCallback CB16627A-A7FC-47C4-96CE-29AB2AA38001 -o -e 1.0:tcp -h 127.0.0.1 -p 39125 -t 60000
Ice ServerCallback CB16627A-A7FC-47C4-96CE-29AB2AA38001 -o -e 1.0:tcp -h 127.0.0.1 -p 39125 -t 60000 failed
Removed Ice ServerCallback CB16627A-A7FC-47C4-96CE-29AB2AA38001 -o -e 1.0:tcp -h 127.0.0.1 -p 39125 -t 60000

I am unsure why it's even trying to register a server callback to the loopback interface, especially on random ports. I tried specifically setting the local IP as the ice IP as well, and it still tries to use 127.0.0.1.

Any ideas? Do I have to use ice published endpoints, and if so, the entrypoint.sh overwrites the ice settings on restart.

ARM build missing

Currently the ARM build aren't available on the Docker Hub.
Reasons :

  • Compilation with Openssl 3 is fix on upstream, but not released yet. So we cannot build on Ubuntu 22.04
  • Compilation with Ubuntu 20.04 isn't working on ARM (some lib are missing)
  • Compilation is working on 21.10, but this Ubuntu version is almost EOL (July, 2022), we don't want unsupported system.

This will be fix on next mumble-server release.

missmatch to dockerhub

Most probably you are already working on it and I am just too early/impatient... 😄 But the image on dockerhub does not seem to correspond to the current state of this repo. On the dockerhub image the entrypoint file is called docker-entrypoint.sh and is different to the entrypoint.sh in this rep.

All config environment variables are ignored

I run the mumble server with this docker compose file:

services:
  murmur:
    container_name: murmur
    image: mumblevoip/mumble-server:latest
    restart: always
    ports:
      - "49155:50051/tcp"
      - "64738:64738/tcp"
      - "64738:64738/udp"
    environment:
      MUMBLE_CONFIG_SERVER_PASSWORD: "mypassword"
      MUMBLE_CONFIG_WELCOME_TEXT: "My Welcome Text"
      MUMBLE_CONFIG_USERS: "8"
      MUMBLE_CONFIG_BANDWIDTH: "128000"

None of the settings seem to work. E.g. the log file shows:

Setting config "database" to: '/data/murmur.sqlite'
Setting config "ice" to: '"tcp -h 127.0.0.1 -p 6502"'
Setting config "welcometext" to: '"
Welcome to this server, running the official Mumble Docker image.
Enjoy your stay!
"'
Setting config "port" to: '64738'
Setting config "users" to: '100'
Running Mumble server as uid=1000 gid=1000
"/data" has the following permissions set:
drwxr-xr-x, owner: "mumble" (UID: 1000), group: "users" (GID: 100)
Command run to start the service : /usr/bin/mumble-server -fg -ini /data/mumble_server_config.ini
Starting...

As you can see the welcome text is not what was configured.

Possibility to read passwords from files

Hi there! Thanks for providing this awesome handy image :-)

To support Docker secrets [1], it would be great if it was possible to provide the values of SENSITIVE_CONFIGS kind variables from files instead as just values, similar to how database configurations work.

For example, instead of...:

MUMBLE_SERVERPASSWORD=oh_noes_i_m_leaking_this_to_the_docker_compose

...the idea would be to be able to supply...:

MUMBLE_SERVERPASSWORD_FILE=/run/secrets/mumble_serverpassword

Thus removing any secrets from docker-compose.yml, from docker run... bash history, and improving the support for docker swarm etc.

[1]
https://docs.docker.com/engine/swarm/secrets/

Cheers,
Kalsan

dockerized server with dockerized mysql server

The issue

I want dockerized server to use dockerized mysql server. but, it is using sqlite by default. I have changed the /auxiliary_files/mumble-server.ini file with appropriate value.
I guess it is because of the entrypoint.sh file where all configuration commands are for sqlite.
How can I change the file so that server get connected to mysql instead of sqlite?

Mumble version

1.5.0

Mumble component

Server

OS

Linux

Additional information

No response

Certificate errors when connecting from mumble desktop

Hi all, sorry if this isn't the proper place to ask this but I'm having issues. I installed the container through docker compose and got nginx properly configured for it, and it passes certification in a web browser. AM I doing something wrong? I'm using the desktop version in the ubuntu repos if age of the package makes a difference

How to setup an ssl certificate on docker mumble server?

The issue

I'm wondering if I could get some help with setting up my Mumble server with a ssl certificate. So that I don't have to convince my gaming friends I'm not trying to hack them when they get the "untrusted certificate" message.

So I recently installed a Mumble server using docker-compose.

Normally, I use Nginx Proxy Manager to set up ssl to the various services I'm running on my homeserver. It's a noob-friendly GUI. You click "add proxy", set the subdomain, forwarding up address and port, and then click "request ssl certificate". And voila, it works.

So my domain is "example.com" which points to my ISP ip address. Also all subdomains point to the same ip (A records are example.com and *.example.com). In the ISP router, ports 80 and 443 are forwarded to the VM running Nginx Proxy Manager. This is how it works now for plex, nextcloud, etc.

Could someone help me with which steps I should go through to basically get rid of the "untrusted certificate" message with the docker-based Mumble server? Adding a proxy in Nginx Proxy Manager and forwarding "mumble.example.com" to the ip and port the docker server is running on doesn't seem to work.

Thanks I advance!

Mumble version

Latest as of last week.

Mumble component

Server

OS

Linux

Additional information

No response

mumble docker image error

Description

hi folks

the latest docker image
mumblevoip/mumble-server:latest
wont work

docker log says:

exec /entrypoint.sh: exec format error

Steps to reproduce

run the current docker image

Mumble version

mumblevoip/mumble-server:latest

Mumble component

Server

OS

Linux

Reproducible?

Yes

Additional information

No response

Relevant log output

No response

Screenshots

No response

Accept options not existing in `/etc/mumble/bare_config.ini` and log warning instead of exiting with error

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.

Logs do not seems to be written to a log file

Version

latest tag (digest c19e948b9790)

The issue

The server log file does not seem to be created regardless of passing or not the logfile option as an environment variable. In both cases, when connecting to the container, no log file can be found in /var/log/ nor in /data nor in the directory specified by the environment variable.

Connecting to the container as root and running a "find" does not yield any result.

When passing a MUMBLE_CONFIG_LOGFILE: /data/murmur.log environment variable in my docker-compose.yml file, the variable is correctly set into /data/mumble_server_config.ini however the /data/murmur.log file is never created and as such logs are not written to it.

It is not a volume / access rights issue (for instance the db file is correctly mounted / created / modified + logging into the container as "mumble" user and executing touch where the logfileshould be located creates the file with no issue, however nothing is written to it later even if the file is created manually.)

it seems that murmur forces itself to foreground mode which logs to the console and not to a file or that something is missing to allow it to write logs.

Tried both with docker-compose up and docker-compose up -d with no difference.

CONFIG_FILE is readonly, preventing the use of a custom config file

Hi,

I imported my existing config when I migrated from a standalone server installation to docker.

Yesterday's update broke my installation. At first I thought it was due to the UID, so I had to change my system for it to match the values of 1000/1000, but that didn't fix anything.

When reading the new commit for the entrypoint.sh, 6a9d8f5

The variable CONFIG_FILE is set as readonly.

Therefore, the code at lines 58ish can't work :

if [[ -f "$MUMBLE_CUSTOM_CONFIG_FILE" ]]; then
	echo "Using manually specified config file at $MUMBLE_CUSTOM_CONFIG_FILE"
	echo "All MUMBLE_CONFIG variables will be ignored"
	CONFIG_FILE="$MUMBLE_CUSTOM_CONFIG_FILE"
else

Because the variable is readonly...

Can you revert that commit or correct the problem please ?

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.