From Mumble Wiki
Revision as of 02:25, 12 March 2011 by Fwaggle (talk | contribs) (Exhaustively document Murmur.ini, including hidden settings :D)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Murmur's configuration file (murmur.ini) consists of single line configuration settings, in the format of key=value. Empty lines and anything after # to the end of a line are ignored.

Some settings are process-wide (database, etc) while others are used as defaults on a per-server basis. registername for example will be used as the default "title" for all virtual servers, unless it's overridden via RPC.

A unique example is port - the first server will attempt to bind to this port, with each subsequent server incrementing the port by one for it's own port.

Database Configuration

There are other options not listed below, namely: dbUsername, dbPassword, dbHost, dbPrefix, dbOpts, and dbPort. These options have different meanings depending on the database engine used, and explaining them is outside the scope of this document.


If dbDriver is QSQLITE (the default), this setting will specify the path to the database file. Other database drivers will use this setting for their own purposes -with QMYSQL it will set the database name.



The database backend that Murmur will use for storage of persistent data. The default is QSQLITE, which is the SQLite database driver. Murmur does it's best to speak sensible, standards-compliant SQL - so you may have luck with any of the other database drivers supported by QSql - but note that SQLite is the most tested configuration followed very distantly behind by MySQL.

RPC Configuration


Murmur has deprecated support for control via D-Bus. It's poorly documented, new features aren't added to it, and it's possible it could be removed at some point in the future. To activate it simply uncomment the following line:



This setting allows you to configure a distinct service name for this Murmur process on the D-Bus. It's really only useful if you have multiple Murmur processes that share the same D-Bus.



Murmur supports extensive RPC via ZeroC Ice, and the ice setting specifies the "endpoint". More information on configuring Ice Endpoints can be found in the ZeroC Ice documentation.

Note that all virtual servers share an Ice service, and without secrets configured anyone with access to the Ice port has full administrative access to every virtual server on the Murmur process. It's not recommended it's exposed to the world for that reason, it's recommended you protect the service via a firewall and configure Ice Secrets below.

The default will cause Ice to listen on TCP port 6502 on the loopback interface:

ice="tcp -h -p 6502"

icesecretread and icesecretwrite

The default Ice configuration listens on a local TCP socket, which means that anyone with access to the local machine can access it. Murmur supports setting plaintext "secrets" on the service, so that any script or program accessing the service must also possess the secret.

Access is split into two levels: "read" (look only) and "write" (modify). "write" access implies "read" access. We'll work on tracking down examples of setting "secret" in the context for your Ice scripts at some point.

To configure secrets:


Note that if either of these entries is uncommented and empty, access will be denied. To disable secrets, comment these settings out.

Security Stuff

autobanAttempts, autobanTimeframe and autobanTime

In order to prevent misconfigured, impolite or malicious clients from affecting the low-latency of other users, Murmur has a rudimentary global-ban system. It's configured using the autobanAttempts, autobanTimeframe and autobanTime settings.

If a client attempts autobanAttempts connections in autobanTimeframe seconds, they will be banned for autobanTime seconds. This is a global ban, from all virtual servers on the Murmur process. It will not show up in any of the ban-lists on the server, and they can't be removed without restarting the Murmur process - just let them expire. A single, properly functioning client should not trip these bans.

To disable, set autobanAttempts or autobanTimeframe to 0. Commenting these settings out will cause Murmur to use the defaults:

#autobanAttempts = 10
#autobanTimeframe = 120
#autobanTime = 300


This setting configures the default password for unregistered users - registered users will not be prompted for this password (they will either have their own, or be authenticated by their certificate). This setting is usually configured on a per-virtual-server basis, via RPC.


Setting process SUID

On Unix-like OSes, you can start Murmur as root and have it drop privileges to another account such as "mumble" or "murmur". The username must already exist on your system, and have write access to the Murmur database, logfiles, etc.

This option is ignored if Murmur is not started as root.



By default, in log files and in the user status window for privileged users, Mumble will show IP addresses - in some situations you may find this unwanted behavior. If obfuscate is set to true, Murmur will randomize the IP addresses of connecting users.

The random seed used for obfuscating the addresses is stored per-server, so that things like bans and such will still work as expected (they just won't show the "real" IP address).

Note that this setting currently only applies to IPv4 addresses, and that it is currently just a simple XOR with a random value - it is probably trivially broken if a user knows their IP address and can compare it with the obfuscated one assigned to them.



In the UDP ping response, Murmur will include it's version as well. Adjusting this setting to false disables that behavior.



Setting this to false disables responses to the UDP ping sweep that clients will make when the connection dialog is open. Note that on publicly listed servers, and on some configured clients, this will prevent the server from showing up in the list.


Process Administrivia


By default, murmur will log to murmur.log in the current working directory. You can change this file by specifying it in the logfile setting, including a full path if necessary.

You can set this setting blank, and Murmur will log only via message boxes (Win32 systems) and to the console (non-Win32 systems).



Murmur also stores logs in the database, which are accessible via RPC. The default is 31 days of months, but you can set this setting to 0 to keep logs forever, or -1 to disable logging to the database.



If this setting is set to a filename, Murmur will write it's PID to this file when it forks. This enables service checkers to ensure the process is still running, and restart it if it's not. The file will be removed if Murmur shuts down cleanly.

Note that Murmur on Windows systems will not write a PID file.


This setting configures a "message of the day" which is displayed to all users who connect to the server. if allowhtml is true, you can put some HTML in this message. Encase in quotes to spread it out on multiple lines.

Welcome to this server running Murmur."



This setting configures the TCP and UDP ports that Murmur will listen on - the default is 64738. If the Murmur process is running multiple virtual servers, then this port will be incremented for each virtual server by default. You can specify, via RPC, a specific port for each virtual server if you wish to override the defaults.



The host setting configures the default interface which each virtual server will listen on. You can override this setting for each virtual server if you want them on different IPs - the default is "all interfaces", but note that on multi-homed servers this will sometimes break UDP so specifying an interface is sometimes useful.

If you want to listen on multiple distinct interfaces, specify them in a space-seperated list.

host=333.333.333.333 3333::3333

sslCert and sslKey

If you have your own certificate and wish to use it instead of the certificate that Murmur automatically generates, you can enter the filenames here. If your key and cert are seperate files, point the respective settings at each file. If your key and cert are in one file, set it in sslKey



If the keyfile specified above is encrypted with a passphrase, you can enter it in this setting. It must be plaintext, so you may wish to adjust the permissions on your murmur.ini file accordingly.



If your certificate is signed by an authority that uses a sub-signed or "intermediate" certificate, you probably need to bundle it with your certificate in order to get Murmur to accept it. You can either concatenate the two certificates into one file, or you can put it in a file by itself and put the path to that file in sslCA.



Bonjour is an auto-discovery service that allows other people on the same LAN as you to find the server without needing the address to it. It only really makes sense to enable this on a LAN-based server. The default is false.



You can configure a per-user upper bandwidth limit, in bits per second. This allows you to clamp your users down to a sensible setting if you are limited in bandwidth. This does not set a minimum bandwidth - the Murmur client will check it's own bandwidth setting and the server's bandwidth settings, and choose the lower of the two.

The default is 72000, which is 72Kbps. Setting this over about 130000 doesn't really do anything. Note that this is per user.



Murmur and Mumble are usually pretty good about cleaning up hung clients, but occasionally one will get stuck on the server. The timeout setting will cause a periodic check of all clients who haven't communicated with the server in this many seconds - causing zombie clients to be disconnected.

Note that this has no effect on idle clients or people who AFK. It will only affect people who are already disconnected, and just haven't told the server.


Users and Channels


The users setting configures a limit on the maximum number of users per virtual server.



Where users sets a blanket limit on the number of clients per virtual server, usersperchannel sets a limit on the number per channel. The default is 0, for no limit.


channelname and username

These two settings allow you to configure a regular expression of acceptable names for users and channels. This allows you very powerful control over names of objects on your servers - things like maximum and minimum username lengths, etc.

channelname=[ \\-=\\w\\#\\[\\]\\{\\}\\(\\)\\@\\|]+


Mumble supports strong authentication via client certificates, and providing you have an RPC mechanism in place to set them, weak authentication via passwords. By default, users without certificates are still allowed on a server if they know the serverpassword, or if there isn't one set - however they cannot self-register, even if the server allows it (as there's no certificate to register).

Setting certrequired to true ensures that only clients who possess a certificate of some kind are allowed on the server. This is mostly safe, as recent Mumble versions will automatically generate a certificate if the certificate wizard is closed prematurely.



If a user has no stored channel (they've never been connected to the server before, or rememberchannel is set to false) and the client hasn't been given a URL that includes a channel path, the default behavior is that they will end up in the root channel.

You can set this setting to a channel ID, and the user will automatically be moved into that channel instead. Note that this is the numeric ID of the channel, which can be a little tricky to get (you'll either need to use an RPC mechanism, watch the console of a debug client, or root around through the Murmur Database to get it).

defaultchannel=4 # AFK channel


When a user connects to a server they've already been on, by default the server will remember the last channel they were in and move them to it automatically. Toggling this setting to false will disable that feature.



The textmessagelength setting configures the maximum length of each message sent via the server in bytes. Set to 0 for no limit. Note that on older versions of Murmur, if users want to paste images to each other inline, a fairly sizable limit is required. On newer versions, the imagemessagelength setting controls the size of these messages.



Like textmessagelength, this setting configures the maximum length in bytes of messages passing through the server - but it only applies to messages that include inline image blobs.



Set to true to allow some HTML to be used in text messages between clients, user comments and channel descriptions.


Server Registration

Mumble supports a public server registry, which your Murmur can automatically configure itself to register with if you choose. The server must be public (no serverpassword), it must be accessible worldwide, and it must have a Murmur-generated certificate or a 3rd party strong certificate with the TLS bit enabled.

serverpassword must be empty, and all the other register* settings must be filled in. registerHostname must be valid and resolve.


This setting is also used as the "Root" channel name, so you probably want to set it even if you don't want to register your server.

The registerName setting also specifies the "name" of your server in the public server list. The list is no longer sorted alphabetically, so please, in the interests of being user-friendly, don't set it to something silly trying to arbitrarily "rank" your server.

registerName=Super Awesome Mumble Server


registerPassword is a simple, plain-text secret between your server and the registration server. It's sole purpose is to prevent other servers from impersonating your server in the public server list.

Set this setting empty to disable registration with the public server list.



This points to a URL to the website for the server. Put your group's website, your sponsor's website, or the website where users can self-administrate with the server. They can right-click on your server in the registration list to access this URL.



This setting is the DNS hostname where your server can be reached. It must be set if you want your server registered on the public server list, and it must resolve.