https://wiki.mumble.info/api.php?action=feedcontributions&user=Javitonino&feedformat=atomMumble Wiki - User contributions [en]2024-03-28T09:27:27ZUser contributionsMediaWiki 1.31.0https://wiki.mumble.info/index.php?title=BuildingLinux&diff=1763BuildingLinux2007-10-21T14:04:51Z<p>Javitonino: /* Run Mumble */</p>
<hr />
<div>This guide is based on this article [http://www.linux-gamers.net/modules/newbb/viewtopic.php?topic_id=2896&forum=6] found at www.linux-gamers.net.<br />
<br />
== Install the dependencies ==<br />
<br />
For Mumble/Murmur 1.1.0 and greater (including SVN), Qt 4.3 is required. For the 1.0.0 release, Qt 4.2 is sufficient.<br />
<br />
=== For Gentoo ===<br />
<br />
Note: Make sure you have sqlite and/ or sqlite3 in your USE flags in /etc/make.conf, if you haven't emerged qt4 with these before, you need to reemerge it.<br />
<br />
emerge dev-libs/boost media-libs/speex x11-libs/libXevie x11-libs/qt (See Note)<br />
<br />
=== For Debian / Ubuntu ===<br />
<br />
apt-get install qt4-dev-tools libqt4-dev libspeex1 libspeex-dev libboost-dev libasound2-dev libxevie-dev libxevie1 libssl-dev g++<br />
<br />
It's recommended to remove the package qt3-dev-tools if installed.<br />
<br />
If you want to use versions of Mumble greater greater than 1.0, you'll need to use Debian lenny or Ubuntu Gutsy, as they are the only versions supporting Qt 4.3.<br />
<br />
== Download the source ==<br />
<br />
Get the mumble source<br />
<br />
svn co https://mumble.svn.sourceforge.net/svnroot/mumble/trunk mumble<br />
cd mumble/<br />
<br />
== Compile Mumble and Murmur (Mumble server) ==<br />
<br />
qmake main.pro<br />
make<br />
<br />
Alternatively, if you are using Debian:<br />
<br />
qmake-qt4 main.pro<br />
make<br />
<br />
===Push to talk===<br />
<br />
For using push to talk, edit /etc/X11/xorg.conf:<br />
<br />
Section "Extensions"<br />
Option "XEVIE" "Enable"<br />
EndSection<br />
<br />
Restart the Xserver.<br />
<br />
'''Note''': If you use Mumble 1.1.0 or newer, you don't need to enable Xevie, if you run mumble as an user with read access to /dev/input<br />
<br />
===Text to Speech===<br />
<br />
For text-to-speech voices you will need to install festival and at least a voice. Most distros ship packages for that in their repositories.<br />
<br />
== Run Mumble ==<br />
<br />
cd release<br />
./mumble<br />
<br />
== Run Murmur ==<br />
<br />
* see [[Running Murmur]]</div>Javitoninohttps://wiki.mumble.info/index.php?title=BuildingLinux&diff=1762BuildingLinux2007-10-21T14:04:27Z<p>Javitonino: /* For Debian */</p>
<hr />
<div>This guide is based on this article [http://www.linux-gamers.net/modules/newbb/viewtopic.php?topic_id=2896&forum=6] found at www.linux-gamers.net.<br />
<br />
== Install the dependencies ==<br />
<br />
For Mumble/Murmur 1.1.0 and greater (including SVN), Qt 4.3 is required. For the 1.0.0 release, Qt 4.2 is sufficient.<br />
<br />
=== For Gentoo ===<br />
<br />
Note: Make sure you have sqlite and/ or sqlite3 in your USE flags in /etc/make.conf, if you haven't emerged qt4 with these before, you need to reemerge it.<br />
<br />
emerge dev-libs/boost media-libs/speex x11-libs/libXevie x11-libs/qt (See Note)<br />
<br />
=== For Debian / Ubuntu ===<br />
<br />
apt-get install qt4-dev-tools libqt4-dev libspeex1 libspeex-dev libboost-dev libasound2-dev libxevie-dev libxevie1 libssl-dev g++<br />
<br />
It's recommended to remove the package qt3-dev-tools if installed.<br />
<br />
If you want to use versions of Mumble greater greater than 1.0, you'll need to use Debian lenny or Ubuntu Gutsy, as they are the only versions supporting Qt 4.3.<br />
<br />
== Download the source ==<br />
<br />
Get the mumble source<br />
<br />
svn co https://mumble.svn.sourceforge.net/svnroot/mumble/trunk mumble<br />
cd mumble/<br />
<br />
== Compile Mumble and Murmur (Mumble server) ==<br />
<br />
qmake main.pro<br />
make<br />
<br />
Alternatively, if you are using Debian:<br />
<br />
qmake-qt4 main.pro<br />
make<br />
<br />
===Push to talk===<br />
<br />
For using push to talk, edit /etc/X11/xorg.conf:<br />
<br />
Section "Extensions"<br />
Option "XEVIE" "Enable"<br />
EndSection<br />
<br />
Restart the Xserver.<br />
<br />
'''Note''': If you use Mumble 1.1.0 or newer, you don't need to enable Xevie, if you run mumble as an user with read access to /dev/input<br />
<br />
===Text to Speech===<br />
<br />
For text-to-speech voices you will need to install festival and at least a voice. Most distros ship packages for that in their repositories.<br />
<br />
== Run Mumble ==<br />
<br />
cd debug<br />
./mumble<br />
<br />
== Run Murmur ==<br />
<br />
* see [[Running Murmur]]</div>Javitoninohttps://wiki.mumble.info/index.php?title=BuildingLinux&diff=1761BuildingLinux2007-10-21T14:02:58Z<p>Javitonino: /* For Debian */</p>
<hr />
<div>This guide is based on this article [http://www.linux-gamers.net/modules/newbb/viewtopic.php?topic_id=2896&forum=6] found at www.linux-gamers.net.<br />
<br />
== Install the dependencies ==<br />
<br />
For Mumble/Murmur 1.1.0 and greater (including SVN), Qt 4.3 is required. For the 1.0.0 release, Qt 4.2 is sufficient.<br />
<br />
=== For Gentoo ===<br />
<br />
Note: Make sure you have sqlite and/ or sqlite3 in your USE flags in /etc/make.conf, if you haven't emerged qt4 with these before, you need to reemerge it.<br />
<br />
emerge dev-libs/boost media-libs/speex x11-libs/libXevie x11-libs/qt (See Note)<br />
<br />
=== For Debian / Ubuntu ===<br />
<br />
apt-get install qt4-dev-tools libqt4-dev libspeex1 libspeex-dev libboost-dev libasound2-dev libxevie-dev libxevie1 libssl-dev g++<br />
<br />
It's recommended to remove the package qt3-dev-tools if installed.<br />
<br />
If you want to use versions of Mumble greater greater than 1.0, you'll need to use Debian lenny or Ubuntu Gutsy, as they are the only versions supporting Qt 4.3.<br />
<br />
== Download the source ==<br />
<br />
Get the mumble source<br />
<br />
svn co https://mumble.svn.sourceforge.net/svnroot/mumble/trunk mumble<br />
cd mumble/<br />
<br />
== Compile Mumble and Murmur (Mumble server) ==<br />
<br />
qmake main.pro<br />
make<br />
<br />
=== For Debian ===<br />
<br />
qmake-qt4 main.pro<br />
make<br />
<br />
For using push to talk, edit /etc/X11/xorg.conf:<br />
<br />
Section "Extensions"<br />
Option "XEVIE" "Enable"<br />
EndSection<br />
<br />
Restart the Xserver.<br />
''Note'': If you use Mumble 1.1.0 or newer, you don't need to enable Xevie, if you run mumble as an user with read access to /dev/input<br />
<br />
For text-to-speech voices you will need to install festival and at least a voice. Most distros ship packages for that in their repositories.<br />
<br />
== Run Mumble ==<br />
<br />
cd debug<br />
./mumble<br />
<br />
== Run Murmur ==<br />
<br />
* see [[Running Murmur]]</div>Javitoninohttps://wiki.mumble.info/index.php?title=BuildingLinux&diff=1760BuildingLinux2007-10-21T14:01:12Z<p>Javitonino: /* For Debian / Ubuntu */</p>
<hr />
<div>This guide is based on this article [http://www.linux-gamers.net/modules/newbb/viewtopic.php?topic_id=2896&forum=6] found at www.linux-gamers.net.<br />
<br />
== Install the dependencies ==<br />
<br />
For Mumble/Murmur 1.1.0 and greater (including SVN), Qt 4.3 is required. For the 1.0.0 release, Qt 4.2 is sufficient.<br />
<br />
=== For Gentoo ===<br />
<br />
Note: Make sure you have sqlite and/ or sqlite3 in your USE flags in /etc/make.conf, if you haven't emerged qt4 with these before, you need to reemerge it.<br />
<br />
emerge dev-libs/boost media-libs/speex x11-libs/libXevie x11-libs/qt (See Note)<br />
<br />
=== For Debian / Ubuntu ===<br />
<br />
apt-get install qt4-dev-tools libqt4-dev libspeex1 libspeex-dev libboost-dev libasound2-dev libxevie-dev libxevie1 libssl-dev g++<br />
<br />
It's recommended to remove the package qt3-dev-tools if installed.<br />
<br />
If you want to use versions of Mumble greater greater than 1.0, you'll need to use Debian lenny or Ubuntu Gutsy, as they are the only versions supporting Qt 4.3.<br />
<br />
== Download the source ==<br />
<br />
Get the mumble source<br />
<br />
svn co https://mumble.svn.sourceforge.net/svnroot/mumble/trunk mumble<br />
cd mumble/<br />
<br />
== Compile Mumble and Murmur (Mumble server) ==<br />
<br />
qmake main.pro<br />
make<br />
<br />
=== For Debian ===<br />
<br />
qmake-qt4 main.pro<br />
make<br />
<br />
For using push to talk, edit /etc/X11/xorg.conf:<br />
<br />
Section "Extensions"<br />
Option "XEVIE" "Enable"<br />
EndSection<br />
<br />
Restart the Xserver.<br />
<br />
For text-to-speech voices you will need to install festival and at least a voice. Most distros ship packages for that in their repositories.<br />
<br />
== Run Mumble ==<br />
<br />
cd debug<br />
./mumble<br />
<br />
== Run Murmur ==<br />
<br />
* see [[Running Murmur]]</div>Javitoninohttps://wiki.mumble.info/index.php?title=Template:Languages&diff=1638Template:Languages2007-08-09T12:47:15Z<p>Javitonino: </p>
<hr />
<div><div style="border-top: 1px solid #6C83B0; border-bottom: 1px solid #6C83B0; text-align: center; margin-bottom: 5px; padding: 0px;"><br />
Languages: [[{{{1}}}|English]] [[{{{1}}}_(Deutsch)|Deutsch]] [[{{{1}}} (Español)|Español]]<br />
</div><br />
<br />
<noinclude><br />
= What is this template for? =<br />
This template will add a top bar to select the language you want to read the article in. For this to work, articles in other languages must be named like the english one and adding (Deutsch) (Español) (Français) after the name.<br />
<br />
=How do I use it?=<br />
To include that template, add the following to the article you are editing:<br />
<nowiki>{{Languages|{{PAGENAME}}}}</nowiki><br />
<br />
=Example=<br />
Look at the ACL_and_Groups page. It is using the template right now.<br />
</noinclude></div>Javitoninohttps://wiki.mumble.info/index.php?title=ACL_and_Groups/English&diff=1637ACL and Groups/English2007-08-09T12:46:48Z<p>Javitonino: </p>
<hr />
<div>{{Languages|{{PAGENAME}}}}<br />
<br />
= ACL FAQ in other Languages =<br />
<br />
This ACL FAQ you can find in following Languages<br><br />
[[ACL_and_Groups|English]]&nbsp;&nbsp; [[ACL_FAQ_(Deutsch)|Deutsch]]&nbsp;&nbsp; [[ACL_FAQ_(Espanol|Espanol]]&nbsp;&nbsp; [[ACL_FAQ_(Francaise)|Francaise]]&nbsp;&nbsp; [[ACL_FAQ_(Italiano)|Italiano]]<br />
<br />
<br />
=Tutorial=<br />
You can find an illustrated tutorial/quick guide on how to administer groups and permission here: [[ACL tutorial_(English)|ACL Tutorial]]<br />
<br />
= Groups =<br />
<br />
Groups are tied to a specific channel, but can also be inherited by subchannels. Groups are convenient ways to administer channels; set up the ACLs on the top of the tree that should have similar privilege structure, and just change the group memberships on subchannels.<br />
<br />
For each channel, a group has 3 pieces of data. The list of players to add to the group, the list of players inherited from the same group on the parent channel, and the list of players to remove from the group.<br />
<br />
A group will only inherit players from the parent if ''Inherit'' is set true and the group was marked ''Inheritable'' on the parent. Most of the time you want both of these to be set.<br />
<br />
== Example ==<br />
<br />
Let's take a practical example; the ''admin'' group. Every time a player makes a channel, he is automatically added to the admin group. This doesn't automatically give him any privileges, it just marks him as a member of that group, however Murmur's default installation installs an ACL that gives the ''admin'' group write bit (all access).<br />
<br />
<br />
In a structure like this:<br />
* Root<br />
** A<br />
*** B<br />
** C<br />
*** D<br />
<br />
In Root, player "Big Boss" is alone in the admin group. In channel A, player "BossA" is in the Add list, and "BossB" is the same in channel B.<br />
<br />
Since the ''admin'' group is inherited and inheritable, a player that is a member at any parent of the current channel is also a member in the current channel. So the total list of members in channel B is "Big Boss, BossA, BossB". The convenience of this system is that if we later att "Super Boss" to admin in Root, he'll automatically be in the admin group of every channel below.<br />
<br />
Let's move on, and say that player "BossC" is in the Add list in channel C, but here admin is marked as not inherit. This means that "Big Boss" is not in the admin list, and any changes for admin in Root will not be seen here. Channel D will inherit the list from C, unless C also marks admin as not inheritable.<br />
<br />
= ACL =<br />
<br />
ACL (Access Control Lists) are all attached to a specific channel. A channel can specify if it wants to inherit the ACL on the parent, but it cannot specify which; it's a all or nothing deal. ACL are evaluated in order, from top to bottom along the chain of channels.<br />
<br />
For each entry, either a user or a group will match. A user must be a specific, registered user, while a group can be any group valid in the channel the ACL is defined on. Note that group membership is evaluated in the channel the ACL is executed in, which is important for inherited ACLs. If a group begins with a ''!'', it's membership is inverted, and if it begins with a ''~'', it is evaluated in the context of the channel the ACL is defined on (and not the active channel).<br />
: all<br />
Everyone<br />
: auth<br />
All authenticated users<br />
: in<br />
All users inside current channel<br />
: out<br />
All users outside current channel<br />
<br />
For each entry, permissions are either allowed or denied; in case of a conflict the last entry takes precedence. Remember that all entries are evaluated in order, so if you have the following set of entries:<br />
* @all deny speak<br />
* @all allow speak<br />
Then everyone will be allowed to speak. On the other hand<br />
* @all allow speak<br />
* @all deny speak<br />
Will deny speak from everyone.<br />
<br />
Each entry can be marked as either applying in the current channel, in subchannels or both. Most of the time you want both. Remember that for an entry to be applied on a subchannel, you have to apply it to subchannels '''and''' allow inheritance in the subchannels.<br />
<br />
== The @sub group ==<br />
<br />
There is a special group called ''sub'', which just like ''all'' has a special meaning. Sub is used as ''sub,a,b,c'', where ''a'' is the minimum number of common parents, and ''b'' and ''c'' restrain the path depth: <br />
*b is the minimum and c the maximum path length, measured from the channel referred by a.<br />
*If any of those parameter is missing, then there will be no minimum/maximum path length.<br />
<br />
It's somewhat complex, but also rather powerful. For example, assume the following tree:<br />
<br />
* Root<br />
** A<br />
*** A1<br />
**** Sub1<br />
**** Sub2<br />
*** A2<br />
*** A3<br />
** B<br />
*** B1<br />
*** B2<br />
<br />
Let's deny enter to all on ''Root'' to start with. Then, on ''A'', we define<br />
<br />
# @~sub,0,1 +enter<br />
<br />
First of all, this ACL will be evaluated in the context of the defining channel, since the group starts with ~.<br />
<br />
The first parameter (0) indicates how many additional elements of the path name must match. A zero means we require a match up to this point. This means that any player in a channel under the path Root.A will match. If the parameter had been 1 and we were in channel Sub2, the path of the player would need to match Root.A.Sub1. Setting this to positive values only makes sense for pinned groups (with the ~).<br />
<br />
The second parameter requires the path of the evaluated channel to be at least one element longer than the path of the channel of the ACL. So this rule will match in anything that starts with Root.A and has at least one more element.<br />
<br />
To sum it up; this rule allows anyone in one of A's descendants (but no A itself) to join A or any of its descendants (we assume subchannels inherit the rule).<br />
<br />
If we don't use the ~, then it will allow people in any of A descendants to go up (ie, from Sub1 to A1 or A but not the other way) or, in other words, allow people in the descendant of a channel (any depth) to enter it.<br />
<br />
Let's add a new rule to ''A1'':<br />
<br />
# @sub,-1,0 +link<br />
<br />
This allows anyone that's in the parent (equal path up to -1 elements (the first parameter)) or any of the siblings (path length equal (the 0 parameter)) to link to this channel.<br />
<br />
And finally, just to show how messed up it can get, let's add this on B:<br />
<br />
# @~sub,-1,2,2 +enter<br />
<br />
This lets anyone that's currently in a descendant of Root (B's parent) and has a path length of exactly 2 (length of Root.B -1 + 2) join, so this rule would match someone in A1, but not A or Sub1.<br />
<br />
== Write ==<br />
<br />
This gives total control over the channel, including the ability to edit ACLs. This privilege implies all other privileges.<br />
<br />
== Traverse ==<br />
<br />
Without this privlege, a player will be unable to access the channel or any subchannels in any way, regardless of privileges in the subchannel. Don't deny this unless you really know what you're doing; you can probably achieve the effect you want by denying a player the Enter privlege.<br />
<br />
== Enter ==<br />
<br />
Allows player to enter channel. Even without this privilege, a player can be moved into the channel by a player with Move/Kick.<br />
<br />
== Speak ==<br />
<br />
Allows player to speak in channel. For linked channels, only players with Speak privilege in the destination channels will be heard. This can be used to set up a hierarchy of linked channels where all players can hear all the leader of each group, but normal players will not be propageated outside their channel. This way, players will hear someone else is talkig to the group leader and (hopefully) stop talking for a short while.<br />
<br />
If a player joins a channel he does not have Speak privilege in, he will be suppressed by the server, and will be unable to speak until someone unmutes him.<br />
<br />
== Mute / Deafen ==<br />
<br />
Allows a player to mute or deafen another player. Note that mute status will follow a player until he is either manually unmuted or reconnects to the server.<br />
<br />
== Move / Kick ==<br />
<br />
Allows a player to move another player to another channel or kick them off the server. Unless the target player has Enter privileges in the channel he's being moved to, Move privileges is required in both channels.<br />
<br />
== Make Channel ==<br />
<br />
Allows a player to make a subchannel in the current channel. The player will automatically be added to the ''admin'' group in the new channel, so make the inheritable ACLs give the privileges you desire.<br />
<br />
== Link Channel ==<br />
<br />
Allows a player to link or unlink, as well as push-to-link a channel. Unlinking requires Link privilege in either channel, and linking requires Link privilege in both.<br />
<br />
== AltSpeak ==<br />
<br />
Allows a player to speak in channel if he is holding the Alt Push-To-Talk key(can be configured in the Shortcuts tab of the options window). It works as Speak for linked channels, etc.<br />
<br />
= Examples =<br />
<br />
== Group of servers with FPS game ==<br />
<br />
In this example, we assume we have a group of public servers running FPS games. Each game has 2 competing sides, and each side consists of one or more squads. We want a hierarchy such as this:<br />
<br />
* Servers<br />
** "Servername"<br />
*** Team 1<br />
**** Squad 1<br />
**** Squad 2<br />
**** ...<br />
*** Team 2<br />
**** Squad 1<br />
**** ...<br />
*** ...<br />
** ...<br />
<br />
Let's assume we have a small script linked with qstat that puts the player in the channel of the right side, and once in there we want to give them the ability to switch between squad channels and link at will. However, we do not want them to gain access to the channels of the other side.<br />
<br />
This is actually a very straightforward implementation; on the "Servers" channel, define an empty group called players. Then, add the following acls:<br />
<br />
# @all deny enter<br />
# @~sub,2,2 allow enter, allow link<br />
<br />
The first rule denies enter privilege to all players, and the second rule allows anyone within a hierarchy at least 2 elements down from "Servers" to move and link at will. In practice, this means that once a player is inside "Team 1", he can move freely about in there but can't switch to the other team or another server subchannel.<br />
<br />
== MMORPG Raid ==<br />
<br />
Assume this setup:<br />
<br />
* Root<br />
** Raid<br />
*** Healers<br />
*** Tanks<br />
*** Damage Dealers<br />
*** Wussards and other pets<br />
<br />
The desire is to have one leader of each group, plus a few people as raid leaders.<br />
<br />
Set this up as follows: In "Raid", create a group called "groupleaders". Put the leader of each group in this group. In the same channel define "raidleaders", and put the raidleaders in this group.<br />
<br />
In the Raid channel, define the following ACLS:<br />
# @all deny enter, deny speak [Apply Here only]<br />
# @raidleaders allow enter, allow speak, allow link, allow mute, allow kick [Apply Here and Apply Subs]<br />
# @groupleaders allow speak, allow link [Apply Here only]<br />
# @groupleaders allow link, allow mute, allow kick [Apply Subs only]<br />
<br />
The first rule makes sure nobody can speak or enter the Raid channel. The second rule lifts this restriction from anyone in the raidleaders group as well as giving them broad permissions. The third rule makes sure groupleaders can link and speak to the raid channel, and the fourth gives them permission to link from the subchannel as well as get rid of troublesome players.<br />
<br />
Normal players will not be able to join the raid channel, but as that denial only applied in the raid channel they can join any subchannel they wish. When the channels are linked, everyone in the linked channels will hear raid leaders and group leaders. However, raid leaders will only hear group leaders, they will not hear normal players. This way, players can stay quiet when they hear a command coming down (and also hear the command direct without the groupleader having to repeat it), and if they don't that won't bother the rest of the raid.</div>Javitoninohttps://wiki.mumble.info/index.php?title=ACL_and_Groups/Espa%C3%B1ol&diff=1634ACL and Groups/Español2007-08-09T12:05:48Z<p>Javitonino: ACL FAQ (Espanol moved to ACL and Groups (Español)</p>
<hr />
<div>= Quiénes desean traducirlo =</div>Javitoninohttps://wiki.mumble.info/index.php?title=ACL_and_Groups/Deutsch&diff=1632ACL and Groups/Deutsch2007-08-09T12:04:39Z<p>Javitonino: ACL FAQ (Deutsch) moved to ACL and Groups (Deutsch)</p>
<hr />
<div>= ACL FAQ in anderen Sprachen =<br />
<br />
Die ACL FAQ ist verfügbar in folgenden Sprachen:<br><br />
[[ACL_and_Groups|English]]&nbsp;&nbsp; [[ACL_FAQ_(Deutsch)|Deutsch]]&nbsp;&nbsp; [[ACL_FAQ_(Espanol|Espanol]]&nbsp;&nbsp; [[ACL_FAQ_(Francaise)|Francaise]]&nbsp;&nbsp; [[ACL_FAQ_(Italiano)|Italiano]]<br />
<br />
= Tutorial =<br />
<br />
Ein ausführliches bebildertes Tutorial von User "Javitonino" wie man ACL und Gruppen administriert, findet ihr, [[ACL_tutorial_(Deutsch)|wenn ihr hier klickt]]<br />
<br />
= Gruppen =<br />
<br />
Gruppen sind an einen bestimmten Kanal (Channel) geknüpft, können aber auch von Unterkanälen (Subchannels) geerbt (übernommen) werden. <br />
Gruppen sind bequeme Wege um Kanäle zu administrieren; die Zugriffe (ACL) an der Spitze des Kanalbaumes einzurichten welcher gleichartige Rechtestrukturen haben soll, oder um einfach nur die Gruppenzugehörigkeit in den Unterkanälen zu ändern.<br />
<br><br />
<br><br />
Eine Gruppe hat für jeden Kanal 3 Datenteile. Die Liste von Spielern in einer Gruppe, Die Liste von Spielern die von derselben Gruppe des übergeordneten Kanals vererbt wurden und die Liste von Spielern welche von der Gruppe gelöscht werden.<br />
<br><br />
<br><br />
Eine Gruppe wird Spieler nur dann vom Elternkanal (übergeordneten Kanal) vererben, wenn <i>erben</i> auf "wahr" gesetzt ist und die Gruppe als "vererbbar" markiert ist im übergeordneten Kanal. Meist sollte beides gesetzt sein. <br />
<br><br />
<br><br />
== Beispiele ==<br />
<br><br />
Ein praktisches Beispiel: Die admin Gruppe. <br />
<br />
Immer wenn ein Spieler einen Kanal erstellt, dann ist er automatisch der Admin Gruppe hinzugefügt.<br />
<br />
Das gibt ihm nicht automatisch beliebige Rechte, es markiert ihn einfach als ein Mitglied dieser Gruppe, indes Murmurs Standardinstallation installiert eine Zugriffskontrolle (ACL), welche der Admin Gruppe Schreibrechte gewährt (Komplettzugriff).<br />
<br />
In einer Struktur wie dieser:<br />
<br><br />
Root<br />
&nbsp;&nbsp;A<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;B<br />
&nbsp;&nbsp;C<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;D<br />
<br><br />
Im Rootkanal, Spieler "BigBoss" ist allein in der Admingruppe. Im Kanal A, Spieler "Boss A" ist in der Admingruppe, und "Boss B" ist es ebenfalls in Kanal B.<br />
<br />
Wenn die Admingruppe vererbt und vererbbar ist, ist ein Spieler, der Mitglied einer Gruppe eines beliebigen Elternkanal des aktuellen Kanals (in dem er sich gerade befindet) ist, ist also auch in diesem aktuellen Kanal Mitglied dieser Gruppe. <br />
Wer also in A in der Gruppe Admin ist, ist auch im Unterkanal B in der Gruppe Admin.<br />
So ist die Liste der Mitglieder in "admin" im Kanal B folgende: Big Boss, Boss A und Boss B.<br />
<br />
Der Nutzen aus diesem System ist, dass wenn wir später den Spieler "Super Boss" der Admingruppe in Root (dem obersten Kanal) hinzufügen, dann wird er automatisch Admin in jedem Channel darunter.<br />
<br><br />
<br><br />
Lasst uns weitergehen und wir sagen, der Spieler "Boss C" ist in der Admin Liste in Kanal C, nur hier ist "admin" als "nicht vererbt" markiert. Das bedeutet, dass "Big Boss" hier im Kanal C NICHT in der Admin Liste ist, und jede Änderung für Admin in Root ist hier in Kanal C nicht ersichtlich. Kanal D vererbt die Liste von C, außer wenn C "admin" ebenso als "nicht vererbbar" markiert.<br />
<br />
= ACL =<br />
<br />
Die ACL (Zugriffssteuerung) sind einem bestimmten Kanal (Channel) zugewiesen. Ein Kanal kann bestimmen, ob er die ACL des Ursprungskanals erben will, aber er kann nicht bestimmen, welche, entweder die komplette ACL erben oder sie nicht erben. ACL werden in einer Abfolge bewertet, von oben bis unten entlang der Kette von Kanälen.<br />
<br><br />
Jeder Eintrag entspricht einem User oder einer Gruppe. Ein User muss ein bestimmter registrierter User sein, während eine Gruppe jede Gruppe sein kann, welche gültig in dem Kanal ist, für den die ACL definiert ist.<br />
<br><br />
Beachte, dass die Gruppenzugehörigkeit bewertet ist in dem Kanal in dem die ACL ausgeführt wird, was für vererbte ACL wichtig ist. <br />
<br><br />
Wenn eine Gruppe mit einem ! beginnt, dann ist die Zugehörigkeit umgekehrt. und wenn sie mit einer Tilde ~ beginnt, dann wird sie im Zusammenhang des Kanals für den die ACL definiert ist, bewertet. (und nicht der aktive Kanal).<br />
<br><br />
<br><b><br />
all (Alle/Jeder)<br />
<br><br />
auth (Alle registrierte User)<br />
<br><br />
in (Alle User in dem aktuellen Kanal)<br />
<br><br />
out (Alle User ausserhalb des aktuellen Kanals)<br />
<br></b><br />
<br><br />
Für jeden Eintrag sind die Rechte entweder erlaubt oder verboten; Für den Fall eines Konfliktes hat der letzte Eintrag Vorrang. (Anmerkung von BarefeetXanadu: Daher wird beim Sperren eines Kanals erst für @all das Betreten verboten und dann für einige User oder alle registrierten @auth das Betreten erlaubt. Wenn man erst erlaubt für einige und dann z.B: @all verbietet, dann wirkt eben das letzte, das verboten für @all und die ACL funktioniert dann nicht wie gewünscht.).<br />
Erinnere Dich daran, dass alle Einträge der Reihe nach ausgewertet werden, hast Du also folgende Reihenfolge:<br><br />
<br><b><br />
@all deny speak (@all verbiete sprechen)<br><br />
@all allow speak (@all erlaube sprechen)<br><br />
<br></b><br />
Dann kann jeder sprechen.<br><br />
<br><b><br />
@all allow speak<br><br />
@all deny speak<br><br />
<br></b><br />
wird jedem das Sprechen verbieten.<br><br />
(siehe auch meine Anmerkung bzgl. Raum betreten oder nicht). <br><br />
<br><br />
Jeder Eintrag kann markiert werden, ob er sich auf den aktuellen Kanal, den Unterkanal oder auf beide bezieht. In der Regel willst Du dass der Eintrag sich auf beide bezieht. Erinnere Dich, wenn ein Eintrag sich auf einen Unterkanal beziehen soll, dass Du den Eintrag auf den Unterkanal anwendest <b>und</b> die Vererbung in den Unterkanälen erlaubst.<br><br />
<br><br />
<br><br />
<br><br />
== Die @sub Gruppe ==<br />
<br><br />
Es gibt eine spezielle Gruppe, die sich @sub nennt, welche genau wie @all eine spezielle Bedeutung hat.<br><br />
Sub wird in der Form: sub,a,b,c angewendet. A steht für die minimale Anzahl der üblichen Parents (Eltern) und b und c beschränkt die Pfadtiefe:<br><br />
<br><br />
b ist die minimale und c die maximale Pfadlänge, gemessen von dem Kanal auf den a sich bezieht.<br><br />
Fehlt irgendeiner dieser Parameter, dann gibt es keine minimale/maximale Pfadlänge.<br><br />
<br><br />
Es ist etwas komplex, aber ferner recht machtvoll. Ein Beispiel, lasst uns folgende Baumstruktur annehmen:<br><br />
<br><b><br />
Root<br />
&nbsp;&nbsp;A<br><br />
&nbsp;&nbsp;&nbsp;&nbsp;A1<br><br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Sub1<br><br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Sub2<br><br />
&nbsp;&nbsp;&nbsp;&nbsp;A2<br><br />
&nbsp;&nbsp;&nbsp;&nbsp;A3<br><br />
&nbsp;&nbsp;B<br><br />
&nbsp;&nbsp;&nbsp;&nbsp;B1<br><br />
&nbsp;&nbsp;&nbsp;&nbsp;B2<br><br />
<br></b><br />
Lasst uns @all das Betreten verbieten in root für den Anfang. Dann in A definieren wir:<br><br />
<br><b><br />
@~sub,0,1 +enter <br />
<br></b><br />
<br><br />
Als allererstes, diese ACL wird im Kontext des definierenden Kanals gesehen (da die Gruppe mit einer Tilde ~ beginnt, wir erinnern uns).<br><br />
<br><br />
Der erste Parameter (0) zeigt an, wieviel weitere Elemente des Pfadnamen übereinstimmen müssen. Eine 0 bedeutet, wir benötigen eine Übereinstimmung bis an diesen Punkt. Das bedeutet, dass irgendein Spieler in einem Kanal unter dem Pfad Root.A übereinstimmen muss. Wenn der Parameter auf 1 steht, und wir sind in Unterkanal Sub2, dann muss der Pfad des Spielers mit Root.A.Sub1 übereinstimmen. Das auf Positive Werte zu setzen macht nur Sinn für aufgesteckte (pinned) Gruppen (die mit der Tilde~).<br><br />
<br><br />
Der zweite Parameter benötigt mindestens dass der Pfad des bewerteten Kanals um ein Element länger ist als der Pfad von dem Kanal von der ACL. Diese Regel muss komplett in allem, was mit Root.A beginnt, und zumindest ein Element mehr hat, übereinstimmen.<br />
<br><br />
<br><br />
Zusammenfassend ist festzustellen: Diese Regel erlaubt jedem in einem von A nachkommenden Kanal (nicht in A selber), den Kanal A oder irgendeinen A nachkommenden Kanal zu betreten. (Wir unterstellen, dass die Unterkanäle diese Regel vererben).<br><br />
<br><br />
Wenn wir die Tilde ~ nicht benutzen, dann ist es Leuten in den von A nachkommenden Kanälen erlaubt, nach oben zu gehen (z.B: von Sub1 nach A1 oder nach A aber nicht die andere Richtung, also nicht A1 nach Sub1) oder in anderen Worten: "Erlaube den Spielern in den Nachkommen eines Kanals (irgendeine Tiefe), den Kanal zu betreten (z.B. erlaube den Spielern in A1, den A zu betreten.)<br><br />
<br><br />
Lasst uns dem Kanal A1 eine neue Regel geben.<br><b><br />
@sub,-1,0 +link</b> <br />
<br><br />
Dies erlaubt jedem im Ursprungskanal (gleiche Pfade bis auf -1 Elemente (der erste Parameter) oder irgendeiner der Geschwister (Pfadlänge gleich (der 0 Parameter)), zu diesem Kanal zu linken.<br />
<br><br />
<br><br />
Zum Abschluss einfach um zu zeigen wie derangiert es gehen kann, lasst uns zu Kanal B folgende Regel hinzufügen:<br><b><br />
@~sub,-1,2,2 +enter</b><br />
<br><br />
<br><br />
Dies lässt jeden, der in einem nachkommenden Kanal des Kanals Root (Ursprung von B) ist, und eine Pfadlänge von exakt 2 hat (Länge von Root.B -1+2) den Kanal Root betreten. Diese Regel würde übereinstimmen mit jemandem in A1, aber nicht A oder Sub1.<br><br />
<br><br />
<br><br />
== Write (Schreiben) ==<br />
<br><br />
Dies gibt totale Kontrolle über den Kanal, inkl. der Fähigkeit, die ACL zu editieren. Dieses Privileg schliesst alle anderen Privilegien mit ein.<br><br />
<br><br />
== Traverse (Traverse) ==<br />
<br><br />
Ohne dieses Privileg kann ein Spieler auf den Kanal oder irgendeinen Unterkanal nicht zugreifen, egal auf welchem Weg, ohne Rücksicht auf Privilegien in Unterkanälen. Verweigere dieses Privileg nicht, ausser Du weisst genau was du tust. Du kannst den Effekt den du möchtest, besser erreichen wenn du das Recht des Betretens (Enter) verbietest (Deny).<br><br />
<br><br />
== Enter (Betreten) ==<br />
<br><br />
Erlaubt Spielern, den Kanal zu betreten. Ohne das Privileg kann ein Spieler dennoch in den Kanal gemoved werden (vom Admin der Spieler moven kann).<br><br />
<br><br />
== Speak (Sprechen) == <br />
<br><br />
Erlaubt Spielern, im Kanal zu sprechen. Für verlinkte Kanäle, nur die Spieler mit Sprechprivileg in den Zielkanälen (Wo der Link hinzielt) können gehört werden. Dies kann genutzt werden um eine Hierarchie aufzubauen, in der alle Spieler alle Leader jeder Gruppe hören können, aber normal wird die Sprache der Spieler nicht ausserhalb deren Kanals übertragen.<br><br />
Auf diese Weise hören Spieler irgendeinen anderen zum Gruppenführer sprechen und hören mit Sprechen (hoffentlich) auf für kurze Zeit.<br><br />
Wenn ein Spieler einen Kanal betritt in dem er kein Recht auf Sprechen hat, dann wird er vom Server "unterdrückt", und ist unfähig zu sprechen bis ihn irgendjemand "unmuted" also das "Stumm" entfernt.<br><br />
<br><br />
<br> <br />
== Mute/Deafen (Stumm/Taub) == <br />
<br><br />
Erlaubt einem Spieler, andere Spieler stumm oder taub zu stellen. Beachte dass der Stumm Status dem Spieler folgt bis er entweder manuell das Stumm wegbekommt oder den Server neu connectet.<br><br />
<br><br />
<br><br />
== Move/Kick (Spieler ziehen/Kicken)== <br />
<br><br />
Erlaubt einem Spieler, einen anderen Spieler in einen anderen Raum zu ziehen oder ihn vom Server zu kicken. (Need Correction: Ausser der angezielte Spieler hat ENTER Rechte in den Kanälen in die er gezogen wurde, Move Rechte werden in beiden Kanälen benötigt.)<br><br />
<br><br />
<br><br />
== Make Channel (Erstelle Kanal)== <br><br />
Erlaubt einem Spieler, in einem Kanal einen Unterkanal zu erstellen. Der Player wird automatisch der <i>admin</i> Gruppe des neuen Kanals (nicht aller Kanäle) hinzugefügt, so mache die vererbbaren ACL so, dass sie die Privilegen geben welche Du wünschst.<br><br />
<br><br />
<br><br />
== Link Channel (Verbinde Kanäle) == <br />
<br><br />
Erlaubt einem Spieler, Kanäle zu verbinden oder die Verbindungen zu lösen, ebenso (This needs Recorrection too: drück-zum-Verbinden einen Kanal). Um Verbindungen zu lösen, brauchst Du Linkrechte in einem von beiden Kanälen, und Verbinden benötigt Linkrechte in BEIDEN Kanälen. <br><br />
<br><br />
<br><br />
== AltSpeak (Alternativ Sprechen) ==<br />
<br><br />
Erlaubt einem Spieler, in einem Kanal mittels der ALT-PTT Taste zu sprechen. (Kann im Shortcuts Menü konfiguriert werden). Es arbeitet als Sprechmöglichkeit für verbundene Kanäle etc. AltSpeak erkennt ihr am grünen Mund.<br><br />
<br><br />
<br />
= Beispiele =<br />
<br />
== Gruppen von FPS Game Servern == <br />
<br><br />
In diesem Beispiel nehmen wir an, wir haben eine Gruppe von FPS Public Game Server. Jedes Spiel hat zwei konkurrierende Seiten, und jede Seite besteht aus einem oder mehreren Squads. Wir wollen eine Hierarchie wie diese hier:<br><br />
<br><br />
Servers<br />
&nbsp;&nbsp;"Servername"<br />
&nbsp;&nbsp;&nbsp;&nbsp;Team 1<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Squad 1<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Squad 2<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;............<br />
&nbsp;&nbsp;&nbsp;&nbsp;Team 2<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Squad 1<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Squad 2<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;............<br />
&nbsp;&nbsp;&nbsp;&nbsp;.............<br />
&nbsp;&nbsp;..................<br />
<br><br />
<br><br />
Lasst uns annehmen, wir haben ein kleines Skript mit qstat gelinkt, welches die Spieler in den Kanal auf der rechten Seite steckt und eines in dem wir ihnen die Fähigkeit geben wollen zwischen den Squad Kanälen zu wechseln und beliebig zu linken (verbinden). Aber wir wollen nicht, dass sie Zugriff auf die andere Seite erhalten.<br><br />
<br><br />
Aktuell ist das eine sehr eindeutige Implementation; Auf den "Server" Kanälen definieren wir eine leere Gruppe welche sich "Spieler" nennt. Dann fügen wir der Gruppe folgende ACL hinzu.<br><br />
<br><br />
1. @all deny enter<br><br />
2. @~sub,2,2 allow enter, allow link<br><br />
<br><br />
Die erste Regel verbietet den Spielern das Betreten, die zweite Regel erlaubt jedem innerhalb einer Hierarchie mindestens zwei Elemente von "Server" abwärts, nach eigenem Wunsch zu linken und zu "moven". Praktisch heisst dass wenn ein Spieler im Team 1 ist, kann er in Team 1 sich frei bewegen aber er kann nicht zum anderen Team oder zu einem anderen Server Unterkanal wechseln.<br><br />
<br><br />
<br><br />
== MMORPG Raid ==<br />
<br><br />
Wir nehmen diese Einrichtung an:<br><br />
<br><br />
Root<br><br />
&nbsp;&nbsp;Raid<br><br />
&nbsp;&nbsp;&nbsp;&nbsp;Healers<br><br />
&nbsp;&nbsp;&nbsp;&nbsp;Tanks<br><br />
&nbsp;&nbsp;&nbsp;&nbsp;Damage Dealers<br><br />
&nbsp;&nbsp;&nbsp;&nbsp;Wussards and other Pets<br><br />
<br><br />
Unser Wunsch ist es, einen Führer pro Gruppe zu haben, plus ein paar Leute als Raidführer.<br><br />
<br><br />
Richte das ein wie folgt: Erstelle in "Raid" eine Gruppe welche sich "Gruppenführer" nennt. Stecke den Führer von jeder Gruppe in diese Gruppe. Im selben Kanal definiere die Gruppe "Raidführer" und stecke die Raidführer in diese Gruppe.<br><br />
<br><br />
Im "Raid" Kanal definiere folgende ACL:<br><br />
<br><br />
1. @all deny enter, deny speak [Apply Here only]<br><br />
2. @raidleaders allow enter, allow speak, allow link, allow mute, allow kick [Apply Here and Apply Subs]<br><br />
3. @groupleaders allow speak, allow link [Apply Here only]<br><br />
4. @groupleaders allow link, allow mute, allow kick [Apply Subs only]<br> <br />
<br><br />
Die erste Regel stellt sicher, dass niemand sprechen kann oder den "Raid" Kanal betreten kann. Die zweite Regel hebt die erste Regel für jeden Raidführer auf ebenso wie diese weitgehende Rechte bekommen. Die dritte Regel stellt sicher, dass Gruppenführer zum "Raid" Kanal verbinden sowie dorthin sprechen können, und die vierte Regel gibt den Gruppenführern die Erlaubnis, vom Unterkanal zu verbinden ebenso wie lästige Leute loszuwerden.<br><br />
<br><br />
Normale Spieler sind nicht in der Lage, den "Raid" Kanal zu betreten aber da diese Weigerung nur im "Raid" Kanal giltet, können sie alle Unterkanäle betreten, welche sie wollen. Wenn die Kanäle verbunden sind, kann jeder in den verbundenen Kanälen die Raidführer hören sowie die Gruppenführer. Dennoch hören Raidführer nur die Gruppenführer, nicht die anderen Spieler. Auf diesem Weg bleiben Spieler ruhig wenn sie ein Kommando bekommen von den Führern (und hören das Kommando direkt ohne das der Gruppenführer es wiederholen muss), und wenn nicht, dann stört es nicht den Rest des Raid.</div>Javitoninohttps://wiki.mumble.info/index.php?title=Template:Languages&diff=1631Template:Languages2007-08-09T12:02:29Z<p>Javitonino: </p>
<hr />
<div><div style="border-top: 1px solid #6C83B0; border-bottom: 1px solid #6C83B0; text-align: center; margin-bottom: 5px; padding: 0px;"><br />
Languages: [[{{{1}}}|English]] [[{{{1}}}_(Deutsch)|Deutsch]] [[{{{1}}} (Español)|Español]]<br />
</div><br />
<br />
<noinclude><br />
= What is this template for? =<br />
This template will add a top bar to select the language you want to read the article in. For this to work, articles in other languages must be named like the english one and adding (Deutsch) (Español) (Français) after the name.<br />
<br />
=How do I use it?=<br />
To include that template, add the following to the article you are editing:<br />
<nowiki>{{Languages|pagename}}</nowiki><br />
Where pagename is the name of the article you are editing in English.<br />
<br />
=Example=<br />
Look at the ACL_and_Groups page. It is using the template right now.<br />
</noinclude></div>Javitoninohttps://wiki.mumble.info/index.php?title=Template:Languages&diff=1630Template:Languages2007-08-09T12:01:54Z<p>Javitonino: How to use it</p>
<hr />
<div><div style="border-top: 1px solid #6C83B0; border-bottom: 1px solid #6C83B0; text-align: center; margin-bottom: 5px; padding: 0px;"><br />
Languages: [[{{{1}}}|English]] [[{{{1}}}_(Deutsch)|Deutsch]] [[{{{1}}} (Español)|Español]]<br />
</div><br />
<br />
<noinclude><br />
= What is this template for? =<br />
This template will add a top bar to select the language you want to read the article in. For this to work, articles in other languages must be named like the english one and adding (Deutsch) (Español) (Français) after the name.<br />
<br />
=How do I use it?=<br />
To include that template, add the following to the article you are editing:<br />
{{Languages|pagename}}<br />
Where pagename is the name of the article you are editing in English.<br />
<br />
=Example=<br />
Look at the ACL_and_Groups page. It is using the template right now.<br />
</noinclude></div>Javitoninohttps://wiki.mumble.info/index.php?title=ACL_and_Groups/English&diff=1629ACL and Groups/English2007-08-09T11:58:35Z<p>Javitonino: </p>
<hr />
<div>{{Languages|ACL and Groups}}<br />
<br />
= ACL FAQ in other Languages =<br />
<br />
This ACL FAQ you can find in following Languages<br><br />
[[ACL_and_Groups|English]]&nbsp;&nbsp; [[ACL_FAQ_(Deutsch)|Deutsch]]&nbsp;&nbsp; [[ACL_FAQ_(Espanol|Espanol]]&nbsp;&nbsp; [[ACL_FAQ_(Francaise)|Francaise]]&nbsp;&nbsp; [[ACL_FAQ_(Italiano)|Italiano]]<br />
<br />
<br />
=Tutorial=<br />
You can find an illustrated tutorial/quick guide on how to administer groups and permission here: [[ACL tutorial_(English)|ACL Tutorial]]<br />
<br />
= Groups =<br />
<br />
Groups are tied to a specific channel, but can also be inherited by subchannels. Groups are convenient ways to administer channels; set up the ACLs on the top of the tree that should have similar privilege structure, and just change the group memberships on subchannels.<br />
<br />
For each channel, a group has 3 pieces of data. The list of players to add to the group, the list of players inherited from the same group on the parent channel, and the list of players to remove from the group.<br />
<br />
A group will only inherit players from the parent if ''Inherit'' is set true and the group was marked ''Inheritable'' on the parent. Most of the time you want both of these to be set.<br />
<br />
== Example ==<br />
<br />
Let's take a practical example; the ''admin'' group. Every time a player makes a channel, he is automatically added to the admin group. This doesn't automatically give him any privileges, it just marks him as a member of that group, however Murmur's default installation installs an ACL that gives the ''admin'' group write bit (all access).<br />
<br />
<br />
In a structure like this:<br />
* Root<br />
** A<br />
*** B<br />
** C<br />
*** D<br />
<br />
In Root, player "Big Boss" is alone in the admin group. In channel A, player "BossA" is in the Add list, and "BossB" is the same in channel B.<br />
<br />
Since the ''admin'' group is inherited and inheritable, a player that is a member at any parent of the current channel is also a member in the current channel. So the total list of members in channel B is "Big Boss, BossA, BossB". The convenience of this system is that if we later att "Super Boss" to admin in Root, he'll automatically be in the admin group of every channel below.<br />
<br />
Let's move on, and say that player "BossC" is in the Add list in channel C, but here admin is marked as not inherit. This means that "Big Boss" is not in the admin list, and any changes for admin in Root will not be seen here. Channel D will inherit the list from C, unless C also marks admin as not inheritable.<br />
<br />
= ACL =<br />
<br />
ACL (Access Control Lists) are all attached to a specific channel. A channel can specify if it wants to inherit the ACL on the parent, but it cannot specify which; it's a all or nothing deal. ACL are evaluated in order, from top to bottom along the chain of channels.<br />
<br />
For each entry, either a user or a group will match. A user must be a specific, registered user, while a group can be any group valid in the channel the ACL is defined on. Note that group membership is evaluated in the channel the ACL is executed in, which is important for inherited ACLs. If a group begins with a ''!'', it's membership is inverted, and if it begins with a ''~'', it is evaluated in the context of the channel the ACL is defined on (and not the active channel).<br />
: all<br />
Everyone<br />
: auth<br />
All authenticated users<br />
: in<br />
All users inside current channel<br />
: out<br />
All users outside current channel<br />
<br />
For each entry, permissions are either allowed or denied; in case of a conflict the last entry takes precedence. Remember that all entries are evaluated in order, so if you have the following set of entries:<br />
* @all deny speak<br />
* @all allow speak<br />
Then everyone will be allowed to speak. On the other hand<br />
* @all allow speak<br />
* @all deny speak<br />
Will deny speak from everyone.<br />
<br />
Each entry can be marked as either applying in the current channel, in subchannels or both. Most of the time you want both. Remember that for an entry to be applied on a subchannel, you have to apply it to subchannels '''and''' allow inheritance in the subchannels.<br />
<br />
== The @sub group ==<br />
<br />
There is a special group called ''sub'', which just like ''all'' has a special meaning. Sub is used as ''sub,a,b,c'', where ''a'' is the minimum number of common parents, and ''b'' and ''c'' restrain the path depth: <br />
*b is the minimum and c the maximum path length, measured from the channel referred by a.<br />
*If any of those parameter is missing, then there will be no minimum/maximum path length.<br />
<br />
It's somewhat complex, but also rather powerful. For example, assume the following tree:<br />
<br />
* Root<br />
** A<br />
*** A1<br />
**** Sub1<br />
**** Sub2<br />
*** A2<br />
*** A3<br />
** B<br />
*** B1<br />
*** B2<br />
<br />
Let's deny enter to all on ''Root'' to start with. Then, on ''A'', we define<br />
<br />
# @~sub,0,1 +enter<br />
<br />
First of all, this ACL will be evaluated in the context of the defining channel, since the group starts with ~.<br />
<br />
The first parameter (0) indicates how many additional elements of the path name must match. A zero means we require a match up to this point. This means that any player in a channel under the path Root.A will match. If the parameter had been 1 and we were in channel Sub2, the path of the player would need to match Root.A.Sub1. Setting this to positive values only makes sense for pinned groups (with the ~).<br />
<br />
The second parameter requires the path of the evaluated channel to be at least one element longer than the path of the channel of the ACL. So this rule will match in anything that starts with Root.A and has at least one more element.<br />
<br />
To sum it up; this rule allows anyone in one of A's descendants (but no A itself) to join A or any of its descendants (we assume subchannels inherit the rule).<br />
<br />
If we don't use the ~, then it will allow people in any of A descendants to go up (ie, from Sub1 to A1 or A but not the other way) or, in other words, allow people in the descendant of a channel (any depth) to enter it.<br />
<br />
Let's add a new rule to ''A1'':<br />
<br />
# @sub,-1,0 +link<br />
<br />
This allows anyone that's in the parent (equal path up to -1 elements (the first parameter)) or any of the siblings (path length equal (the 0 parameter)) to link to this channel.<br />
<br />
And finally, just to show how messed up it can get, let's add this on B:<br />
<br />
# @~sub,-1,2,2 +enter<br />
<br />
This lets anyone that's currently in a descendant of Root (B's parent) and has a path length of exactly 2 (length of Root.B -1 + 2) join, so this rule would match someone in A1, but not A or Sub1.<br />
<br />
== Write ==<br />
<br />
This gives total control over the channel, including the ability to edit ACLs. This privilege implies all other privileges.<br />
<br />
== Traverse ==<br />
<br />
Without this privlege, a player will be unable to access the channel or any subchannels in any way, regardless of privileges in the subchannel. Don't deny this unless you really know what you're doing; you can probably achieve the effect you want by denying a player the Enter privlege.<br />
<br />
== Enter ==<br />
<br />
Allows player to enter channel. Even without this privilege, a player can be moved into the channel by a player with Move/Kick.<br />
<br />
== Speak ==<br />
<br />
Allows player to speak in channel. For linked channels, only players with Speak privilege in the destination channels will be heard. This can be used to set up a hierarchy of linked channels where all players can hear all the leader of each group, but normal players will not be propageated outside their channel. This way, players will hear someone else is talkig to the group leader and (hopefully) stop talking for a short while.<br />
<br />
If a player joins a channel he does not have Speak privilege in, he will be suppressed by the server, and will be unable to speak until someone unmutes him.<br />
<br />
== Mute / Deafen ==<br />
<br />
Allows a player to mute or deafen another player. Note that mute status will follow a player until he is either manually unmuted or reconnects to the server.<br />
<br />
== Move / Kick ==<br />
<br />
Allows a player to move another player to another channel or kick them off the server. Unless the target player has Enter privileges in the channel he's being moved to, Move privileges is required in both channels.<br />
<br />
== Make Channel ==<br />
<br />
Allows a player to make a subchannel in the current channel. The player will automatically be added to the ''admin'' group in the new channel, so make the inheritable ACLs give the privileges you desire.<br />
<br />
== Link Channel ==<br />
<br />
Allows a player to link or unlink, as well as push-to-link a channel. Unlinking requires Link privilege in either channel, and linking requires Link privilege in both.<br />
<br />
== AltSpeak ==<br />
<br />
Allows a player to speak in channel if he is holding the Alt Push-To-Talk key(can be configured in the Shortcuts tab of the options window). It works as Speak for linked channels, etc.<br />
<br />
= Examples =<br />
<br />
== Group of servers with FPS game ==<br />
<br />
In this example, we assume we have a group of public servers running FPS games. Each game has 2 competing sides, and each side consists of one or more squads. We want a hierarchy such as this:<br />
<br />
* Servers<br />
** "Servername"<br />
*** Team 1<br />
**** Squad 1<br />
**** Squad 2<br />
**** ...<br />
*** Team 2<br />
**** Squad 1<br />
**** ...<br />
*** ...<br />
** ...<br />
<br />
Let's assume we have a small script linked with qstat that puts the player in the channel of the right side, and once in there we want to give them the ability to switch between squad channels and link at will. However, we do not want them to gain access to the channels of the other side.<br />
<br />
This is actually a very straightforward implementation; on the "Servers" channel, define an empty group called players. Then, add the following acls:<br />
<br />
# @all deny enter<br />
# @~sub,2,2 allow enter, allow link<br />
<br />
The first rule denies enter privilege to all players, and the second rule allows anyone within a hierarchy at least 2 elements down from "Servers" to move and link at will. In practice, this means that once a player is inside "Team 1", he can move freely about in there but can't switch to the other team or another server subchannel.<br />
<br />
== MMORPG Raid ==<br />
<br />
Assume this setup:<br />
<br />
* Root<br />
** Raid<br />
*** Healers<br />
*** Tanks<br />
*** Damage Dealers<br />
*** Wussards and other pets<br />
<br />
The desire is to have one leader of each group, plus a few people as raid leaders.<br />
<br />
Set this up as follows: In "Raid", create a group called "groupleaders". Put the leader of each group in this group. In the same channel define "raidleaders", and put the raidleaders in this group.<br />
<br />
In the Raid channel, define the following ACLS:<br />
# @all deny enter, deny speak [Apply Here only]<br />
# @raidleaders allow enter, allow speak, allow link, allow mute, allow kick [Apply Here and Apply Subs]<br />
# @groupleaders allow speak, allow link [Apply Here only]<br />
# @groupleaders allow link, allow mute, allow kick [Apply Subs only]<br />
<br />
The first rule makes sure nobody can speak or enter the Raid channel. The second rule lifts this restriction from anyone in the raidleaders group as well as giving them broad permissions. The third rule makes sure groupleaders can link and speak to the raid channel, and the fourth gives them permission to link from the subchannel as well as get rid of troublesome players.<br />
<br />
Normal players will not be able to join the raid channel, but as that denial only applied in the raid channel they can join any subchannel they wish. When the channels are linked, everyone in the linked channels will hear raid leaders and group leaders. However, raid leaders will only hear group leaders, they will not hear normal players. This way, players can stay quiet when they hear a command coming down (and also hear the command direct without the groupleader having to repeat it), and if they don't that won't bother the rest of the raid.</div>Javitoninohttps://wiki.mumble.info/index.php?title=Template:Languages&diff=1628Template:Languages2007-08-09T11:49:28Z<p>Javitonino: </p>
<hr />
<div><div style="border-top: 1px solid #6C83B0; border-bottom: 1px solid #6C83B0; text-align: center; margin-bottom: 5px; padding: 0px;"><br />
Languages: [[{{{1}}}|English]] [[{{{1}}}_(Deutsch)|Deutsch]] [[{{{1}}} (Español)|Español]]<br />
</div></div>Javitoninohttps://wiki.mumble.info/index.php?title=Template:Languages&diff=1627Template:Languages2007-08-09T11:49:04Z<p>Javitonino: </p>
<hr />
<div><div style="border-top: 1px solid #6C83B0; border-bottom: 1px solid #6C83B0; text-align: center; margin-bottom: 5px; padding: 0px;"><br />
Languages: [[{{{FULLPAGENAME}}}|English]] [[{{{1}}}_(Deutsch)|Deutsch]] [[{{{1}}} (Español)|Español]]<br />
</div></div>Javitoninohttps://wiki.mumble.info/index.php?title=Template:Languages&diff=1626Template:Languages2007-08-09T11:48:07Z<p>Javitonino: </p>
<hr />
<div><div style="border-top: 1px solid #6C83B0; border-bottom: 1px solid #6C83B0; text-align: center; margin-bottom: 5px; padding: 0px;"><br />
Languages: [[{{{{1}}}|English]] [[{{{1}}}_(Deutsch)|Deutsch]] [[{{{1}}} (Español)|Español]]<br />
</div></div>Javitoninohttps://wiki.mumble.info/index.php?title=Template:Languages&diff=1625Template:Languages2007-08-09T11:47:14Z<p>Javitonino: </p>
<hr />
<div><div style="border-top: 1px solid #6C83B0; border-bottom: 1px solid #6C83B0; text-align: center; margin-bottom: 5px; padding: 0px;"><br />
Languages: [[{{FULLPAGENAME}}|English]] [[{{{1}}}_(Deutsch)|Deutsch]] [[{{{1}}} (Español)|Español]]<br />
</div></div>Javitoninohttps://wiki.mumble.info/index.php?title=Template:Languages&diff=1624Template:Languages2007-08-09T11:45:01Z<p>Javitonino: </p>
<hr />
<div><div style="border-top: 1px solid #6C83B0; border-bottom: 1px solid #6C83B0; text-align: center; margin-bottom: 5px; padding: 0px;"><br />
Languages: [[{{{1}}}|English]] [[{{{1}}}_(Deutsch)|Deutsch]] [[{{{1}}} (Español)|Español]]<br />
</div></div>Javitoninohttps://wiki.mumble.info/index.php?title=Template:Languages&diff=1623Template:Languages2007-08-09T11:44:19Z<p>Javitonino: </p>
<hr />
<div><div style="border-top: 1px solid #6C83B0; border-bottom: 1px solid #6C83B0; text-align: center; margin-bottom: 2px;"><br />
Languages: [[{{{1}}}|English]] [[{{{1}}}_(Deutsch)|Deutsch]] [[{{{1}}} (Español)|Español]]<br />
</div></div>Javitoninohttps://wiki.mumble.info/index.php?title=ACL_and_Groups/English&diff=1622ACL and Groups/English2007-08-09T11:43:59Z<p>Javitonino: </p>
<hr />
<div>{{Languages|ACL_and_Groups}}<br />
<br />
= ACL FAQ in other Languages =<br />
<br />
This ACL FAQ you can find in following Languages<br><br />
[[ACL_and_Groups|English]]&nbsp;&nbsp; [[ACL_FAQ_(Deutsch)|Deutsch]]&nbsp;&nbsp; [[ACL_FAQ_(Espanol|Espanol]]&nbsp;&nbsp; [[ACL_FAQ_(Francaise)|Francaise]]&nbsp;&nbsp; [[ACL_FAQ_(Italiano)|Italiano]]<br />
<br />
<br />
=Tutorial=<br />
You can find an illustrated tutorial/quick guide on how to administer groups and permission here: [[ACL tutorial_(English)|ACL Tutorial]]<br />
<br />
= Groups =<br />
<br />
Groups are tied to a specific channel, but can also be inherited by subchannels. Groups are convenient ways to administer channels; set up the ACLs on the top of the tree that should have similar privilege structure, and just change the group memberships on subchannels.<br />
<br />
For each channel, a group has 3 pieces of data. The list of players to add to the group, the list of players inherited from the same group on the parent channel, and the list of players to remove from the group.<br />
<br />
A group will only inherit players from the parent if ''Inherit'' is set true and the group was marked ''Inheritable'' on the parent. Most of the time you want both of these to be set.<br />
<br />
== Example ==<br />
<br />
Let's take a practical example; the ''admin'' group. Every time a player makes a channel, he is automatically added to the admin group. This doesn't automatically give him any privileges, it just marks him as a member of that group, however Murmur's default installation installs an ACL that gives the ''admin'' group write bit (all access).<br />
<br />
<br />
In a structure like this:<br />
* Root<br />
** A<br />
*** B<br />
** C<br />
*** D<br />
<br />
In Root, player "Big Boss" is alone in the admin group. In channel A, player "BossA" is in the Add list, and "BossB" is the same in channel B.<br />
<br />
Since the ''admin'' group is inherited and inheritable, a player that is a member at any parent of the current channel is also a member in the current channel. So the total list of members in channel B is "Big Boss, BossA, BossB". The convenience of this system is that if we later att "Super Boss" to admin in Root, he'll automatically be in the admin group of every channel below.<br />
<br />
Let's move on, and say that player "BossC" is in the Add list in channel C, but here admin is marked as not inherit. This means that "Big Boss" is not in the admin list, and any changes for admin in Root will not be seen here. Channel D will inherit the list from C, unless C also marks admin as not inheritable.<br />
<br />
= ACL =<br />
<br />
ACL (Access Control Lists) are all attached to a specific channel. A channel can specify if it wants to inherit the ACL on the parent, but it cannot specify which; it's a all or nothing deal. ACL are evaluated in order, from top to bottom along the chain of channels.<br />
<br />
For each entry, either a user or a group will match. A user must be a specific, registered user, while a group can be any group valid in the channel the ACL is defined on. Note that group membership is evaluated in the channel the ACL is executed in, which is important for inherited ACLs. If a group begins with a ''!'', it's membership is inverted, and if it begins with a ''~'', it is evaluated in the context of the channel the ACL is defined on (and not the active channel).<br />
: all<br />
Everyone<br />
: auth<br />
All authenticated users<br />
: in<br />
All users inside current channel<br />
: out<br />
All users outside current channel<br />
<br />
For each entry, permissions are either allowed or denied; in case of a conflict the last entry takes precedence. Remember that all entries are evaluated in order, so if you have the following set of entries:<br />
* @all deny speak<br />
* @all allow speak<br />
Then everyone will be allowed to speak. On the other hand<br />
* @all allow speak<br />
* @all deny speak<br />
Will deny speak from everyone.<br />
<br />
Each entry can be marked as either applying in the current channel, in subchannels or both. Most of the time you want both. Remember that for an entry to be applied on a subchannel, you have to apply it to subchannels '''and''' allow inheritance in the subchannels.<br />
<br />
== The @sub group ==<br />
<br />
There is a special group called ''sub'', which just like ''all'' has a special meaning. Sub is used as ''sub,a,b,c'', where ''a'' is the minimum number of common parents, and ''b'' and ''c'' restrain the path depth: <br />
*b is the minimum and c the maximum path length, measured from the channel referred by a.<br />
*If any of those parameter is missing, then there will be no minimum/maximum path length.<br />
<br />
It's somewhat complex, but also rather powerful. For example, assume the following tree:<br />
<br />
* Root<br />
** A<br />
*** A1<br />
**** Sub1<br />
**** Sub2<br />
*** A2<br />
*** A3<br />
** B<br />
*** B1<br />
*** B2<br />
<br />
Let's deny enter to all on ''Root'' to start with. Then, on ''A'', we define<br />
<br />
# @~sub,0,1 +enter<br />
<br />
First of all, this ACL will be evaluated in the context of the defining channel, since the group starts with ~.<br />
<br />
The first parameter (0) indicates how many additional elements of the path name must match. A zero means we require a match up to this point. This means that any player in a channel under the path Root.A will match. If the parameter had been 1 and we were in channel Sub2, the path of the player would need to match Root.A.Sub1. Setting this to positive values only makes sense for pinned groups (with the ~).<br />
<br />
The second parameter requires the path of the evaluated channel to be at least one element longer than the path of the channel of the ACL. So this rule will match in anything that starts with Root.A and has at least one more element.<br />
<br />
To sum it up; this rule allows anyone in one of A's descendants (but no A itself) to join A or any of its descendants (we assume subchannels inherit the rule).<br />
<br />
If we don't use the ~, then it will allow people in any of A descendants to go up (ie, from Sub1 to A1 or A but not the other way) or, in other words, allow people in the descendant of a channel (any depth) to enter it.<br />
<br />
Let's add a new rule to ''A1'':<br />
<br />
# @sub,-1,0 +link<br />
<br />
This allows anyone that's in the parent (equal path up to -1 elements (the first parameter)) or any of the siblings (path length equal (the 0 parameter)) to link to this channel.<br />
<br />
And finally, just to show how messed up it can get, let's add this on B:<br />
<br />
# @~sub,-1,2,2 +enter<br />
<br />
This lets anyone that's currently in a descendant of Root (B's parent) and has a path length of exactly 2 (length of Root.B -1 + 2) join, so this rule would match someone in A1, but not A or Sub1.<br />
<br />
== Write ==<br />
<br />
This gives total control over the channel, including the ability to edit ACLs. This privilege implies all other privileges.<br />
<br />
== Traverse ==<br />
<br />
Without this privlege, a player will be unable to access the channel or any subchannels in any way, regardless of privileges in the subchannel. Don't deny this unless you really know what you're doing; you can probably achieve the effect you want by denying a player the Enter privlege.<br />
<br />
== Enter ==<br />
<br />
Allows player to enter channel. Even without this privilege, a player can be moved into the channel by a player with Move/Kick.<br />
<br />
== Speak ==<br />
<br />
Allows player to speak in channel. For linked channels, only players with Speak privilege in the destination channels will be heard. This can be used to set up a hierarchy of linked channels where all players can hear all the leader of each group, but normal players will not be propageated outside their channel. This way, players will hear someone else is talkig to the group leader and (hopefully) stop talking for a short while.<br />
<br />
If a player joins a channel he does not have Speak privilege in, he will be suppressed by the server, and will be unable to speak until someone unmutes him.<br />
<br />
== Mute / Deafen ==<br />
<br />
Allows a player to mute or deafen another player. Note that mute status will follow a player until he is either manually unmuted or reconnects to the server.<br />
<br />
== Move / Kick ==<br />
<br />
Allows a player to move another player to another channel or kick them off the server. Unless the target player has Enter privileges in the channel he's being moved to, Move privileges is required in both channels.<br />
<br />
== Make Channel ==<br />
<br />
Allows a player to make a subchannel in the current channel. The player will automatically be added to the ''admin'' group in the new channel, so make the inheritable ACLs give the privileges you desire.<br />
<br />
== Link Channel ==<br />
<br />
Allows a player to link or unlink, as well as push-to-link a channel. Unlinking requires Link privilege in either channel, and linking requires Link privilege in both.<br />
<br />
== AltSpeak ==<br />
<br />
Allows a player to speak in channel if he is holding the Alt Push-To-Talk key(can be configured in the Shortcuts tab of the options window). It works as Speak for linked channels, etc.<br />
<br />
= Examples =<br />
<br />
== Group of servers with FPS game ==<br />
<br />
In this example, we assume we have a group of public servers running FPS games. Each game has 2 competing sides, and each side consists of one or more squads. We want a hierarchy such as this:<br />
<br />
* Servers<br />
** "Servername"<br />
*** Team 1<br />
**** Squad 1<br />
**** Squad 2<br />
**** ...<br />
*** Team 2<br />
**** Squad 1<br />
**** ...<br />
*** ...<br />
** ...<br />
<br />
Let's assume we have a small script linked with qstat that puts the player in the channel of the right side, and once in there we want to give them the ability to switch between squad channels and link at will. However, we do not want them to gain access to the channels of the other side.<br />
<br />
This is actually a very straightforward implementation; on the "Servers" channel, define an empty group called players. Then, add the following acls:<br />
<br />
# @all deny enter<br />
# @~sub,2,2 allow enter, allow link<br />
<br />
The first rule denies enter privilege to all players, and the second rule allows anyone within a hierarchy at least 2 elements down from "Servers" to move and link at will. In practice, this means that once a player is inside "Team 1", he can move freely about in there but can't switch to the other team or another server subchannel.<br />
<br />
== MMORPG Raid ==<br />
<br />
Assume this setup:<br />
<br />
* Root<br />
** Raid<br />
*** Healers<br />
*** Tanks<br />
*** Damage Dealers<br />
*** Wussards and other pets<br />
<br />
The desire is to have one leader of each group, plus a few people as raid leaders.<br />
<br />
Set this up as follows: In "Raid", create a group called "groupleaders". Put the leader of each group in this group. In the same channel define "raidleaders", and put the raidleaders in this group.<br />
<br />
In the Raid channel, define the following ACLS:<br />
# @all deny enter, deny speak [Apply Here only]<br />
# @raidleaders allow enter, allow speak, allow link, allow mute, allow kick [Apply Here and Apply Subs]<br />
# @groupleaders allow speak, allow link [Apply Here only]<br />
# @groupleaders allow link, allow mute, allow kick [Apply Subs only]<br />
<br />
The first rule makes sure nobody can speak or enter the Raid channel. The second rule lifts this restriction from anyone in the raidleaders group as well as giving them broad permissions. The third rule makes sure groupleaders can link and speak to the raid channel, and the fourth gives them permission to link from the subchannel as well as get rid of troublesome players.<br />
<br />
Normal players will not be able to join the raid channel, but as that denial only applied in the raid channel they can join any subchannel they wish. When the channels are linked, everyone in the linked channels will hear raid leaders and group leaders. However, raid leaders will only hear group leaders, they will not hear normal players. This way, players can stay quiet when they hear a command coming down (and also hear the command direct without the groupleader having to repeat it), and if they don't that won't bother the rest of the raid.</div>Javitoninohttps://wiki.mumble.info/index.php?title=Template:Languages&diff=1621Template:Languages2007-08-09T11:43:35Z<p>Javitonino: </p>
<hr />
<div><div style="border-top: 1px solid #6C83B0; border-bottom: 1px solid #6C83B0; text-align: center;"><br />
Languages: [[{{{1}}}|English]] [[{{{1}}}_(Deutsch)|Deutsch]] [[{{{1}}} (Español)|Español]]<br />
</div></div>Javitoninohttps://wiki.mumble.info/index.php?title=Template:Languages&diff=1620Template:Languages2007-08-09T11:40:59Z<p>Javitonino: </p>
<hr />
<div>----<br />
Languages: [[{{{1}}}|English]] [[{{{1}}}_(Deutsch)|Deutsch]] [[{{{1}}} (Español)|Español]]<br />
----</div>Javitoninohttps://wiki.mumble.info/index.php?title=Template:Languages&diff=1619Template:Languages2007-08-09T11:40:16Z<p>Javitonino: </p>
<hr />
<div>Languages: [[{{{1}}}|English]] [[{{{1}}}_(Deutsch)|Deutsch]] [[{{{1}}} (Español)|Español]]</div>Javitoninohttps://wiki.mumble.info/index.php?title=Template:Languages&diff=1618Template:Languages2007-08-09T11:39:35Z<p>Javitonino: </p>
<hr />
<div>[[{{{1}}}|English]] [[{{{1}}}_(Deutsch)|Deutsch]] [[{{{1}}} (Español)|Español]]</div>Javitoninohttps://wiki.mumble.info/index.php?title=Template:Languages&diff=1617Template:Languages2007-08-09T11:37:19Z<p>Javitonino: Template for language selection</p>
<hr />
<div>[[{{{1}}} English]] [[{{{1}}}_(Deutsch)]] [[{{{1}}} (Español)_Español]]</div>Javitoninohttps://wiki.mumble.info/index.php?title=FAQ/Deutsch&diff=1543FAQ/Deutsch2007-08-03T11:22:43Z<p>Javitonino: /* Wie kann ich Murmur als SyS V Dienst laufen lassen (selbständig starten nach Serverstart) */ Script appeared in multiple boxes... fixed</p>
<hr />
<div>==FAQ: Über Mumble==<br />
<br />
===Was ist Mumble===<br />
Mumble ist eine Voice Chat Anwendung für Gruppen. Es kann für ALLES verwendet werden, die primäre Nutzung liegt aber im Bereich der Computerspiele<br />
<br />
===Auf welchen Plattformen läuft Mumble===<br />
Der Mumble Client läuft unter Windows XP und unter Linux.<br />
Der Server "Murmur" läuft auf allen Systemen, auf denen Du QT4 kompilieren kannst<br />
<br />
<br />
===Systemanforderungen===<br />
Client: Linux oder Windows XP, ein Mikrofon. Der Server bzw. die Anzahl der Server hängt von der Bandbreite Deines Servers ab. Solange Deine Netzwerkhardware über ausreichende Kapazitäten verfügt, solange läuft der Server "Murmur" auf allem ;-)<br />
<br />
Bitte beachtet, die Mumble-Binarys wurden für SSE-Prozessoren (Pentium 3 oder Athlon XP) kompiliert.<br />
Mumble ist eine VoIP Lösung für Computerspiele, und da die meisten modernen Computerspiele eine so gute CPU benötigen, war es für das Entwicklerteam von Mumble nicht notwendig, Mumble dahingehend zu optimieren.<br />
<br />
===Mumble Installieren:===<br />
Vorgebaute Programmpakete könnt ihr von Sourceforge downloaden wenn ihr Windows oder ein i386-Linux mit installiertem Debian Paket Manager habt. Installationsquellen:<br />
<br />
<br />
* Windows: [[http://sourceforge.net/project/showfiles.php?group_id=147372|Sourceforge]]<br />
* Linux<br />
* Debian, Ubuntu, etc. [[http://sourceforge.net/project/showfiles.php?group_id=147372|Sourceforge]] (.deb) oder das Trevino Repository [[http://3v1n0.tuxfamily.org/|[2]]]<br />
* Distros welche RPM benutzen: Du kannst ein RPM nutzen [[http://sourceforge.net/forum/forum.php?thread_id=1782689&forum_id=492606|welches im Forum gefunden wurde]]<br />
* Gentoo: //emerge mumble// funktioniert. Ihr müsst aber die sqlite oder sqlite3 Flags aktiviert haben und müsst,<br />
falls ihr QT4 ohne die Flags emerged habt, QT4 erneut emergen.<br />
* Archlinux: Ihr findet ein PKGBUILD im AUR: [[http://aur.archlinux.org/packages.php?do_Details=1&ID=10221|[3]]]<br />
<br />
Ausschlussklausel: Nur die Dateien von Sourceforge sind offiziell. Seit vorsichtig im Umgang mit Dateien von anderen Quellen.<br />
Für diejenigen wo es wollen. Hier findet ihr zwei gute Tutorials wo erklärt wird, wie ihr Mumble/Murmur auf eurem System kompilieren könnt.<br />
<br />
* Linux: [[http://mumble.sourceforge.net/Building_from_Source|Kompilierung]]<br />
* Windows: [[http://mumble.sourceforge.net/BuildingWindows|Kompilierung auf Windows Systemen]]<br />
<br />
<br />
===Was macht Mumble besser===<br />
Mumble hat eine niedrige Latenz kombiniert mit einer guten Soundqualität. Es nutzt Speex extensiv, nicht nur die Sprachkompression selbst, sondern auch die Sprachvorverarbeitung um ungewollte Geräusche zu entfernen und die Deutlichkeit der Sprache zu erhöhen. Mumble nutzt die "Positional Audio" Technik für Spiele welche dies unterstützen. Das bedeutet das die Stimmen der anderen Spieler aus der Richtung kommen wo deren Charaktere sich im Spiel befinden.<br />
<br />
===Welche Bandbreite benötige ich===<br />
Seit 0.9.1 ist dies sehr variabel und hängt stark vom Spieler ab. Mit Top Qualität, kleinster Latenz und Positional Audio beträgt die Bandbreite 64,6 kbit/s inkl. dem IP und UDP Overhead. Mit 80ms Übertragungsverzögerung, der geringsten Sprachqualität und ohne Positional Audio sind es 11.0 kbit/s (wieder mit IP und UDP Overhead). Standard sind 45.4 kbit/s; das Entwicklerteam hat noch keine Verschlechterung rausgehört gegenüber den 20 kbit/s mehr bei 65.4 kbit/s. Wenn Ihr mit anderen Produkten vergleicht, dann vergesst nicht, die komplette Bandbreite zu vergleichen und nicht nur die Bitrate der Audioentschlüsselung.<br />
<br />
Es gibt 2 Möglichkeiten, um die Bandbreite zu tunen. Die Audio Bitrate per Audio Frame (20 ms) und die Anzahl von Frames pro Paket. Jedes gesendete Paket hat einen Overhead von 28 Byte nur IP und UDP alleine, so dass bei der höchsten Übermittlungsrate (50 Pakete pro Sekunde) 1400 Byte nackte Daten nur für die Übermittlung des Netzwerk Overheads anfallen.<br />
Probiere es aus und finde ein Gleichgewicht zwischen den beiden Parametern, welche für dich gut sind. Die Entwickler empfehlen, auf eine hohe Audiobitrate zugunsten geringerer Latenz zu verzichten. Mumble klingt auch auf der niedrigsten Audio Qualitätsstufe noch ganz gut.<br />
<br />
Es gibt keine Möglichkeit, die Menge der hereinkommenden Bandbreite einzustellen; du musst die Daten welche durch die anderen sprechenden Spieler anfallen, "ertragen" können. Das ist eine geringfügige Angelegenheit, denn aktuell sind die meisten Spieler auf ADSL so dass der meiste Upload der anderen Spieler nur einen "Flaschenhals" darstellt, also eher gering ist.<br />
<br />
<br />
===Welche Werkzeuge wurden für die Entwicklung von Mumble verwendet===<br />
Siehe auch Entwicklungswerkzeuge<br />
<br />
===Wie kann ich helfen===<br />
Ein guter Start ist, Mumble zu nutzen. Wenn es Dir gefällt, zeig es deinen Freunden. Wenn Dir etwas nicht gefällt, dann teile dies den Entwicklern mit, so dass diese Probleme entfernen können.<br />
<br />
==FAQ: Audio Funktionen==<br />
<br />
===Wie funktioniert "Positional Audio"===<br />
Deine Position im Spiel wird mit jedem Audio Paket übermittelt und Mumble benutzt Standard DirectSound 3D, um die Audioausgabe entsprechend zu positionieren auf der Empfängerseite. Nur Spiele mit entsprechendem PlugIn können "Positional Audio" nutzen. Alle anderen Spiele laufen normal, aber ohne 3D Sound resp. "Positional Audio".<br />
<br />
===Warum klingt Mumble so viel besser als andere VoIP Programme===<br />
Ein Wort: Geräuschverminderung. Standard bei Speex 1.1 aufwärts und alle VoIP Anwendungen welche Speex implementieren, haben die Möglichkeit, ganz trivial die selben Filter zu verwenden.<br />
<br />
Die Geräusche vom Eingang zu entfernen bedeutet, das die Audioqualität klarer und die benötigte Bitrate kleiner wird. Es braucht weniger Bits um eine klare Stimme zu erzeugen als es Bits braucht, um akkurat die Geräusche darzustellen. So wird in allen Geräuschübermittlungen ein grosser Anteil Bits Nebengeräusche formen.<br />
(Die kann man sich sparen ;-) )<br />
<br />
===Wo ist die Lautstärkenkontrolle===<br />
Mumble benutzt die Standardlautstärke, welche Du in Deinem Betriebssystem eingestellt hast. Es gibt keine Funktion für die Verstärkung hereinkommender Sprache, und wird es auch nicht geben, da dies die Audioqualität verschlechtern wird, und die Entwickler dies nicht wollen. Verständlich.<br />
<br />
===Die Qualität von Text to Speech ist entsetzlich===<br />
Die Entwickler nutzen die Standard MS-Speech API, und die Stimmen die inklusiv dort sind, sind alles andere als gut. Wenn Ihr MS Office oder die "Speech SDK" installiert habt, dann habt ihr mehr Stimmen, welche ihr im Speech Control Panel konfigurieren könnt. Ihr könnt auch eine kommerzielle Text-to-Speech Engine kaufen; Solange diese SAPI5 kompatibel ist, kann diese auch in Mumble verwendet werden. Die Hauptentwickler benutzen derzeit NeoSpeech Kate (kann eigenständig von NextUp bezogen werden).<br />
<br />
===Warum klingen manche Klänge metallisch===<br />
Mumble benutzt den Speex Geräuschfilter, und wenn beim Sprecher ein starker Geräuschhintergrund besteht, dann werden auch Teile der Stimme gefiltert. Die Alternative wären laute Geräusche; das heisst, kostbare Bandbreite wird verschwendet um die Geräusche zu entschlüsseln und die klare Wiedergabe der Stimme wird ebenfalls schlechter.<br />
<br />
===Warum erkennt die "Voice Activity" meine Stimme nicht mehr===<br />
Wenn Du deine Audioaustattung schnell und plötzlich änderst wie z.B. ziehen und neu einstöpseln des Mikrofons oder ziehen eines Blattes direkt über dem Mikrofon bringt den Stimmpräprozessor aus dem Gleichgewicht. Er wird sich zwar wieder erholen, dies kann jedoch einige Zeit dauern.<br />
<br />
Um den Präprozessor zu resetten, wähle "Reset" aus dem "Audio"menü.<br />
<br />
===Was ist dieses eigenartige Echo in dem ich mich selbst von den anderen Usern wieder höre===<br />
Bedauerlicherweise produzieren eine Menge bekannter Headsets Spuren von Echo. In anderen VoIP Produkten bemerkst Du diese nicht, weil das Echo geringer ist als der Geräuschpegel, aber Mumble entfernt alle Geräusche und so wird das Echo klar. Da kann man nur wenig machen. Aber es gibt doch einige Dinge, die derjenige der das Echo produziert, tun kann.<br />
Die einfachste Lösung ist, ASIO zu benutzen und Echo Entfernung einzuschalten. Das erfordert ein Analoges Headset (kein USB Typ) und eine Soundkarte von hoher Qualität.<br />
Die beschwerlichere Lösung ist, das Headset zu bearbeiten. Wenn es möglich ist, den Arm des Headsets etwas herauszubrechen so dass das Mikrofon weiter weg vom Ohrhörer ist, dann tu es und mach den Arm mit einem dicken Isolierband wieder hin. Das isoliert das Headset von Vibrationen. Wenn Dein Headset offen ist, (keine grossen Ohrhörer), dann gibt es einen Weg des Klanges durch die Luft von den Ohrhörern zum Mikrofon, der Echo erzeugen kann. Du kannst dies lösen, indem du Schaumstoffartige Dinge an die Ohrhörervorderseite anhängst, um den Sound der nach aussen hörbar wird, einzudämmen. Dies zerstört meist die Ergonomie des Headsets und weiter schaut es etwas befremdlich aus ;-)<br />
<br />
==FAQ: Server==<br />
<br />
===Welche Qualität an Bandbreite brauche ich===<br />
Im schlimmsten Fall: Anzahl User X Anzahl sprechender User X 60 kbit/s. Mit nicht ganz so aggressiven Einstellungen etwas 20 kbit/s und Minimum bei 12 kbit/s.<br />
<br />
Beachte, dass Mumble mit der sozialen Spielcommunity verzahnt ist, jeder kann zu jedem sprechen in klarer Sprache, anstelle nur Befehle zu bellen. Der Anteil sprechender User kann also höher sein als erwartet.<br />
Das bedeutet auch dass ein Server mit 20 Spielern, wo zwei gleichzeitig sprechen, 0.8-2.4 Mbit/s benötigt, abhängig von den Qualitätseinstellungen. In der INI des Servers kannst Du angeben, welche Bitrate maximal erlaubt ist für User und ebenso auch die maximale erlaubte Anzahl von Usern die online sein können (Slots).<br />
<br />
<br />
===Wo stelle ich die Willkommensnachricht, den "Listen Port" und weiteres ein===<br />
In der murmur.ini<br />
<br />
Diese Datei erklärt sich selber<br />
<br />
<br />
===Wie administriert man die ACL===<br />
Kommt noch:<br />
<br />
===Welche Qualität an Bandbreite brauche ich===<br />
Im schlimmsten Fall: Anzahl User X Anzahl sprechender User X 60 kbit/s. Mit nicht ganz so aggressiven Einstellungen etwas 20 kbit/s und Minimum bei 12 kbit/s.<br />
<br />
Beachte, dass Mumble mit der sozialen Spielcommunity verzahnt ist, jeder kann zu jedem sprechen in klarer Sprache, anstelle nur Befehle zu bellen. Der Anteil sprechender User kann also höher sein als erwartet.<br />
Das bedeutet auch dass ein Server mit 20 Spielern, wo zwei gleichzeitig sprechen, 0.8-2.4 Mbit/s benötigt, abhängig von den Qualitätseinstellungen. In der INI des Servers kannst Du angeben, welche Bitrate maximal erlaubt ist für User und ebenso auch die maximale erlaubte Anzahl von Usern die online sein können (Slots).<br />
<br />
<br />
===mumble.pri:8: Unbekannte test Funktion: CONFIG===<br />
Mumble benötigt QT 4.2 (Bei Mumble-Funk.de läuft 4.2.2).<br />
<br />
Wenn Ihr QT kompiliert dann macht am Anfang<br />
<br />
[[code]]<br />
./configure -qt-sql-sqlite<br />
[[code]]<br />
<br />
<br />
um das MakeFile zu erstellen.<br />
<br />
<br />
===Wie kann ich die Datenbank resetten===<br />
Bei sqlite (Standard):<br />
<br />
Lösche die Datei murmur.sqlite und führe den Befehl<br />
murmur -supw erneut aus.<br />
<br />
Bei MySQL: TRUNCATE DATABASENAME (kein Delete)<br />
<br />
<br />
===Wie ändere ich das Passwort eines Users===<br />
Konsole (BASh):<br />
<br />
-bash-3.00$ sqlite3 murmur.sqlite<br />
sqlite> UPDATE players SET pw<br />
'newpassword' WHERE name<br />
'playername';<br />
sqlite><br />
<br />
<br />
Weitere Möglichkeit: SQLiteBrowser verwenden<br />
<br />
<br />
===Wie kann ich die Datenbank sichern (Backup)===<br />
Fahre den Murmur runter und kopiere die murmur.sqlite. Dies ist die Datenbank.<br />
<br />
MySQL: Exportiere die Datenbank an der Konsole (man mysql) oder mit PHPMyAdmin.<br />
<br />
<br />
===Wie kann ich Murmur als SyS V Dienst laufen lassen (selbständig starten nach Serverstart)===<br />
Benutze dieses Skript.<br />
<br />
#!/bin/bash<br />
#<br />
# chkconfig: 35 90 12<br />
# description: Murmur Service<br />
# Idologic Jun 27, 2007 <br />
<br />
# Get function from functions library<br />
. /etc/init.d/functions <br />
<br />
# Start the service Murmur<br />
start() {<br />
initlog -c "echo -n Starting Murmur server: "<br />
daemon /usr/bin/murmur -ini /etc/murmur/murmur.ini<br />
### Creating the lock file ###<br />
touch /var/lock/subsys/murmur<br />
success $"Murmur server startup"<br />
echo<br />
} <br />
<br />
# Restart the service Murmur<br />
stop() {<br />
initlog -c "echo -n Stopping Murmur server: "<br />
killproc murmur<br />
### Deleting the lock file ###<br />
rm -f /var/lock/subsys/murmur<br />
echo<br />
}<br />
<br />
### main logic ###<br />
case "$1″ in<br />
start)<br />
start<br />
;;<br />
stop)<br />
stop<br />
;;<br />
status)<br />
status murmur<br />
;;<br />
restart|reload|condrestart)<br />
stop<br />
start<br />
;;<br />
*)<br />
echo $"Usage: $0 {start|stop|restart|reload|status}"<br />
exit 1<br />
esac <br />
<br />
exit 0<br />
<br />
==FAQ: Bekannte Probleme und Lösungen==<br />
<br />
===Fehler: failure to load mumble_ol.dll===<br />
<br />
Wenn bei Dir Windows XP mit SP2 läuft, dann ist dein DirectX vielleicht veraltet. Es gibt wohl so ziemlich jeden Monat ein Update von DirectX, daher updatet auch so ziemlich jedes Spiel Dein DirectX. Derzeit ist 9.0c aktuell. Schaue auf das Erscheinungsdatum Deines DirectX.<br />
<br />
Aktuelle DirectX Versionen gibt es direkt von Microsoft.<br />
[[http://www.microsoft.com/windows/directx/default.mspx|klickt einfach mal hier um DirectX upzudaten.]]<br />
<br />
Runtergeladen, entpackt und installiert wurde dieses Problem für mich gelöst: [[http://www.microsoft.com/downloads/details.aspx?FamilyID=b406cf67-d926-463b-99e8-27199d6626b5&DisplayLang=en|DirectX End-User Runtimes]]<br />
<br />
<br />
===Ich kann andere nicht hören, andere hören mich nicht ;-(===<br />
<br />
Das kann man wohl lösen mit der Checkbox "Use TCP Mode" in Konfiguration -> Einstellungen -> Grundeinstellungen.<br />
<br />
<br />
===Webserver kann Datenbank nicht beschreiben, wenn murmur.cgi benutzt wird===<br />
<br />
Schau nach, dass die DB beschreibbar ist vom Webserverbenutzer, genauso auch das Directory in dem die DB liegt.<br />
<br />
<br />
===Fehlermeldungen in murmur.cgi Zeile 118===<br />
<br />
Sofern Du keinen anderen SMTP Server (Mailausgang) definiert hast, benötigst Du einen MTA auf dem localhost.<br />
<br />
<br />
<br />
===Ich kann zwar auf den Server drauf, aber Channels anlegen / joinen geht nicht===<br />
<br />
Du kannst nicht den 0.9.1 Client mit dem 0.9.2 Server nutzen. Genausowenig den 0.9.4 Client mit dem neuen 1.0.0 Server.<br />
<br />
===Wo ist der PTT Knopf (Push to Talk)===<br />
<br />
Wenn in Konfiguration -> Einstellungen -> Grundeinstellungen Push-To-Talk aktiv ist, dann muss mit Konfiguration -> Einstellungen -> Shortcuts auch eine Taste als PTT Taste definiert werden.<br />
<br />
<br />
===Shortcuts wie z.B: PTT gehen nicht unter Linux===<br />
<br />
<br />
Bitte aktiviert die Xevie Erweiterung damit die Shortcuts funktionieren.<br />
<br />
Bitte fügt folgende Zeilen in die Xorg.conf ein:<br />
<br />
Option "XEVIE" "Enable"<br />
<br />
Das schaut dann in etwa so aus:<br />
Section "Extensions"<br />
...<br />
Option "XEVIE" "Enable"<br />
EndSection<br />
<br />
Dann noch den X-Server neustarten (STRG+ALT+Backspace) und Mumble neu starten.<br />
<br />
<br />
===Die Tasten scheinen gesperrt zu sein, wenn ich Shortcuts unter Linux benutze===<br />
<br />
Zeitweise sind Tasten "gesperrt", wenn Xevie verwendet wird. Beispiel: Du drückst zwei Tasten gleichzeitig und wenn du die Tasten loslässt, dann wird nur eine Taste als gelöst erkannt. Das sieht man am besten in Spielen, wenn du anfängst, diagonal zu laufen. Wenn du dann stoppst, wird die Bewegung beibehalten. Das kann repariert werden mit den Tastenwiederholungseinstellungen welche ihr finden könnt unter:<br />
<br />
<br />
Gnome: System->Einstellungen->Tastatur<br />
<br />
KDE: K Menü->Kontrollzentrum->Peripherie->Tastatur<br />
<br />
Du kannst auch ausprobieren, den Geschwindigkeits/Anteil Regler zu verändern sowie die Tastenwiederholung auszuschalten (die erste Checkbox).</div>Javitoninohttps://wiki.mumble.info/index.php?title=ACL_and_Groups/English&diff=1535ACL and Groups/English2007-08-02T17:30:32Z<p>Javitonino: Added link to tutorial</p>
<hr />
<div>=Tutorial=<br />
You can find an illustrated tutorial/quick guide on how to administer groups and permission here: [[ACL tutorial]]<br />
<br />
= Groups =<br />
<br />
Groups are tied to a specific channel, but can also be inherited by subchannels. Groups are convenient ways to administer channels; set up the ACLs on the top of the tree that should have similar privilege structure, and just change the group memberships on subchannels.<br />
<br />
For each channel, a group has 3 pieces of data. The list of players to add to the group, the list of players inherited from the same group on the parent channel, and the list of players to remove from the group.<br />
<br />
A group will only inherit players from the parent if ''Inherit'' is set true and the group was marked ''Inheritable'' on the parent. Most of the time you want both of these to be set.<br />
<br />
== Example ==<br />
<br />
Let's take a practical example; the ''admin'' group. Every time a player makes a channel, he is automatically added to the admin group. This doesn't automatically give him any privileges, it just marks him as a member of that group, however Murmur's default installation installs an ACL that gives the ''admin'' group write bit (all access).<br />
<br />
<br />
In a structure like this:<br />
* Root<br />
** A<br />
*** B<br />
** C<br />
*** D<br />
<br />
In Root, player "Big Boss" is alone in the admin group. In channel A, player "BossA" is in the Add list, and "BossB" is the same in channel B.<br />
<br />
Since the ''admin'' group is inherited and inheritable, a player that is a member at any parent of the current channel is also a member in the current channel. So the total list of members in channel B is "Big Boss, BossA, BossB". The convenience of this system is that if we later att "Super Boss" to admin in Root, he'll automatically be in the admin group of every channel below.<br />
<br />
Let's move on, and say that player "BossC" is in the Add list in channel C, but here admin is marked as not inherit. This means that "Big Boss" is not in the admin list, and any changes for admin in Root will not be seen here. Channel D will inherit the list from C, unless C also marks admin as not inheritable.<br />
<br />
= ACL =<br />
<br />
ACL (Access Control Lists) are all attached to a specific channel. A channel can specify if it wants to inherit the ACL on the parent, but it cannot specify which; it's a all or nothing deal. ACL are evaluated in order, from top to bottom along the chain of channels.<br />
<br />
For each entry, either a user or a group will match. A user must be a specific, registered user, while a group can be any group valid in the channel the ACL is defined on. Note that group membership is evaluated in the channel the ACL is executed in, which is important for inherited ACLs. If a group begins with a ''!'', it's membership is inverted, and if it begins with a ''~'', it is evaluated in the context of the channel the ACL is defined on (and not the active channel).<br />
: all<br />
Everyone<br />
: auth<br />
All authenticated users<br />
: in<br />
All users inside current channel<br />
: out<br />
All users outside current channel<br />
<br />
For each entry, permissions are either allowed or denied; in case of a conflict the last entry takes precedence. Remember that all entries are evaluated in order, so if you have the following set of entries:<br />
* @all deny speak<br />
* @all allow speak<br />
Then everyone will be allowed to speak. On the other hand<br />
* @all allow speak<br />
* @all deny speak<br />
Will deny speak from everyone.<br />
<br />
Each entry can be marked as either applying in the current channel, in subchannels or both. Most of the time you want both. Remember that for an entry to be applied on a subchannel, you have to apply it to subchannels '''and''' allow inheritance in the subchannels.<br />
<br />
== The @sub group ==<br />
<br />
There is a special group called ''sub'', which just like ''all'' has a special meaning. Sub is used as ''sub,a,b,c'', where ''a'' is the minimum number of common parents, and ''b'' and ''c'' restrain the path depth: <br />
*b is the minimum and c the maximum path length, measured from the channel referred by a.<br />
*If any of those parameter is missing, then there will be no minimum/maximum path length.<br />
<br />
It's somewhat complex, but also rather powerful. For example, assume the following tree:<br />
<br />
* Root<br />
** A<br />
*** A1<br />
**** Sub1<br />
**** Sub2<br />
*** A2<br />
*** A3<br />
** B<br />
*** B1<br />
*** B2<br />
<br />
Let's deny enter to all on ''Root'' to start with. Then, on ''A'', we define<br />
<br />
# @~sub,0,1 +enter<br />
<br />
First of all, this ACL will be evaluated in the context of the defining channel, since the group starts with ~.<br />
<br />
The first parameter (0) indicates how many additional elements of the path name must match. A zero means we require a match up to this point. This means that any player in a channel under the path Root.A will match. If the parameter had been 1 and we were in channel Sub2, the path of the player would need to match Root.A.Sub1. Setting this to positive values only makes sense for pinned groups (with the ~).<br />
<br />
The second parameter requires the path of the evaluated channel to be at least one element longer than the path of the channel of the ACL. So this rule will match in anything that starts with Root.A and has at least one more element.<br />
<br />
To sum it up; this rule allows anyone in one of A's descendants (but no A itself) to join A or any of its descendants (we assume subchannels inherit the rule).<br />
<br />
If we don't use the ~, then it will allow people in any of A descendants to go up (ie, from Sub1 to A1 or A but not the other way) or, in other words, allow people in the descendant of a channel (any depth) to enter it.<br />
<br />
Let's add a new rule to ''A1'':<br />
<br />
# @sub,-1,0 +link<br />
<br />
This allows anyone that's in the parent (equal path up to -1 elements (the first parameter)) or any of the siblings (path length equal (the 0 parameter)) to link to this channel.<br />
<br />
And finally, just to show how messed up it can get, let's add this on B:<br />
<br />
# @~sub,-1,2,2 +enter<br />
<br />
This lets anyone that's currently in a descendant of Root (B's parent) and has a path length of exactly 2 (length of Root.B -1 + 2) join, so this rule would match someone in A1, but not A or Sub1.<br />
<br />
== Write ==<br />
<br />
This gives total control over the channel, including the ability to edit ACLs. This privilege implies all other privileges.<br />
<br />
== Traverse ==<br />
<br />
Without this privlege, a player will be unable to access the channel or any subchannels in any way, regardless of privileges in the subchannel. Don't deny this unless you really know what you're doing; you can probably achieve the effect you want by denying a player the Enter privlege.<br />
<br />
== Enter ==<br />
<br />
Allows player to enter channel. Even without this privilege, a player can be moved into the channel by a player with Move/Kick.<br />
<br />
== Speak ==<br />
<br />
Allows player to speak in channel. For linked channels, only players with Speak privilege in the destination channels will be heard. This can be used to set up a hierarchy of linked channels where all players can hear all the leader of each group, but normal players will not be propageated outside their channel. This way, players will hear someone else is talkig to the group leader and (hopefully) stop talking for a short while.<br />
<br />
If a player joins a channel he does not have Speak privilege in, he will be suppressed by the server, and will be unable to speak until someone unmutes him.<br />
<br />
== Mute / Deafen ==<br />
<br />
Allows a player to mute or deafen another player. Note that mute status will follow a player until he is either manually unmuted or reconnects to the server.<br />
<br />
== Move / Kick ==<br />
<br />
Allows a player to move another player to another channel or kick them off the server. Unless the target player has Enter privileges in the channel he's being moved to, Move privileges is required in both channels.<br />
<br />
== Make Channel ==<br />
<br />
Allows a player to make a subchannel in the current channel. The player will automatically be added to the ''admin'' group in the new channel, so make the inheritable ACLs give the privileges you desire.<br />
<br />
== Link Channel ==<br />
<br />
Allows a player to link or unlink, as well as push-to-link a channel. Unlinking requires Link privilege in either channel, and linking requires Link privilege in both.<br />
<br />
== AltSpeak ==<br />
<br />
Allows a player to speak in channel if he is holding the Alt Push-To-Talk key(can be configured in the Shortcuts tab of the options window). It works as Speak for linked channels, etc.<br />
<br />
= Examples =<br />
<br />
== Group of servers with FPS game ==<br />
<br />
In this example, we assume we have a group of public servers running FPS games. Each game has 2 competing sides, and each side consists of one or more squads. We want a hierarchy such as this:<br />
<br />
* Servers<br />
** "Servername"<br />
*** Team 1<br />
**** Squad 1<br />
**** Squad 2<br />
**** ...<br />
*** Team 2<br />
**** Squad 1<br />
**** ...<br />
*** ...<br />
** ...<br />
<br />
Let's assume we have a small script linked with qstat that puts the player in the channel of the right side, and once in there we want to give them the ability to switch between squad channels and link at will. However, we do not want them to gain access to the channels of the other side.<br />
<br />
This is actually a very straightforward implementation; on the "Servers" channel, define an empty group called players. Then, add the following acls:<br />
<br />
# @all deny enter<br />
# @~sub,2,2 allow enter, allow link<br />
<br />
The first rule denies enter privilege to all players, and the second rule allows anyone within a hierarchy at least 2 elements down from "Servers" to move and link at will. In practice, this means that once a player is inside "Team 1", he can move freely about in there but can't switch to the other team or another server subchannel.<br />
<br />
== MMORPG Raid ==<br />
<br />
Assume this setup:<br />
<br />
* Root<br />
** Raid<br />
*** Healers<br />
*** Tanks<br />
*** Damage Dealers<br />
*** Wussards and other pets<br />
<br />
The desire is to have one leader of each group, plus a few people as raid leaders.<br />
<br />
Set this up as follows: In "Raid", create a group called "groupleaders". Put the leader of each group in this group. In the same channel define "raidleaders", and put the raidleaders in this group.<br />
<br />
In the Raid channel, define the following ACLS:<br />
# @all deny enter, deny speak [Apply Here only]<br />
# @raidleaders allow enter, allow speak, allow link, allow mute, allow kick [Apply Here and Apply Subs]<br />
# @groupleaders allow speak, allow link [Apply Here only]<br />
# @groupleaders allow link, allow mute, allow kick [Apply Subs only]<br />
<br />
The first rule makes sure nobody can speak or enter the Raid channel. The second rule lifts this restriction from anyone in the raidleaders group as well as giving them broad permissions. The third rule makes sure groupleaders can link and speak to the raid channel, and the fourth gives them permission to link from the subchannel as well as get rid of troublesome players.<br />
<br />
Normal players will not be able to join the raid channel, but as that denial only applied in the raid channel they can join any subchannel they wish. When the channels are linked, everyone in the linked channels will hear raid leaders and group leaders. However, raid leaders will only hear group leaders, they will not hear normal players. This way, players can stay quiet when they hear a command coming down (and also hear the command direct without the groupleader having to repeat it), and if they don't that won't bother the rest of the raid.</div>Javitoninohttps://wiki.mumble.info/index.php?title=ACL_Tutorial/English&diff=1534ACL Tutorial/English2007-08-02T17:23:32Z<p>Javitonino: /* Registered user */</p>
<hr />
<div>=ACL tutorial=<br />
This tutorial will help you understand how permissions work on Mumble. Details about this topic can be found in [[ACL and Groups]], where there are some examples, descriptions of special groups, etc.<br />
<br />
==What we are going to do==<br />
We are going to set a server, with a ''General chat'' channel where everyone can talk. We are also creating a ''Custom channels'' channel where anyone who is authed can create and administrate his own channel.<br />
Then, as a normal authed user, we will create a couple of channels for a FPS game where people can talk either to their team or to everyone just by pressing one key.<br />
<br />
Enough talking, let's get to work.<br />
<br />
==Setting permission for the whole server==<br />
First, we will need to set up a password for the SuperUser. If you haven't done that yet, you can do it by typing this at a console/command prompt:<br />
murmur -supw somepassword<br />
<br />
Then, we open Mumble and connect to the server using SuperUser and the password we have just set. You should be looking at something like this now:<br />
<br />
http://img361.imageshack.us/img361/6586/mumbletut1dx8.png<br />
<br />
Let's start with the permissions. Open the ACL editor, you can do thi will use the menu alternative. Once we are there, you can see a windows with two tabs. The first one is for defining people who is in a group, etc. The second one is used to assign permissions to groups. <br />
Right now, in that tab, you should have two rules set: <br />
*The first one allows people on the auth group to create channels in the root channel and its subchannels.<br />
*The second one allows people in the group admins to ''Write'', that means edit permissions.<br />
<br />
For now, we will delete the rule related with the auth group by selecting it and clicking remove. We said that we don't want anyone in the root channel, as we will make a ''General chat'' channel for that. So we will add a rule to keep them out. To do that, click add, and click every checkbox in the deny column except the ''Traverse'' one.<br />
<br />
The reason to leave traverse unchecked is because it will forbid people to enter this channel '''and''' subchannels. Since every other channel is a subchannel of root, this will effectively forbid people from entering any channel. So we leave it unchecked. It is not neccesary to mark the allow check, because ''Traverse'' is allowed by default. Default settings are:<br />
*Allow: Traverse, Enter, Speak and AltSpeak<br />
*Deny: Write, Mute/Deafen, Move/Kick, Make Channel and Link channel<br />
<br />
If you are wondering, yes, we could have left Write, Mute/Deafen, Move/Kick, Make Channel and Link channel unchecked and they will still be forbidden. There is no reason to leave those rights denied as they will be by default. Now your screen should be looking like this (except that you have disabled some useless checks):<br />
<br />
http://img361.imageshack.us/img361/9215/mumbletut2hw0.png<br />
<br />
In Mumble, rules are applied from top to bottom. Right now, the:<br />
@admins allow write<br />
rule is useless as it will get over written by the<br />
@all deny write ...<br />
So we will have to fix it. Simply select the rule referring to all and click up. That should put that on top. You have now established some default settings for the whole server :)<br />
<br />
http://img363.imageshack.us/img363/3368/mumbletut3if8.png<br />
<br />
==Creating the ''General chat'' channel and setting its permissions==<br />
This channel will serve as a chat room for everyone that gets to join our channel. Since we don't allow them to speak in the root channel, and they must join this channel if they want to chat, maybe we should put a welcome message to the server that warns about that. Anyways, here we go.<br />
First, create the channel. This is as easy as clicking Channel->Add (or right-clicking in the channel you want and click add to create a subchannel, but you know, root isn't shown, so we will use the menu one). In the box that appears type the channel name, click ''OK'' and we are done.<br />
<br />
Now, we want to give the right for everyone to speak here. So we head to ''Edit ACL'' (remember to select the new channel before). You will see the rules of the root channel, but if you select them, you will see that all the options are grayed out. That's because they are inherited from the parent channel (in this case, ''Root''). If you uncheck the ''Inherit ACL's'' option, they will disappear, but we don't want that. Just add a new rule that allow everyone (group=all) to Speak or AltSpeak and click ok to save it. We are now done with this channel. Easy, no?.<br />
<br />
http://img372.imageshack.us/img372/2854/mumbletut4wu0.png<br />
<br />
==Creating the ''Custom channels'' channel and configuring it==<br />
As we said, we will let anyone who is registered to create his own channel here. The first step is easy, create the channel just as we did before. You should have something like this just in front of your nose:<br />
<br />
http://img361.imageshack.us/img361/1720/mumbletut5qo2.png<br />
<br />
Now we'll be giving ''Make channel'' rights to authed people. Just go to ACL editor, add a new rule, in the group list select or write auth and select the allow make channel checkbox.<br />
'''Warning:''' If you type the group name, make sure you press enter when you've finished. This will update the rule group. You can see that if tou type and don't press enter, it will not change the group in the top listing.<br />
<br />
http://img356.imageshack.us/img356/7333/mumbletut6vl9.png http://img387.imageshack.us/img387/6638/mumbletut6bsq9.png<br />
<br />
And now we have a pretty channel when people can create his own channel. Note that they cannot even enter ''Custom channels'' channel but they still can create subchannels. Isn't it cool?<br />
<br />
=Registered user=<br />
In this part, we will be playing a registered and authed player with a veeeeery original name: AuthedPlayer. He will be creating his own channels to host a little public channel and two private subchannels, one for each team of a FPS game. He would like that they can talk to their team or to both teams. We are seeing how to do this with the AltSpeak right, linking channels and more.<br />
<br />
==Creating the main channel==<br />
After logging in, we may play a little to check that we can't enter the root channel once we leave it (the first time you connect you will land here), that we cannot enter the ''Custom channels'' channel, etc. Once we have checked that permissions are working as expected we start creating our first channel. We simply right click in ''Custom channels'' (remember that you can still use the menu) and click add to create a new channel. As I am very creative I called it ''My Private Channel''. Automatically we are added to the admins group in that channel, so we can ''Write'' on it (remember the rules in the root channel? they are inherited all the way down to our channel). But that also mean that we get the ''Make channel'' permission inherited, so everyone who is authed can make a channel inside ours. We don't like that so...<br />
<br />
http://img400.imageshack.us/img400/2249/mumbletut7dw7.png<br />
<br />
Our rule will overwrite the inherited one, because inherited rules are always put at top. So now that we have our channel secured, we will give permission to enter and speak:<br />
<br />
http://img387.imageshack.us/img387/2315/mumbletut8lu5.png<br />
<br />
Note that we have disabled ''Applies to sub-channels''. As subchannels will not be public, we don't want them to have the ''Enter'' permission granted. If we haven't disabled this option, we have to create yet another rule just to deny the ''Enter'' permission. This way is easier. And now, we have this channel ready for service. Let's continue with the subchannels.<br />
<br />
==Creating the team subchannels==<br />
First, we create two subchannels of our own channel. As usual I called them in a very creative way... Team1 and Team2. We could define rules for each one, but it is quicker to define them in the parent channel (My Private Channel) and make the subchannels inherit the rules. First, we want people in one team channel to be able to speak so we do it like that:<br />
<br />
http://img452.imageshack.us/img452/2127/mumbletut9ix7.png<br />
<br />
Notice that we have unchecked the ''Apply to this channel'' option, as we are defining this rule only for the subchannels. More interesting is the use of the speacial group ''in''. This group refers to the people that are inside the channel the rules refers to. It appears it is the same as all, but it is quite different: <br />
We are going to link both channels. That means that people in different channels will hear each other. But we want that people only can hear teammates. So we use ''in'' to give Speak privileges to people in the same channel. This means, people in Team2 can't hear people in Team1 because the people in Team1 don't have rights to speak in Team2 because the ''in'' group only gives them permission in his own channel. It is a little complicated to understand at first, but it is very useful. To understand it, you have first to understand that each channel has its separate groups. That means that ''in'' group in Team1 is no the same group that ''in'' group in Team2.<br />
<br />
To explain it better I'm going to use some names...<br />
*Jack is in Team1<br />
*John is in Team2<br />
Both channels are linked, so the voice will be transmitted from one to the other as long as the speaker have rights in the destination channel. Jack speaks but John will not be able to hear it. That is because Jack has no rights to speak in Team2 as it is not in the Team2's ''in'' group. So voice will not be transmitted across the channel link and John will not be able to hear Jack.<br />
If we have used ''all'' instead of ''in'' for the rule, Jack and John will hear each other without a problem, as everyone is in ''all'' group.<br />
<br />
Well, let's continue. We wanted to people talk to the other team. This is when AltSpeak comes handy. We add a rule like this:<br />
<br />
http://img359.imageshack.us/img359/7660/mumbletut10sq9.png<br />
<br />
This will allow everyone (both teams) to talk to each other when AltSpeaking. AltSpeak is enabled while pressing a key defined in Shortcuts (in the Mumble options). While holding down that key, voice will be transmitted using the AltSpeak rights. As we allowed anyone to AltSpeak and both channels are linked, that means that if someone talks while pressing the key, it will be heard by both teams.<br />
<br />
And we are done.<br />
<br />
==How it looks like for some anonymous players==<br />
First you "invite" them to your team channels (you can move them from your public channel to your team channels by drag-and-drop). They have to be in your public channel to do that, as you will need Move permissions in both the origin and destination channels. If not AltSpeaking...<br />
<br />
http://img361.imageshack.us/img361/3603/mumbletut11zg8.png http://img358.imageshack.us/img358/6740/mumbletut11bkf8.png<br />
<br />
If AltSpeaking:<br />
<br />
http://img361.imageshack.us/img361/5271/mumbletut12ef3.png http://img462.imageshack.us/img462/8103/mumbletut12bko1.png<br />
<br />
=Final notes=<br />
This is a quick tutorial and I have not explained a lot of things. For example custom groups. They should be easy to figure out but here goes a quick explanation:<br />
*You define rights for that group by simply writing the group name in the group box (remember, ENTER is your friend;)) and marking the appropriate checkboxes. <br />
*To add a person to the group you go to the other tab in the ACL editor, select the group name in the group box (or write it+enter), write the name you want to add in the box at the botton of the added list and press the corresponding add button. You can only add registered nicks to that list.<br />
*Groups are per-channel and are inheritable. If you want to inherit some group members, you can mark inherit and add the members you don't want to be part of the group in the specific channel to the remove list (there is a button at the end of the inherited list to make this easy).<br />
I have also left behind the use of the sub group. You can find more info about that in [[ACL and Groups]]<br />
<br />
There are a lot of rules that could have been made easier. For example, in the last part of the tutorial, you could stick the ''deny Make Channel'' and the ''allow AltSpeak'' in the same rule applied to both channel and subchannels. This is just an example of which can be made without going too deep, feel free to create your own impossible-to-understand layouts and add them to the examples section in [[ACL and Groups]]<br />
<br />
And last but not least, please leave a comment in the discussion page of this article if you feel like that. Thanks :)</div>Javitoninohttps://wiki.mumble.info/index.php?title=ACL_Tutorial/English&diff=1533ACL Tutorial/English2007-08-02T17:19:02Z<p>Javitonino: /* Registered user */</p>
<hr />
<div>=ACL tutorial=<br />
This tutorial will help you understand how permissions work on Mumble. Details about this topic can be found in [[ACL and Groups]], where there are some examples, descriptions of special groups, etc.<br />
<br />
==What we are going to do==<br />
We are going to set a server, with a ''General chat'' channel where everyone can talk. We are also creating a ''Custom channels'' channel where anyone who is authed can create and administrate his own channel.<br />
Then, as a normal authed user, we will create a couple of channels for a FPS game where people can talk either to their team or to everyone just by pressing one key.<br />
<br />
Enough talking, let's get to work.<br />
<br />
==Setting permission for the whole server==<br />
First, we will need to set up a password for the SuperUser. If you haven't done that yet, you can do it by typing this at a console/command prompt:<br />
murmur -supw somepassword<br />
<br />
Then, we open Mumble and connect to the server using SuperUser and the password we have just set. You should be looking at something like this now:<br />
<br />
http://img361.imageshack.us/img361/6586/mumbletut1dx8.png<br />
<br />
Let's start with the permissions. Open the ACL editor, you can do thi will use the menu alternative. Once we are there, you can see a windows with two tabs. The first one is for defining people who is in a group, etc. The second one is used to assign permissions to groups. <br />
Right now, in that tab, you should have two rules set: <br />
*The first one allows people on the auth group to create channels in the root channel and its subchannels.<br />
*The second one allows people in the group admins to ''Write'', that means edit permissions.<br />
<br />
For now, we will delete the rule related with the auth group by selecting it and clicking remove. We said that we don't want anyone in the root channel, as we will make a ''General chat'' channel for that. So we will add a rule to keep them out. To do that, click add, and click every checkbox in the deny column except the ''Traverse'' one.<br />
<br />
The reason to leave traverse unchecked is because it will forbid people to enter this channel '''and''' subchannels. Since every other channel is a subchannel of root, this will effectively forbid people from entering any channel. So we leave it unchecked. It is not neccesary to mark the allow check, because ''Traverse'' is allowed by default. Default settings are:<br />
*Allow: Traverse, Enter, Speak and AltSpeak<br />
*Deny: Write, Mute/Deafen, Move/Kick, Make Channel and Link channel<br />
<br />
If you are wondering, yes, we could have left Write, Mute/Deafen, Move/Kick, Make Channel and Link channel unchecked and they will still be forbidden. There is no reason to leave those rights denied as they will be by default. Now your screen should be looking like this (except that you have disabled some useless checks):<br />
<br />
http://img361.imageshack.us/img361/9215/mumbletut2hw0.png<br />
<br />
In Mumble, rules are applied from top to bottom. Right now, the:<br />
@admins allow write<br />
rule is useless as it will get over written by the<br />
@all deny write ...<br />
So we will have to fix it. Simply select the rule referring to all and click up. That should put that on top. You have now established some default settings for the whole server :)<br />
<br />
http://img363.imageshack.us/img363/3368/mumbletut3if8.png<br />
<br />
==Creating the ''General chat'' channel and setting its permissions==<br />
This channel will serve as a chat room for everyone that gets to join our channel. Since we don't allow them to speak in the root channel, and they must join this channel if they want to chat, maybe we should put a welcome message to the server that warns about that. Anyways, here we go.<br />
First, create the channel. This is as easy as clicking Channel->Add (or right-clicking in the channel you want and click add to create a subchannel, but you know, root isn't shown, so we will use the menu one). In the box that appears type the channel name, click ''OK'' and we are done.<br />
<br />
Now, we want to give the right for everyone to speak here. So we head to ''Edit ACL'' (remember to select the new channel before). You will see the rules of the root channel, but if you select them, you will see that all the options are grayed out. That's because they are inherited from the parent channel (in this case, ''Root''). If you uncheck the ''Inherit ACL's'' option, they will disappear, but we don't want that. Just add a new rule that allow everyone (group=all) to Speak or AltSpeak and click ok to save it. We are now done with this channel. Easy, no?.<br />
<br />
http://img372.imageshack.us/img372/2854/mumbletut4wu0.png<br />
<br />
==Creating the ''Custom channels'' channel and configuring it==<br />
As we said, we will let anyone who is registered to create his own channel here. The first step is easy, create the channel just as we did before. You should have something like this just in front of your nose:<br />
<br />
http://img361.imageshack.us/img361/1720/mumbletut5qo2.png<br />
<br />
Now we'll be giving ''Make channel'' rights to authed people. Just go to ACL editor, add a new rule, in the group list select or write auth and select the allow make channel checkbox.<br />
'''Warning:''' If you type the group name, make sure you press enter when you've finished. This will update the rule group. You can see that if tou type and don't press enter, it will not change the group in the top listing.<br />
<br />
http://img356.imageshack.us/img356/7333/mumbletut6vl9.png http://img387.imageshack.us/img387/6638/mumbletut6bsq9.png<br />
<br />
And now we have a pretty channel when people can create his own channel. Note that they cannot even enter ''Custom channels'' channel but they still can create subchannels. Isn't it cool?<br />
<br />
=Registered user=<br />
In this part, we will be playing a registered and authed player with a veeeeery original name: AuthedPlayer. He will be creating his own channels to host a little public channel and two private subchannels, one for each team of a FPS game. He would like that they can talk to their team or to both teams. We are seeing how to do this with the AltSpeak right, linking channels and more.<br />
<br />
==Creating the main channel==<br />
After logging in, we may play a little to check that we can't enter the root channel once we leave it (the first time you connect you will land here), that we cannot enter the ''Custom channels'' channel, etc. Once we have checked that permissions are working as expected we start creating our first channel. We simply right click in ''Custom channels'' (remember that you can still use the menu) and click add to create a new channel. As I am very creative I called it ''My Private Channel''. Automatically we are added to the admins group in that channel, so we can ''Write'' on it (remember the rules in the root channel? they are inherited all the way down to our channel). But that also mean that we get the ''Make channel'' permission inherited, so everyone who is authed can make a channel inside ours. We don't like that so...<br />
<br />
http://img400.imageshack.us/img400/2249/mumbletut7dw7.png<br />
<br />
Our rule will overwrite the inherited one, because inherited rules are always put at top. So now that we have our channel secured, we will give permission to enter and speak:<br />
<br />
http://img387.imageshack.us/img387/2315/mumbletut8lu5.png<br />
<br />
Note that we have disabled ''Applies to sub-channels''. As subchannels will not be public, we don't want them to have the ''Enter'' permission granted. If we haven't disabled this option, we have to create yet another rule just to deny the ''Enter'' permission. This way is easier. And now, we have this channel ready for service. Let's continue with the subchannels.<br />
<br />
==Creating the team subchannels==<br />
First, we create two subchannels of our own channel. As usual I called them in a very creative way... Team1 and Team2. We could define rules for each one, but it is quicker to define them in the parent channel (My Private Channel) and make the subchannels inherit the rules. First, we want people in one team channel to be able to speak so we do it like that:<br />
<br />
http://img452.imageshack.us/img452/2127/mumbletut9ix7.png<br />
<br />
Notice that we have unchecked the ''Apply to this channel'' option, as we are defining this rule only for the subchannels. More interesting is the use of the speacial group ''in''. This group refers to the people that are inside the channel the rules refers to. It appears it is the same as all, but it is quite different: <br />
We are going to link both channels. That means that people in different channels will hear each other. But we want that people only can hear teammates. So we use ''in'' to give Speak privileges to people in the same channel. This means, people in Team2 can't hear people in Team1 because the people in Team1 don't have rights to speak in Team2 because the ''in'' group only gives them permission in his own channel. It is a little complicated to understand at first, but it is very useful. To understand it, you have first to understand that each channel has its separate groups. That means that ''in'' group in Team1 is no the same group that ''in'' group in Team2.<br />
<br />
To explain it better I'm going to use some names...<br />
*Jack is in Team1<br />
*John is in Team2<br />
Both channels are linked, so the voice will be transmitted from one to the other as long as the speaker have rights in the destination channel. Jack speaks but John will not be able to hear it. That is because Jack has no rights to speak in Team2 as it is not in the Team2's ''in'' group. So voice will not be transmitted across the channel link and John will not be able to hear Jack.<br />
If we have used ''all'' instead of ''in'' for the rule, Jack and John will hear each other without a problem, as everyone is in ''all'' group.<br />
<br />
Well, let's continue. We wanted to people talk to the other team. This is when AltSpeak comes handy. We add a rule like this:<br />
<br />
http://img359.imageshack.us/img359/7660/mumbletut10sq9.png<br />
<br />
This will allow everyone (both teams) to talk to each other when AltSpeaking. AltSpeak is enabled while pressing a key defined in Shortcuts (in the Mumble options). While holding down that key, voice will be transmitted using the AltSpeak rights. As we allowed anyone to AltSpeak and both channels are linked, that means that if someone talks while pressing the key, it will be heard by both teams.<br />
<br />
And we are done.<br />
<br />
=Final notes=<br />
This is a quick tutorial and I have not explained a lot of things. For example custom groups. They should be easy to figure out but here goes a quick explanation:<br />
*You define rights for that group by simply writing the group name in the group box (remember, ENTER is your friend;)) and marking the appropriate checkboxes. <br />
*To add a person to the group you go to the other tab in the ACL editor, select the group name in the group box (or write it+enter), write the name you want to add in the box at the botton of the added list and press the corresponding add button. You can only add registered nicks to that list.<br />
*Groups are per-channel and are inheritable. If you want to inherit some group members, you can mark inherit and add the members you don't want to be part of the group in the specific channel to the remove list (there is a button at the end of the inherited list to make this easy).<br />
I have also left behind the use of the sub group. You can find more info about that in [[ACL and Groups]]<br />
<br />
There are a lot of rules that could have been made easier. For example, in the last part of the tutorial, you could stick the ''deny Make Channel'' and the ''allow AltSpeak'' in the same rule applied to both channel and subchannels. This is just an example of which can be made without going too deep, feel free to create your own impossible-to-understand layouts and add them to the examples section in [[ACL and Groups]]<br />
<br />
And last but not least, please leave a comment in the discussion page of this article if you feel like that. Thanks :)</div>Javitoninohttps://wiki.mumble.info/index.php?title=ACL_Tutorial/English&diff=1532ACL Tutorial/English2007-08-02T16:50:57Z<p>Javitonino: /* Creating the main channel */ Wrong image fixed</p>
<hr />
<div>=ACL tutorial=<br />
This tutorial will help you understand how permissions work on Mumble. Details about this topic can be found in [[ACL and Groups]], where there are some examples, descriptions of special groups, etc.<br />
<br />
==What we are going to do==<br />
We are going to set a server, with a ''General chat'' channel where everyone can talk. We are also creating a ''Custom channels'' channel where anyone who is authed can create and administrate his own channel.<br />
Then, as a normal authed user, we will create a couple of channels for a FPS game where people can talk either to their team or to everyone just by pressing one key.<br />
<br />
Enough talking, let's get to work.<br />
<br />
==Setting permission for the whole server==<br />
First, we will need to set up a password for the SuperUser. If you haven't done that yet, you can do it by typing this at a console/command prompt:<br />
murmur -supw somepassword<br />
<br />
Then, we open Mumble and connect to the server using SuperUser and the password we have just set. You should be looking at something like this now:<br />
<br />
http://img361.imageshack.us/img361/6586/mumbletut1dx8.png<br />
<br />
Let's start with the permissions. Open the ACL editor, you can do thi will use the menu alternative. Once we are there, you can see a windows with two tabs. The first one is for defining people who is in a group, etc. The second one is used to assign permissions to groups. <br />
Right now, in that tab, you should have two rules set: <br />
*The first one allows people on the auth group to create channels in the root channel and its subchannels.<br />
*The second one allows people in the group admins to ''Write'', that means edit permissions.<br />
<br />
For now, we will delete the rule related with the auth group by selecting it and clicking remove. We said that we don't want anyone in the root channel, as we will make a ''General chat'' channel for that. So we will add a rule to keep them out. To do that, click add, and click every checkbox in the deny column except the ''Traverse'' one.<br />
<br />
The reason to leave traverse unchecked is because it will forbid people to enter this channel '''and''' subchannels. Since every other channel is a subchannel of root, this will effectively forbid people from entering any channel. So we leave it unchecked. It is not neccesary to mark the allow check, because ''Traverse'' is allowed by default. Default settings are:<br />
*Allow: Traverse, Enter, Speak and AltSpeak<br />
*Deny: Write, Mute/Deafen, Move/Kick, Make Channel and Link channel<br />
<br />
If you are wondering, yes, we could have left Write, Mute/Deafen, Move/Kick, Make Channel and Link channel unchecked and they will still be forbidden. There is no reason to leave those rights denied as they will be by default. Now your screen should be looking like this (except that you have disabled some useless checks):<br />
<br />
http://img361.imageshack.us/img361/9215/mumbletut2hw0.png<br />
<br />
In Mumble, rules are applied from top to bottom. Right now, the:<br />
@admins allow write<br />
rule is useless as it will get over written by the<br />
@all deny write ...<br />
So we will have to fix it. Simply select the rule referring to all and click up. That should put that on top. You have now established some default settings for the whole server :)<br />
<br />
http://img363.imageshack.us/img363/3368/mumbletut3if8.png<br />
<br />
==Creating the ''General chat'' channel and setting its permissions==<br />
This channel will serve as a chat room for everyone that gets to join our channel. Since we don't allow them to speak in the root channel, and they must join this channel if they want to chat, maybe we should put a welcome message to the server that warns about that. Anyways, here we go.<br />
First, create the channel. This is as easy as clicking Channel->Add (or right-clicking in the channel you want and click add to create a subchannel, but you know, root isn't shown, so we will use the menu one). In the box that appears type the channel name, click ''OK'' and we are done.<br />
<br />
Now, we want to give the right for everyone to speak here. So we head to ''Edit ACL'' (remember to select the new channel before). You will see the rules of the root channel, but if you select them, you will see that all the options are grayed out. That's because they are inherited from the parent channel (in this case, ''Root''). If you uncheck the ''Inherit ACL's'' option, they will disappear, but we don't want that. Just add a new rule that allow everyone (group=all) to Speak or AltSpeak and click ok to save it. We are now done with this channel. Easy, no?.<br />
<br />
http://img372.imageshack.us/img372/2854/mumbletut4wu0.png<br />
<br />
==Creating the ''Custom channels'' channel and configuring it==<br />
As we said, we will let anyone who is registered to create his own channel here. The first step is easy, create the channel just as we did before. You should have something like this just in front of your nose:<br />
<br />
http://img361.imageshack.us/img361/1720/mumbletut5qo2.png<br />
<br />
Now we'll be giving ''Make channel'' rights to authed people. Just go to ACL editor, add a new rule, in the group list select or write auth and select the allow make channel checkbox.<br />
'''Warning:''' If you type the group name, make sure you press enter when you've finished. This will update the rule group. You can see that if tou type and don't press enter, it will not change the group in the top listing.<br />
<br />
http://img356.imageshack.us/img356/7333/mumbletut6vl9.png http://img387.imageshack.us/img387/6638/mumbletut6bsq9.png<br />
<br />
And now we have a pretty channel when people can create his own channel. Note that they cannot even enter ''Custom channels'' channel but they still can create subchannels. Isn't it cool?<br />
<br />
=Registered user=<br />
In this part, we will be playing a registered and authed player with a veeeeery original name: AuthedPlayer. He will be creating his own channels to host a little public channel and two private subchannels, one for each team of a FPS game. He would like that they can talk to their team or to both teams. We are seeing how to do this with the AltSpeak right, linking channels and more.<br />
<br />
==Creating the main channel==<br />
After logging in, we may play a little to check that we can't enter the root channel once we leave it (the first time you connect you will land here), that we cannot enter the ''Custom channels'' channel, etc. Once we have checked that permissions are working as expected we start creating our first channel. We simply right click in ''Custom channels'' (remember that you can still use the menu) and click add to create a new channel. As I am very creative I called it ''My Private Channel''. Automatically we are added to the admins group in that channel, so we can ''Write'' on it (remember the rules in the root channel? they are inherited all the way down to our channel). But that also mean that we get the ''Make channel'' permission inherited, so everyone who is authed can make a channel inside ours. We don't like that so...<br />
<br />
http://img400.imageshack.us/img400/2249/mumbletut7dw7.png<br />
<br />
Our rule will overwrite the inherited one, because inherited rules are always put at top. So now that we have our channel secured, we will give permission to enter and speak:<br />
<br />
http://img387.imageshack.us/img387/2315/mumbletut8lu5.png<br />
<br />
Note that we have disabled ''Applies to sub-channels''. As subchannels will not be public, we don't want them to have the ''Enter'' permission granted. If we haven't disabled this option, we have to create yet another rule just to deny the ''Enter'' permission. This way is easier. And now, we have this channel ready for service. Let's continue with the subchannels.<br />
<br />
==Creating the team subchannels==<br />
<br />
To be continued right now... I'm just saving just in case</div>Javitoninohttps://wiki.mumble.info/index.php?title=ACL_Tutorial/English&diff=1531ACL Tutorial/English2007-08-02T16:49:52Z<p>Javitonino: /* Creating the main channel */</p>
<hr />
<div>=ACL tutorial=<br />
This tutorial will help you understand how permissions work on Mumble. Details about this topic can be found in [[ACL and Groups]], where there are some examples, descriptions of special groups, etc.<br />
<br />
==What we are going to do==<br />
We are going to set a server, with a ''General chat'' channel where everyone can talk. We are also creating a ''Custom channels'' channel where anyone who is authed can create and administrate his own channel.<br />
Then, as a normal authed user, we will create a couple of channels for a FPS game where people can talk either to their team or to everyone just by pressing one key.<br />
<br />
Enough talking, let's get to work.<br />
<br />
==Setting permission for the whole server==<br />
First, we will need to set up a password for the SuperUser. If you haven't done that yet, you can do it by typing this at a console/command prompt:<br />
murmur -supw somepassword<br />
<br />
Then, we open Mumble and connect to the server using SuperUser and the password we have just set. You should be looking at something like this now:<br />
<br />
http://img361.imageshack.us/img361/6586/mumbletut1dx8.png<br />
<br />
Let's start with the permissions. Open the ACL editor, you can do thi will use the menu alternative. Once we are there, you can see a windows with two tabs. The first one is for defining people who is in a group, etc. The second one is used to assign permissions to groups. <br />
Right now, in that tab, you should have two rules set: <br />
*The first one allows people on the auth group to create channels in the root channel and its subchannels.<br />
*The second one allows people in the group admins to ''Write'', that means edit permissions.<br />
<br />
For now, we will delete the rule related with the auth group by selecting it and clicking remove. We said that we don't want anyone in the root channel, as we will make a ''General chat'' channel for that. So we will add a rule to keep them out. To do that, click add, and click every checkbox in the deny column except the ''Traverse'' one.<br />
<br />
The reason to leave traverse unchecked is because it will forbid people to enter this channel '''and''' subchannels. Since every other channel is a subchannel of root, this will effectively forbid people from entering any channel. So we leave it unchecked. It is not neccesary to mark the allow check, because ''Traverse'' is allowed by default. Default settings are:<br />
*Allow: Traverse, Enter, Speak and AltSpeak<br />
*Deny: Write, Mute/Deafen, Move/Kick, Make Channel and Link channel<br />
<br />
If you are wondering, yes, we could have left Write, Mute/Deafen, Move/Kick, Make Channel and Link channel unchecked and they will still be forbidden. There is no reason to leave those rights denied as they will be by default. Now your screen should be looking like this (except that you have disabled some useless checks):<br />
<br />
http://img361.imageshack.us/img361/9215/mumbletut2hw0.png<br />
<br />
In Mumble, rules are applied from top to bottom. Right now, the:<br />
@admins allow write<br />
rule is useless as it will get over written by the<br />
@all deny write ...<br />
So we will have to fix it. Simply select the rule referring to all and click up. That should put that on top. You have now established some default settings for the whole server :)<br />
<br />
http://img363.imageshack.us/img363/3368/mumbletut3if8.png<br />
<br />
==Creating the ''General chat'' channel and setting its permissions==<br />
This channel will serve as a chat room for everyone that gets to join our channel. Since we don't allow them to speak in the root channel, and they must join this channel if they want to chat, maybe we should put a welcome message to the server that warns about that. Anyways, here we go.<br />
First, create the channel. This is as easy as clicking Channel->Add (or right-clicking in the channel you want and click add to create a subchannel, but you know, root isn't shown, so we will use the menu one). In the box that appears type the channel name, click ''OK'' and we are done.<br />
<br />
Now, we want to give the right for everyone to speak here. So we head to ''Edit ACL'' (remember to select the new channel before). You will see the rules of the root channel, but if you select them, you will see that all the options are grayed out. That's because they are inherited from the parent channel (in this case, ''Root''). If you uncheck the ''Inherit ACL's'' option, they will disappear, but we don't want that. Just add a new rule that allow everyone (group=all) to Speak or AltSpeak and click ok to save it. We are now done with this channel. Easy, no?.<br />
<br />
http://img372.imageshack.us/img372/2854/mumbletut4wu0.png<br />
<br />
==Creating the ''Custom channels'' channel and configuring it==<br />
As we said, we will let anyone who is registered to create his own channel here. The first step is easy, create the channel just as we did before. You should have something like this just in front of your nose:<br />
<br />
http://img361.imageshack.us/img361/1720/mumbletut5qo2.png<br />
<br />
Now we'll be giving ''Make channel'' rights to authed people. Just go to ACL editor, add a new rule, in the group list select or write auth and select the allow make channel checkbox.<br />
'''Warning:''' If you type the group name, make sure you press enter when you've finished. This will update the rule group. You can see that if tou type and don't press enter, it will not change the group in the top listing.<br />
<br />
http://img356.imageshack.us/img356/7333/mumbletut6vl9.png http://img387.imageshack.us/img387/6638/mumbletut6bsq9.png<br />
<br />
And now we have a pretty channel when people can create his own channel. Note that they cannot even enter ''Custom channels'' channel but they still can create subchannels. Isn't it cool?<br />
<br />
=Registered user=<br />
In this part, we will be playing a registered and authed player with a veeeeery original name: AuthedPlayer. He will be creating his own channels to host a little public channel and two private subchannels, one for each team of a FPS game. He would like that they can talk to their team or to both teams. We are seeing how to do this with the AltSpeak right, linking channels and more.<br />
<br />
==Creating the main channel==<br />
After logging in, we may play a little to check that we can't enter the root channel once we leave it (the first time you connect you will land here), that we cannot enter the ''Custom channels'' channel, etc. Once we have checked that permissions are working as expected we start creating our first channel. We simply right click in ''Custom channels'' (remember that you can still use the menu) and click add to create a new channel. As I am very creative I called it ''My Private Channel''. Automatically we are added to the admins group in that channel, so we can ''Write'' on it (remember the rules in the root channel? they are inherited all the way down to our channel). But that also mean that we get the ''Make channel'' permission inherited, so everyone who is authed can make a channel inside ours. We don't like that so...<br />
<br />
http://img399.imageshack.us/img399/9484/mumbletut6dn8.png<br />
<br />
Our rule will overwrite the inherited one, because inherited rules are always put at top. So now that we have our channel secured, we will give permission to enter and speak:<br />
<br />
http://img387.imageshack.us/img387/2315/mumbletut8lu5.png<br />
<br />
Note that we have disabled ''Applies to sub-channels''. As subchannels will not be public, we don't want them to have the ''Enter'' permission granted. If we haven't disabled this option, we have to create yet another rule just to deny the ''Enter'' permission. This way is easier. And now, we have this channel ready for service. Let's continue with the subchannels.<br />
<br />
==Creating the team subchannels==<br />
<br />
To be continued right now... I'm just saving just in case</div>Javitoninohttps://wiki.mumble.info/index.php?title=ACL_Tutorial/English&diff=1530ACL Tutorial/English2007-08-02T16:49:09Z<p>Javitonino: /* Registered user */</p>
<hr />
<div>=ACL tutorial=<br />
This tutorial will help you understand how permissions work on Mumble. Details about this topic can be found in [[ACL and Groups]], where there are some examples, descriptions of special groups, etc.<br />
<br />
==What we are going to do==<br />
We are going to set a server, with a ''General chat'' channel where everyone can talk. We are also creating a ''Custom channels'' channel where anyone who is authed can create and administrate his own channel.<br />
Then, as a normal authed user, we will create a couple of channels for a FPS game where people can talk either to their team or to everyone just by pressing one key.<br />
<br />
Enough talking, let's get to work.<br />
<br />
==Setting permission for the whole server==<br />
First, we will need to set up a password for the SuperUser. If you haven't done that yet, you can do it by typing this at a console/command prompt:<br />
murmur -supw somepassword<br />
<br />
Then, we open Mumble and connect to the server using SuperUser and the password we have just set. You should be looking at something like this now:<br />
<br />
http://img361.imageshack.us/img361/6586/mumbletut1dx8.png<br />
<br />
Let's start with the permissions. Open the ACL editor, you can do thi will use the menu alternative. Once we are there, you can see a windows with two tabs. The first one is for defining people who is in a group, etc. The second one is used to assign permissions to groups. <br />
Right now, in that tab, you should have two rules set: <br />
*The first one allows people on the auth group to create channels in the root channel and its subchannels.<br />
*The second one allows people in the group admins to ''Write'', that means edit permissions.<br />
<br />
For now, we will delete the rule related with the auth group by selecting it and clicking remove. We said that we don't want anyone in the root channel, as we will make a ''General chat'' channel for that. So we will add a rule to keep them out. To do that, click add, and click every checkbox in the deny column except the ''Traverse'' one.<br />
<br />
The reason to leave traverse unchecked is because it will forbid people to enter this channel '''and''' subchannels. Since every other channel is a subchannel of root, this will effectively forbid people from entering any channel. So we leave it unchecked. It is not neccesary to mark the allow check, because ''Traverse'' is allowed by default. Default settings are:<br />
*Allow: Traverse, Enter, Speak and AltSpeak<br />
*Deny: Write, Mute/Deafen, Move/Kick, Make Channel and Link channel<br />
<br />
If you are wondering, yes, we could have left Write, Mute/Deafen, Move/Kick, Make Channel and Link channel unchecked and they will still be forbidden. There is no reason to leave those rights denied as they will be by default. Now your screen should be looking like this (except that you have disabled some useless checks):<br />
<br />
http://img361.imageshack.us/img361/9215/mumbletut2hw0.png<br />
<br />
In Mumble, rules are applied from top to bottom. Right now, the:<br />
@admins allow write<br />
rule is useless as it will get over written by the<br />
@all deny write ...<br />
So we will have to fix it. Simply select the rule referring to all and click up. That should put that on top. You have now established some default settings for the whole server :)<br />
<br />
http://img363.imageshack.us/img363/3368/mumbletut3if8.png<br />
<br />
==Creating the ''General chat'' channel and setting its permissions==<br />
This channel will serve as a chat room for everyone that gets to join our channel. Since we don't allow them to speak in the root channel, and they must join this channel if they want to chat, maybe we should put a welcome message to the server that warns about that. Anyways, here we go.<br />
First, create the channel. This is as easy as clicking Channel->Add (or right-clicking in the channel you want and click add to create a subchannel, but you know, root isn't shown, so we will use the menu one). In the box that appears type the channel name, click ''OK'' and we are done.<br />
<br />
Now, we want to give the right for everyone to speak here. So we head to ''Edit ACL'' (remember to select the new channel before). You will see the rules of the root channel, but if you select them, you will see that all the options are grayed out. That's because they are inherited from the parent channel (in this case, ''Root''). If you uncheck the ''Inherit ACL's'' option, they will disappear, but we don't want that. Just add a new rule that allow everyone (group=all) to Speak or AltSpeak and click ok to save it. We are now done with this channel. Easy, no?.<br />
<br />
http://img372.imageshack.us/img372/2854/mumbletut4wu0.png<br />
<br />
==Creating the ''Custom channels'' channel and configuring it==<br />
As we said, we will let anyone who is registered to create his own channel here. The first step is easy, create the channel just as we did before. You should have something like this just in front of your nose:<br />
<br />
http://img361.imageshack.us/img361/1720/mumbletut5qo2.png<br />
<br />
Now we'll be giving ''Make channel'' rights to authed people. Just go to ACL editor, add a new rule, in the group list select or write auth and select the allow make channel checkbox.<br />
'''Warning:''' If you type the group name, make sure you press enter when you've finished. This will update the rule group. You can see that if tou type and don't press enter, it will not change the group in the top listing.<br />
<br />
http://img356.imageshack.us/img356/7333/mumbletut6vl9.png http://img387.imageshack.us/img387/6638/mumbletut6bsq9.png<br />
<br />
And now we have a pretty channel when people can create his own channel. Note that they cannot even enter ''Custom channels'' channel but they still can create subchannels. Isn't it cool?<br />
<br />
=Registered user=<br />
In this part, we will be playing a registered and authed player with a veeeeery original name: AuthedPlayer. He will be creating his own channels to host a little public channel and two private subchannels, one for each team of a FPS game. He would like that they can talk to their team or to both teams. We are seeing how to do this with the AltSpeak right, linking channels and more.<br />
<br />
==Creating the main channel==<br />
After logging in, we may play a little to check that we can't enter the root channel once we leave it (the first time you connect you will land here), that we cannot enter the ''Custom channels'' channel, etc. Once we have checked that permissions are working as expected we start creating our first channel. We simply right click in ''Custom channels'' (remember that you can still use the menu) and click add to create a new channel. As I am very creative I called it ''My Private Channel''. Automatically we are added to the admins group in that channel, so we can ''Write'' on it (remember the rules in the root channel? they are inherited all the way down to our channel). But that also mean that we get the ''Make channel'' permission inherited, so everyone who is authed can make a channel inside ours. We don't like that so...<br />
<br />
http://img387.imageshack.us/img387/6638/mumbletut6bsq9.png<br />
<br />
Our rule will overwrite the inherited one, because inherited rules are always put at top. So now that we have our channel secured, we will give permission to enter and speak:<br />
<br />
http://img387.imageshack.us/img387/2315/mumbletut8lu5.png<br />
<br />
Note that we have disabled ''Applies to sub-channels''. As subchannels will not be public, we don't want them to have the ''Enter'' permission granted. If we haven't disabled this option, we have to create yet another rule just to deny the ''Enter'' permission. This way is easier. And now, we have this channel ready for service. Let's continue with the subchannels.<br />
<br />
==Creating the team subchannels==<br />
<br />
To be continued right now... I'm just saving just in case</div>Javitoninohttps://wiki.mumble.info/index.php?title=ACL_Tutorial/English&diff=1528ACL Tutorial/English2007-08-02T16:34:47Z<p>Javitonino: </p>
<hr />
<div>=ACL tutorial=<br />
This tutorial will help you understand how permissions work on Mumble. Details about this topic can be found in [[ACL and Groups]], where there are some examples, descriptions of special groups, etc.<br />
<br />
==What we are going to do==<br />
We are going to set a server, with a ''General chat'' channel where everyone can talk. We are also creating a ''Custom channels'' channel where anyone who is authed can create and administrate his own channel.<br />
Then, as a normal authed user, we will create a couple of channels for a FPS game where people can talk either to their team or to everyone just by pressing one key.<br />
<br />
Enough talking, let's get to work.<br />
<br />
==Setting permission for the whole server==<br />
First, we will need to set up a password for the SuperUser. If you haven't done that yet, you can do it by typing this at a console/command prompt:<br />
murmur -supw somepassword<br />
<br />
Then, we open Mumble and connect to the server using SuperUser and the password we have just set. You should be looking at something like this now:<br />
<br />
http://img361.imageshack.us/img361/6586/mumbletut1dx8.png<br />
<br />
Let's start with the permissions. Open the ACL editor, you can do thi will use the menu alternative. Once we are there, you can see a windows with two tabs. The first one is for defining people who is in a group, etc. The second one is used to assign permissions to groups. <br />
Right now, in that tab, you should have two rules set: <br />
*The first one allows people on the auth group to create channels in the root channel and its subchannels.<br />
*The second one allows people in the group admins to ''Write'', that means edit permissions.<br />
<br />
For now, we will delete the rule related with the auth group by selecting it and clicking remove. We said that we don't want anyone in the root channel, as we will make a ''General chat'' channel for that. So we will add a rule to keep them out. To do that, click add, and click every checkbox in the deny column except the ''Traverse'' one.<br />
<br />
The reason to leave traverse unchecked is because it will forbid people to enter this channel '''and''' subchannels. Since every other channel is a subchannel of root, this will effectively forbid people from entering any channel. So we leave it unchecked. It is not neccesary to mark the allow check, because ''Traverse'' is allowed by default. Default settings are:<br />
*Allow: Traverse, Enter, Speak and AltSpeak<br />
*Deny: Write, Mute/Deafen, Move/Kick, Make Channel and Link channel<br />
<br />
If you are wondering, yes, we could have left Write, Mute/Deafen, Move/Kick, Make Channel and Link channel unchecked and they will still be forbidden. There is no reason to leave those rights denied as they will be by default. Now your screen should be looking like this (except that you have disabled some useless checks):<br />
<br />
http://img361.imageshack.us/img361/9215/mumbletut2hw0.png<br />
<br />
In Mumble, rules are applied from top to bottom. Right now, the:<br />
@admins allow write<br />
rule is useless as it will get over written by the<br />
@all deny write ...<br />
So we will have to fix it. Simply select the rule referring to all and click up. That should put that on top. You have now established some default settings for the whole server :)<br />
<br />
http://img363.imageshack.us/img363/3368/mumbletut3if8.png<br />
<br />
==Creating the ''General chat'' channel and setting its permissions==<br />
This channel will serve as a chat room for everyone that gets to join our channel. Since we don't allow them to speak in the root channel, and they must join this channel if they want to chat, maybe we should put a welcome message to the server that warns about that. Anyways, here we go.<br />
First, create the channel. This is as easy as clicking Channel->Add (or right-clicking in the channel you want and click add to create a subchannel, but you know, root isn't shown, so we will use the menu one). In the box that appears type the channel name, click ''OK'' and we are done.<br />
<br />
Now, we want to give the right for everyone to speak here. So we head to ''Edit ACL'' (remember to select the new channel before). You will see the rules of the root channel, but if you select them, you will see that all the options are grayed out. That's because they are inherited from the parent channel (in this case, ''Root''). If you uncheck the ''Inherit ACL's'' option, they will disappear, but we don't want that. Just add a new rule that allow everyone (group=all) to Speak or AltSpeak and click ok to save it. We are now done with this channel. Easy, no?.<br />
<br />
http://img372.imageshack.us/img372/2854/mumbletut4wu0.png<br />
<br />
==Creating the ''Custom channels'' channel and configuring it==<br />
As we said, we will let anyone who is registered to create his own channel here. The first step is easy, create the channel just as we did before. You should have something like this just in front of your nose:<br />
<br />
http://img361.imageshack.us/img361/1720/mumbletut5qo2.png<br />
<br />
Now we'll be giving ''Make channel'' rights to authed people. Just go to ACL editor, add a new rule, in the group list select or write auth and select the allow make channel checkbox.<br />
'''Warning:''' If you type the group name, make sure you press enter when you've finished. This will update the rule group. You can see that if tou type and don't press enter, it will not change the group in the top listing.<br />
<br />
http://img356.imageshack.us/img356/7333/mumbletut6vl9.png http://img387.imageshack.us/img387/6638/mumbletut6bsq9.png<br />
<br />
And now we have a pretty channel when people can create his own channel. Note that they cannot even enter ''Custom channels'' channel but they still can create subchannels. Isn't it cool?<br />
<br />
=Registered user=<br />
In this part, we will be playing a registered and authed player with a veeeeery original name: AuthedPlayer. He will be creating his own channels to host a little public channel and two private subchannels, one for each team of a FPS game. He would like that they can talk to their team or to both teams. We are seeing how to do this with the AltSpeak right, linking channels and more.<br />
<br />
To be continued right now... I'm just saving just in case</div>Javitoninohttps://wiki.mumble.info/index.php?title=ACL_Tutorial/English&diff=1527ACL Tutorial/English2007-08-02T16:20:04Z<p>Javitonino: /* ACL tutorial */</p>
<hr />
<div>=ACL tutorial=<br />
This tutorial will help you understand how permissions work on Mumble. Details about this topic can be found in [[ACL and Groups]], where there are some examples, descriptions of special groups, etc.<br />
<br />
==What we are going to do==<br />
We are going to set a server, with a ''General chat'' channel where everyone can talk. We are also creating a ''Custom channels'' channel where anyone who is authed can create and administrate his own channel.<br />
Then, as a normal authed user, we will create a couple of channels for a FPS game where people can talk either to their team or to everyone just by pressing one key.<br />
<br />
Enough talking, let's get to work.<br />
<br />
==Setting permission for the whole server==<br />
First, we will need to set up a password for the SuperUser. If you haven't done that yet, you can do it by typing this at a console/command prompt:<br />
murmur -supw somepassword<br />
<br />
Then, we open Mumble and connect to the server using SuperUser and the password we have just set. You should be looking at something like this now:<br />
<br />
http://img361.imageshack.us/img361/6586/mumbletut1dx8.png<br />
<br />
Let's start with the permissions. Open the ACL editor, you can do thi will use the menu alternative. Once we are there, you can see a windows with two tabs. The first one is for defining people who is in a group, etc. The second one is used to assign permissions to groups. <br />
Right now, in that tab, you should have two rules set: <br />
*The first one allows people on the auth group to create channels in the root channel and its subchannels.<br />
*The second one allows people in the group admins to ''Write'', that means edit permissions.<br />
<br />
For now, we will delete the rule related with the auth group by selecting it and clicking remove. We said that we don't want anyone in the root channel, as we will make a ''General chat'' channel for that. So we will add a rule to keep them out. To do that, click add, and click every checkbox in the deny column except the ''Traverse'' one.<br />
<br />
The reason to leave traverse unchecked is because it will forbid people to enter this channel '''and''' subchannels. Since every other channel is a subchannel of root, this will effectively forbid people from entering any channel. So we leave it unchecked. It is not neccesary to mark the allow check, because ''Traverse'' is allowed by default. Default settings are:<br />
*Allow: Traverse, Enter, Speak and AltSpeak<br />
*Deny: Write, Mute/Deafen, Move/Kick, Make Channel and Link channel<br />
<br />
If you are wondering, yes, we could have left Write, Mute/Deafen, Move/Kick, Make Channel and Link channel unchecked and they will still be forbidden. There is no reason to leave those rights denied as they will be by default. Now your screen should be looking like this (except that you have disabled some useless checks):<br />
<br />
http://img361.imageshack.us/img361/9215/mumbletut2hw0.png<br />
<br />
In Mumble, rules are applied from top to bottom. Right now, the:<br />
@admins allow write<br />
rule is useless as it will get over written by the<br />
@all deny write ...<br />
So we will have to fix it. Simply select the rule referring to all and click up. That should put that on top. You have now established some default settings for the whole server :)<br />
<br />
http://img363.imageshack.us/img363/3368/mumbletut3if8.png<br />
<br />
==Creating the ''General chat'' channel and setting its permissions==<br />
This channel will serve as a chat room for everyone that gets to join our channel. Since we don't allow them to speak in the root channel, and they must join this channel if they want to chat, maybe we should put a welcome message to the server that warns about that. Anyways, here we go.<br />
First, create the channel. This is as easy as clicking Channel->Add (or right-clicking in the channel you want and click add to create a subchannel, but you know, root isn't shown, so we will use the menu one). In the box that appears type the channel name, click ''OK'' and we are done.<br />
<br />
Now, we want to give the right for everyone to speak here. So we head to ''Edit ACL'' (remember to select the new channel before). You will see the rules of the root channel, but if you select them, you will see that all the options are grayed out. That's because they are inherited from the parent channel (in this case, ''Root''). If you uncheck the ''Inherit ACL's'' option, they will disappear, but we don't want that. Just add a new rule that allow everyone (group=all) to Speak or AltSpeak and click ok to save it. We are now done with this channel. Easy, no?.<br />
<br />
http://img372.imageshack.us/img372/2854/mumbletut4wu0.png<br />
<br />
==Creating the ''Custom channels'' channel and configuring it==<br />
<br />
<br />
To be continued right now... I'm just saving just in case</div>Javitoninohttps://wiki.mumble.info/index.php?title=ACL_Tutorial/English&diff=1526ACL Tutorial/English2007-08-02T16:03:57Z<p>Javitonino: Started writing an illustrated tutorial to ACL</p>
<hr />
<div>=ACL tutorial=<br />
This tutorial will help you understand how permissions work on Mumble. Details about this topic can be found in [[ACL and Groups]], where there are some examples, descriptions of special groups, etc.<br />
<br />
==What we are going to do==<br />
We are going to set a server, with a ''General chat'' channel where everyone can talk. We are also creating a ''Custom channels'' channel where anyone who is authed can create and administrate his own channel.<br />
Then, as a normal authed user, we will create a couple of channels for a FPS game where people can talk either to their team or to everyone just by pressing one key.<br />
<br />
Enough talking, let's get to work.<br />
<br />
==Setting permission for the whole server==<br />
First, we will need to set up a password for the SuperUser. If you haven't done that yet, you can do it by typing this at a console/command prompt:<br />
murmur -supw somepassword<br />
<br />
Then, we open Mumble and connect to the server using SuperUser and the password we have just set. You should be looking at something like this now:<br />
<br />
http://img361.imageshack.us/img361/6586/mumbletut1dx8.png<br />
<br />
Let's start with the permissions. Open the ACL editor, you can do thi will use the menu alternative. Once we are there, you can see a windows with two tabs. The first one is for defining people who is in a group, etc. The second one is used to assign permissions to groups. <br />
Right now, in that tab, you should have two rules set: <br />
*The first one allows people on the auth group to create channels in the root channel and its subchannels.<br />
*The second one allows people in the group admins to ''Write'', that means edit permissions.<br />
<br />
For now, we will delete the rule related with the auth group by selecting it and clicking remove. We said that we don't want anyone in the root channel, as we will make a ''General chat'' channel for that. So we will add a rule to keep them out. To do that, click add, and click every checkbox in the deny column except the ''Traverse'' one.<br />
<br />
The reason to leave traverse unchecked is because it will forbid people to enter this channel '''and''' subchannels. Since every other channel is a subchannel of root, this will effectively forbid people from entering any channel. So we leave it unchecked. It is not neccesary to mark the allow check, because ''Traverse'' is allowed by default. Default settings are:<br />
*Allow: Traverse, Enter, Speak and AltSpeak<br />
*Deny: Write, Mute/Deafen, Move/Kick, Make Channel and Link channel<br />
<br />
If you are wondering, yes, we could have left Write, Mute/Deafen, Move/Kick, Make Channel and Link channel unchecked and they will still be forbidden. There is no reason to leave those rights denied as they will be by default. Now your screen should be looking like this (except that you have disabled some useless checks):<br />
<br />
http://img361.imageshack.us/img361/9215/mumbletut2hw0.png<br />
<br />
In Mumble, rules are applied from top to bottom. Right now, the:<br />
@admins allow write<br />
rule is useless as it will get over written by the<br />
@all deny write ...<br />
So we will have to fix it. Simply select the rule referring to all and click up. That should put that on top. You have now established some default settings for the whole server :)<br />
<br />
http://img363.imageshack.us/img363/3368/mumbletut3if8.png<br />
<br />
==Creating the ''General chat'' channel and setting its permissions==<br />
<br />
To be continued right now... I'm just saving just in case</div>Javitoninohttps://wiki.mumble.info/index.php?title=Talk:Main_Page&diff=1523Talk:Main Page2007-08-02T08:19:13Z<p>Javitonino: </p>
<hr />
<div>== Bitrate ==<br />
<br />
How about give Mumble the option to set a max bitrate for audio stream ?<br />
<br />
if u got it right, the data volume can increase in some cases 5.8 Mbit/s and thats for only 10 users<br />
i dont know anyone, who got a 23 Mbit/s connection for a private internet access, to hear a 40 ppl server case.<br />
<br />
It's O.K. on LAN, but i don't see it in an Internet-Based voice chat.<br />
<br />
== Re: Bitrate ==<br />
<br />
First of all, this is not a comment about the wiki, it's a question, and as such belongs on the SF forums :) (Click SourceForge to the left).<br />
<br />
Second, this has been included in murmur for over a year now ;)<br />
<br />
== Please add some important links on the main page like "Building from Source", "Server HOWTO" ==<br />
<br />
I have searched for an installation guide (building from svn source), but I could not find anything on the official mumble webpages. I think a [[Building from Source]] guide would be a good idea, because the last binary release is a little bit old and there are already many external HOWTOs which try to describe this procedure but they are not up-to-date. A [[Server HOWTO]] would also be nice. Oh, I see there are already articles like [[Configuring Murmur]] and [[Running Murmur]], but no page links to them.<br />
Maybe you can design the main page more clearly like [http://www.mediawiki.org/wiki/MediaWiki] or [http://wiki.cookie-craft.de/en/index.php/Main_Page]. -- [[User:Xylo|Xylo]] 09:09, 20 June 2007 (PDT)<br />
<br />
== Re: Please add some important links on the main page... ==<br />
<br />
I couldn't agree more. And of course the should be displayed in a somewhat organized way. On a sidenote: The mainpage is not editable by "normal" users, i can see that this may be on purpose, because of Spam protection, but calls to use/contribute to the wiki, as heared in the forums, make not that much sense if the pages are not linked in.<br />
<br />
No specific clue for the layout but here are some examples:<br />
<br />
=== Installing ===<br />
* Building from Source: [[Building_from_Source]]<br />
* Dev Tools: [[Development_Tools]]<br />
<br />
=== Server Setup ===<br />
* Server Coniguration: [[Configuring_Murmur]]<br />
* Running the Server: [[Running_Murmur]]<br />
* Init Skript: [[Murmur_Init_Script]]<br />
* ACL & Groups: [[ACL and Groups]]<br />
<br />
=== Client Setup ===<br />
* Advanced Client Configuration: [[Advanced_client_configuration]]<br />
* Supported Games: [[Games]]<br />
<br />
=== Misc ===<br />
* Commercial_Hosting: [[Commercial_Hosting]]<br />
* Errors: [[Connection_Failed]]<br />
<br />
== Re: Please add some important links on the main page... ==<br />
I created [[Installing Mumble]] so most important information about installing is in one page. Maybe it's useful to add it to the main page, or replace the current links (building) with it (the page already includes links to the building pages). As it is now it may appear that you '''have''' to compile mumble and that there are no binaries available.<br />
And there is a little typo in Server configuration (f missing)</div>Javitoninohttps://wiki.mumble.info/index.php?title=Talk:Main_Page&diff=1522Talk:Main Page2007-08-02T08:13:47Z<p>Javitonino: </p>
<hr />
<div>== Bitrate ==<br />
<br />
How about give Mumble the option to set a max bitrate for audio stream ?<br />
<br />
if u got it right, the data volume can increase in some cases 5.8 Mbit/s and thats for only 10 users<br />
i dont know anyone, who got a 23 Mbit/s connection for a private internet access, to hear a 40 ppl server case.<br />
<br />
It's O.K. on LAN, but i don't see it in an Internet-Based voice chat.<br />
<br />
== Re: Bitrate ==<br />
<br />
First of all, this is not a comment about the wiki, it's a question, and as such belongs on the SF forums :) (Click SourceForge to the left).<br />
<br />
Second, this has been included in murmur for over a year now ;)<br />
<br />
== Please add some important links on the main page like "Building from Source", "Server HOWTO" ==<br />
<br />
I have searched for an installation guide (building from svn source), but I could not find anything on the official mumble webpages. I think a [[Building from Source]] guide would be a good idea, because the last binary release is a little bit old and there are already many external HOWTOs which try to describe this procedure but they are not up-to-date. A [[Server HOWTO]] would also be nice. Oh, I see there are already articles like [[Configuring Murmur]] and [[Running Murmur]], but no page links to them.<br />
Maybe you can design the main page more clearly like [http://www.mediawiki.org/wiki/MediaWiki] or [http://wiki.cookie-craft.de/en/index.php/Main_Page]. -- [[User:Xylo|Xylo]] 09:09, 20 June 2007 (PDT)<br />
<br />
== Re: Please add some important links on the main page... ==<br />
<br />
I couldn't agree more. And of course the should be displayed in a somewhat organized way. On a sidenote: The mainpage is not editable by "normal" users, i can see that this may be on purpose, because of Spam protection, but calls to use/contribute to the wiki, as heared in the forums, make not that much sense if the pages are not linked in.<br />
<br />
No specific clue for the layout but here are some examples:<br />
<br />
=== Installing ===<br />
* Building from Source: [[Building_from_Source]]<br />
* Dev Tools: [[Development_Tools]]<br />
<br />
=== Server Setup ===<br />
* Server Coniguration: [[Configuring_Murmur]]<br />
* Running the Server: [[Running_Murmur]]<br />
* Init Skript: [[Murmur_Init_Script]]<br />
* ACL & Groups: [[ACL and Groups]]<br />
<br />
=== Client Setup ===<br />
* Advanced Client Configuration: [[Advanced_client_configuration]]<br />
* Supported Games: [[Games]]<br />
<br />
=== Misc ===<br />
* Commercial_Hosting: [[Commercial_Hosting]]<br />
* Errors: [[Connection_Failed]]<br />
<br />
== Re: Please add some important links on the main page... ==<br />
I created [[Installing Mumble]] so most important information about installing is in one page. Maybe it's useful to add it to the main page, or replace the current links (building) with it (the page already includes links to the building pages).<br />
And there is a little typo in Server configuration (f missing)</div>Javitoninohttps://wiki.mumble.info/index.php?title=Installing_Mumble&diff=1521Installing Mumble2007-08-02T08:07:37Z<p>Javitonino: Trying to put all info on installing in the same page, so it's easier to read.</p>
<hr />
<div>=Getting and Installing Mumble=<br />
==Windows==<br />
Just head to [http://sourceforge.net/project/showfiles.php?group_id=147372 SourceForge downloads page], get the Windows executable and run it. Follow the installer instructions and you are done.<br />
<br />
Also, you can build Mumble yourself from source as described in [[BuildingWindows]].<br />
<br />
==Linux==<br />
If you want to compile your own version of Mumble, you can read some help in [[Building_from_Source]].<br />
<br />
===Debian, Ubuntu and other .deb based distros===<br />
You can download the .deb package avalaible at [http://sourceforge.net/project/showfiles.php?group_id=147372 SourceForge] and install it with your package manager. If you are not sure how to do this, just head to a console and type the following as root:<br />
<br />
dpkg --install mumble_1.0.0_i386.deb<br />
<br />
Of course, change the version number as appropriate. <br />
You can also try using the [http://3v1n0.tuxfamily.org/ Treviño repository]. Just add it to your repository list, update the package list and install Mumble.<br />
<br />
===Fedora, PCLinuxOS and other RPM based distros===<br />
You can find a rpm package in the [http://sourceforge.net/forum/forum.php?thread_id=1782689&forum_id=492606 forum]. Note that it is not officially supported, but it should work. You can install it with your rpm package manager or typing (as root):<br />
<br />
rpm -i mumble-1.0.0-2.i386.rpm<br />
<br />
===Gentoo===<br />
emerge mumble<br />
That should do it. You will need Qt4 compiled with the sqlite and sqlite3 flags. Note that the ebuild in the repository is a little outdated, you can find newer versions in the [http://sourceforge.net/forum/forum.php?thread_id=1779400&forum_id=492606 forums].<br />
<br />
===ArchLinux===<br />
A PKGBUILD is avalaible in the [http://aur.archlinux.org/packages.php?do_Details=1&ID=10221&K=mumble AUR]. Download the tarball and then run:<br />
tar xfv mumble.tar.gz<br />
cd mumble<br />
makepkg<br />
<br />
That should create a package for you. Of course, you need to install all the dependencies listed before. To do it in a single command:<br />
<br />
pacman -S alsa-lib qt4 libxevie sqlite3 boost<br />
<br />
Finally, install the package:<br />
<br />
pacman -A mumble-1.0.0-1.pkg.tar.gz<br />
<br />
Of course, replace the package name as appropriate.<br />
<br />
=Post-installation tips=<br />
==Common tips==<br />
===Initializing/Resetting Murmur password===<br />
Type:<br />
murmur -supw <password><br />
That will change the password for SuperUser, a special user that have all rights.<br />
If you want to reset the entire database, just delete murmur.sqlite and the recreate it with the command above.<br />
<br />
==Windows==<br />
===Text-to-Speech===<br />
The Text-To-Speech voices that ship by default with Windows are not all that good (and if you are not English, its even worse as it will try to speak english even when the text is not). If you have installed either MS Office or the Speech SDK, you will get more voices which can be configured from the Speech control panel. You can also buy a commercial Text-To-Speech engine; as long as it's SAPI5 compatible it can be used by Mumble. The main developers are currently using NeoSpeech Kate (buyable standalone from [http://www.nextup.com NextUp]).<br />
<br />
===It complains about mumble_ol.dll / Problems with Overlay===<br />
If you are running XP you will need to update it to SP2. You also need to update to the latest DirectX9 version that can be downloaded from the [http://www.microsoft.com/downloads/details.aspx?FamilyId=2DA43D38-DB71-4C1B-BC6A-9B6652CD92A3&displaylang=en Microsoft site]. The [http://www.microsoft.com/downloads/details.aspx?FamilyID=b406cf67-d926-463b-99e8-27199d6626b5&DisplayLang=en June 2007 version] should be enough.<br />
<br />
==Linux==<br />
===Getting the Shortcuts to work===<br />
You need to enable Xevie in your xorg.conf. To do this you will have to add the following line to xorg.conf, in the extensions section:<br />
<br />
Option "XEVIE" "Enable"<br />
<br />
That should like something like this:<br />
<br />
Section "Extensions"<br />
...<br />
Option "XEVIE" "Enable"<br />
...<br />
EndSection<br />
<br />
Then restart the X server (Ctrol+Alt+Backspace) and try again.<br />
<br />
===Running murmur as a SysV service===<br />
You can use [[Murmur_Init_Script]].</div>Javitoninohttps://wiki.mumble.info/index.php?title=FAQ/English&diff=1517FAQ/English2007-08-01T16:37:49Z<p>Javitonino: /* Installing Mumble */</p>
<hr />
<div>= About Mumble =<br />
<br />
== What is Mumble? ==<br />
<br />
Mumble is a voice chat application for groups. While it can be used for any kind of activity, it is primarily intended for gaming.<br />
<br />
== What platforms does it run on? ==<br />
<br />
The client, Mumble, runs on Windows XP and Linux. The server component, Murmur, should run on anything you can compile Qt 4.0 on.<br />
<br />
== What are the system requirements? ==<br />
<br />
The client runs on any Linux or Windows XP machine, and you also need a microphone. The server is mostly bandwidth bound, so as long as your network hardware is sufficient it should run on pretty much anything.<br />
<br />
Please note that the binaries distributed from SourceForge are compiled for SSE (Pentium 3 or Athlon-XP). Mumble is a VOIP solution for gaming, and as most modern games require at least that good a CPU it makes little sense for us not to optimize for it.<br />
<br />
== Installing Mumble ==<br />
Prebuilt binary packages can be downloaded from SourceForge[http://sourceforge.net/projects/mumble/] if you're running Windows or an i386 Linux distribution with the Debian package manager installed.<br />
Installation sources:<br />
*Windows: [http://sourceforge.net/project/showfiles.php?group_id=147372 SourceForge]<br />
*Linux:<br />
**Debian, Ubuntu, etc: [http://sourceforge.net/project/showfiles.php?group_id=147372 SourceForge] (.deb) or Treviño repository ([http://3v1n0.tuxfamily.org/])<br />
**RPM based distro's: You could try [http://sourceforge.net/forum/forum.php?thread_id=1782689&forum_id=492606 a rpm found in the forum]. <br />
**Gentoo: ''emerge mumble'' should do it (You'll need sqlite and/or sqlite3 flags enabled, and reemerge qt4 if it was emerged without them)<br />
**Archlinux: You can find a PKGBUILD in the AUR: [http://aur.archlinux.org/packages.php?do_Details=1&ID=10221]<br />
<br />
'''Disclaimer''': Only the files are SourceForge are official. Be careful with the other ones.<br />
<br />
For those who need to (or want to), here are two good tutorials for compiling Mumble/Murmur for your system:<br />
*Linux - [[Building_from_Source]]<br />
*Windows - [[BuildingWindows]]<br />
<br />
== What makes Mumble better? ==<br />
<br />
Mumble has very low latency combined with good sound quality; it uses Speex extensively, not just the voice compression technology, but also the voice preprocessing to remove noise and improve clarity. Mumble also has positional audio for supported games, meaning the other players' voice will come from the direction their character is in game.<br />
<br />
== What are the bandwidth requirements? ==<br />
<br />
From 0.9.1, this is highly variable, and mostly up to the user. With top quality, minimum latency and positional information sent, it is 64.6 kbit/s including the IP and UDP overhead. With 80 ms transmission delay, the lowest quality speech and no positional information, it is 11.0 kbit/s (again with IP and UDP overhead). The default uses 45.4 kbit/s; we did not hear any noticable improvement in quality from the last 20 kbit/s. When comparing with other products, remember to compare the total bandwidth use and not just the bitrate of the audio encoding.<br />
<br />
There are two parts to tuning the bandwidth; the audio bitrate per audio frame (20ms) and the amount of frames to put in each packet. Each transmitted packet has a overhead of 28 bytes from IP and UDP alone, so at the highest transmission rate (50 packets per second), that is 1400 bytes of data for raw network overhead alone. You should try to find a balance that works well for you, but we generally recommend sacrificing high audio bitrate for lower latency; Mumble sounds quite good even on the lowest quality setting.<br />
<br />
There is no way to adjust the amount of incoming bandwidth; you will have to have enough to sustain the total amount of speaking players. This should be a minor issue; most players these days are on asymetric lines and hence it is only upload that is a bottleneck.<br />
<br />
== What tools did you use to make this? ==<br />
<br />
See [[Development Tools]].<br />
<br />
== How can I help? ==<br />
<br />
A good start would be just using Mumble. If you like it, tell all your friends. If you do not like it, tell us what is wrong so we can fix it.<br />
<br />
= Audio Features = <br />
<br />
== How does the positional sound work? ==<br />
<br />
Your position ingame is transmitted along with every audio packet, and Mumble uses standard DirectSound 3D to position the audio on the receiver side. Only games for which a plug-in has been written get positional audio. All other games will work as well, you just will not get 3D sound.<br />
<br />
== Why does Mumble sound so much better than other voice products? ==<br />
<br />
One word: Denoising. This is a standard part of Speex 1.1 and above, and any voice product already implementing speex should be able to trivially include the same filtering. <br />
Removing the noise from the input means that the audio will be clearer and that the needed bitrate will decrease. It takes fewer bits to model clear voice than it does to accurately represent the noise, so in any noisy transmission a large share of the bits will be noise modelling.<br />
<br />
== Where is the volume control? ==<br />
<br />
Mumble uses the default volume you have configured in your operating system. There is no support for amplifying incoming voices, and there probably will not be, as this will decrease audio quality, something we are very reluctant to do.<br />
<br />
== The text-to-speech quality is horrible! ==<br />
<br />
We use the standard MS Speech API, and the included voices are not all that good. If you have installed either MS Office or the Speech SDK, you will get more voices which can be configured from the Speech control panel. You can also buy a commercial Text-To-Speech engine; as long as it's SAPI5 compatible it can be used by Mumble. The main developers are currently using NeoSpeech Kate (buyable standalone from [http://www.nextup.com NextUp]).<br />
<br />
== Why do some voices sound metallic? ==<br />
<br />
Mumble uses Speex noise filtering, and if the environment of the sender is especially noisy, some parts of the voice will be filtered as well. The alternative would be noisy sound, meaning precious bandwidth would be used to encode noise and the clarity of the voice would also decrease.<br />
<br />
== Why doesn't the voice activity detect my voice any more? ==<br />
<br />
If you change your audio environment suddenly and drastically, by for example disconnecting and reconnecting your microphone or dragging a piece of paper directly over the microphone, you will throw the voice preprocessor off balance. It will recover, but it will take time. <br />
<br />
To reset the preprocessor, choose 'Reset' from the 'Audio' menu.<br />
<br />
== What is this weird echo I hear of myself from other users? ==<br />
<br />
Unfortunately, a lot of popular headsets produce tiny traces of echo. In other VOIP products, you will not notice it because the echo is lower than the noise level, but as Mumble dutifully removes all noise, the echo suddenly becomes clear. There is little the person hearing the echo can do, but there are a few things the person producing the echo can do. The easy solution is to use ASIO and enable echo cancellation, however this requires that the headset is of the analog type (no USB) and a very high quality soundcard.<br />
<br />
The more troublesome solution is to modify the headset. If it is possible to pry the arm with the microphone from the headphones, do so and reattach it with a thick piece of rubber tape; this should insulate it from vibrations. If your headset is open (no large earmuffs), there exists an echo path through air from the headphones to the microphone. You can fix this by attaching anything foam-like to the front of the headphones to muffle the sound heard outside them, but this will most likely ruin the ergonomics of the headset as well as look somewhat odd.<br />
<br />
We might put up a page of "tested headsets" if anyone wants it.<br />
<br />
= Server =<br />
<br />
== What sort of bandwidth will I need for the server? ==<br />
<br />
Worst case scenario: Number of users &times; Number of talking users &times; 60 kbit/s. With less aggressive quality settings, it's ~20 kbit/s, and the bare minimum is 12kbit/s. Note that Mumble is geared towards social gaming; its quality enables people to talk naturally to each other instead of just barking short commands, so the amount of "users talking at the same time" can be somewhat higher than expected.<br />
<br />
This means that a server with 20 players and 2 players talking at once requires 0.8-2.4 Mbit/s, depending on quality settings. In the server's .ini file, you can specify the maximum allowed bitrate for users as well as the maximum number of clients to allow.<br />
<br />
== Where do I configure the welcome message, listen port and so on? ==<br />
<br />
murmur.ini, it is self-documenting.<br />
<br />
== How do the ACLs work? ==<br />
<br />
See [[ACL and Groups]]<br />
<br />
== mumble.pri:8: Unknown test function: CONFIG ==<br />
<br />
Mumble requires Qt version 4, preferably 4.0.1.<br />
<br />
You will need this flag "-qt-sql-sqlite" when you run the ./configure for Qt.<br />
<br />
== How can I reset the database? ==<br />
<br />
Delete the murmur.sqlite file.<br /><br />
Rerun the command:<br /><br /><br />
<br />
<code><br />
murmur -supw <password><br />
</code><br /><br />
<br />
== How can I change a users password? ==<br />
<br />
<code><br />
-bash-3.00$ '''sqlite3 murmur.sqlite'''<br /><br />
sqlite> '''UPDATE players SET pw = 'newpassword' WHERE name = 'playername';'''<br /><br />
sqlite> <Ctrl-D><br /><br />
</code><br />
<br />
== How do I backup the database? ==<br />
<br />
Shut down the server (kill the process), and make a copy of murmur.sqlite. That file is the database.<br />
<br />
<br />
== How do I run Murmur as a Linux/Unix Sys V service? ==<br />
<br />
See [[Murmur Init Script]]<br />
<br />
= Common Problems and Resolutions =<br />
<br />
Problem: Webserver not able to write to DB when using murmur.cgi. <br />
<br />
Solution: Make sure both DB and directory that DB is in is writing be the webserver user.<br />
<br />
Problem: Error message in murmur.cgi line 118<br />
<br />
Solution: You need an MTA on localhost unless you have defined a different SMTP server.<br />
<br />
Problem: Connecting, but not able to create/join channels<br />
<br />
Solution: You currently cannot use the 0.9.1 client with the CVS version of the server (0.9.2).<br />
<br />
Problem: Can't find Push to Talk button<br />
<br />
Solution: When you set Push to talk in Configure > Settings > Basic Audio, you then need to also bind a key to PTT. You do this in Configure > Settings > Shortcuts.<br />
<br />
== Failure to load mumble_ol.dll ==<br />
<br />
If you are running Win XP with SP2, this is due to a outdated DirectX. DirectX is actually updated each and every month, which is why you see every game trying to update your DirectX. So while the version may be 9.0c, what you want to look at is the release date. The latest version may be found at<br />
http://www.microsoft.com/windows/directx/default.mspx<br />
<br />
Downloaded, extracted and installed this package and it fixed this problem for me: [http://www.microsoft.com/downloads/details.aspx?FamilyID=b406cf67-d926-463b-99e8-27199d6626b5&DisplayLang=en DirectX End-User Runtimes (June 2007)] --[[User:Iam8up|Iam8up]] 08:01, 10 July 2007 (PDT)<br />
<br />
== Can't hear other users/users can't hear me ==<br />
<br />
This seems to be fixable by experimenting with the "Use TCP mode" checkbox in "Basic Audio" settings.<br />
<br />
== Shortcuts don't work on Linux ==<br />
<br />
You have to enable the Xevie extension for them to work. To do this you will have to add the following line to xorg.conf, in the extensions section:<br />
Option "XEVIE" "Enable"<br />
<br />
That should like something like this:<br />
<br />
Section "Extensions"<br />
...<br />
Option "XEVIE" "Enable"<br />
...<br />
EndSection<br />
<br />
Then restart the X server (Ctrol+Alt+Backspace) and try again.<br />
<br />
== Keys seem to lock when using Shortcuts on Linux ==<br />
<br />
Sometimes, keys get "locked" when using Xevie. For example, you press two keys at the same time, but when you release them, only of them is detected as released. This is better seen on games, when you start moving diagonally, and when you stop, it keeps moving.<br />
This can be fixed by playing around with the key repetition settings which can be found:<br />
* Gnome: System->Preferences->Keyboard<br />
* KDE: K menu->Control Center->Peripherals->Keyboard<br />
<br />
You can try changing the Speed/Rate slider and disabling the key repetition (first checkbox)</div>Javitoninohttps://wiki.mumble.info/index.php?title=FAQ/English&diff=1516FAQ/English2007-08-01T16:36:54Z<p>Javitonino: /* Installing Mumble */</p>
<hr />
<div>= About Mumble =<br />
<br />
== What is Mumble? ==<br />
<br />
Mumble is a voice chat application for groups. While it can be used for any kind of activity, it is primarily intended for gaming.<br />
<br />
== What platforms does it run on? ==<br />
<br />
The client, Mumble, runs on Windows XP and Linux. The server component, Murmur, should run on anything you can compile Qt 4.0 on.<br />
<br />
== What are the system requirements? ==<br />
<br />
The client runs on any Linux or Windows XP machine, and you also need a microphone. The server is mostly bandwidth bound, so as long as your network hardware is sufficient it should run on pretty much anything.<br />
<br />
Please note that the binaries distributed from SourceForge are compiled for SSE (Pentium 3 or Athlon-XP). Mumble is a VOIP solution for gaming, and as most modern games require at least that good a CPU it makes little sense for us not to optimize for it.<br />
<br />
== Installing Mumble ==<br />
Prebuilt binary packages can be downloaded from SourceForge[http://sourceforge.net/projects/mumble/] if you're running Windows or an i386 Linux distribution with the Debian package manager installed.<br />
Installation sources:<br />
*Windows: [http://sourceforge.net/project/showfiles.php?group_id=147372]<br />
*Linux:<br />
**Debian, Ubuntu, etc: [http://sourceforge.net/project/showfiles.php?group_id=147372] (.deb) or Treviño repository ([http://3v1n0.tuxfamily.org/])<br />
**RPM based distro's: You could try [http://sourceforge.net/forum/forum.php?thread_id=1782689&forum_id=492606 a rpm found in the forum]. <br />
**Gentoo: ''emerge mumble'' should do it (You'll need sqlite and/or sqlite3 flags enabled, and reemerge qt4 if it was emerged without them)<br />
**Archlinux: You can find a PKGBUILD in the AUR: [http://aur.archlinux.org/packages.php?do_Details=1&ID=10221]<br />
<br />
'''Disclaimer''': Only the files are SourceForge are official. Be careful with the other ones.<br />
<br />
For those who need to (or want to), here are two good tutorials for compiling Mumble/Murmur for your system:<br />
*Linux - [[Building_from_Source]]<br />
*Windows - [[BuildingWindows]]<br />
<br />
== What makes Mumble better? ==<br />
<br />
Mumble has very low latency combined with good sound quality; it uses Speex extensively, not just the voice compression technology, but also the voice preprocessing to remove noise and improve clarity. Mumble also has positional audio for supported games, meaning the other players' voice will come from the direction their character is in game.<br />
<br />
== What are the bandwidth requirements? ==<br />
<br />
From 0.9.1, this is highly variable, and mostly up to the user. With top quality, minimum latency and positional information sent, it is 64.6 kbit/s including the IP and UDP overhead. With 80 ms transmission delay, the lowest quality speech and no positional information, it is 11.0 kbit/s (again with IP and UDP overhead). The default uses 45.4 kbit/s; we did not hear any noticable improvement in quality from the last 20 kbit/s. When comparing with other products, remember to compare the total bandwidth use and not just the bitrate of the audio encoding.<br />
<br />
There are two parts to tuning the bandwidth; the audio bitrate per audio frame (20ms) and the amount of frames to put in each packet. Each transmitted packet has a overhead of 28 bytes from IP and UDP alone, so at the highest transmission rate (50 packets per second), that is 1400 bytes of data for raw network overhead alone. You should try to find a balance that works well for you, but we generally recommend sacrificing high audio bitrate for lower latency; Mumble sounds quite good even on the lowest quality setting.<br />
<br />
There is no way to adjust the amount of incoming bandwidth; you will have to have enough to sustain the total amount of speaking players. This should be a minor issue; most players these days are on asymetric lines and hence it is only upload that is a bottleneck.<br />
<br />
== What tools did you use to make this? ==<br />
<br />
See [[Development Tools]].<br />
<br />
== How can I help? ==<br />
<br />
A good start would be just using Mumble. If you like it, tell all your friends. If you do not like it, tell us what is wrong so we can fix it.<br />
<br />
= Audio Features = <br />
<br />
== How does the positional sound work? ==<br />
<br />
Your position ingame is transmitted along with every audio packet, and Mumble uses standard DirectSound 3D to position the audio on the receiver side. Only games for which a plug-in has been written get positional audio. All other games will work as well, you just will not get 3D sound.<br />
<br />
== Why does Mumble sound so much better than other voice products? ==<br />
<br />
One word: Denoising. This is a standard part of Speex 1.1 and above, and any voice product already implementing speex should be able to trivially include the same filtering. <br />
Removing the noise from the input means that the audio will be clearer and that the needed bitrate will decrease. It takes fewer bits to model clear voice than it does to accurately represent the noise, so in any noisy transmission a large share of the bits will be noise modelling.<br />
<br />
== Where is the volume control? ==<br />
<br />
Mumble uses the default volume you have configured in your operating system. There is no support for amplifying incoming voices, and there probably will not be, as this will decrease audio quality, something we are very reluctant to do.<br />
<br />
== The text-to-speech quality is horrible! ==<br />
<br />
We use the standard MS Speech API, and the included voices are not all that good. If you have installed either MS Office or the Speech SDK, you will get more voices which can be configured from the Speech control panel. You can also buy a commercial Text-To-Speech engine; as long as it's SAPI5 compatible it can be used by Mumble. The main developers are currently using NeoSpeech Kate (buyable standalone from [http://www.nextup.com NextUp]).<br />
<br />
== Why do some voices sound metallic? ==<br />
<br />
Mumble uses Speex noise filtering, and if the environment of the sender is especially noisy, some parts of the voice will be filtered as well. The alternative would be noisy sound, meaning precious bandwidth would be used to encode noise and the clarity of the voice would also decrease.<br />
<br />
== Why doesn't the voice activity detect my voice any more? ==<br />
<br />
If you change your audio environment suddenly and drastically, by for example disconnecting and reconnecting your microphone or dragging a piece of paper directly over the microphone, you will throw the voice preprocessor off balance. It will recover, but it will take time. <br />
<br />
To reset the preprocessor, choose 'Reset' from the 'Audio' menu.<br />
<br />
== What is this weird echo I hear of myself from other users? ==<br />
<br />
Unfortunately, a lot of popular headsets produce tiny traces of echo. In other VOIP products, you will not notice it because the echo is lower than the noise level, but as Mumble dutifully removes all noise, the echo suddenly becomes clear. There is little the person hearing the echo can do, but there are a few things the person producing the echo can do. The easy solution is to use ASIO and enable echo cancellation, however this requires that the headset is of the analog type (no USB) and a very high quality soundcard.<br />
<br />
The more troublesome solution is to modify the headset. If it is possible to pry the arm with the microphone from the headphones, do so and reattach it with a thick piece of rubber tape; this should insulate it from vibrations. If your headset is open (no large earmuffs), there exists an echo path through air from the headphones to the microphone. You can fix this by attaching anything foam-like to the front of the headphones to muffle the sound heard outside them, but this will most likely ruin the ergonomics of the headset as well as look somewhat odd.<br />
<br />
We might put up a page of "tested headsets" if anyone wants it.<br />
<br />
= Server =<br />
<br />
== What sort of bandwidth will I need for the server? ==<br />
<br />
Worst case scenario: Number of users &times; Number of talking users &times; 60 kbit/s. With less aggressive quality settings, it's ~20 kbit/s, and the bare minimum is 12kbit/s. Note that Mumble is geared towards social gaming; its quality enables people to talk naturally to each other instead of just barking short commands, so the amount of "users talking at the same time" can be somewhat higher than expected.<br />
<br />
This means that a server with 20 players and 2 players talking at once requires 0.8-2.4 Mbit/s, depending on quality settings. In the server's .ini file, you can specify the maximum allowed bitrate for users as well as the maximum number of clients to allow.<br />
<br />
== Where do I configure the welcome message, listen port and so on? ==<br />
<br />
murmur.ini, it is self-documenting.<br />
<br />
== How do the ACLs work? ==<br />
<br />
See [[ACL and Groups]]<br />
<br />
== mumble.pri:8: Unknown test function: CONFIG ==<br />
<br />
Mumble requires Qt version 4, preferably 4.0.1.<br />
<br />
You will need this flag "-qt-sql-sqlite" when you run the ./configure for Qt.<br />
<br />
== How can I reset the database? ==<br />
<br />
Delete the murmur.sqlite file.<br /><br />
Rerun the command:<br /><br /><br />
<br />
<code><br />
murmur -supw <password><br />
</code><br /><br />
<br />
== How can I change a users password? ==<br />
<br />
<code><br />
-bash-3.00$ '''sqlite3 murmur.sqlite'''<br /><br />
sqlite> '''UPDATE players SET pw = 'newpassword' WHERE name = 'playername';'''<br /><br />
sqlite> <Ctrl-D><br /><br />
</code><br />
<br />
== How do I backup the database? ==<br />
<br />
Shut down the server (kill the process), and make a copy of murmur.sqlite. That file is the database.<br />
<br />
<br />
== How do I run Murmur as a Linux/Unix Sys V service? ==<br />
<br />
See [[Murmur Init Script]]<br />
<br />
= Common Problems and Resolutions =<br />
<br />
Problem: Webserver not able to write to DB when using murmur.cgi. <br />
<br />
Solution: Make sure both DB and directory that DB is in is writing be the webserver user.<br />
<br />
Problem: Error message in murmur.cgi line 118<br />
<br />
Solution: You need an MTA on localhost unless you have defined a different SMTP server.<br />
<br />
Problem: Connecting, but not able to create/join channels<br />
<br />
Solution: You currently cannot use the 0.9.1 client with the CVS version of the server (0.9.2).<br />
<br />
Problem: Can't find Push to Talk button<br />
<br />
Solution: When you set Push to talk in Configure > Settings > Basic Audio, you then need to also bind a key to PTT. You do this in Configure > Settings > Shortcuts.<br />
<br />
== Failure to load mumble_ol.dll ==<br />
<br />
If you are running Win XP with SP2, this is due to a outdated DirectX. DirectX is actually updated each and every month, which is why you see every game trying to update your DirectX. So while the version may be 9.0c, what you want to look at is the release date. The latest version may be found at<br />
http://www.microsoft.com/windows/directx/default.mspx<br />
<br />
Downloaded, extracted and installed this package and it fixed this problem for me: [http://www.microsoft.com/downloads/details.aspx?FamilyID=b406cf67-d926-463b-99e8-27199d6626b5&DisplayLang=en DirectX End-User Runtimes (June 2007)] --[[User:Iam8up|Iam8up]] 08:01, 10 July 2007 (PDT)<br />
<br />
== Can't hear other users/users can't hear me ==<br />
<br />
This seems to be fixable by experimenting with the "Use TCP mode" checkbox in "Basic Audio" settings.<br />
<br />
== Shortcuts don't work on Linux ==<br />
<br />
You have to enable the Xevie extension for them to work. To do this you will have to add the following line to xorg.conf, in the extensions section:<br />
Option "XEVIE" "Enable"<br />
<br />
That should like something like this:<br />
<br />
Section "Extensions"<br />
...<br />
Option "XEVIE" "Enable"<br />
...<br />
EndSection<br />
<br />
Then restart the X server (Ctrol+Alt+Backspace) and try again.<br />
<br />
== Keys seem to lock when using Shortcuts on Linux ==<br />
<br />
Sometimes, keys get "locked" when using Xevie. For example, you press two keys at the same time, but when you release them, only of them is detected as released. This is better seen on games, when you start moving diagonally, and when you stop, it keeps moving.<br />
This can be fixed by playing around with the key repetition settings which can be found:<br />
* Gnome: System->Preferences->Keyboard<br />
* KDE: K menu->Control Center->Peripherals->Keyboard<br />
<br />
You can try changing the Speed/Rate slider and disabling the key repetition (first checkbox)</div>Javitoninohttps://wiki.mumble.info/index.php?title=FAQ/English&diff=1515FAQ/English2007-08-01T16:35:27Z<p>Javitonino: /* Installing Mumble */ Added info for RPM distros</p>
<hr />
<div>= About Mumble =<br />
<br />
== What is Mumble? ==<br />
<br />
Mumble is a voice chat application for groups. While it can be used for any kind of activity, it is primarily intended for gaming.<br />
<br />
== What platforms does it run on? ==<br />
<br />
The client, Mumble, runs on Windows XP and Linux. The server component, Murmur, should run on anything you can compile Qt 4.0 on.<br />
<br />
== What are the system requirements? ==<br />
<br />
The client runs on any Linux or Windows XP machine, and you also need a microphone. The server is mostly bandwidth bound, so as long as your network hardware is sufficient it should run on pretty much anything.<br />
<br />
Please note that the binaries distributed from SourceForge are compiled for SSE (Pentium 3 or Athlon-XP). Mumble is a VOIP solution for gaming, and as most modern games require at least that good a CPU it makes little sense for us not to optimize for it.<br />
<br />
== Installing Mumble ==<br />
Prebuilt binary packages can be downloaded from SourceForge[http://sourceforge.net/projects/mumble/] if you're running Windows or an i386 Linux distribution with the Debian package manager installed.<br />
Installation sources:<br />
*Windows: [http://sourceforge.net/project/showfiles.php?group_id=147372]<br />
*Linux:<br />
**Debian, Ubuntu, etc: [http://sourceforge.net/project/showfiles.php?group_id=147372] (.deb) or Treviño repository ([http://3v1n0.tuxfamily.org/])<br />
**RPM based distro's: You could try [http://sourceforge.net/forum/forum.php?thread_id=1782689&forum_id=492606 a rpm found in the forum]. '''Disclaimer''': It is not official in any way and it may screw your computer.<br />
**Gentoo: ''emerge mumble'' should do it (You'll need sqlite and/or sqlite3 flags enabled, and reemerge qt4 if it was emerged without them)<br />
**Archlinux: You can find a PKGBUILD in the AUR: [http://aur.archlinux.org/packages.php?do_Details=1&ID=10221]<br />
<br />
For those who need to (or want to), here are two good tutorials for compiling Mumble/Murmur for your system:<br />
*Linux - [[Building_from_Source]]<br />
*Windows - [[BuildingWindows]]<br />
<br />
== What makes Mumble better? ==<br />
<br />
Mumble has very low latency combined with good sound quality; it uses Speex extensively, not just the voice compression technology, but also the voice preprocessing to remove noise and improve clarity. Mumble also has positional audio for supported games, meaning the other players' voice will come from the direction their character is in game.<br />
<br />
== What are the bandwidth requirements? ==<br />
<br />
From 0.9.1, this is highly variable, and mostly up to the user. With top quality, minimum latency and positional information sent, it is 64.6 kbit/s including the IP and UDP overhead. With 80 ms transmission delay, the lowest quality speech and no positional information, it is 11.0 kbit/s (again with IP and UDP overhead). The default uses 45.4 kbit/s; we did not hear any noticable improvement in quality from the last 20 kbit/s. When comparing with other products, remember to compare the total bandwidth use and not just the bitrate of the audio encoding.<br />
<br />
There are two parts to tuning the bandwidth; the audio bitrate per audio frame (20ms) and the amount of frames to put in each packet. Each transmitted packet has a overhead of 28 bytes from IP and UDP alone, so at the highest transmission rate (50 packets per second), that is 1400 bytes of data for raw network overhead alone. You should try to find a balance that works well for you, but we generally recommend sacrificing high audio bitrate for lower latency; Mumble sounds quite good even on the lowest quality setting.<br />
<br />
There is no way to adjust the amount of incoming bandwidth; you will have to have enough to sustain the total amount of speaking players. This should be a minor issue; most players these days are on asymetric lines and hence it is only upload that is a bottleneck.<br />
<br />
== What tools did you use to make this? ==<br />
<br />
See [[Development Tools]].<br />
<br />
== How can I help? ==<br />
<br />
A good start would be just using Mumble. If you like it, tell all your friends. If you do not like it, tell us what is wrong so we can fix it.<br />
<br />
= Audio Features = <br />
<br />
== How does the positional sound work? ==<br />
<br />
Your position ingame is transmitted along with every audio packet, and Mumble uses standard DirectSound 3D to position the audio on the receiver side. Only games for which a plug-in has been written get positional audio. All other games will work as well, you just will not get 3D sound.<br />
<br />
== Why does Mumble sound so much better than other voice products? ==<br />
<br />
One word: Denoising. This is a standard part of Speex 1.1 and above, and any voice product already implementing speex should be able to trivially include the same filtering. <br />
Removing the noise from the input means that the audio will be clearer and that the needed bitrate will decrease. It takes fewer bits to model clear voice than it does to accurately represent the noise, so in any noisy transmission a large share of the bits will be noise modelling.<br />
<br />
== Where is the volume control? ==<br />
<br />
Mumble uses the default volume you have configured in your operating system. There is no support for amplifying incoming voices, and there probably will not be, as this will decrease audio quality, something we are very reluctant to do.<br />
<br />
== The text-to-speech quality is horrible! ==<br />
<br />
We use the standard MS Speech API, and the included voices are not all that good. If you have installed either MS Office or the Speech SDK, you will get more voices which can be configured from the Speech control panel. You can also buy a commercial Text-To-Speech engine; as long as it's SAPI5 compatible it can be used by Mumble. The main developers are currently using NeoSpeech Kate (buyable standalone from [http://www.nextup.com NextUp]).<br />
<br />
== Why do some voices sound metallic? ==<br />
<br />
Mumble uses Speex noise filtering, and if the environment of the sender is especially noisy, some parts of the voice will be filtered as well. The alternative would be noisy sound, meaning precious bandwidth would be used to encode noise and the clarity of the voice would also decrease.<br />
<br />
== Why doesn't the voice activity detect my voice any more? ==<br />
<br />
If you change your audio environment suddenly and drastically, by for example disconnecting and reconnecting your microphone or dragging a piece of paper directly over the microphone, you will throw the voice preprocessor off balance. It will recover, but it will take time. <br />
<br />
To reset the preprocessor, choose 'Reset' from the 'Audio' menu.<br />
<br />
== What is this weird echo I hear of myself from other users? ==<br />
<br />
Unfortunately, a lot of popular headsets produce tiny traces of echo. In other VOIP products, you will not notice it because the echo is lower than the noise level, but as Mumble dutifully removes all noise, the echo suddenly becomes clear. There is little the person hearing the echo can do, but there are a few things the person producing the echo can do. The easy solution is to use ASIO and enable echo cancellation, however this requires that the headset is of the analog type (no USB) and a very high quality soundcard.<br />
<br />
The more troublesome solution is to modify the headset. If it is possible to pry the arm with the microphone from the headphones, do so and reattach it with a thick piece of rubber tape; this should insulate it from vibrations. If your headset is open (no large earmuffs), there exists an echo path through air from the headphones to the microphone. You can fix this by attaching anything foam-like to the front of the headphones to muffle the sound heard outside them, but this will most likely ruin the ergonomics of the headset as well as look somewhat odd.<br />
<br />
We might put up a page of "tested headsets" if anyone wants it.<br />
<br />
= Server =<br />
<br />
== What sort of bandwidth will I need for the server? ==<br />
<br />
Worst case scenario: Number of users &times; Number of talking users &times; 60 kbit/s. With less aggressive quality settings, it's ~20 kbit/s, and the bare minimum is 12kbit/s. Note that Mumble is geared towards social gaming; its quality enables people to talk naturally to each other instead of just barking short commands, so the amount of "users talking at the same time" can be somewhat higher than expected.<br />
<br />
This means that a server with 20 players and 2 players talking at once requires 0.8-2.4 Mbit/s, depending on quality settings. In the server's .ini file, you can specify the maximum allowed bitrate for users as well as the maximum number of clients to allow.<br />
<br />
== Where do I configure the welcome message, listen port and so on? ==<br />
<br />
murmur.ini, it is self-documenting.<br />
<br />
== How do the ACLs work? ==<br />
<br />
See [[ACL and Groups]]<br />
<br />
== mumble.pri:8: Unknown test function: CONFIG ==<br />
<br />
Mumble requires Qt version 4, preferably 4.0.1.<br />
<br />
You will need this flag "-qt-sql-sqlite" when you run the ./configure for Qt.<br />
<br />
== How can I reset the database? ==<br />
<br />
Delete the murmur.sqlite file.<br /><br />
Rerun the command:<br /><br /><br />
<br />
<code><br />
murmur -supw <password><br />
</code><br /><br />
<br />
== How can I change a users password? ==<br />
<br />
<code><br />
-bash-3.00$ '''sqlite3 murmur.sqlite'''<br /><br />
sqlite> '''UPDATE players SET pw = 'newpassword' WHERE name = 'playername';'''<br /><br />
sqlite> <Ctrl-D><br /><br />
</code><br />
<br />
== How do I backup the database? ==<br />
<br />
Shut down the server (kill the process), and make a copy of murmur.sqlite. That file is the database.<br />
<br />
<br />
== How do I run Murmur as a Linux/Unix Sys V service? ==<br />
<br />
See [[Murmur Init Script]]<br />
<br />
= Common Problems and Resolutions =<br />
<br />
Problem: Webserver not able to write to DB when using murmur.cgi. <br />
<br />
Solution: Make sure both DB and directory that DB is in is writing be the webserver user.<br />
<br />
Problem: Error message in murmur.cgi line 118<br />
<br />
Solution: You need an MTA on localhost unless you have defined a different SMTP server.<br />
<br />
Problem: Connecting, but not able to create/join channels<br />
<br />
Solution: You currently cannot use the 0.9.1 client with the CVS version of the server (0.9.2).<br />
<br />
Problem: Can't find Push to Talk button<br />
<br />
Solution: When you set Push to talk in Configure > Settings > Basic Audio, you then need to also bind a key to PTT. You do this in Configure > Settings > Shortcuts.<br />
<br />
== Failure to load mumble_ol.dll ==<br />
<br />
If you are running Win XP with SP2, this is due to a outdated DirectX. DirectX is actually updated each and every month, which is why you see every game trying to update your DirectX. So while the version may be 9.0c, what you want to look at is the release date. The latest version may be found at<br />
http://www.microsoft.com/windows/directx/default.mspx<br />
<br />
Downloaded, extracted and installed this package and it fixed this problem for me: [http://www.microsoft.com/downloads/details.aspx?FamilyID=b406cf67-d926-463b-99e8-27199d6626b5&DisplayLang=en DirectX End-User Runtimes (June 2007)] --[[User:Iam8up|Iam8up]] 08:01, 10 July 2007 (PDT)<br />
<br />
== Can't hear other users/users can't hear me ==<br />
<br />
This seems to be fixable by experimenting with the "Use TCP mode" checkbox in "Basic Audio" settings.<br />
<br />
== Shortcuts don't work on Linux ==<br />
<br />
You have to enable the Xevie extension for them to work. To do this you will have to add the following line to xorg.conf, in the extensions section:<br />
Option "XEVIE" "Enable"<br />
<br />
That should like something like this:<br />
<br />
Section "Extensions"<br />
...<br />
Option "XEVIE" "Enable"<br />
...<br />
EndSection<br />
<br />
Then restart the X server (Ctrol+Alt+Backspace) and try again.<br />
<br />
== Keys seem to lock when using Shortcuts on Linux ==<br />
<br />
Sometimes, keys get "locked" when using Xevie. For example, you press two keys at the same time, but when you release them, only of them is detected as released. This is better seen on games, when you start moving diagonally, and when you stop, it keeps moving.<br />
This can be fixed by playing around with the key repetition settings which can be found:<br />
* Gnome: System->Preferences->Keyboard<br />
* KDE: K menu->Control Center->Peripherals->Keyboard<br />
<br />
You can try changing the Speed/Rate slider and disabling the key repetition (first checkbox)</div>Javitoninohttps://wiki.mumble.info/index.php?title=BuildingLinux&diff=1514BuildingLinux2007-08-01T16:15:02Z<p>Javitonino: /* Compile Mumble and Murmur (Mumble server) */</p>
<hr />
<div>This guide is based on this article [http://www.linux-gamers.net/modules/newbb/viewtopic.php?topic_id=2896&forum=6] found at www.linux-gamers.net.<br />
<br />
== Install the dependencies ==<br />
<br />
=== For Gentoo ===<br />
<br />
Note: Make sure you have sqlite and/ or sqlite3 in your USE flags in /etc/make.conf, if you haven't emerged qt4 with these before, you need to reemerge it.<br />
<br />
emerge dev-libs/boost media-libs/speex x11-libs/libXevie x11-libs/qt (See Note)<br />
<br />
=== For Debian / Ubuntu ===<br />
<br />
apt-get install qt4-dev-tools libqt4-dev libspeex1 libspeex-dev libboost-dev libasound2-dev libxevie-dev libxevie1<br />
<br />
It's recommended to remove the package qt3-dev-tools if installed.<br />
<br />
== Download the source ==<br />
<br />
Get the mumble source<br />
<br />
svn co https://mumble.svn.sourceforge.net/svnroot/mumble/trunk mumble<br />
cd mumble/<br />
<br />
== Compile Mumble and Murmur (Mumble server) ==<br />
<br />
qmake main.pro<br />
make<br />
<br />
For using push to talk, edit /etc/X11/xorg.conf:<br />
<br />
Section "Extensions"<br />
Option "XEVIE" "Enable"<br />
EndSection<br />
<br />
Restart the Xserver.<br />
<br />
For text-to-speech voices you will need to install festival and at least a voice. Most distros ship packages for that in their repositories.<br />
<br />
== Run Mumble ==<br />
<br />
cd release/<br />
./mumble<br />
<br />
== Run Murmur ==<br />
<br />
* see [[Running Murmur]]</div>Javitoninohttps://wiki.mumble.info/index.php?title=FAQ/English&diff=1513FAQ/English2007-08-01T16:03:59Z<p>Javitonino: /* Installing Mumble */</p>
<hr />
<div>= About Mumble =<br />
<br />
== What is Mumble? ==<br />
<br />
Mumble is a voice chat application for groups. While it can be used for any kind of activity, it is primarily intended for gaming.<br />
<br />
== What platforms does it run on? ==<br />
<br />
The client, Mumble, runs on Windows XP and Linux. The server component, Murmur, should run on anything you can compile Qt 4.0 on.<br />
<br />
== What are the system requirements? ==<br />
<br />
The client runs on any Linux or Windows XP machine, and you also need a microphone. The server is mostly bandwidth bound, so as long as your network hardware is sufficient it should run on pretty much anything.<br />
<br />
Please note that the binaries distributed from SourceForge are compiled for SSE (Pentium 3 or Athlon-XP). Mumble is a VOIP solution for gaming, and as most modern games require at least that good a CPU it makes little sense for us not to optimize for it.<br />
<br />
== Installing Mumble ==<br />
Prebuilt binary packages can be downloaded from SourceForge[http://sourceforge.net/projects/mumble/] if you're running Windows or an i386 Linux distribution with the Debian package manager installed.<br />
Installation sources:<br />
*Windows: [http://sourceforge.net/project/showfiles.php?group_id=147372]<br />
*Linux:<br />
**Debian, Ubuntu, etc: [http://sourceforge.net/project/showfiles.php?group_id=147372] (.deb) or Treviño repository ([http://3v1n0.tuxfamily.org/])<br />
**Gentoo: ''emerge mumble'' should do it (You'll need sqlite and/or sqlite3 flags enabled, and reemerge qt4 if it was emerged without them)<br />
**Archlinux: You can find a PKGBUILD in the AUR: [http://aur.archlinux.org/packages.php?do_Details=1&ID=10221]<br />
<br />
For those who need to (or want to), here are two good tutorials for compiling Mumble/Murmur for your system:<br />
*Linux - [[Building_from_Source]]<br />
*Windows - [[BuildingWindows]]<br />
<br />
== What makes Mumble better? ==<br />
<br />
Mumble has very low latency combined with good sound quality; it uses Speex extensively, not just the voice compression technology, but also the voice preprocessing to remove noise and improve clarity. Mumble also has positional audio for supported games, meaning the other players' voice will come from the direction their character is in game.<br />
<br />
== What are the bandwidth requirements? ==<br />
<br />
From 0.9.1, this is highly variable, and mostly up to the user. With top quality, minimum latency and positional information sent, it is 64.6 kbit/s including the IP and UDP overhead. With 80 ms transmission delay, the lowest quality speech and no positional information, it is 11.0 kbit/s (again with IP and UDP overhead). The default uses 45.4 kbit/s; we did not hear any noticable improvement in quality from the last 20 kbit/s. When comparing with other products, remember to compare the total bandwidth use and not just the bitrate of the audio encoding.<br />
<br />
There are two parts to tuning the bandwidth; the audio bitrate per audio frame (20ms) and the amount of frames to put in each packet. Each transmitted packet has a overhead of 28 bytes from IP and UDP alone, so at the highest transmission rate (50 packets per second), that is 1400 bytes of data for raw network overhead alone. You should try to find a balance that works well for you, but we generally recommend sacrificing high audio bitrate for lower latency; Mumble sounds quite good even on the lowest quality setting.<br />
<br />
There is no way to adjust the amount of incoming bandwidth; you will have to have enough to sustain the total amount of speaking players. This should be a minor issue; most players these days are on asymetric lines and hence it is only upload that is a bottleneck.<br />
<br />
== What tools did you use to make this? ==<br />
<br />
See [[Development Tools]].<br />
<br />
== How can I help? ==<br />
<br />
A good start would be just using Mumble. If you like it, tell all your friends. If you do not like it, tell us what is wrong so we can fix it.<br />
<br />
= Audio Features = <br />
<br />
== How does the positional sound work? ==<br />
<br />
Your position ingame is transmitted along with every audio packet, and Mumble uses standard DirectSound 3D to position the audio on the receiver side. Only games for which a plug-in has been written get positional audio. All other games will work as well, you just will not get 3D sound.<br />
<br />
== Why does Mumble sound so much better than other voice products? ==<br />
<br />
One word: Denoising. This is a standard part of Speex 1.1 and above, and any voice product already implementing speex should be able to trivially include the same filtering. <br />
Removing the noise from the input means that the audio will be clearer and that the needed bitrate will decrease. It takes fewer bits to model clear voice than it does to accurately represent the noise, so in any noisy transmission a large share of the bits will be noise modelling.<br />
<br />
== Where is the volume control? ==<br />
<br />
Mumble uses the default volume you have configured in your operating system. There is no support for amplifying incoming voices, and there probably will not be, as this will decrease audio quality, something we are very reluctant to do.<br />
<br />
== The text-to-speech quality is horrible! ==<br />
<br />
We use the standard MS Speech API, and the included voices are not all that good. If you have installed either MS Office or the Speech SDK, you will get more voices which can be configured from the Speech control panel. You can also buy a commercial Text-To-Speech engine; as long as it's SAPI5 compatible it can be used by Mumble. The main developers are currently using NeoSpeech Kate (buyable standalone from [http://www.nextup.com NextUp]).<br />
<br />
== Why do some voices sound metallic? ==<br />
<br />
Mumble uses Speex noise filtering, and if the environment of the sender is especially noisy, some parts of the voice will be filtered as well. The alternative would be noisy sound, meaning precious bandwidth would be used to encode noise and the clarity of the voice would also decrease.<br />
<br />
== Why doesn't the voice activity detect my voice any more? ==<br />
<br />
If you change your audio environment suddenly and drastically, by for example disconnecting and reconnecting your microphone or dragging a piece of paper directly over the microphone, you will throw the voice preprocessor off balance. It will recover, but it will take time. <br />
<br />
To reset the preprocessor, choose 'Reset' from the 'Audio' menu.<br />
<br />
== What is this weird echo I hear of myself from other users? ==<br />
<br />
Unfortunately, a lot of popular headsets produce tiny traces of echo. In other VOIP products, you will not notice it because the echo is lower than the noise level, but as Mumble dutifully removes all noise, the echo suddenly becomes clear. There is little the person hearing the echo can do, but there are a few things the person producing the echo can do. The easy solution is to use ASIO and enable echo cancellation, however this requires that the headset is of the analog type (no USB) and a very high quality soundcard.<br />
<br />
The more troublesome solution is to modify the headset. If it is possible to pry the arm with the microphone from the headphones, do so and reattach it with a thick piece of rubber tape; this should insulate it from vibrations. If your headset is open (no large earmuffs), there exists an echo path through air from the headphones to the microphone. You can fix this by attaching anything foam-like to the front of the headphones to muffle the sound heard outside them, but this will most likely ruin the ergonomics of the headset as well as look somewhat odd.<br />
<br />
We might put up a page of "tested headsets" if anyone wants it.<br />
<br />
= Server =<br />
<br />
== What sort of bandwidth will I need for the server? ==<br />
<br />
Worst case scenario: Number of users &times; Number of talking users &times; 60 kbit/s. With less aggressive quality settings, it's ~20 kbit/s, and the bare minimum is 12kbit/s. Note that Mumble is geared towards social gaming; its quality enables people to talk naturally to each other instead of just barking short commands, so the amount of "users talking at the same time" can be somewhat higher than expected.<br />
<br />
This means that a server with 20 players and 2 players talking at once requires 0.8-2.4 Mbit/s, depending on quality settings. In the server's .ini file, you can specify the maximum allowed bitrate for users as well as the maximum number of clients to allow.<br />
<br />
== Where do I configure the welcome message, listen port and so on? ==<br />
<br />
murmur.ini, it is self-documenting.<br />
<br />
== How do the ACLs work? ==<br />
<br />
See [[ACL and Groups]]<br />
<br />
== mumble.pri:8: Unknown test function: CONFIG ==<br />
<br />
Mumble requires Qt version 4, preferably 4.0.1.<br />
<br />
You will need this flag "-qt-sql-sqlite" when you run the ./configure for Qt.<br />
<br />
== How can I reset the database? ==<br />
<br />
Delete the murmur.sqlite file.<br /><br />
Rerun the command:<br /><br /><br />
<br />
<code><br />
murmur -supw <password><br />
</code><br /><br />
<br />
== How can I change a users password? ==<br />
<br />
<code><br />
-bash-3.00$ '''sqlite3 murmur.sqlite'''<br /><br />
sqlite> '''UPDATE players SET pw = 'newpassword' WHERE name = 'playername';'''<br /><br />
sqlite> <Ctrl-D><br /><br />
</code><br />
<br />
== How do I backup the database? ==<br />
<br />
Shut down the server (kill the process), and make a copy of murmur.sqlite. That file is the database.<br />
<br />
<br />
== How do I run Murmur as a Linux/Unix Sys V service? ==<br />
<br />
See [[Murmur Init Script]]<br />
<br />
= Common Problems and Resolutions =<br />
<br />
Problem: Webserver not able to write to DB when using murmur.cgi. <br />
<br />
Solution: Make sure both DB and directory that DB is in is writing be the webserver user.<br />
<br />
Problem: Error message in murmur.cgi line 118<br />
<br />
Solution: You need an MTA on localhost unless you have defined a different SMTP server.<br />
<br />
Problem: Connecting, but not able to create/join channels<br />
<br />
Solution: You currently cannot use the 0.9.1 client with the CVS version of the server (0.9.2).<br />
<br />
Problem: Can't find Push to Talk button<br />
<br />
Solution: When you set Push to talk in Configure > Settings > Basic Audio, you then need to also bind a key to PTT. You do this in Configure > Settings > Shortcuts.<br />
<br />
== Failure to load mumble_ol.dll ==<br />
<br />
If you are running Win XP with SP2, this is due to a outdated DirectX. DirectX is actually updated each and every month, which is why you see every game trying to update your DirectX. So while the version may be 9.0c, what you want to look at is the release date. The latest version may be found at<br />
http://www.microsoft.com/windows/directx/default.mspx<br />
<br />
Downloaded, extracted and installed this package and it fixed this problem for me: [http://www.microsoft.com/downloads/details.aspx?FamilyID=b406cf67-d926-463b-99e8-27199d6626b5&DisplayLang=en DirectX End-User Runtimes (June 2007)] --[[User:Iam8up|Iam8up]] 08:01, 10 July 2007 (PDT)<br />
<br />
== Can't hear other users/users can't hear me ==<br />
<br />
This seems to be fixable by experimenting with the "Use TCP mode" checkbox in "Basic Audio" settings.<br />
<br />
== Shortcuts don't work on Linux ==<br />
<br />
You have to enable the Xevie extension for them to work. To do this you will have to add the following line to xorg.conf, in the extensions section:<br />
Option "XEVIE" "Enable"<br />
<br />
That should like something like this:<br />
<br />
Section "Extensions"<br />
...<br />
Option "XEVIE" "Enable"<br />
...<br />
EndSection<br />
<br />
Then restart the X server (Ctrol+Alt+Backspace) and try again.<br />
<br />
== Keys seem to lock when using Shortcuts on Linux ==<br />
<br />
Sometimes, keys get "locked" when using Xevie. For example, you press two keys at the same time, but when you release them, only of them is detected as released. This is better seen on games, when you start moving diagonally, and when you stop, it keeps moving.<br />
This can be fixed by playing around with the key repetition settings which can be found:<br />
* Gnome: System->Preferences->Keyboard<br />
* KDE: K menu->Control Center->Peripherals->Keyboard<br />
<br />
You can try changing the Speed/Rate slider and disabling the key repetition (first checkbox)</div>Javitoninohttps://wiki.mumble.info/index.php?title=FAQ/English&diff=1512FAQ/English2007-08-01T15:59:37Z<p>Javitonino: /* Installing Mumble */</p>
<hr />
<div>= About Mumble =<br />
<br />
== What is Mumble? ==<br />
<br />
Mumble is a voice chat application for groups. While it can be used for any kind of activity, it is primarily intended for gaming.<br />
<br />
== What platforms does it run on? ==<br />
<br />
The client, Mumble, runs on Windows XP and Linux. The server component, Murmur, should run on anything you can compile Qt 4.0 on.<br />
<br />
== What are the system requirements? ==<br />
<br />
The client runs on any Linux or Windows XP machine, and you also need a microphone. The server is mostly bandwidth bound, so as long as your network hardware is sufficient it should run on pretty much anything.<br />
<br />
Please note that the binaries distributed from SourceForge are compiled for SSE (Pentium 3 or Athlon-XP). Mumble is a VOIP solution for gaming, and as most modern games require at least that good a CPU it makes little sense for us not to optimize for it.<br />
<br />
== Installing Mumble ==<br />
Prebuilt binary packages can be downloaded from SourceForge[http://sourceforge.net/projects/mumble/] if you're running Windows or an i386 Linux distribution with the Debian package manager installed.<br />
Installation sources:<br />
*Windows: [http://sourceforge.net/project/showfiles.php?group_id=147372]<br />
*Linux:<br />
**Debian, Ubuntu, etc: [http://sourceforge.net/project/showfiles.php?group_id=147372] (.deb) or Treviño repository ([http://3v1n0.tuxfamily.org/])<br />
**Gentoo: ''emerge mumble'' should do it<br />
**Archlinux: You can find a PKGBUILD in the AUR: [http://aur.archlinux.org/packages.php?do_Details=1&ID=10221]<br />
<br />
For those who need to (or want to), here are two good tutorials for compiling Mumble/Murmur for your system:<br />
*Linux - [[Building_from_Source]]<br />
*Windows - [[BuildingWindows]]<br />
<br />
== What makes Mumble better? ==<br />
<br />
Mumble has very low latency combined with good sound quality; it uses Speex extensively, not just the voice compression technology, but also the voice preprocessing to remove noise and improve clarity. Mumble also has positional audio for supported games, meaning the other players' voice will come from the direction their character is in game.<br />
<br />
== What are the bandwidth requirements? ==<br />
<br />
From 0.9.1, this is highly variable, and mostly up to the user. With top quality, minimum latency and positional information sent, it is 64.6 kbit/s including the IP and UDP overhead. With 80 ms transmission delay, the lowest quality speech and no positional information, it is 11.0 kbit/s (again with IP and UDP overhead). The default uses 45.4 kbit/s; we did not hear any noticable improvement in quality from the last 20 kbit/s. When comparing with other products, remember to compare the total bandwidth use and not just the bitrate of the audio encoding.<br />
<br />
There are two parts to tuning the bandwidth; the audio bitrate per audio frame (20ms) and the amount of frames to put in each packet. Each transmitted packet has a overhead of 28 bytes from IP and UDP alone, so at the highest transmission rate (50 packets per second), that is 1400 bytes of data for raw network overhead alone. You should try to find a balance that works well for you, but we generally recommend sacrificing high audio bitrate for lower latency; Mumble sounds quite good even on the lowest quality setting.<br />
<br />
There is no way to adjust the amount of incoming bandwidth; you will have to have enough to sustain the total amount of speaking players. This should be a minor issue; most players these days are on asymetric lines and hence it is only upload that is a bottleneck.<br />
<br />
== What tools did you use to make this? ==<br />
<br />
See [[Development Tools]].<br />
<br />
== How can I help? ==<br />
<br />
A good start would be just using Mumble. If you like it, tell all your friends. If you do not like it, tell us what is wrong so we can fix it.<br />
<br />
= Audio Features = <br />
<br />
== How does the positional sound work? ==<br />
<br />
Your position ingame is transmitted along with every audio packet, and Mumble uses standard DirectSound 3D to position the audio on the receiver side. Only games for which a plug-in has been written get positional audio. All other games will work as well, you just will not get 3D sound.<br />
<br />
== Why does Mumble sound so much better than other voice products? ==<br />
<br />
One word: Denoising. This is a standard part of Speex 1.1 and above, and any voice product already implementing speex should be able to trivially include the same filtering. <br />
Removing the noise from the input means that the audio will be clearer and that the needed bitrate will decrease. It takes fewer bits to model clear voice than it does to accurately represent the noise, so in any noisy transmission a large share of the bits will be noise modelling.<br />
<br />
== Where is the volume control? ==<br />
<br />
Mumble uses the default volume you have configured in your operating system. There is no support for amplifying incoming voices, and there probably will not be, as this will decrease audio quality, something we are very reluctant to do.<br />
<br />
== The text-to-speech quality is horrible! ==<br />
<br />
We use the standard MS Speech API, and the included voices are not all that good. If you have installed either MS Office or the Speech SDK, you will get more voices which can be configured from the Speech control panel. You can also buy a commercial Text-To-Speech engine; as long as it's SAPI5 compatible it can be used by Mumble. The main developers are currently using NeoSpeech Kate (buyable standalone from [http://www.nextup.com NextUp]).<br />
<br />
== Why do some voices sound metallic? ==<br />
<br />
Mumble uses Speex noise filtering, and if the environment of the sender is especially noisy, some parts of the voice will be filtered as well. The alternative would be noisy sound, meaning precious bandwidth would be used to encode noise and the clarity of the voice would also decrease.<br />
<br />
== Why doesn't the voice activity detect my voice any more? ==<br />
<br />
If you change your audio environment suddenly and drastically, by for example disconnecting and reconnecting your microphone or dragging a piece of paper directly over the microphone, you will throw the voice preprocessor off balance. It will recover, but it will take time. <br />
<br />
To reset the preprocessor, choose 'Reset' from the 'Audio' menu.<br />
<br />
== What is this weird echo I hear of myself from other users? ==<br />
<br />
Unfortunately, a lot of popular headsets produce tiny traces of echo. In other VOIP products, you will not notice it because the echo is lower than the noise level, but as Mumble dutifully removes all noise, the echo suddenly becomes clear. There is little the person hearing the echo can do, but there are a few things the person producing the echo can do. The easy solution is to use ASIO and enable echo cancellation, however this requires that the headset is of the analog type (no USB) and a very high quality soundcard.<br />
<br />
The more troublesome solution is to modify the headset. If it is possible to pry the arm with the microphone from the headphones, do so and reattach it with a thick piece of rubber tape; this should insulate it from vibrations. If your headset is open (no large earmuffs), there exists an echo path through air from the headphones to the microphone. You can fix this by attaching anything foam-like to the front of the headphones to muffle the sound heard outside them, but this will most likely ruin the ergonomics of the headset as well as look somewhat odd.<br />
<br />
We might put up a page of "tested headsets" if anyone wants it.<br />
<br />
= Server =<br />
<br />
== What sort of bandwidth will I need for the server? ==<br />
<br />
Worst case scenario: Number of users &times; Number of talking users &times; 60 kbit/s. With less aggressive quality settings, it's ~20 kbit/s, and the bare minimum is 12kbit/s. Note that Mumble is geared towards social gaming; its quality enables people to talk naturally to each other instead of just barking short commands, so the amount of "users talking at the same time" can be somewhat higher than expected.<br />
<br />
This means that a server with 20 players and 2 players talking at once requires 0.8-2.4 Mbit/s, depending on quality settings. In the server's .ini file, you can specify the maximum allowed bitrate for users as well as the maximum number of clients to allow.<br />
<br />
== Where do I configure the welcome message, listen port and so on? ==<br />
<br />
murmur.ini, it is self-documenting.<br />
<br />
== How do the ACLs work? ==<br />
<br />
See [[ACL and Groups]]<br />
<br />
== mumble.pri:8: Unknown test function: CONFIG ==<br />
<br />
Mumble requires Qt version 4, preferably 4.0.1.<br />
<br />
You will need this flag "-qt-sql-sqlite" when you run the ./configure for Qt.<br />
<br />
== How can I reset the database? ==<br />
<br />
Delete the murmur.sqlite file.<br /><br />
Rerun the command:<br /><br /><br />
<br />
<code><br />
murmur -supw <password><br />
</code><br /><br />
<br />
== How can I change a users password? ==<br />
<br />
<code><br />
-bash-3.00$ '''sqlite3 murmur.sqlite'''<br /><br />
sqlite> '''UPDATE players SET pw = 'newpassword' WHERE name = 'playername';'''<br /><br />
sqlite> <Ctrl-D><br /><br />
</code><br />
<br />
== How do I backup the database? ==<br />
<br />
Shut down the server (kill the process), and make a copy of murmur.sqlite. That file is the database.<br />
<br />
<br />
== How do I run Murmur as a Linux/Unix Sys V service? ==<br />
<br />
See [[Murmur Init Script]]<br />
<br />
= Common Problems and Resolutions =<br />
<br />
Problem: Webserver not able to write to DB when using murmur.cgi. <br />
<br />
Solution: Make sure both DB and directory that DB is in is writing be the webserver user.<br />
<br />
Problem: Error message in murmur.cgi line 118<br />
<br />
Solution: You need an MTA on localhost unless you have defined a different SMTP server.<br />
<br />
Problem: Connecting, but not able to create/join channels<br />
<br />
Solution: You currently cannot use the 0.9.1 client with the CVS version of the server (0.9.2).<br />
<br />
Problem: Can't find Push to Talk button<br />
<br />
Solution: When you set Push to talk in Configure > Settings > Basic Audio, you then need to also bind a key to PTT. You do this in Configure > Settings > Shortcuts.<br />
<br />
== Failure to load mumble_ol.dll ==<br />
<br />
If you are running Win XP with SP2, this is due to a outdated DirectX. DirectX is actually updated each and every month, which is why you see every game trying to update your DirectX. So while the version may be 9.0c, what you want to look at is the release date. The latest version may be found at<br />
http://www.microsoft.com/windows/directx/default.mspx<br />
<br />
Downloaded, extracted and installed this package and it fixed this problem for me: [http://www.microsoft.com/downloads/details.aspx?FamilyID=b406cf67-d926-463b-99e8-27199d6626b5&DisplayLang=en DirectX End-User Runtimes (June 2007)] --[[User:Iam8up|Iam8up]] 08:01, 10 July 2007 (PDT)<br />
<br />
== Can't hear other users/users can't hear me ==<br />
<br />
This seems to be fixable by experimenting with the "Use TCP mode" checkbox in "Basic Audio" settings.<br />
<br />
== Shortcuts don't work on Linux ==<br />
<br />
You have to enable the Xevie extension for them to work. To do this you will have to add the following line to xorg.conf, in the extensions section:<br />
Option "XEVIE" "Enable"<br />
<br />
That should like something like this:<br />
<br />
Section "Extensions"<br />
...<br />
Option "XEVIE" "Enable"<br />
...<br />
EndSection<br />
<br />
Then restart the X server (Ctrol+Alt+Backspace) and try again.<br />
<br />
== Keys seem to lock when using Shortcuts on Linux ==<br />
<br />
Sometimes, keys get "locked" when using Xevie. For example, you press two keys at the same time, but when you release them, only of them is detected as released. This is better seen on games, when you start moving diagonally, and when you stop, it keeps moving.<br />
This can be fixed by playing around with the key repetition settings which can be found:<br />
* Gnome: System->Preferences->Keyboard<br />
* KDE: K menu->Control Center->Peripherals->Keyboard<br />
<br />
You can try changing the Speed/Rate slider and disabling the key repetition (first checkbox)</div>Javitoninohttps://wiki.mumble.info/index.php?title=FAQ/English&diff=1510FAQ/English2007-07-31T19:06:36Z<p>Javitonino: /* Common Problems and Resolutions */</p>
<hr />
<div>= About Mumble =<br />
<br />
== What is Mumble? ==<br />
<br />
Mumble is a voice chat application for groups. While it can be used for any kind of activity, it is primarily intended for gaming.<br />
<br />
== What platforms does it run on? ==<br />
<br />
The client, Mumble, runs on Windows XP and Linux. The server component, Murmur, should run on anything you can compile Qt 4.0 on.<br />
<br />
== What are the system requirements? ==<br />
<br />
The client runs on any Linux or Windows XP machine, and you also need a microphone. The server is mostly bandwidth bound, so as long as your network hardware is sufficient it should run on pretty much anything.<br />
<br />
Please note that the binaries distributed from SourceForge are compiled for SSE (Pentium 3 or Athlon-XP). Mumble is a VOIP solution for gaming, and as most modern games require at least that good a CPU it makes little sense for us not to optimize for it.<br />
<br />
== Installing Mumble ==<br />
PreBuilt binary packages can be downloaded from SourceForge[http://sourceforge.net/projects/mumble/] if you're running Windows or an i386 Linux distribution with the Debian package manager installed.<br />
<br />
<br />
For those who need to (or want to), here are two good tutorials for compiling Mumble/Murmur for your system:<br />
<br />
Linux - [[Building_from_Source]]<br />
<br />
Windows - [[BuildingWindows]]<br />
<br />
<br />
== What makes Mumble better? ==<br />
<br />
Mumble has very low latency combined with good sound quality; it uses Speex extensively, not just the voice compression technology, but also the voice preprocessing to remove noise and improve clarity. Mumble also has positional audio for supported games, meaning the other players' voice will come from the direction their character is in game.<br />
<br />
== What are the bandwidth requirements? ==<br />
<br />
From 0.9.1, this is highly variable, and mostly up to the user. With top quality, minimum latency and positional information sent, it is 64.6 kbit/s including the IP and UDP overhead. With 80 ms transmission delay, the lowest quality speech and no positional information, it is 11.0 kbit/s (again with IP and UDP overhead). The default uses 45.4 kbit/s; we did not hear any noticable improvement in quality from the last 20 kbit/s. When comparing with other products, remember to compare the total bandwidth use and not just the bitrate of the audio encoding.<br />
<br />
There are two parts to tuning the bandwidth; the audio bitrate per audio frame (20ms) and the amount of frames to put in each packet. Each transmitted packet has a overhead of 28 bytes from IP and UDP alone, so at the highest transmission rate (50 packets per second), that is 1400 bytes of data for raw network overhead alone. You should try to find a balance that works well for you, but we generally recommend sacrificing high audio bitrate for lower latency; Mumble sounds quite good even on the lowest quality setting.<br />
<br />
There is no way to adjust the amount of incoming bandwidth; you will have to have enough to sustain the total amount of speaking players. This should be a minor issue; most players these days are on asymetric lines and hence it is only upload that is a bottleneck.<br />
<br />
== What tools did you use to make this? ==<br />
<br />
See [[Development Tools]].<br />
<br />
== How can I help? ==<br />
<br />
A good start would be just using Mumble. If you like it, tell all your friends. If you do not like it, tell us what is wrong so we can fix it.<br />
<br />
= Audio Features = <br />
<br />
== How does the positional sound work? ==<br />
<br />
Your position ingame is transmitted along with every audio packet, and Mumble uses standard DirectSound 3D to position the audio on the receiver side. Only games for which a plug-in has been written get positional audio. All other games will work as well, you just will not get 3D sound.<br />
<br />
== Why does Mumble sound so much better than other voice products? ==<br />
<br />
One word: Denoising. This is a standard part of Speex 1.1 and above, and any voice product already implementing speex should be able to trivially include the same filtering. <br />
Removing the noise from the input means that the audio will be clearer and that the needed bitrate will decrease. It takes fewer bits to model clear voice than it does to accurately represent the noise, so in any noisy transmission a large share of the bits will be noise modelling.<br />
<br />
== Where is the volume control? ==<br />
<br />
Mumble uses the default volume you have configured in your operating system. There is no support for amplifying incoming voices, and there probably will not be, as this will decrease audio quality, something we are very reluctant to do.<br />
<br />
== The text-to-speech quality is horrible! ==<br />
<br />
We use the standard MS Speech API, and the included voices are not all that good. If you have installed either MS Office or the Speech SDK, you will get more voices which can be configured from the Speech control panel. You can also buy a commercial Text-To-Speech engine; as long as it's SAPI5 compatible it can be used by Mumble. The main developers are currently using NeoSpeech Kate (buyable standalone from [http://www.nextup.com NextUp]).<br />
<br />
== Why do some voices sound metallic? ==<br />
<br />
Mumble uses Speex noise filtering, and if the environment of the sender is especially noisy, some parts of the voice will be filtered as well. The alternative would be noisy sound, meaning precious bandwidth would be used to encode noise and the clarity of the voice would also decrease.<br />
<br />
== Why doesn't the voice activity detect my voice any more? ==<br />
<br />
If you change your audio environment suddenly and drastically, by for example disconnecting and reconnecting your microphone or dragging a piece of paper directly over the microphone, you will throw the voice preprocessor off balance. It will recover, but it will take time. <br />
<br />
To reset the preprocessor, choose 'Reset' from the 'Audio' menu.<br />
<br />
== What is this weird echo I hear of myself from other users? ==<br />
<br />
Unfortunately, a lot of popular headsets produce tiny traces of echo. In other VOIP products, you will not notice it because the echo is lower than the noise level, but as Mumble dutifully removes all noise, the echo suddenly becomes clear. There is little the person hearing the echo can do, but there are a few things the person producing the echo can do. The easy solution is to use ASIO and enable echo cancellation, however this requires that the headset is of the analog type (no USB) and a very high quality soundcard.<br />
<br />
The more troublesome solution is to modify the headset. If it is possible to pry the arm with the microphone from the headphones, do so and reattach it with a thick piece of rubber tape; this should insulate it from vibrations. If your headset is open (no large earmuffs), there exists an echo path through air from the headphones to the microphone. You can fix this by attaching anything foam-like to the front of the headphones to muffle the sound heard outside them, but this will most likely ruin the ergonomics of the headset as well as look somewhat odd.<br />
<br />
We might put up a page of "tested headsets" if anyone wants it.<br />
<br />
= Server =<br />
<br />
== What sort of bandwidth will I need for the server? ==<br />
<br />
Worst case scenario: Number of users &times; Number of talking users &times; 60 kbit/s. With less aggressive quality settings, it's ~20 kbit/s, and the bare minimum is 12kbit/s. Note that Mumble is geared towards social gaming; its quality enables people to talk naturally to each other instead of just barking short commands, so the amount of "users talking at the same time" can be somewhat higher than expected.<br />
<br />
This means that a server with 20 players and 2 players talking at once requires 0.8-2.4 Mbit/s, depending on quality settings. In the server's .ini file, you can specify the maximum allowed bitrate for users as well as the maximum number of clients to allow.<br />
<br />
== Where do I configure the welcome message, listen port and so on? ==<br />
<br />
murmur.ini, it is self-documenting.<br />
<br />
== How do the ACLs work? ==<br />
<br />
See [[ACL and Groups]]<br />
<br />
== mumble.pri:8: Unknown test function: CONFIG ==<br />
<br />
Mumble requires Qt version 4, preferably 4.0.1.<br />
<br />
You will need this flag "-qt-sql-sqlite" when you run the ./configure for Qt.<br />
<br />
== How can I reset the database? ==<br />
<br />
Delete the murmur.sqlite file.<br /><br />
Rerun the command:<br /><br /><br />
<br />
<code><br />
murmur -supw <password><br />
</code><br /><br />
<br />
== How can I change a users password? ==<br />
<br />
<code><br />
-bash-3.00$ '''sqlite3 murmur.sqlite'''<br /><br />
sqlite> '''UPDATE players SET pw = 'newpassword' WHERE name = 'playername';'''<br /><br />
sqlite> <Ctrl-D><br /><br />
</code><br />
<br />
== How do I backup the database? ==<br />
<br />
Shut down the server (kill the process), and make a copy of murmur.sqlite. That file is the database.<br />
<br />
<br />
== How do I run Murmur as a Linux/Unix Sys V service? ==<br />
<br />
See [[Murmur Init Script]]<br />
<br />
= Common Problems and Resolutions =<br />
<br />
Problem: Webserver not able to write to DB when using murmur.cgi. <br />
<br />
Solution: Make sure both DB and directory that DB is in is writing be the webserver user.<br />
<br />
Problem: Error message in murmur.cgi line 118<br />
<br />
Solution: You need an MTA on localhost unless you have defined a different SMTP server.<br />
<br />
Problem: Connecting, but not able to create/join channels<br />
<br />
Solution: You currently cannot use the 0.9.1 client with the CVS version of the server (0.9.2).<br />
<br />
Problem: Can't find Push to Talk button<br />
<br />
Solution: When you set Push to talk in Configure > Settings > Basic Audio, you then need to also bind a key to PTT. You do this in Configure > Settings > Shortcuts.<br />
<br />
== Failure to load mumble_ol.dll ==<br />
<br />
If you are running Win XP with SP2, this is due to a outdated DirectX. DirectX is actually updated each and every month, which is why you see every game trying to update your DirectX. So while the version may be 9.0c, what you want to look at is the release date. The latest version may be found at<br />
http://www.microsoft.com/windows/directx/default.mspx<br />
<br />
Downloaded, extracted and installed this package and it fixed this problem for me: [http://www.microsoft.com/downloads/details.aspx?FamilyID=b406cf67-d926-463b-99e8-27199d6626b5&DisplayLang=en DirectX End-User Runtimes (June 2007)] --[[User:Iam8up|Iam8up]] 08:01, 10 July 2007 (PDT)<br />
<br />
== Can't hear other users/users can't hear me ==<br />
<br />
This seems to be fixable by experimenting with the "Use TCP mode" checkbox in "Basic Audio" settings.<br />
<br />
== Shortcuts don't work on Linux ==<br />
<br />
You have to enable the Xevie extension for them to work. To do this you will have to add the following line to xorg.conf, in the extensions section:<br />
Option "XEVIE" "Enable"<br />
<br />
That should like something like this:<br />
<br />
Section "Extensions"<br />
...<br />
Option "XEVIE" "Enable"<br />
...<br />
EndSection<br />
<br />
Then restart the X server (Ctrol+Alt+Backspace) and try again.<br />
<br />
== Keys seem to lock when using Shortcuts on Linux ==<br />
<br />
Sometimes, keys get "locked" when using Xevie. For example, you press two keys at the same time, but when you release them, only of them is detected as released. This is better seen on games, when you start moving diagonally, and when you stop, it keeps moving.<br />
This can be fixed by playing around with the key repetition settings which can be found:<br />
* Gnome: System->Preferences->Keyboard<br />
* KDE: K menu->Control Center->Peripherals->Keyboard<br />
<br />
You can try changing the Speed/Rate slider and disabling the key repetition (first checkbox)</div>Javitoninohttps://wiki.mumble.info/index.php?title=ACL_and_Groups/English&diff=1509ACL and Groups/English2007-07-31T18:43:48Z<p>Javitonino: /* The @sub group */</p>
<hr />
<div>= Groups =<br />
<br />
Groups are tied to a specific channel, but can also be inherited by subchannels. Groups are convenient ways to administer channels; set up the ACLs on the top of the tree that should have similar privilege structure, and just change the group memberships on subchannels.<br />
<br />
For each channel, a group has 3 pieces of data. The list of players to add to the group, the list of players inherited from the same group on the parent channel, and the list of players to remove from the group.<br />
<br />
A group will only inherit players from the parent if ''Inherit'' is set true and the group was marked ''Inheritable'' on the parent. Most of the time you want both of these to be set.<br />
<br />
== Example ==<br />
<br />
Let's take a practical example; the ''admin'' group. Every time a player makes a channel, he is automatically added to the admin group. This doesn't automatically give him any privileges, it just marks him as a member of that group, however Murmur's default installation installs an ACL that gives the ''admin'' group write bit (all access).<br />
<br />
<br />
In a structure like this:<br />
* Root<br />
** A<br />
*** B<br />
** C<br />
*** D<br />
<br />
In Root, player "Big Boss" is alone in the admin group. In channel A, player "BossA" is in the Add list, and "BossB" is the same in channel B.<br />
<br />
Since the ''admin'' group is inherited and inheritable, a player that is a member at any parent of the current channel is also a member in the current channel. So the total list of members in channel B is "Big Boss, BossA, BossB". The convenience of this system is that if we later att "Super Boss" to admin in Root, he'll automatically be in the admin group of every channel below.<br />
<br />
Let's move on, and say that player "BossC" is in the Add list in channel C, but here admin is marked as not inherit. This means that "Big Boss" is not in the admin list, and any changes for admin in Root will not be seen here. Channel D will inherit the list from C, unless C also marks admin as not inheritable.<br />
<br />
= ACL =<br />
<br />
ACL (Access Control Lists) are all attached to a specific channel. A channel can specify if it wants to inherit the ACL on the parent, but it cannot specify which; it's a all or nothing deal. ACL are evaluated in order, from top to bottom along the chain of channels.<br />
<br />
For each entry, either a user or a group will match. A user must be a specific, registered user, while a group can be any group valid in the channel the ACL is defined on. Note that group membership is evaluated in the channel the ACL is executed in, which is important for inherited ACLs. If a group begins with a ''!'', it's membership is inverted, and if it begins with a ''~'', it is evaluated in the context of the channel the ACL is defined on (and not the active channel).<br />
: all<br />
Everyone<br />
: auth<br />
All authenticated users<br />
: in<br />
All users inside current channel<br />
: out<br />
All users outside current channel<br />
<br />
For each entry, permissions are either allowed or denied; in case of a conflict the last entry takes precedence. Remember that all entries are evaluated in order, so if you have the following set of entries:<br />
* @all deny speak<br />
* @all allow speak<br />
Then everyone will be allowed to speak. On the other hand<br />
* @all allow speak<br />
* @all deny speak<br />
Will deny speak from everyone.<br />
<br />
Each entry can be marked as either applying in the current channel, in subchannels or both. Most of the time you want both. Remember that for an entry to be applied on a subchannel, you have to apply it to subchannels '''and''' allow inheritance in the subchannels.<br />
<br />
== The @sub group ==<br />
<br />
There is a special group called ''sub'', which just like ''all'' has a special meaning. Sub is used as ''sub,a,b,c'', where ''a'' is the minimum number of common parents, and ''b'' and ''c'' restrain the path depth: <br />
*b is the minimum and c the maximum path length, measured from the channel referred by a.<br />
*If any of those parameter is missing, then there will be no minimum/maximum path length.<br />
<br />
It's somewhat complex, but also rather powerful. For example, assume the following tree:<br />
<br />
* Root<br />
** A<br />
*** A1<br />
**** Sub1<br />
**** Sub2<br />
*** A2<br />
*** A3<br />
** B<br />
*** B1<br />
*** B2<br />
<br />
Let's deny enter to all on ''Root'' to start with. Then, on ''A'', we define<br />
<br />
# @~sub,0,1 +enter<br />
<br />
First of all, this ACL will be evaluated in the context of the defining channel, since the group starts with ~.<br />
<br />
The first parameter (0) indicates how many additional elements of the path name must match. A zero means we require a match up to this point. This means that any player in a channel under the path Root.A will match. If the parameter had been 1 and we were in channel Sub2, the path of the player would need to match Root.A.Sub1. Setting this to positive values only makes sense for pinned groups (with the ~).<br />
<br />
The second parameter requires the path of the evaluated channel to be at least one element longer than the path of the channel of the ACL. So this rule will match in anything that starts with Root.A and has at least one more element.<br />
<br />
To sum it up; this rule allows anyone in one of A's descendants (but no A itself) to join A or any of its descendants (we assume subchannels inherit the rule).<br />
<br />
If we don't use the ~, then it will allow people in any of A descendants to go up (ie, from Sub1 to A1 or A but not the other way) or, in other words, allow people in the descendant of a channel (any depth) to enter it.<br />
<br />
Let's add a new rule to ''A1'':<br />
<br />
# @sub,-1,0 +link<br />
<br />
This allows anyone that's in the parent (equal path up to -1 elements (the first parameter)) or any of the siblings (path length equal (the 0 parameter)) to link to this channel.<br />
<br />
And finally, just to show how messed up it can get, let's add this on B:<br />
<br />
# @~sub,-1,2,2 +enter<br />
<br />
This lets anyone that's currently in a descendant of Root (B's parent) and has a path length of exactly 2 (length of Root.B -1 + 2) join, so this rule would match someone in A1, but not A or Sub1.<br />
<br />
== Write ==<br />
<br />
This gives total control over the channel, including the ability to edit ACLs. This privilege implies all other privileges.<br />
<br />
== Traverse ==<br />
<br />
Without this privlege, a player will be unable to access the channel or any subchannels in any way, regardless of privileges in the subchannel. Don't deny this unless you really know what you're doing; you can probably achieve the effect you want by denying a player the Enter privlege.<br />
<br />
== Enter ==<br />
<br />
Allows player to enter channel. Even without this privilege, a player can be moved into the channel by a player with Move/Kick.<br />
<br />
== Speak ==<br />
<br />
Allows player to speak in channel. For linked channels, only players with Speak privilege in the destination channels will be heard. This can be used to set up a hierarchy of linked channels where all players can hear all the leader of each group, but normal players will not be propageated outside their channel. This way, players will hear someone else is talkig to the group leader and (hopefully) stop talking for a short while.<br />
<br />
If a player joins a channel he does not have Speak privilege in, he will be suppressed by the server, and will be unable to speak until someone unmutes him.<br />
<br />
== Mute / Deafen ==<br />
<br />
Allows a player to mute or deafen another player. Note that mute status will follow a player until he is either manually unmuted or reconnects to the server.<br />
<br />
== Move / Kick ==<br />
<br />
Allows a player to move another player to another channel or kick them off the server. Unless the target player has Enter privileges in the channel he's being moved to, Move privileges is required in both channels.<br />
<br />
== Make Channel ==<br />
<br />
Allows a player to make a subchannel in the current channel. The player will automatically be added to the ''admin'' group in the new channel, so make the inheritable ACLs give the privileges you desire.<br />
<br />
== Link Channel ==<br />
<br />
Allows a player to link or unlink, as well as push-to-link a channel. Unlinking requires Link privilege in either channel, and linking requires Link privilege in both.<br />
<br />
== AltSpeak ==<br />
<br />
Allows a player to speak in channel if he is holding the Alt Push-To-Talk key(can be configured in the Shortcuts tab of the options window). It works as Speak for linked channels, etc.<br />
<br />
= Examples =<br />
<br />
== Group of servers with FPS game ==<br />
<br />
In this example, we assume we have a group of public servers running FPS games. Each game has 2 competing sides, and each side consists of one or more squads. We want a hierarchy such as this:<br />
<br />
* Servers<br />
** "Servername"<br />
*** Team 1<br />
**** Squad 1<br />
**** Squad 2<br />
**** ...<br />
*** Team 2<br />
**** Squad 1<br />
**** ...<br />
*** ...<br />
** ...<br />
<br />
Let's assume we have a small script linked with qstat that puts the player in the channel of the right side, and once in there we want to give them the ability to switch between squad channels and link at will. However, we do not want them to gain access to the channels of the other side.<br />
<br />
This is actually a very straightforward implementation; on the "Servers" channel, define an empty group called players. Then, add the following acls:<br />
<br />
# @all deny enter<br />
# @~sub,2,2 allow enter, allow link<br />
<br />
The first rule denies enter privilege to all players, and the second rule allows anyone within a hierarchy at least 2 elements down from "Servers" to move and link at will. In practice, this means that once a player is inside "Team 1", he can move freely about in there but can't switch to the other team or another server subchannel.<br />
<br />
== MMORPG Raid ==<br />
<br />
Assume this setup:<br />
<br />
* Root<br />
** Raid<br />
*** Healers<br />
*** Tanks<br />
*** Damage Dealers<br />
*** Wussards and other pets<br />
<br />
The desire is to have one leader of each group, plus a few people as raid leaders.<br />
<br />
Set this up as follows: In "Raid", create a group called "groupleaders". Put the leader of each group in this group. In the same channel define "raidleaders", and put the raidleaders in this group.<br />
<br />
In the Raid channel, define the following ACLS:<br />
# @all deny enter, deny speak [Apply Here only]<br />
# @raidleaders allow enter, allow speak, allow link, allow mute, allow kick [Apply Here and Apply Subs]<br />
# @groupleaders allow speak, allow link [Apply Here only]<br />
# @groupleaders allow link, allow mute, allow kick [Apply Subs only]<br />
<br />
The first rule makes sure nobody can speak or enter the Raid channel. The second rule lifts this restriction from anyone in the raidleaders group as well as giving them broad permissions. The third rule makes sure groupleaders can link and speak to the raid channel, and the fourth gives them permission to link from the subchannel as well as get rid of troublesome players.<br />
<br />
Normal players will not be able to join the raid channel, but as that denial only applied in the raid channel they can join any subchannel they wish. When the channels are linked, everyone in the linked channels will hear raid leaders and group leaders. However, raid leaders will only hear group leaders, they will not hear normal players. This way, players can stay quiet when they hear a command coming down (and also hear the command direct without the groupleader having to repeat it), and if they don't that won't bother the rest of the raid.</div>Javitoninohttps://wiki.mumble.info/index.php?title=ACL_and_Groups/English&diff=1508ACL and Groups/English2007-07-31T18:31:38Z<p>Javitonino: /* AltSpeak */</p>
<hr />
<div>= Groups =<br />
<br />
Groups are tied to a specific channel, but can also be inherited by subchannels. Groups are convenient ways to administer channels; set up the ACLs on the top of the tree that should have similar privilege structure, and just change the group memberships on subchannels.<br />
<br />
For each channel, a group has 3 pieces of data. The list of players to add to the group, the list of players inherited from the same group on the parent channel, and the list of players to remove from the group.<br />
<br />
A group will only inherit players from the parent if ''Inherit'' is set true and the group was marked ''Inheritable'' on the parent. Most of the time you want both of these to be set.<br />
<br />
== Example ==<br />
<br />
Let's take a practical example; the ''admin'' group. Every time a player makes a channel, he is automatically added to the admin group. This doesn't automatically give him any privileges, it just marks him as a member of that group, however Murmur's default installation installs an ACL that gives the ''admin'' group write bit (all access).<br />
<br />
<br />
In a structure like this:<br />
* Root<br />
** A<br />
*** B<br />
** C<br />
*** D<br />
<br />
In Root, player "Big Boss" is alone in the admin group. In channel A, player "BossA" is in the Add list, and "BossB" is the same in channel B.<br />
<br />
Since the ''admin'' group is inherited and inheritable, a player that is a member at any parent of the current channel is also a member in the current channel. So the total list of members in channel B is "Big Boss, BossA, BossB". The convenience of this system is that if we later att "Super Boss" to admin in Root, he'll automatically be in the admin group of every channel below.<br />
<br />
Let's move on, and say that player "BossC" is in the Add list in channel C, but here admin is marked as not inherit. This means that "Big Boss" is not in the admin list, and any changes for admin in Root will not be seen here. Channel D will inherit the list from C, unless C also marks admin as not inheritable.<br />
<br />
= ACL =<br />
<br />
ACL (Access Control Lists) are all attached to a specific channel. A channel can specify if it wants to inherit the ACL on the parent, but it cannot specify which; it's a all or nothing deal. ACL are evaluated in order, from top to bottom along the chain of channels.<br />
<br />
For each entry, either a user or a group will match. A user must be a specific, registered user, while a group can be any group valid in the channel the ACL is defined on. Note that group membership is evaluated in the channel the ACL is executed in, which is important for inherited ACLs. If a group begins with a ''!'', it's membership is inverted, and if it begins with a ''~'', it is evaluated in the context of the channel the ACL is defined on (and not the active channel).<br />
: all<br />
Everyone<br />
: auth<br />
All authenticated users<br />
: in<br />
All users inside current channel<br />
: out<br />
All users outside current channel<br />
<br />
For each entry, permissions are either allowed or denied; in case of a conflict the last entry takes precedence. Remember that all entries are evaluated in order, so if you have the following set of entries:<br />
* @all deny speak<br />
* @all allow speak<br />
Then everyone will be allowed to speak. On the other hand<br />
* @all allow speak<br />
* @all deny speak<br />
Will deny speak from everyone.<br />
<br />
Each entry can be marked as either applying in the current channel, in subchannels or both. Most of the time you want both. Remember that for an entry to be applied on a subchannel, you have to apply it to subchannels '''and''' allow inheritance in the subchannels.<br />
<br />
== The @sub group ==<br />
<br />
There is a special group called ''sub'', which just like ''all'' has a special meaning. Sub is used as ''sub,a,b,c'', where ''a'' is the minimum number of common parents, and ''b'' and ''c'' restrain the path depth. It's somewhat complex, but also rather powerful.<br />
<br />
For example, assume the following tree:<br />
* Root<br />
** A<br />
*** A1<br />
**** Sub1<br />
**** Sub2<br />
*** A2<br />
*** A3<br />
** B<br />
*** B1<br />
*** B2<br />
<br />
Let's deny enter to all on ''Root'' to start with. Then, on ''A'', we define<br />
<br />
# @~sub,0,1 +enter<br />
<br />
First of all, this ACL will be evaluated in the context of the defining channel, since the group starts with ~.<br />
<br />
The first parameter (0) indicates how many additional elements of the path name must match. A zero means we require a match up to this point. This means that any player in a channel under the path Root.A will match. If the parameter had been 1 and we were in channel Sub2, the path of the player would need to match Root.A.Sub1. Setting this to positive values only makes sense for pinned groups (with the ~).<br />
<br />
The second parameter requires the path of the evaluated channel to be at least one element longer than the path of the channel of the ACL. So this rule will match in anything that starts with Root.A and has at least one more element.<br />
<br />
To sum it up; this rule allows anyone in one of A's descendants (but no A itself) to join A or any of its descendants (we assume subchannels inherit the rule).<br />
<br />
If we don't use the ~, then it will allow people in any of A descendants to go up (ie, from Sub1 to A1 or A but not the other way) or, in other words, allow people in the descendant of a channel (any depth) to enter it.<br />
<br />
Let's add a new rule to ''A1'':<br />
<br />
# @sub,-1,0 +link<br />
<br />
This allows anyone that's in the parent (equal path up to -1 elements (the first parameter)) or any of the siblings (path length equal (the 0 parameter)) to link to this channel.<br />
<br />
And finally, just to show how messed up it can get, let's add this on B:<br />
<br />
# @~sub,-1,2 +enter<br />
<br />
This lets anyone that's currently in a descendant of Root (B's parent) and has a path length of at least 2 (length of Root.B -1 + 2) join, so this rule would match someone in A1, but not A.<br />
<br />
== Write ==<br />
<br />
This gives total control over the channel, including the ability to edit ACLs. This privilege implies all other privileges.<br />
<br />
== Traverse ==<br />
<br />
Without this privlege, a player will be unable to access the channel or any subchannels in any way, regardless of privileges in the subchannel. Don't deny this unless you really know what you're doing; you can probably achieve the effect you want by denying a player the Enter privlege.<br />
<br />
== Enter ==<br />
<br />
Allows player to enter channel. Even without this privilege, a player can be moved into the channel by a player with Move/Kick.<br />
<br />
== Speak ==<br />
<br />
Allows player to speak in channel. For linked channels, only players with Speak privilege in the destination channels will be heard. This can be used to set up a hierarchy of linked channels where all players can hear all the leader of each group, but normal players will not be propageated outside their channel. This way, players will hear someone else is talkig to the group leader and (hopefully) stop talking for a short while.<br />
<br />
If a player joins a channel he does not have Speak privilege in, he will be suppressed by the server, and will be unable to speak until someone unmutes him.<br />
<br />
== Mute / Deafen ==<br />
<br />
Allows a player to mute or deafen another player. Note that mute status will follow a player until he is either manually unmuted or reconnects to the server.<br />
<br />
== Move / Kick ==<br />
<br />
Allows a player to move another player to another channel or kick them off the server. Unless the target player has Enter privileges in the channel he's being moved to, Move privileges is required in both channels.<br />
<br />
== Make Channel ==<br />
<br />
Allows a player to make a subchannel in the current channel. The player will automatically be added to the ''admin'' group in the new channel, so make the inheritable ACLs give the privileges you desire.<br />
<br />
== Link Channel ==<br />
<br />
Allows a player to link or unlink, as well as push-to-link a channel. Unlinking requires Link privilege in either channel, and linking requires Link privilege in both.<br />
<br />
== AltSpeak ==<br />
<br />
Allows a player to speak in channel if he is holding the Alt Push-To-Talk key(can be configured in the Shortcuts tab of the options window). It works as Speak for linked channels, etc.<br />
<br />
= Examples =<br />
<br />
== Group of servers with FPS game ==<br />
<br />
In this example, we assume we have a group of public servers running FPS games. Each game has 2 competing sides, and each side consists of one or more squads. We want a hierarchy such as this:<br />
<br />
* Servers<br />
** "Servername"<br />
*** Team 1<br />
**** Squad 1<br />
**** Squad 2<br />
**** ...<br />
*** Team 2<br />
**** Squad 1<br />
**** ...<br />
*** ...<br />
** ...<br />
<br />
Let's assume we have a small script linked with qstat that puts the player in the channel of the right side, and once in there we want to give them the ability to switch between squad channels and link at will. However, we do not want them to gain access to the channels of the other side.<br />
<br />
This is actually a very straightforward implementation; on the "Servers" channel, define an empty group called players. Then, add the following acls:<br />
<br />
# @all deny enter<br />
# @~sub,2,2 allow enter, allow link<br />
<br />
The first rule denies enter privilege to all players, and the second rule allows anyone within a hierarchy at least 2 elements down from "Servers" to move and link at will. In practice, this means that once a player is inside "Team 1", he can move freely about in there but can't switch to the other team or another server subchannel.<br />
<br />
== MMORPG Raid ==<br />
<br />
Assume this setup:<br />
<br />
* Root<br />
** Raid<br />
*** Healers<br />
*** Tanks<br />
*** Damage Dealers<br />
*** Wussards and other pets<br />
<br />
The desire is to have one leader of each group, plus a few people as raid leaders.<br />
<br />
Set this up as follows: In "Raid", create a group called "groupleaders". Put the leader of each group in this group. In the same channel define "raidleaders", and put the raidleaders in this group.<br />
<br />
In the Raid channel, define the following ACLS:<br />
# @all deny enter, deny speak [Apply Here only]<br />
# @raidleaders allow enter, allow speak, allow link, allow mute, allow kick [Apply Here and Apply Subs]<br />
# @groupleaders allow speak, allow link [Apply Here only]<br />
# @groupleaders allow link, allow mute, allow kick [Apply Subs only]<br />
<br />
The first rule makes sure nobody can speak or enter the Raid channel. The second rule lifts this restriction from anyone in the raidleaders group as well as giving them broad permissions. The third rule makes sure groupleaders can link and speak to the raid channel, and the fourth gives them permission to link from the subchannel as well as get rid of troublesome players.<br />
<br />
Normal players will not be able to join the raid channel, but as that denial only applied in the raid channel they can join any subchannel they wish. When the channels are linked, everyone in the linked channels will hear raid leaders and group leaders. However, raid leaders will only hear group leaders, they will not hear normal players. This way, players can stay quiet when they hear a command coming down (and also hear the command direct without the groupleader having to repeat it), and if they don't that won't bother the rest of the raid.</div>Javitoninohttps://wiki.mumble.info/index.php?title=ACL_and_Groups/English&diff=1507ACL and Groups/English2007-07-31T18:24:36Z<p>Javitonino: /* The @sub group */</p>
<hr />
<div>= Groups =<br />
<br />
Groups are tied to a specific channel, but can also be inherited by subchannels. Groups are convenient ways to administer channels; set up the ACLs on the top of the tree that should have similar privilege structure, and just change the group memberships on subchannels.<br />
<br />
For each channel, a group has 3 pieces of data. The list of players to add to the group, the list of players inherited from the same group on the parent channel, and the list of players to remove from the group.<br />
<br />
A group will only inherit players from the parent if ''Inherit'' is set true and the group was marked ''Inheritable'' on the parent. Most of the time you want both of these to be set.<br />
<br />
== Example ==<br />
<br />
Let's take a practical example; the ''admin'' group. Every time a player makes a channel, he is automatically added to the admin group. This doesn't automatically give him any privileges, it just marks him as a member of that group, however Murmur's default installation installs an ACL that gives the ''admin'' group write bit (all access).<br />
<br />
<br />
In a structure like this:<br />
* Root<br />
** A<br />
*** B<br />
** C<br />
*** D<br />
<br />
In Root, player "Big Boss" is alone in the admin group. In channel A, player "BossA" is in the Add list, and "BossB" is the same in channel B.<br />
<br />
Since the ''admin'' group is inherited and inheritable, a player that is a member at any parent of the current channel is also a member in the current channel. So the total list of members in channel B is "Big Boss, BossA, BossB". The convenience of this system is that if we later att "Super Boss" to admin in Root, he'll automatically be in the admin group of every channel below.<br />
<br />
Let's move on, and say that player "BossC" is in the Add list in channel C, but here admin is marked as not inherit. This means that "Big Boss" is not in the admin list, and any changes for admin in Root will not be seen here. Channel D will inherit the list from C, unless C also marks admin as not inheritable.<br />
<br />
= ACL =<br />
<br />
ACL (Access Control Lists) are all attached to a specific channel. A channel can specify if it wants to inherit the ACL on the parent, but it cannot specify which; it's a all or nothing deal. ACL are evaluated in order, from top to bottom along the chain of channels.<br />
<br />
For each entry, either a user or a group will match. A user must be a specific, registered user, while a group can be any group valid in the channel the ACL is defined on. Note that group membership is evaluated in the channel the ACL is executed in, which is important for inherited ACLs. If a group begins with a ''!'', it's membership is inverted, and if it begins with a ''~'', it is evaluated in the context of the channel the ACL is defined on (and not the active channel).<br />
: all<br />
Everyone<br />
: auth<br />
All authenticated users<br />
: in<br />
All users inside current channel<br />
: out<br />
All users outside current channel<br />
<br />
For each entry, permissions are either allowed or denied; in case of a conflict the last entry takes precedence. Remember that all entries are evaluated in order, so if you have the following set of entries:<br />
* @all deny speak<br />
* @all allow speak<br />
Then everyone will be allowed to speak. On the other hand<br />
* @all allow speak<br />
* @all deny speak<br />
Will deny speak from everyone.<br />
<br />
Each entry can be marked as either applying in the current channel, in subchannels or both. Most of the time you want both. Remember that for an entry to be applied on a subchannel, you have to apply it to subchannels '''and''' allow inheritance in the subchannels.<br />
<br />
== The @sub group ==<br />
<br />
There is a special group called ''sub'', which just like ''all'' has a special meaning. Sub is used as ''sub,a,b,c'', where ''a'' is the minimum number of common parents, and ''b'' and ''c'' restrain the path depth. It's somewhat complex, but also rather powerful.<br />
<br />
For example, assume the following tree:<br />
* Root<br />
** A<br />
*** A1<br />
**** Sub1<br />
**** Sub2<br />
*** A2<br />
*** A3<br />
** B<br />
*** B1<br />
*** B2<br />
<br />
Let's deny enter to all on ''Root'' to start with. Then, on ''A'', we define<br />
<br />
# @~sub,0,1 +enter<br />
<br />
First of all, this ACL will be evaluated in the context of the defining channel, since the group starts with ~.<br />
<br />
The first parameter (0) indicates how many additional elements of the path name must match. A zero means we require a match up to this point. This means that any player in a channel under the path Root.A will match. If the parameter had been 1 and we were in channel Sub2, the path of the player would need to match Root.A.Sub1. Setting this to positive values only makes sense for pinned groups (with the ~).<br />
<br />
The second parameter requires the path of the evaluated channel to be at least one element longer than the path of the channel of the ACL. So this rule will match in anything that starts with Root.A and has at least one more element.<br />
<br />
To sum it up; this rule allows anyone in one of A's descendants (but no A itself) to join A or any of its descendants (we assume subchannels inherit the rule).<br />
<br />
If we don't use the ~, then it will allow people in any of A descendants to go up (ie, from Sub1 to A1 or A but not the other way) or, in other words, allow people in the descendant of a channel (any depth) to enter it.<br />
<br />
Let's add a new rule to ''A1'':<br />
<br />
# @sub,-1,0 +link<br />
<br />
This allows anyone that's in the parent (equal path up to -1 elements (the first parameter)) or any of the siblings (path length equal (the 0 parameter)) to link to this channel.<br />
<br />
And finally, just to show how messed up it can get, let's add this on B:<br />
<br />
# @~sub,-1,2 +enter<br />
<br />
This lets anyone that's currently in a descendant of Root (B's parent) and has a path length of at least 2 (length of Root.B -1 + 2) join, so this rule would match someone in A1, but not A.<br />
<br />
== Write ==<br />
<br />
This gives total control over the channel, including the ability to edit ACLs. This privilege implies all other privileges.<br />
<br />
== Traverse ==<br />
<br />
Without this privlege, a player will be unable to access the channel or any subchannels in any way, regardless of privileges in the subchannel. Don't deny this unless you really know what you're doing; you can probably achieve the effect you want by denying a player the Enter privlege.<br />
<br />
== Enter ==<br />
<br />
Allows player to enter channel. Even without this privilege, a player can be moved into the channel by a player with Move/Kick.<br />
<br />
== Speak ==<br />
<br />
Allows player to speak in channel. For linked channels, only players with Speak privilege in the destination channels will be heard. This can be used to set up a hierarchy of linked channels where all players can hear all the leader of each group, but normal players will not be propageated outside their channel. This way, players will hear someone else is talkig to the group leader and (hopefully) stop talking for a short while.<br />
<br />
If a player joins a channel he does not have Speak privilege in, he will be suppressed by the server, and will be unable to speak until someone unmutes him.<br />
<br />
== Mute / Deafen ==<br />
<br />
Allows a player to mute or deafen another player. Note that mute status will follow a player until he is either manually unmuted or reconnects to the server.<br />
<br />
== Move / Kick ==<br />
<br />
Allows a player to move another player to another channel or kick them off the server. Unless the target player has Enter privileges in the channel he's being moved to, Move privileges is required in both channels.<br />
<br />
== Make Channel ==<br />
<br />
Allows a player to make a subchannel in the current channel. The player will automatically be added to the ''admin'' group in the new channel, so make the inheritable ACLs give the privileges you desire.<br />
<br />
== Link Channel ==<br />
<br />
Allows a player to link or unlink, as well as push-to-link a channel. Unlinking requires Link privilege in either channel, and linking requires Link privilege in both.<br />
<br />
== AltSpeak ==<br />
<br />
Allows a player to speak in channel if he is holding the Alt Push-To-Talk key(can be configured in the Shorcuts tab of the optiosn window). It works as Speak for linked channels, etc.<br />
<br />
= Examples =<br />
<br />
== Group of servers with FPS game ==<br />
<br />
In this example, we assume we have a group of public servers running FPS games. Each game has 2 competing sides, and each side consists of one or more squads. We want a hierarchy such as this:<br />
<br />
* Servers<br />
** "Servername"<br />
*** Team 1<br />
**** Squad 1<br />
**** Squad 2<br />
**** ...<br />
*** Team 2<br />
**** Squad 1<br />
**** ...<br />
*** ...<br />
** ...<br />
<br />
Let's assume we have a small script linked with qstat that puts the player in the channel of the right side, and once in there we want to give them the ability to switch between squad channels and link at will. However, we do not want them to gain access to the channels of the other side.<br />
<br />
This is actually a very straightforward implementation; on the "Servers" channel, define an empty group called players. Then, add the following acls:<br />
<br />
# @all deny enter<br />
# @~sub,2,2 allow enter, allow link<br />
<br />
The first rule denies enter privilege to all players, and the second rule allows anyone within a hierarchy at least 2 elements down from "Servers" to move and link at will. In practice, this means that once a player is inside "Team 1", he can move freely about in there but can't switch to the other team or another server subchannel.<br />
<br />
== MMORPG Raid ==<br />
<br />
Assume this setup:<br />
<br />
* Root<br />
** Raid<br />
*** Healers<br />
*** Tanks<br />
*** Damage Dealers<br />
*** Wussards and other pets<br />
<br />
The desire is to have one leader of each group, plus a few people as raid leaders.<br />
<br />
Set this up as follows: In "Raid", create a group called "groupleaders". Put the leader of each group in this group. In the same channel define "raidleaders", and put the raidleaders in this group.<br />
<br />
In the Raid channel, define the following ACLS:<br />
# @all deny enter, deny speak [Apply Here only]<br />
# @raidleaders allow enter, allow speak, allow link, allow mute, allow kick [Apply Here and Apply Subs]<br />
# @groupleaders allow speak, allow link [Apply Here only]<br />
# @groupleaders allow link, allow mute, allow kick [Apply Subs only]<br />
<br />
The first rule makes sure nobody can speak or enter the Raid channel. The second rule lifts this restriction from anyone in the raidleaders group as well as giving them broad permissions. The third rule makes sure groupleaders can link and speak to the raid channel, and the fourth gives them permission to link from the subchannel as well as get rid of troublesome players.<br />
<br />
Normal players will not be able to join the raid channel, but as that denial only applied in the raid channel they can join any subchannel they wish. When the channels are linked, everyone in the linked channels will hear raid leaders and group leaders. However, raid leaders will only hear group leaders, they will not hear normal players. This way, players can stay quiet when they hear a command coming down (and also hear the command direct without the groupleader having to repeat it), and if they don't that won't bother the rest of the raid.</div>Javitoninohttps://wiki.mumble.info/index.php?title=ACL_and_Groups/English&diff=1506ACL and Groups/English2007-07-31T17:51:07Z<p>Javitonino: /* ACL */</p>
<hr />
<div>= Groups =<br />
<br />
Groups are tied to a specific channel, but can also be inherited by subchannels. Groups are convenient ways to administer channels; set up the ACLs on the top of the tree that should have similar privilege structure, and just change the group memberships on subchannels.<br />
<br />
For each channel, a group has 3 pieces of data. The list of players to add to the group, the list of players inherited from the same group on the parent channel, and the list of players to remove from the group.<br />
<br />
A group will only inherit players from the parent if ''Inherit'' is set true and the group was marked ''Inheritable'' on the parent. Most of the time you want both of these to be set.<br />
<br />
== Example ==<br />
<br />
Let's take a practical example; the ''admin'' group. Every time a player makes a channel, he is automatically added to the admin group. This doesn't automatically give him any privileges, it just marks him as a member of that group, however Murmur's default installation installs an ACL that gives the ''admin'' group write bit (all access).<br />
<br />
<br />
In a structure like this:<br />
* Root<br />
** A<br />
*** B<br />
** C<br />
*** D<br />
<br />
In Root, player "Big Boss" is alone in the admin group. In channel A, player "BossA" is in the Add list, and "BossB" is the same in channel B.<br />
<br />
Since the ''admin'' group is inherited and inheritable, a player that is a member at any parent of the current channel is also a member in the current channel. So the total list of members in channel B is "Big Boss, BossA, BossB". The convenience of this system is that if we later att "Super Boss" to admin in Root, he'll automatically be in the admin group of every channel below.<br />
<br />
Let's move on, and say that player "BossC" is in the Add list in channel C, but here admin is marked as not inherit. This means that "Big Boss" is not in the admin list, and any changes for admin in Root will not be seen here. Channel D will inherit the list from C, unless C also marks admin as not inheritable.<br />
<br />
= ACL =<br />
<br />
ACL (Access Control Lists) are all attached to a specific channel. A channel can specify if it wants to inherit the ACL on the parent, but it cannot specify which; it's a all or nothing deal. ACL are evaluated in order, from top to bottom along the chain of channels.<br />
<br />
For each entry, either a user or a group will match. A user must be a specific, registered user, while a group can be any group valid in the channel the ACL is defined on. Note that group membership is evaluated in the channel the ACL is executed in, which is important for inherited ACLs. If a group begins with a ''!'', it's membership is inverted, and if it begins with a ''~'', it is evaluated in the context of the channel the ACL is defined on (and not the active channel).<br />
: all<br />
Everyone<br />
: auth<br />
All authenticated users<br />
: in<br />
All users inside current channel<br />
: out<br />
All users outside current channel<br />
<br />
For each entry, permissions are either allowed or denied; in case of a conflict the last entry takes precedence. Remember that all entries are evaluated in order, so if you have the following set of entries:<br />
* @all deny speak<br />
* @all allow speak<br />
Then everyone will be allowed to speak. On the other hand<br />
* @all allow speak<br />
* @all deny speak<br />
Will deny speak from everyone.<br />
<br />
Each entry can be marked as either applying in the current channel, in subchannels or both. Most of the time you want both. Remember that for an entry to be applied on a subchannel, you have to apply it to subchannels '''and''' allow inheritance in the subchannels.<br />
<br />
== The @sub group ==<br />
<br />
There is a special group called ''sub'', which just like ''all'' has a special meaning. Sub is used as ''sub,a,b,c'', where ''a'' is the minimum number of common parents, and ''b'' and ''c'' restrain the path depth. It's somewhat complex, but also rather powerful.<br />
<br />
For example, assume the following tree:<br />
* Root<br />
** A<br />
*** A1<br />
**** Sub1<br />
**** Sub2<br />
*** A2<br />
*** A3<br />
** B<br />
*** B1<br />
*** B2<br />
<br />
Let's deny enter to all on ''Root'' to start with. Then, on ''A'', we define<br />
<br />
# @~sub,0,1 +enter<br />
<br />
First of all, this ACL will be evaluated in the context of the defining channel, since the group starts with ~.<br />
<br />
The first parameter (0) indicates how many additional elements of the path name must match. A zero means we require a match up to this point. This means that any player in a channel under the path Root.A will match. If the parameter had been 1 and we were in channel Sub2, the path of the player would need to match Root.A.Sub1. Setting this to positive values only makes sense for pinned groups (with the ~).<br />
<br />
The second parameter requires the path of the evaluated channel to be at least one element longer than the path of the channel of the ACL. So this rule will match in anything that starts with Root.A and has at least one more element.<br />
<br />
To sum it up; this rule allows anyone in A or one of it's decendants to join one of As decendants, but not A itself.<br />
<br />
Let's add a new rule to ''A1'':<br />
<br />
# @sub,-1,0 +link<br />
<br />
This allows anyone that's in the parent (equal path up to -1 elements (the first parameter)) or any of the siblings (path length equal (the 0 parameter) to link to this channel.<br />
<br />
And finally, just to show how messed up it can get, let's add this on B:<br />
<br />
# @~sub,-1,1 +enter<br />
<br />
This lets anyone that's currently in a decendant of Root (B's parent) and has a path length of at least 2 (length of Root.B + 1) join, so this rule would match someone in A1, but not A.<br />
<br />
<br />
== Write ==<br />
<br />
This gives total control over the channel, including the ability to edit ACLs. This privilege implies all other privileges.<br />
<br />
== Traverse ==<br />
<br />
Without this privlege, a player will be unable to access the channel or any subchannels in any way, regardless of privileges in the subchannel. Don't deny this unless you really know what you're doing; you can probably achieve the effect you want by denying a player the Enter privlege.<br />
<br />
== Enter ==<br />
<br />
Allows player to enter channel. Even without this privilege, a player can be moved into the channel by a player with Move/Kick.<br />
<br />
== Speak ==<br />
<br />
Allows player to speak in channel. For linked channels, only players with Speak privilege in the destination channels will be heard. This can be used to set up a hierarchy of linked channels where all players can hear all the leader of each group, but normal players will not be propageated outside their channel. This way, players will hear someone else is talkig to the group leader and (hopefully) stop talking for a short while.<br />
<br />
If a player joins a channel he does not have Speak privilege in, he will be suppressed by the server, and will be unable to speak until someone unmutes him.<br />
<br />
== Mute / Deafen ==<br />
<br />
Allows a player to mute or deafen another player. Note that mute status will follow a player until he is either manually unmuted or reconnects to the server.<br />
<br />
== Move / Kick ==<br />
<br />
Allows a player to move another player to another channel or kick them off the server. Unless the target player has Enter privileges in the channel he's being moved to, Move privileges is required in both channels.<br />
<br />
== Make Channel ==<br />
<br />
Allows a player to make a subchannel in the current channel. The player will automatically be added to the ''admin'' group in the new channel, so make the inheritable ACLs give the privileges you desire.<br />
<br />
== Link Channel ==<br />
<br />
Allows a player to link or unlink, as well as push-to-link a channel. Unlinking requires Link privilege in either channel, and linking requires Link privilege in both.<br />
<br />
== AltSpeak ==<br />
<br />
Allows a player to speak in channel if he is holding the Alt Push-To-Talk key(can be configured in the Shorcuts tab of the optiosn window). It works as Speak for linked channels, etc.<br />
<br />
= Examples =<br />
<br />
== Group of servers with FPS game ==<br />
<br />
In this example, we assume we have a group of public servers running FPS games. Each game has 2 competing sides, and each side consists of one or more squads. We want a hierarchy such as this:<br />
<br />
* Servers<br />
** "Servername"<br />
*** Team 1<br />
**** Squad 1<br />
**** Squad 2<br />
**** ...<br />
*** Team 2<br />
**** Squad 1<br />
**** ...<br />
*** ...<br />
** ...<br />
<br />
Let's assume we have a small script linked with qstat that puts the player in the channel of the right side, and once in there we want to give them the ability to switch between squad channels and link at will. However, we do not want them to gain access to the channels of the other side.<br />
<br />
This is actually a very straightforward implementation; on the "Servers" channel, define an empty group called players. Then, add the following acls:<br />
<br />
# @all deny enter<br />
# @~sub,2,2 allow enter, allow link<br />
<br />
The first rule denies enter privilege to all players, and the second rule allows anyone within a hierarchy at least 2 elements down from "Servers" to move and link at will. In practice, this means that once a player is inside "Team 1", he can move freely about in there but can't switch to the other team or another server subchannel.<br />
<br />
== MMORPG Raid ==<br />
<br />
Assume this setup:<br />
<br />
* Root<br />
** Raid<br />
*** Healers<br />
*** Tanks<br />
*** Damage Dealers<br />
*** Wussards and other pets<br />
<br />
The desire is to have one leader of each group, plus a few people as raid leaders.<br />
<br />
Set this up as follows: In "Raid", create a group called "groupleaders". Put the leader of each group in this group. In the same channel define "raidleaders", and put the raidleaders in this group.<br />
<br />
In the Raid channel, define the following ACLS:<br />
# @all deny enter, deny speak [Apply Here only]<br />
# @raidleaders allow enter, allow speak, allow link, allow mute, allow kick [Apply Here and Apply Subs]<br />
# @groupleaders allow speak, allow link [Apply Here only]<br />
# @groupleaders allow link, allow mute, allow kick [Apply Subs only]<br />
<br />
The first rule makes sure nobody can speak or enter the Raid channel. The second rule lifts this restriction from anyone in the raidleaders group as well as giving them broad permissions. The third rule makes sure groupleaders can link and speak to the raid channel, and the fourth gives them permission to link from the subchannel as well as get rid of troublesome players.<br />
<br />
Normal players will not be able to join the raid channel, but as that denial only applied in the raid channel they can join any subchannel they wish. When the channels are linked, everyone in the linked channels will hear raid leaders and group leaders. However, raid leaders will only hear group leaders, they will not hear normal players. This way, players can stay quiet when they hear a command coming down (and also hear the command direct without the groupleader having to repeat it), and if they don't that won't bother the rest of the raid.</div>Javitoninohttps://wiki.mumble.info/index.php?title=ACL_and_Groups/English&diff=1505ACL and Groups/English2007-07-31T17:27:49Z<p>Javitonino: /* ACL */</p>
<hr />
<div>= Groups =<br />
<br />
Groups are tied to a specific channel, but can also be inherited by subchannels. Groups are convenient ways to administer channels; set up the ACLs on the top of the tree that should have similar privilege structure, and just change the group memberships on subchannels.<br />
<br />
For each channel, a group has 3 pieces of data. The list of players to add to the group, the list of players inherited from the same group on the parent channel, and the list of players to remove from the group.<br />
<br />
A group will only inherit players from the parent if ''Inherit'' is set true and the group was marked ''Inheritable'' on the parent. Most of the time you want both of these to be set.<br />
<br />
== Example ==<br />
<br />
Let's take a practical example; the ''admin'' group. Every time a player makes a channel, he is automatically added to the admin group. This doesn't automatically give him any privileges, it just marks him as a member of that group, however Murmur's default installation installs an ACL that gives the ''admin'' group write bit (all access).<br />
<br />
<br />
In a structure like this:<br />
* Root<br />
** A<br />
*** B<br />
** C<br />
*** D<br />
<br />
In Root, player "Big Boss" is alone in the admin group. In channel A, player "BossA" is in the Add list, and "BossB" is the same in channel B.<br />
<br />
Since the ''admin'' group is inherited and inheritable, a player that is a member at any parent of the current channel is also a member in the current channel. So the total list of members in channel B is "Big Boss, BossA, BossB". The convenience of this system is that if we later att "Super Boss" to admin in Root, he'll automatically be in the admin group of every channel below.<br />
<br />
Let's move on, and say that player "BossC" is in the Add list in channel C, but here admin is marked as not inherit. This means that "Big Boss" is not in the admin list, and any changes for admin in Root will not be seen here. Channel D will inherit the list from C, unless C also marks admin as not inheritable.<br />
<br />
= ACL =<br />
<br />
ACL (Access Control Lists) are all attached to a specific channel. A channel can specify if it wants to inherit the ACL on the parent, but it cannot specify which; it's a all or nothing deal. ACL are evaluated in order, from top to bottom along the chain of channels.<br />
<br />
For each entry, either a user or a group will match. A user must be a specific, registered user, while a group can be any group valid in the channel the ACL is defined on. Note that group membership is evaluated in the channel the ACL is executed in, which is important for inherited ACLs. If a group begins with a ''!'', it's membership is inverted, and if it begins with a ''~'', it is evaluated in the context of the channel the ACL is defined on (and not the active channel).<br />
: all<br />
Everyone<br />
: auth<br />
All authenticated users<br />
: in<br />
All users inside current channel<br />
: out<br />
All users outside current channel<br />
<br />
For each entry, permissions are either allowed or denied; in case of a conflict the last entry takes precedence. Remember that all entries are evaluated in order, so if you have the following set of entries:<br />
* @all deny speak<br />
* @all allow speak<br />
Then everyone will be allowed to speak. On the other hand<br />
* @all allow speak<br />
* @all deny traverse<br />
Will deny speak from everyone.<br />
<br />
Each entry can be marked as either applying in the current channel, in subchannels or both. Most of the time you want both. Remember that for an entry to be applied on a subchannel, you have to apply it to subchannels '''and''' allow inheritance in the subchannels.<br />
<br />
== The @sub group ==<br />
<br />
There is a special group called ''sub'', which just like ''all'' has a special meaning. Sub is used as ''sub,a,b,c'', where ''a'' is the minimum number of common parents, and ''b'' and ''c'' restrain the path depth. It's somewhat complex, but also rather powerful.<br />
<br />
For example, assume the following tree:<br />
* Root<br />
** A<br />
*** A1<br />
**** Sub1<br />
**** Sub2<br />
*** A2<br />
*** A3<br />
** B<br />
*** B1<br />
*** B2<br />
<br />
Let's deny enter to all on ''Root'' to start with. Then, on ''A'', we define<br />
<br />
# @~sub,0,1 +enter<br />
<br />
First of all, this ACL will be evaluated in the context of the defining channel, since the group starts with ~.<br />
<br />
The first parameter (0) indicates how many additional elements of the path name must match. A zero means we require a match up to this point. This means that any player in a channel under the path Root.A will match. If the parameter had been 1 and we were in channel Sub2, the path of the player would need to match Root.A.Sub1. Setting this to positive values only makes sense for pinned groups (with the ~).<br />
<br />
The second parameter requires the path of the evaluated channel to be at least one element longer than the path of the channel of the ACL. So this rule will match in anything that starts with Root.A and has at least one more element.<br />
<br />
To sum it up; this rule allows anyone in A or one of it's decendants to join one of As decendants, but not A itself.<br />
<br />
Let's add a new rule to ''A1'':<br />
<br />
# @sub,-1,0 +link<br />
<br />
This allows anyone that's in the parent (equal path up to -1 elements (the first parameter)) or any of the siblings (path length equal (the 0 parameter) to link to this channel.<br />
<br />
And finally, just to show how messed up it can get, let's add this on B:<br />
<br />
# @~sub,-1,1 +enter<br />
<br />
This lets anyone that's currently in a decendant of Root (B's parent) and has a path length of at least 2 (length of Root.B + 1) join, so this rule would match someone in A1, but not A.<br />
<br />
<br />
== Write ==<br />
<br />
This gives total control over the channel, including the ability to edit ACLs. This privilege implies all other privileges.<br />
<br />
== Traverse ==<br />
<br />
Without this privlege, a player will be unable to access the channel or any subchannels in any way, regardless of privileges in the subchannel. Don't deny this unless you really know what you're doing; you can probably achieve the effect you want by denying a player the Enter privlege.<br />
<br />
== Enter ==<br />
<br />
Allows player to enter channel. Even without this privilege, a player can be moved into the channel by a player with Move/Kick.<br />
<br />
== Speak ==<br />
<br />
Allows player to speak in channel. For linked channels, only players with Speak privilege in the destination channels will be heard. This can be used to set up a hierarchy of linked channels where all players can hear all the leader of each group, but normal players will not be propageated outside their channel. This way, players will hear someone else is talkig to the group leader and (hopefully) stop talking for a short while.<br />
<br />
If a player joins a channel he does not have Speak privilege in, he will be suppressed by the server, and will be unable to speak until someone unmutes him.<br />
<br />
== Mute / Deafen ==<br />
<br />
Allows a player to mute or deafen another player. Note that mute status will follow a player until he is either manually unmuted or reconnects to the server.<br />
<br />
== Move / Kick ==<br />
<br />
Allows a player to move another player to another channel or kick them off the server. Unless the target player has Enter privileges in the channel he's being moved to, Move privileges is required in both channels.<br />
<br />
== Make Channel ==<br />
<br />
Allows a player to make a subchannel in the current channel. The player will automatically be added to the ''admin'' group in the new channel, so make the inheritable ACLs give the privileges you desire.<br />
<br />
== Link Channel ==<br />
<br />
Allows a player to link or unlink, as well as push-to-link a channel. Unlinking requires Link privilege in either channel, and linking requires Link privilege in both.<br />
<br />
== AltSpeak ==<br />
<br />
Allows a player to speak in channel if he is holding the Alt Push-To-Talk key(can be configured in the Shorcuts tab of the optiosn window). It works as Speak for linked channels, etc.<br />
<br />
= Examples =<br />
<br />
== Group of servers with FPS game ==<br />
<br />
In this example, we assume we have a group of public servers running FPS games. Each game has 2 competing sides, and each side consists of one or more squads. We want a hierarchy such as this:<br />
<br />
* Servers<br />
** "Servername"<br />
*** Team 1<br />
**** Squad 1<br />
**** Squad 2<br />
**** ...<br />
*** Team 2<br />
**** Squad 1<br />
**** ...<br />
*** ...<br />
** ...<br />
<br />
Let's assume we have a small script linked with qstat that puts the player in the channel of the right side, and once in there we want to give them the ability to switch between squad channels and link at will. However, we do not want them to gain access to the channels of the other side.<br />
<br />
This is actually a very straightforward implementation; on the "Servers" channel, define an empty group called players. Then, add the following acls:<br />
<br />
# @all deny enter<br />
# @~sub,2,2 allow enter, allow link<br />
<br />
The first rule denies enter privilege to all players, and the second rule allows anyone within a hierarchy at least 2 elements down from "Servers" to move and link at will. In practice, this means that once a player is inside "Team 1", he can move freely about in there but can't switch to the other team or another server subchannel.<br />
<br />
== MMORPG Raid ==<br />
<br />
Assume this setup:<br />
<br />
* Root<br />
** Raid<br />
*** Healers<br />
*** Tanks<br />
*** Damage Dealers<br />
*** Wussards and other pets<br />
<br />
The desire is to have one leader of each group, plus a few people as raid leaders.<br />
<br />
Set this up as follows: In "Raid", create a group called "groupleaders". Put the leader of each group in this group. In the same channel define "raidleaders", and put the raidleaders in this group.<br />
<br />
In the Raid channel, define the following ACLS:<br />
# @all deny enter, deny speak [Apply Here only]<br />
# @raidleaders allow enter, allow speak, allow link, allow mute, allow kick [Apply Here and Apply Subs]<br />
# @groupleaders allow speak, allow link [Apply Here only]<br />
# @groupleaders allow link, allow mute, allow kick [Apply Subs only]<br />
<br />
The first rule makes sure nobody can speak or enter the Raid channel. The second rule lifts this restriction from anyone in the raidleaders group as well as giving them broad permissions. The third rule makes sure groupleaders can link and speak to the raid channel, and the fourth gives them permission to link from the subchannel as well as get rid of troublesome players.<br />
<br />
Normal players will not be able to join the raid channel, but as that denial only applied in the raid channel they can join any subchannel they wish. When the channels are linked, everyone in the linked channels will hear raid leaders and group leaders. However, raid leaders will only hear group leaders, they will not hear normal players. This way, players can stay quiet when they hear a command coming down (and also hear the command direct without the groupleader having to repeat it), and if they don't that won't bother the rest of the raid.</div>Javitonino