https://wiki.mumble.info/api.php?action=feedcontributions&user=PatPeter&feedformat=atomMumble Wiki - User contributions [en]2024-03-29T10:01:40ZUser contributionsMediaWiki 1.31.0https://wiki.mumble.info/index.php?title=LanguageTranslation&diff=2829LanguageTranslation2009-02-23T03:39:40Z<p>PatPeter: LanguageTranslation moved to Language Translation: Space for uniformity to other Wiki pages</p>
<hr />
<div>#REDIRECT [[Language Translation]]</div>PatPeterhttps://wiki.mumble.info/index.php?title=ACL_and_Groups/English&diff=2827ACL and Groups/English2009-02-23T03:04:20Z<p>PatPeter: Tutorial does not exist, the link does not need to be here until it does</p>
<hr />
<div>{{Languages|ACL and Groups}}<br />
<br />
= Groups =<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 />
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.<br />
<br />
[[Category:Documentation]]<br />
[[Category:Documentation English]]</div>PatPeterhttps://wiki.mumble.info/index.php?title=Template:Outdated&diff=2794Template:Outdated2009-02-16T00:40:14Z<p>PatPeter: Clean up</p>
<hr />
<div>[[Category:Outdated]]<br />
<div style="border: 1px solid #ffaa00; background-color: #ffee99; font-size: 130%; font-weight: bold; padding: 1em; margin: 1em 0;"><br />
'''IMPORTANT:''' The content of this page is outdated or wrong. If you have checked or updated this page and found the content to be suitable, please remove this notice. If the article isn't updated, it will be removed.<br />
</div><noinclude><br />
<br />
== Usage ==<br />
<br />
=== Out-of-date English content ===<br />
<nowiki>{{Outdated}}</nowiki><br />
For English pages that contain out-of-date information, simply add the template to the top of the page (or section if it only applies to part of the page). The template will be displayed as shown at the top of this page.<br />
<br />
=== Out-of-date translations ===<br />
<nowiki>{{Outdated|Page name}}</nowiki><br />
<br />
e.g. <nowiki>{{Outdated|Project:Language policy}}</nowiki><br />
<br />
For non-English pages that are out-of-date translations, include the name of the English-language page it was translated from. The resulting banner will include a link to the source text, like this:<br />
<br />
{{:Outdated|Project:Language policy}}<br />
<br />
[[Category:Alert templates|{{PAGENAME}}]]</noinclude></div>PatPeterhttps://wiki.mumble.info/index.php?title=Upcoming&diff=2793Upcoming2009-02-16T00:31:06Z<p>PatPeter: subst:</p>
<hr />
<div>This lists upcoming features in future versions of Mumble. No ETA is given, and they will happen in the 2009 timeframe at the earliest. Also, some of these ideas are just ideas and not actual plans.<br />
<br />
''Please do not edit this page unless you plan to implement the new feature yourself. This is '''not''' a feature request page''<br />
<br />
For a more short-term list of upcoming features, have a look at [[To-Do_List]]<br />
<br />
== User certificate ==<br />
<br />
Many people have asked for a way to register new users from inside the client. Any such scheme is inherently dangerous, as it opens up for social engineering attacks and it also has the problem when murmur is connected to an external database. How do you add users to a phpBB database through DBus?<br />
<br />
It also has major problems with account self-management. If a user forgets his password, how can he prove he is who he says he is? The current scheme using email authentication ensures there is at least a single fallback method, but an in-client solution has no such security.<br />
<br />
As an alternative user authentication method, we plan to have each client generate a SSL certificate. This certificate is then your password. This password will never be sent to any server, it will just be used for public key authentication. As such, the same certificate can be used on all servers you connect to.<br />
<br />
Once this is in place, it's pretty easy to "fix" connected user. Such an operation just assigns that user a murmur userID. So a server admin would click a user and "assign ID" or the ACLs would allow the user to do that themselves.<br />
<br />
In such a system, it is up to the user to copy the certificate to a secure location. However, he only has to do so once, and it's the same certificate being used for all servers. We might even support using "real" third-party certificates that are stored in the certificate store of the OS.<br />
<br />
== Video ==<br />
<br />
The current overlay texture system is designed for high speed texture transfers in a format that happens to be 60 pixels high. This is no coincidence.<br />
<br />
Using H.264 encoding, 80x60 pixels is small enough that we can encode a 15fps video stream with minimal CPU impact. The bitrate will also be low (lower than existing audio streams), and with a bit of filtering the quality is near perfect. I really mean this; what filtering did for the audio quality in Mumble it also does for video quality.<br />
<br />
I'd like to see this happen; I miss seeing my friends when we're gaming. It's one thing to hear enthusiasm, it's quite another to see it.<br />
<br />
There are two major challenges. The first is a technical one. 80x60 pixels is not much. It is enough to see a face clearly, if the face is the only thing in the picture. However, most people have their cameras placed so that 70% of the picture area is the room they are sitting in. That will not give a good enouh picture. So, we'll need a method to extract what we need from the image.<br />
<br />
The second is bandwidth. Yes, the video stream will use less bandwidth that an audio stream, but it will be going the whole time. This means that while audio bandwidth scales linearly with the number of users, video bandwidth scales exponentially. For example, if we assume that each user has 30 kbit/s of audio and 20 kbit/s of video. When one user talks, the others shut up. With 10 users, that's 9*30=270 kbit/s out from the server. Video, which is going the entire time, is 9*20=180kbit/s ''for each user'', giving us a total of 1.8Mbit/s.<br />
For all clans and guilds who host their servers somewhere with free bandwidth, this is not a problem. However, I don't really want to know what a 2mbit/s commercial hosting is going to cost. I doubt it's cheap.<br />
<br />
{{docs}}<br />
[[category:Documentation English]]</div>PatPeterhttps://wiki.mumble.info/index.php?title=ACL_Tutorial/English&diff=2792ACL Tutorial/English2009-02-16T00:30:52Z<p>PatPeter: subst:</p>
<hr />
<div>{{Languages|ACL Tutorial}}<br />
[[category:Documentation]]{{docs}}<br />
[[category:Documentation English]]<br />
<br />
=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 -ini /path/to/murmur.ini -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 this by selecting "Edit ACL" from the Channel menu. Once we are there, you can see a window with two tabs. The first one is for defining people who are 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>PatPeterhttps://wiki.mumble.info/index.php?title=ACL_and_Groups/Deutsch&diff=2791ACL and Groups/Deutsch2009-02-16T00:16:30Z<p>PatPeter: No need for language links anywhere else</p>
<hr />
<div>{{Languages|ACL and Groups}}<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.<br />
<br />
[[Category:Documentation]]<br />
[[Category:Documentation German]]</div>PatPeterhttps://wiki.mumble.info/index.php?title=ACL_and_Groups/English&diff=2745ACL and Groups/English2009-02-12T19:41:47Z<p>PatPeter: -PAGENAME</p>
<hr />
<div>{{Languages|ACL and Groups}}<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 />
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 />
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.<br />
<br />
[[Category:Documentation]]<br />
[[Category:Documentation English]]</div>PatPeterhttps://wiki.mumble.info/index.php?title=Template:Languages&diff=2744Template:Languages2009-02-12T19:41:23Z<p>PatPeter: Fix bug and spaces</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|English]]{{#ifexist:{{BASEPAGENAME}}/Español|&nbsp;— [[{{{1}}}/Español|Español]]|}}{{#ifexist:{{BASEPAGENAME}}/Francais|&nbsp;— [[{{{1}}}/Francais|Français]]|}}{{#ifexist:{{BASEPAGENAME}}/Italiano|&nbsp;— [[{{{1}}}/Italiano|Italiano]]|}}{{#ifexist:{{BASEPAGENAME}}/Deutsch|&nbsp;— [[{{{1}}}/Deutsch|Deutsch]]|}}<br />
</div><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 but replacing "/English" with the corresponding language:<br />
<br />
*/Deutsch<br />
*/Español<br />
*/Français<br />
<br />
== How do I use it? ==<br />
To include that template, add the following to the article you are editing:<br />
<nowiki>{{Languages|Name of page without language tag}}</nowiki><br />
<br />
== Example ==<br />
Look at the [[ACL_and_Groups/English|ACL and Groups]] page. It is using the template right now.</noinclude></div>PatPeterhttps://wiki.mumble.info/index.php?title=Template:Languages&diff=2743Template:Languages2009-02-12T19:37:11Z<p>PatPeter: Updating template, will not display non-existent pages</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|English]]{{#ifexist:{{BASEPAGENAME}}/Español| — [[{{{1}}}/Español|Español]]|}}{{#ifexist:{{BASEPAGENAME}}/Francais| — [[{{{1}}}/Francais|Français]]|}}{{#ifexist:{{BASEPAGENAME}}/Italiano — [[{{{1}}}/Italiano|Italiano]]|}}{{#ifexist:{{BASEPAGENAME}}/Deutsch — [[{{{1}}}/Deutsch|Deutsch]]|}}<br />
</div><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 but replacing "/English" with the corresponding language:<br />
<br />
*/Deutsch<br />
*/Español<br />
*/Français<br />
<br />
== How do I use it? ==<br />
To include that template, add the following to the article you are editing:<br />
<nowiki>{{Languages|Name of page without language tag}}</nowiki><br />
<br />
== Example ==<br />
Look at the [[ACL_and_Groups/English|ACL and Groups]] page. It is using the template right now.</noinclude></div>PatPeterhttps://wiki.mumble.info/index.php?title=ACL_and_Groups/English&diff=2526ACL and Groups/English2009-01-18T00:32:06Z<p>PatPeter: -BASE</p>
<hr />
<div>{{Languages|ACL and Groups}}<br />
<br />
{{PAGENAME}}<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 />
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 />
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>PatPeterhttps://wiki.mumble.info/index.php?title=ACL_and_Groups/English&diff=2525ACL and Groups/English2009-01-18T00:31:55Z<p>PatPeter: Testing parsers</p>
<hr />
<div>{{Languages|ACL and Groups}}<br />
<br />
{{BASEPAGENAME}}<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 />
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 />
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>PatPeterhttps://wiki.mumble.info/index.php?title=Template:Languages&diff=2524Template:Languages2009-01-18T00:26:00Z<p>PatPeter: BASEPAGENAME</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|English]]{{#ifexist:{{BASEPAGENAME}}/Español| — [[{{{1}}}/Español|Español]]|}} — [[{{{1}}}/Francais|Français]] — [[{{{1}}}/Italiano|Italiano]] — [[{{{1}}}/Deutsch|Deutsch]]<br />
</div><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|Name of page without language tag}}</nowiki><br />
<br />
== Example ==<br />
Look at the ACL_and_Groups page. It is using the template right now.</noinclude></div>PatPeterhttps://wiki.mumble.info/index.php?title=Template:Languages&diff=2523Template:Languages2009-01-18T00:24:38Z<p>PatPeter: ifexist test</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|English]]{{#ifexist:/Español| — [[{{{1}}}/Español|Español]]|}} — [[{{{1}}}/Francais|Français]] — [[{{{1}}}/Italiano|Italiano]] — [[{{{1}}}/Deutsch|Deutsch]]<br />
</div><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|Name of page without language tag}}</nowiki><br />
<br />
== Example ==<br />
Look at the ACL_and_Groups page. It is using the template right now.</noinclude></div>PatPeterhttps://wiki.mumble.info/index.php?title=Template:Languages&diff=2470Template:Languages2008-12-13T19:06:50Z<p>PatPeter: Lower section headers look better</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|English]] — [[{{{1}}}/Español|Español]] — [[{{{1}}}/Francais|Français]] — [[{{{1}}}/Italiano|Italiano]] — [[{{{1}}}/Deutsch|Deutsch]]<br />
</div><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|Name of page without language tag}}</nowiki><br />
<br />
== Example ==<br />
Look at the ACL_and_Groups page. It is using the template right now.</noinclude></div>PatPeterhttps://wiki.mumble.info/index.php?title=FAQ/Deutsch&diff=2169FAQ/Deutsch2008-08-03T17:53:46Z<p>PatPeter: /* FAQ: Über Mumble */ Removing section as languages accounts for it</p>
<hr />
<div>{{Languages|FAQ}}<br />
<br />
==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 />
<br />
siehe die [[ACL_FAQ_(Deutsch)|ACL FAQ]]<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>PatPeterhttps://wiki.mumble.info/index.php?title=FAQ/Deutsch&diff=2168FAQ/Deutsch2008-08-03T17:53:12Z<p>PatPeter: Typo</p>
<hr />
<div>{{Languages|FAQ}}<br />
<br />
==FAQ: Über Mumble==<br />
<br />
=== Diese FAQ in anderen Sprachen ===<br />
<br />
Die FAQ ist verfügbar in folgenden Sprachen:<br><br />
[[FAQ_(English)|English]]&nbsp;&nbsp; [[FAQ_(Deutsch)|Deutsch]]<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 />
<br />
siehe die [[ACL_FAQ_(Deutsch)|ACL FAQ]]<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>PatPeterhttps://wiki.mumble.info/index.php?title=FAQ/Deutsch&diff=2167FAQ/Deutsch2008-08-03T17:52:49Z<p>PatPeter: Languages</p>
<hr />
<div>{{Langauges|FAQ}}<br />
<br />
==FAQ: Über Mumble==<br />
<br />
=== Diese FAQ in anderen Sprachen ===<br />
<br />
Die FAQ ist verfügbar in folgenden Sprachen:<br><br />
[[FAQ_(English)|English]]&nbsp;&nbsp; [[FAQ_(Deutsch)|Deutsch]]<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 />
<br />
siehe die [[ACL_FAQ_(Deutsch)|ACL FAQ]]<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>PatPeterhttps://wiki.mumble.info/index.php?title=FAQ/Deutsch&diff=2165FAQ/Deutsch2008-08-03T17:52:27Z<p>PatPeter: FAQ (Deutsch) moved to FAQ/Deutsch</p>
<hr />
<div>==FAQ: Über Mumble==<br />
<br />
=== Diese FAQ in anderen Sprachen ===<br />
<br />
Die FAQ ist verfügbar in folgenden Sprachen:<br><br />
[[FAQ_(English)|English]]&nbsp;&nbsp; [[FAQ_(Deutsch)|Deutsch]]<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 />
<br />
siehe die [[ACL_FAQ_(Deutsch)|ACL FAQ]]<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>PatPeterhttps://wiki.mumble.info/index.php?title=Talk:FAQ_(English)&diff=2164Talk:FAQ (English)2008-08-03T17:51:42Z<p>PatPeter: Talk:FAQ (English) moved to Talk:FAQ/English: Subpage for template</p>
<hr />
<div>#redirect [[Talk:FAQ/English]]</div>PatPeterhttps://wiki.mumble.info/index.php?title=Talk:FAQ/English&diff=2163Talk:FAQ/English2008-08-03T17:51:37Z<p>PatPeter: Talk:FAQ (English) moved to Talk:FAQ/English</p>
<hr />
<div>:We might put up a page of "tested headsets" if anyone wants it.<br />
You should definitely do that. Having some idea of which headsets are good - especially USB headsets that work under Linux - would be awesome. [[User:Chandon|Chandon]] 15:44, 19 July 2007 (PDT)<br />
<br />
Great job on murmur/mumble, guys! I was tearing my hair out this morning trying to figure out why clients connected to my multi-homed linux server could only hear the first 2-3 seconds of chat and then nothing else until I saw the note on "Can't hear other users/users can't hear me." For what it's worth, other programs that use UDP communications get around the problems described in this section by binding to each IP address on the server, instead of 0.0.0.0. It would be handy to have an option in the ini file to bind the murmur server to a specific IP. [[User:SR|SR]] 13:14, 14 August 2007 (PDT)</div>PatPeterhttps://wiki.mumble.info/index.php?title=FAQ/English&diff=2161FAQ/English2008-08-03T17:51:29Z<p>PatPeter: FAQ (English) moved to FAQ/English</p>
<hr />
<div>{{Languages|FAQ}}<br />
<br />
<br />
= About Mumble =<br />
<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. It can be compared to programs like Ventrilo or TeamSpeak.<br />
<br />
== What platforms does it run on? ==<br />
<br />
The client, Mumble, runs on Windows, Mac OS X and Linux.<br />
<br />
The server component, Murmur, should run on anything you can compile Qt 4 on.<br />
<br />
== What are the system requirements? ==<br />
<br />
The client runs on any Windows, Linux or Mac OS X machine. 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 Windows 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, Mac OS X 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 />
*Mac OS X: [http://sourceforge.net/project/showfiles.php?group_id=147372 SourceForge] (.dmg)<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 - [[BuildingLinux]]<br />
*Windows - [[BuildingWindows]]<br />
*Mac OS X - [[BuildingMacOsX]]<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 />
<br />
== What tools did you use to make this? ==<br />
<br />
See [[Development Tools]].<br />
<br />
== How can I help or contact you? ==<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. You can do so via the [http://sourceforge.net/forum/?group_id=147372 forums] or meet us on IRC at irc://irc.freenode.org/mumble<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 />
== Can I run multiple servers on one host? ==<br />
<br />
See [[Murmur Init Script]]<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.3 or better; you are running qmake from Qt 3<br />
<br />
== Where is the administrator account? ==<br />
<br />
The topmost user in the Mumble hierarchy is the useraccount "SuperUser", which bypasses all permission checks and is always allowed to do anything. SuperUser can't be used as a normal user account (it can't talk) and should only be used for initial configuration or to recover from misconfiguration.<br />
<br />
To set the superuser password, start murmur with<br />
murmur.exe -supw supersecretpw<br />
or<br />
murmurd -supw supersecretpw<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 add an user? ==<br />
See [[Registering_users]]<br />
<br />
== How can I change a users password? ==<br />
'''Note''' that you should definately use dbus to do so.<br />
<br />
If you can't or don't want to, you may use the sqlite3 command:<br />
<br />
<code><br />
$ '''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 />
<br />
== How can I use an external database for Murmur? ==<br />
<br />
See [[Murmur and PostgreSQL]]<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 />
Also this problem can happen if you have server with multible IP's, you need to use server PRIMARY IP or you will experience random "can't hear you, but you can hear me" issues. Not sure is it possible to bind murmur just use one IP from box.<br />
<br />
== Shortcuts don't work on Linux ==<br />
There are two alternatives:<br />
Either use native input or Xevie.<br />
<br />
For native input make sure that the user running Mumble has read permissions on the /dev/input/eventX files of the input devices you want to use for shortcuts.<br />
Be aware that too weak permissions may be a security risk, because malicious processes may log all your input.<br />
<br />
If Mumble can not read from any input device it falls back to Xevie.<br />
<br />
You need to have Xevie enabled 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 (Ctrl+Alt+Backspace) and try again.<br />
<br />
'''Note:''' As of Mumble 1.1.4 neither Xevie nor access to /dev/input is needed anymore. Push To Talk shortcuts will work out of the box.<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)<br />
<br />
== Sound issue on Linux ==<br />
I want to have festival and mumble on the same soundcard, but either i don't hear festival, or mumble puts out this error:<br />
ALSA lib pcm_dmix.c:864:(snd_pcm_dmix_open) unable to open slave<br />
I tried every alsa device listed in mumble, but it makes no difference<br />
<br />
Solution:<br />
You have to use the dmix plugin, which allows simultaneous access on this device from different applications. Open ~/.config/Mumble/Mumble.conf and replace the output entry by<br />
output="plug:\"dmix:CARD=2\""<br />
(please adept the cardnumber according to your system configuration, if there is only one card use 0)<br />
<br />
After this you have to edit/create your festival configruation, which is located at ~/.festivalrc.<br />
(Parameter.set 'Audio_Command "aplay -D plug:dmix:2 $FILE")<br />
(Parameter.set 'Audio_Required_Format "snd")<br />
(Parameter.set 'Audio_Method 'Audio_Command)<br />
(again, adept the cardnumber)</div>PatPeterhttps://wiki.mumble.info/index.php?title=FAQ/English&diff=2160FAQ/English2008-08-03T17:51:10Z<p>PatPeter: Adding template and removing section</p>
<hr />
<div>{{Languages|FAQ}}<br />
<br />
<br />
= About Mumble =<br />
<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. It can be compared to programs like Ventrilo or TeamSpeak.<br />
<br />
== What platforms does it run on? ==<br />
<br />
The client, Mumble, runs on Windows, Mac OS X and Linux.<br />
<br />
The server component, Murmur, should run on anything you can compile Qt 4 on.<br />
<br />
== What are the system requirements? ==<br />
<br />
The client runs on any Windows, Linux or Mac OS X machine. 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 Windows 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, Mac OS X 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 />
*Mac OS X: [http://sourceforge.net/project/showfiles.php?group_id=147372 SourceForge] (.dmg)<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 - [[BuildingLinux]]<br />
*Windows - [[BuildingWindows]]<br />
*Mac OS X - [[BuildingMacOsX]]<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 />
<br />
== What tools did you use to make this? ==<br />
<br />
See [[Development Tools]].<br />
<br />
== How can I help or contact you? ==<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. You can do so via the [http://sourceforge.net/forum/?group_id=147372 forums] or meet us on IRC at irc://irc.freenode.org/mumble<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 />
== Can I run multiple servers on one host? ==<br />
<br />
See [[Murmur Init Script]]<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.3 or better; you are running qmake from Qt 3<br />
<br />
== Where is the administrator account? ==<br />
<br />
The topmost user in the Mumble hierarchy is the useraccount "SuperUser", which bypasses all permission checks and is always allowed to do anything. SuperUser can't be used as a normal user account (it can't talk) and should only be used for initial configuration or to recover from misconfiguration.<br />
<br />
To set the superuser password, start murmur with<br />
murmur.exe -supw supersecretpw<br />
or<br />
murmurd -supw supersecretpw<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 add an user? ==<br />
See [[Registering_users]]<br />
<br />
== How can I change a users password? ==<br />
'''Note''' that you should definately use dbus to do so.<br />
<br />
If you can't or don't want to, you may use the sqlite3 command:<br />
<br />
<code><br />
$ '''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 />
<br />
== How can I use an external database for Murmur? ==<br />
<br />
See [[Murmur and PostgreSQL]]<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 />
Also this problem can happen if you have server with multible IP's, you need to use server PRIMARY IP or you will experience random "can't hear you, but you can hear me" issues. Not sure is it possible to bind murmur just use one IP from box.<br />
<br />
== Shortcuts don't work on Linux ==<br />
There are two alternatives:<br />
Either use native input or Xevie.<br />
<br />
For native input make sure that the user running Mumble has read permissions on the /dev/input/eventX files of the input devices you want to use for shortcuts.<br />
Be aware that too weak permissions may be a security risk, because malicious processes may log all your input.<br />
<br />
If Mumble can not read from any input device it falls back to Xevie.<br />
<br />
You need to have Xevie enabled 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 (Ctrl+Alt+Backspace) and try again.<br />
<br />
'''Note:''' As of Mumble 1.1.4 neither Xevie nor access to /dev/input is needed anymore. Push To Talk shortcuts will work out of the box.<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)<br />
<br />
== Sound issue on Linux ==<br />
I want to have festival and mumble on the same soundcard, but either i don't hear festival, or mumble puts out this error:<br />
ALSA lib pcm_dmix.c:864:(snd_pcm_dmix_open) unable to open slave<br />
I tried every alsa device listed in mumble, but it makes no difference<br />
<br />
Solution:<br />
You have to use the dmix plugin, which allows simultaneous access on this device from different applications. Open ~/.config/Mumble/Mumble.conf and replace the output entry by<br />
output="plug:\"dmix:CARD=2\""<br />
(please adept the cardnumber according to your system configuration, if there is only one card use 0)<br />
<br />
After this you have to edit/create your festival configruation, which is located at ~/.festivalrc.<br />
(Parameter.set 'Audio_Command "aplay -D plug:dmix:2 $FILE")<br />
(Parameter.set 'Audio_Required_Format "snd")<br />
(Parameter.set 'Audio_Method 'Audio_Command)<br />
(again, adept the cardnumber)</div>PatPeterhttps://wiki.mumble.info/index.php?title=User:PatPeter&diff=2158User:PatPeter2008-08-03T05:37:53Z<p>PatPeter: Special</p>
<hr />
<div>Hello I am PatPeter, I will write more about myself when necessary.<br />
<br />
== All pages ==<br />
{{Special:Allpages}}</div>PatPeterhttps://wiki.mumble.info/index.php?title=Configuring_Murmur&diff=2157Configuring Murmur2008-08-03T05:36:26Z<p>PatPeter: TOC</p>
<hr />
<div>__TOC__<br />
<br />
= Murmur: Mumble Server =<br />
== INI file ==<br />
The server configuration is done through the '''murmur.ini''' file. It is read using the <code>MetaParams::read()</code> function in [http://mumble.svn.sourceforge.net/viewvc/mumble/trunk/src/murmur/Meta.cpp?view=markup Meta.cpp]. The function's source code will show all the available INI property names in the event new setting are added and this page does not get updated.<br />
<br />
Here's an example file:<br />
<br />
<pre><br />
# Welcome message sent to users<br />
welcometext="<br />Welcome to this server running <b>Murmur</b>.<br />Enjoy your stay!<br />"<br />
<br />
# Port to bind TCP and UDP sockets to.<br />
port=64738<br />
<br />
# Password to join server<br />
serverpassword=<br />
<br />
# Maximum number of concurrent clients allowed.<br />
users=50<br />
<br />
# Maximum bandwidth (in bytes per second) clients are allowed<br />
# send speech at.<br />
bandwidth=5000<br />
<br />
# Users hear themselves? (Testmode)<br />
loop=false<br />
<br />
# Path to database. If blank, will search for<br />
# murmur.sqlite in default locations.<br />
database=<br />
<br />
# How often should commands from the database be checked?<br />
# The default is every 10 seconds. Unless you're writing your<br />
# own scripts, don't bother with this.<br />
commandtime=1<br />
<br />
# If you wish to use something other than SQLite, you'll need to set the name<br />
# of the database above, and also uncomment the below.<br />
#<br />
#dbDriver=QMYSQL<br />
#dbUsername=<br />
#dbPassword=<br />
#dbHost=<br />
#dbPort=<br />
<br />
# Murmur defaults to not using D-Bus. If you wish to use dbus, please<br />
# specify so here.<br />
#<br />
#dbus=session<br />
<br />
# Murmur default to logging to murmur.log. If you leave this blank,<br />
# murmur will log to the console (linux) or through message boxes (win32).<br />
# System log file locations:<br />
# For Windows: logfile=c:\windows\system32\LogFiles\murmur.log<br />
# For Linux: logfile=/var/log/murmur.log<br />
logfile=murmur.log<br />
<br />
# To enable public registration, the serverpassword must be blank, and this<br />
# must all be filled out.<br />
# The password here is used to create a registry for the server name; subsequent<br />
# updates will need the same password. Don't loose your password.<br />
# The URL is your own website.<br />
#registerName=Mumble Server<br />
#registerPassword=secret<br />
#registerUrl=http://mumble.sourceforge.net/<br />
<br />
# Specifies autoban settings. Times are in seconds.<br />
#autobanAttempts=10<br />
#autobanTimeframe=120<br />
#autobanTime=300<br />
<br />
# Full path and file name of the PEM encoded server identity <br />
# certificate and private key file for SSL.<br />
#sslCert=<br />
#sslKey=<br />
<br />
</pre><br />
<br />
== Using an external database ==<br />
<br />
It is possible to use an external database instead of SQLite:<br />
* [[Murmur and PostgreSQL]]</div>PatPeterhttps://wiki.mumble.info/index.php?title=Running_Murmur&diff=2156Running Murmur2008-08-03T05:35:45Z<p>PatPeter: h2 => h1</p>
<hr />
<div>= Murmur: Mumble Server =<br />
<br />
== Running From The Start Menu ==<br />
This will run the basic application if you go to the program files menu and select Mumble then click on "murmur". This will start murmur with no extra options.<br />
'''Configuring The Run From Start Menu'''<br />
Well once you get to the murmur thing in the program files menu instead of left clicking, right click and left click on properties. In here you will see multiple text boxes, the target text box is the one that interests us. We may want an admin cp password so take -supw passwordhere on the end in the quotes and now we have an admin password, then if you want to use another ini file, take a space then -ini filenamehere after that to load that ini file onto the end. Read [[Configuring Murmur]] for information on using the ini file. If you checked out from svn, you can find an example ini file in the <code>scripts</code> directory.<br />
<br />
== Running From Command Prompt ==<br />
<br />
To set the SuperUser password run<br />
<br />
'''./murmur -supw <password>'''<br />
<br />
This will set the password in the DB and exit.<br />
<br />
To run the server<br />
<br />
'''./murmur'''<br />
<br />
If you want to have access to the console at a later date, you can first start a screen<br />
<br />
'''screen -AmS murmur'''<br />
<br />
Then start murmur, and then do a Ctrl-A D. This will disconnect the screen. To get back into the screen at a later date.<br />
<br />
'''screen -r'''<br />
<br />
== Adding Registered Users ==<br />
<br />
The default way to setup registered users is to use the '''murmur.pl''' perl script. You need to setup a webserver and make sure its is configured to execute it as CGI.<br />
<br />
If you just want to add,remove,edit users there is a linux bash script for easy adding below:<br />
Copy the following content in a file named '''config.sh''', place it in your murmur direcotry, make it executable and see '''./config.sh --help''' for further instructions.<br />
<br />
'''Note:''' Although this works, it is highly discouraged to update users directly via the database. Changes made directly to it will not be reflected in murmur unless it's restarted. Use DBUS instead (the perl scripts use DBUS).<br />
<pre><br />
#!/bin/bash<br />
#<br />
# -> config.sh <br />
#<br />
# version: 1.1<br />
# author: Massimo Mund<br />
# date: 21.12.2007<br />
# description: a script to easily add, remove and edit users from a murmur server<br />
#<br />
<br />
#information<br />
version="1.1"<br />
<br />
#settings<br />
bin="sqlite3"<br />
dbfile="./murmur.sqlite"<br />
<br />
function checkforsqlite() {<br />
<br />
if [ ! -f /usr/bin/sqlite3 ]; then<br />
echo "it seems that there is no sqlite3 installed, which is necessary for this script! "<br />
echo "install sqlite3 and try it again!"<br />
exit<br />
fi<br />
<br />
}<br />
<br />
function help () {<br />
<br />
echo ""<br />
echo " usage: config.sh <cmd> | --help | --version"<br />
echo ""<br />
echo " commands:"<br />
echo " showusers"<br />
echo " adduser <username> <pw> [<serverid>] [<email>]"<br />
echo " deluser <username> [<serverid>]"<br />
echo " setpw <username> <newpw> [<serverid>]"<br />
echo " setemail <username> <newemail> [<serverid>]"<br />
echo ""<br />
exit<br />
<br />
}<br />
<br />
function version() {<br />
<br />
echo "config.sh : version: $1"<br />
exit<br />
}<br />
<br />
function invalidoption () {<br />
<br />
echo "config.sh : invalid option -- $*"<br />
echo "Try 'config.sh --help' for more information."<br />
exit<br />
<br />
}<br />
<br />
checkforsqlite<br />
<br />
while [ "$#" -gt "0" ]; do<br />
case $1 in<br />
showusers)<br />
$bin $dbfile "select * from players;"<br />
exit<br />
;;<br />
adduser)<br />
shift<br />
username="$1"<br />
email="$4"<br />
pw="$2"<br />
serverid="$3"<br />
playerid=$($bin $dbfile "select MAX(player_id)+1 as id from players WHERE player_id < 10000;")<br />
<br />
if [ "$serverid" == "" ]; then<br />
serverid="1"<br />
fi<br />
<br />
$bin $dbfile "insert into players (server_id, player_id, name, email, pw) values($serverid, $playerid, '$username', '$email', '$pw');"<br />
exit<br />
;;<br />
deluser)<br />
shift<br />
username="$1"<br />
serverid="$2"<br />
<br />
if [ "$serverid" == "" ]; then<br />
serverid="1"<br />
fi<br />
<br />
$bin $dbfile "delete from players where name='$username';"<br />
exit<br />
;;<br />
setpw)<br />
shift<br />
username="$1"<br />
newpw="$2"<br />
serverid="$3"<br />
<br />
if [ "$serverid" == "" ]; then<br />
serverid="1"<br />
fi<br />
<br />
$bin $dbfile "update players set pw='$newpw' where name='$username';"<br />
exit<br />
;;<br />
setemail)<br />
shift<br />
username="$1"<br />
newemail="$2"<br />
serverid="$3"<br />
<br />
if [ "$serverid" == "" ]; then<br />
serverid="1"<br />
fi<br />
<br />
$bin $dbfile "update players set email='$newemail' where name='$username';"<br />
exit<br />
;;<br />
--help)<br />
help<br />
;;<br />
--version)<br />
version $version<br />
;;<br />
*)<br />
invalidoption $*<br />
break<br />
;;<br />
esac<br />
done<br />
<br />
invalidoption $*<br />
</pre></div>PatPeterhttps://wiki.mumble.info/index.php?title=Talk:ACL_and_Groups/English&diff=2153Talk:ACL and Groups/English2008-08-03T05:33:44Z<p>PatPeter: Talk:ACL and Groups moved to Talk:ACL and Groups/English</p>
<hr />
<div><br />
== The @sub group ==<br />
I'm having a hard time understanding the instructions given for the @sub group.<br />
Since the example given for [ACL_and_Groups#Group_of_servers_with_FPS_game|Group of servers with FPS game] is simple, I'll use that for my example why I'm confused.<br />
Am I supposed to rename the group from the default "~sub" to "~sub,2,2 allow enter, allow link", or "~sub,2,2" and then select allow for both Enter and Link permissions? What about the "+enter" and "+link" in the previous examples? I tried several things but I didn't see any results. Also what is the purpose of creating an empty group called "players" and then not creating an ACL for it?<br />
It should also be made more clear which rules are inherited and which ones aren't.<br />
It almost sounds as though this configuration isn't done through the ACL configuration in Mumble as I'm trying to do it, either that or it's an unusual way of explaining things. --[[User:Pilot 51|Pilot 51]] 08:21, 11 October 2007 (PDT)</div>PatPeterhttps://wiki.mumble.info/index.php?title=ACL_and_Groups/English&diff=2151ACL and Groups/English2008-08-03T05:33:43Z<p>PatPeter: ACL and Groups moved to ACL and Groups/English</p>
<hr />
<div>{{Languages|ACL and Groups}}<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 />
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 />
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>PatPeterhttps://wiki.mumble.info/index.php?title=ACL_and_Groups&diff=2152ACL and Groups2008-08-03T05:33:43Z<p>PatPeter: ACL and Groups moved to ACL and Groups/English: Subpage for template</p>
<hr />
<div>#redirect [[ACL and Groups/English]]</div>PatPeterhttps://wiki.mumble.info/index.php?title=ACL_and_Groups/English&diff=2150ACL and Groups/English2008-08-03T05:33:20Z<p>PatPeter: Pagename subst:</p>
<hr />
<div>{{Languages|ACL and Groups}}<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 />
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 />
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>PatPeterhttps://wiki.mumble.info/index.php?title=Template:Languages&diff=2149Template:Languages2008-08-03T05:32:28Z<p>PatPeter: English</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|English]] — [[{{{1}}}/Español|Español]] — [[{{{1}}}/Francais|Français]] — [[{{{1}}}/Italiano|Italiano]] — [[{{{1}}}/Deutsch|Deutsch]]<br />
</div><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|Name of page without language tag}}</nowiki><br />
<br />
=Example=<br />
Look at the ACL_and_Groups page. It is using the template right now.</noinclude></div>PatPeterhttps://wiki.mumble.info/index.php?title=ACL_Tutorial/Deutsch&diff=2148ACL Tutorial/Deutsch2008-08-03T05:32:04Z<p>PatPeter: Languages</p>
<hr />
<div>{{Languages|ACL Tutorial}}<br />
<br />
= Dieses Tutorial in anderen Sprachen =<br />
<br />
Dieses Tutorial ist verfügbar in folgenden Sprachen:<br><br />
[[ACL_tutorial_(English)|English]]&nbsp;&nbsp; [[ACL_tutorial_(Deutsch)|Deutsch]]&nbsp;&nbsp;<br />
<br />
=ACL Tutorial=<br />
<br />
Dieses Tutorial will euch helfen, zu verstehen wie die Rechteverwaltung in Mumble funktioniert. Details findet ihr in der [[ACL_FAQ_DEUTSCH|ACL FAQ]], hier sind einige Beispiele und Erklärungen von speziellen Gruppen etc.<br />
<br />
==Was wollen wir tun==<br />
Wir setzen einen Server auf, mit einem ''General chat'' Kanal wo jeder sprechen kann. Ebenso erstellen wir einen ''Custom channels'' Kanal wo jeder registrierte Benutzer seinen eigenen Kanal erstellen und administrieren kann. <br />
Dann, als normaler registrierter Benutzer wollen wir einige Kanäle für ein FPS Spiel erstellen, wo Leute zu ihrem Team oder zu jedem sprechen können, dazu muss dann nur eine Sprechtaste gedrückt werden.<br />
<br />
Genug geredet, lasst uns anfangen!<br />
<br />
==Rechte setzen für den gesamten Server==<br />
Zuerst brauchen wir ein Passwort für den SuperUser. Hat dieser noch kein Passwort, dann kannst Du ihm jetzt eines geben. Gib einfach an der Konsole bzw. am Befehlsprompt folgendes ein:<br />
murmur -ini /path/to/murmur.ini -supw meinganztollesgeheimespasswort<br />
<br />
Dann öffnen wir Mumble und verbinden uns mit dem Server. Login: SuperUser und das Passwort welches wir ihm gegeben haben. Dann schaut das in etwa so aus:<br />
<br />
http://img361.imageshack.us/img361/6586/mumbletut1dx8.png<br />
<br />
Lasst uns anfangen mit den Berechtigungen. Öffne den ACL Editor, Du kannst das mit einem Rechtsklick machen. Wenn geschehen, dann siehst Du ein Fenster mit zwei Tabs. Der erste dient der Gruppenadministration, wo man Benutzer Gruppen zuordnen kann, etc. Der zweite ordnet Berechtigungen den Gruppen zu.<br />
<br />
In eben jenem ACL Tab (wo die Berechtigungen den Gruppen zugeordnet werden) sollen zwei Regeln gesetzt werden:<br />
<br />
Die erste erlaubt registrierten Benutzern (allen in der @auth Gruppe), Kanäle im Root Channel zu erstellen sowie deren Unterkanäle.<br />
Die zweite erlaubt allen Benutzern in der @admin Gruppe, Berechtigungen zu schreiben / zu setzen.<br />
<br />
Jetzt erstmal löschen wir die Regel die mit der @auth Gruppe verbunden ist, indem wir diese selektieren und auf "Entfernen" klicken. Wir sagen, dass wir niemanden im Root Kanal (Allerersten Kanal) wollen. Wir wollen einen ''General Chat'' Kanal dafür. Wir fügen also eine Regel hinzu, um die User aus dem Root Kanal rauszuhalten. Um dies zu tun, klicke auf Hinzufügen und klick jede Checkbox in der Spalte "Ablehnen" an, ausser Traverse.<br />
<br />
Warum nicht Traverse anklicken:<br />
Ganz einfach, dies würde Leuten verbieten, den Root Kanal UND alle Unterkanäle zu betreten. Da jeder andere Kanal ein Unterkanal von ROOT ist, kann dann kein User irgendeinen Kanal betreten. Also lassen wir Traverse ohne Haken. Ihr müsst bei TRAVERSE nicht erlaubt anklicken, da TRAVERSE standardmässig erlaubt ist. Standardeinstellungen sind:<br />
*Erlaubt: TRAVERSE, BETRETEN, SPRECHEN und ALTERNATIV SPRECHEN<br />
*ABLEHNEN: SCHREIBEN, STUMM/TAUBSTELLEN, VERSCHIEBEN/KICK, CHANNEL ERSTELLEN und CHANNEL VERBINDEN.<br />
<br />
Falls Du dich wunderst, ja wir haben Schreiben, Stumm/Taubstellen, Verschieben/Kick, Channel erstellen und Channel verbinden nicht markiert und sie sind verboten. Man muss diese Rechte nicht auf ablehnen stellen, da diese per Standard abgelehnt sind (wenn wir diese nicht explizit erlauben). <br />
Jetzt schaut euer Bildschirm aus wie dieser hier (ausgenommen ihr habt einige nutzlose Checks deaktiviert):<br />
<br />
http://img361.imageshack.us/img361/9215/mumbletut2hw0.png<br />
<br />
Regeln werden in Mumble von oben nach unten ausgeführt. Das bedeutet, die <br />
@admins allow write<br />
Regel ist nutzlos, sie wird überschrieben durch die <br />
@all deny write ...<br />
Also müssen wir das reparieren. Wähle einfach die Regel welche @all regelt und klicke auf "Hoch". Das bringt diese Regel ganz nach oben. Du hast nun einige Standardeinstellungen für den gesamten Server etabliert.<br />
<br />
http://img363.imageshack.us/img363/3368/mumbletut3if8.png<br />
<br />
==Erstellung des ''General Chat'' Kanal und die Einstellung seiner Berechtigungen==<br />
Dieser Kanal soll als Chatraum für jeden der unseren Kanal betritt, zur Verfügung stehen. Solange wir ihnen nicht das sprechen im Root Kanal erlauben und sie müssen diesen Kanal ''General Chat'' betreten wenn sie chatten (sprechen) wollen, dann sollten wir eine Willkommensnachricht einrichten auf dem Server, die darauf hinweist. Ok weiter gehts.<br />
Zuerst erstelle den Kanal. Das ist ganz einfach, klick Channel->Add (oder Rechtsklick in den Channel den du möchtest, und klick Add um einen Unterkanal zu erstellen, aber du weisst, der Root Kanal wird nicht angezeigt, so benutzen wir das Menü). In der Box welche erscheint, gib den Kanal Name ''General Chat'' ein und klicke "Ok", das wars.<br />
<br />
Jetzt wollen wir jedem das Recht einräumen, in diesem Kanal zu sprechen. Also gehen wir zu "ACL editieren" (vergiss nicht, vorher den neuen Kanal auszuwählen). Du siehst die Regeln des Root Kanals im ''General Chat'' Kanal, aber wenn du diese anwählst, dann siehst du dass diese ausgegraut sind. Warum? Diese Regeln wurden vom übergeordneten Kanal (in diesem Fall dem ''Root Kanal'' vererbt.<br />
Wenn Du die Checkbox ACLs erben deaktivierst, dann verschwinden sie, aber wir wollen das nicht. Füge einfach nur eine neue Regel hinzu welche jedem (Gruppe = @all) erlaubt, den Raum zu betreten, zu sprechen oder AltSpeak zu nutzen und klicke "Ok" um das zu speichern. Wir sind fertig mit diesem Kanal. Einfach, oder nicht?<br />
<br />
http://img372.imageshack.us/img372/2854/mumbletut4wu0.png<br />
<br />
==Erstellen des ''Custom channels'' Kanal und dessen Konfiguration==<br />
<br />
So wie wir sagten, wir wollen jeden, der registriert ist, hier seine eigenen Kanäle erstellen lassen. Der erste Schritt ist einfach, erstelle den Kanal wie zuvor den anderen. Du solltest etwas in der Art wie hier gezeigt vor der Nase haben:<br />
<br />
http://img361.imageshack.us/img361/1720/mumbletut5qo2.png<br />
<br />
Nun wollen wir das Recht ''Channel erstellen'' jedem registrierten (@auth) Benutzer geben. Geh einfach in den ACL Editor für diesen Kanal (auswählen des Kanals nicht vergessen), füge eine neue Regel ein, in der Gruppenliste wähle oder schreibe auth und wähle die Channel Erstellen Checkbox in der Spalte Erlauben.<br />
'''Warnung:''' Wenn Du den Gruppennamen eingibst, stelle sicher dass Du "ENTER" drückst wenn du fertig bist mit dem eingeben. Das aktualisiert die Regelgruppe. Du kannst sehen, wenn Du kein "ENTER" drückst, dann wird in der Anzeige oben der Name der Gruppe nicht geändert (in unserem Fall in @auth, da steht dann immer noch @all).<br />
<br />
http://img356.imageshack.us/img356/7333/mumbletut6vl9.png http://img387.imageshack.us/img387/6638/mumbletut6bsq9.png<br />
<br />
Und nun haben wir einen hübschen Kanal wo Leute ihre eigenen Kanäle kreieren können. Beachte das sie den ''Custom Channels'' Kanal nicht betreten können. Aber sie können ihre Unterkanäle kreieren. Ist das nicht Cool?<br />
<br />
=Registrierte Benutzer=<br />
Hier wollen wir einen registrierten und authentifizierten Spieler spielen mit einem seeeeeehr originellen Namen: AuthedPlayer. Er möchte seine eigenen Kanäle kreieren, um ein paar öffentliche Kanäle und zwei private Unterkanäle anzubieten, einen für jedes Team eines FPS Spiels. Er möchte dass sie zu ihrem Team oder zu beiden Teams sprechen können. Wir schauen wie wir das mit AltSpeak machen können, Kanäle verbinden und mehr.<br />
<br />
==Erstellen des Hauptkanals==<br />
Nach dem Einloggen, spielen wir ein bisschen in Mumble um zu prüfen dass wir den Root Kanal nicht betreten können nachdem wir ihn verlassen haben (wenn du den Server das erste mal connectest, dann landest Du im Root Kanal), weiterhin auch um zu prüfen, dass wir den ''Custom channels'' Kanal nicht betreten können, etc. Wenn wir uns überzeugt haben, dass dies funktioniert wie wir es uns vorgestellt haben, erstellen wir unseren ersten Kanal. Einfach Rechtsklick in ''Custom channels'' (Vergiss nicht, du kannst auch das Menü verwenden, nachdem der Kanal markiert wurde) und klicke "Hinzufügen", um einen neuen Kanal unter ''Custom channels'' zu erstellen. Da ich (Javitonino) sehr kreativ bin, nenne ich ihn ''My Private Channel''. Wir wurden in diesem Kanal automatisch der @admin Gruppe hinzugefügt, so können wir auf ihm schreiben (die ACLs) (Vergiss nicht die Regeln im ''Root Kanal?''Sie sind vererbt komplett runter bis in unseren Kanal). Aber das bedeutet auch, das wir das ''Channel erstellen'' Recht vererbt bekommen haben, so kann jeder registrierte Benutzer in UNSEREM Kanal Kanäle erstellen. Das wollen wir so nicht haben.<br />
<br />
http://img400.imageshack.us/img400/2249/mumbletut7dw7.png<br />
<br />
Unsere Regel überschreibt die vererbte, weil vererbte Regeln oben stehen (werden durch darunter folgende Regeln überschrieben). So wenn wir UNSEREN Kanal gesichert haben, dann geben wir die Erlaubnis, diesen zu betreten und darin zu sprechen:<br />
<br />
http://img387.imageshack.us/img387/2315/mumbletut8lu5.png<br />
<br />
Beachte, dass wir ''Betrifft Unterkanäle'' deaktiviert haben. Genauso wie Unterkanäle nicht öffentlich sind, wollen wir auch nicht dass diese das ''Betreten'' Recht gewähren. Wenn wir diese Option nicht deaktiviert haben, dann müssen wir eine andere Regel erstellen um das ''Betreten'' Recht abzulehnen. Dies ist der einfachere Weg. Und nun haben wir diesen Kanal bereit. Lasst uns mit den Unterkanälen fortfahren.<br />
<br />
==Erstellen der Team Unterkanäle==<br />
Erst erstellen wir zwei Unterkanäle unseres eigenen Kanals. Weil nützlich, benenne ich sie sehr kreativ .... Team1 und Team2. Wir können Regel definieren für jeden der beiden, aber es ist schneller, diese im übergeordneten Kanal (My Private Channel) zu definieren und lassen die Unterkanäle diese Regeln erben. Erst wollen wir, das die Leute in einem Teamkanal auch reden können, also machen wir das so wie hier:<br />
<br />
http://img452.imageshack.us/img452/2127/mumbletut9ix7.png<br />
<br />
Beachte, dass wir ''Betrifft diesen Kanal'' demarkiert haben, weil wir die Regel NUR für die Unterkanäle definieren. Interessanter ist die Nutzung der speziellen Gruppe ''in''. Diese Gruppe umfasst die Leute welche sich IN dem Kanal befinden, auf den sich die Regel bezieht. Es schaut so aus, als ob das dasselbe ist wie @all aber es ist recht unterschiedlich:<br />
<br />
Wir verbinden beide Kanäle. Das bedeutet, dass Leute in verschiedenen Kanälen jeden im anderen verbundenen Kanal hört. Aber wir wollen, dass Leute nur ihre Teamkollegen hören können. So benutzen wir ''in'' um das Recht ''Sprechen'' den Leuten im selben Kanal zu geben. Das bedeutet, dass Leute in Team2 nicht die Leute in Team1 hören können, weil die Leute in Team1 nicht das Sprachrecht in Team2 haben weil die ''in'' Gruppe ihnen die Rechte nur im eigenen Kanal gibt. Am Anfang ist es ein bisschen kompliziert, das zu verstehen, aber es ist sehr nützlich. Um es zu verstehen, verstehe erst, dass jeder Kanal seine eigenen ''in''-Gruppen hat. Das bedeutet dass die ''in'' Gruppe in Team1 nicht dieselbe ist wie die ''in'' Gruppe in Team2.<br />
<br />
Um das besser zu erklären benutze ich einige Namen...<br />
*Jack ist in Team1<br />
*John ist in Team2<br />
Beide Kanäle sind verbunden, so dass die Stimme von einem Kanal in den anderen übertragen wird so die Sprecher im Zielkanal (wo die Stimme hinübertragen wird) Sprachrechte haben. Jack spricht aber John hört ihn nicht, weil Jack kein Recht hat, in Team2 zu sprechen da er nicht in Team2's ''in'' Gruppe ist. So wird seine Stimme nicht über den Kanallink übertragen und John hört Jack nicht. <br />
Hätten wir ''all'' anstelle von ''in'' für die Regel benutzt, dann würden Jack und John sich gegenseitig ohne Probleme hören, weil beide in der ''@all'' Gruppe sind.<br />
<br />
Ok lasst uns weitermachen. Wir wollen, dass die Leute zum anderen Team sprechen können. Da ist dann AltSpeak praktisch.<br />
Wir fügen eine Regel ein wie diese:<br />
<br />
http://img359.imageshack.us/img359/7660/mumbletut10sq9.png<br />
<br />
Dies erlaubt jedem (beiden Teams) zum jeweils anderen Team zu sprechen wenn AltSpeak gedrückt wird. AltSpeak wird aktiviert solange eine Taste gedrückt wird, welche in den Shortcuts definiert wurde (In Mumble Konfiguration->Einstellungen->Shortcuts). Solange wir diese Taste drücken, wird die Stimme durch die AltSpeak Rechte übertragen. Wenn wir jedem das Recht ''AltSpeak'' erlaubt haben und beide Kanäle sind verbunden bedeutet das, dass wenn jemand spricht solang er diese Taste drückt, wird er von beiden Teams gehört.<br />
<br />
Und wir sind fertig ;-)<br />
<br />
==Wie schaut es aus für unregistrierte Spieler==<br />
Erst lädst du sie in deine Teamkanäle ein (Du kannst sie von deinem öffentlichen Kanal in deinen Teamkanal ziehen mittels drag-and-drop). Sie müssen dazu in Deinem öffentlichen Kanal sein, da du das ''Move/Kick'' Recht in beiden, dem Original und Zielkanal brauchst. Wenn kein AltSpeaking...<br />
<br />
http://img361.imageshack.us/img361/3603/mumbletut11zg8.png http://img358.imageshack.us/img358/6740/mumbletut11bkf8.png<br />
<br />
Wenn AltSpeaking:<br />
<br />
http://img361.imageshack.us/img361/5271/mumbletut12ef3.png http://img462.imageshack.us/img462/8103/mumbletut12bko1.png<br />
<br />
=Abschliessende Erklärungen=<br />
Dies ist ein Schnelltutorial und ich habe einiges nicht erklärt. Zum Beispiel ''Benutzerdefinierte Gruppen''. Sie sind einfach zu erklären aber hier eine Schnellerklärung:<br />
<br />
*Du definierst Rechte für diese Gruppe ganz simpel, schreibe den gewünschten Gruppennamen (z.B. ''Freunde'') in die Gruppenbox (Vergiss nicht, ENTER ist Dein Freund;)) und markiere die entsprechenden Checkboxen.<br />
*Um eine Person dieser Gruppe hinzuzufügen, gehe zum unteren Button Hinzufügen im ACL Editor, wähle den Gruppenname in der Gruppenbox (oder schreibe die Gruppe rein + ENTER), dann schreib den Namen den Du in der Box haben möchtest unten an der ''Hinzufügen'' Liste und drücke den zugehörigen "Hinzufügen" Knopf. Du kannst nur registrierte Nicknamen der Liste hinzufügen.<br />
Gruppen sind pro Kanal und vererbar. Wenn du einige Gruppenmitglieder beerben möchtest, dann kannst du "vererben" markieren und die Mitglieder welche du in der Gruppe nicht haben möchtest, in die ''Entfernen'' Liste aufnehmen (da ist ein Knopf am Ende der Vererbungsliste um es einfach zu machen).<br />
Ich hab also noch einige Möglichkeiten übrig vor der Benutzung der ''@sub'' Gruppe. Mehr Infos darüber in [[ACL_FAQ_DEUTSCH|ACL und Gruppen]]<br />
<br />
Es gibt viele Regeln welche einfacher gemacht werden könnten. Als Beispiel, im letzten Abschnitt des Tutorials, du kannst das ''Ablehnen Channel erstellen'' und das ''Erlauben AltSpeak'' in der selben Regel festmachen und das für beide Kanäle und Unterkanäle. Das hier ist nur ein Beispiel was man machen kann, ohne zu sehr in die Tiefe zu gehen, fühl Dich frei deine eigenen unmöglich zu verstehenden Entwürfe zu kreieren und füge sie der Beispielsektion in [[ACL_FAQ_DEUTSCH|ACL und Gruppen]] dazu.<br />
<br />
=Anmerkung von Xanadu Jürgen CB-Radio 13 TSDX 001=<br />
<br />
Dieses Tutorial ist die deutsche Übersetzung des Tutorials von SF.net User Javitonino. Das Originaltutorial in Englisch findet ihr, wenn ihr [[ACL_tutorial|hier klickt]].<br />
Javitonino hat ein super Tut hier auf die Beine gestellt und dafür ein herzliches Dankeschön. Jetzt kapier ich endlich auch mal vernünftig, wie das mit den ACL funktioniert. Ich habe festgestellt dass die ACL in Mumble mächtig sind, mächtiger als bei vergleichbaren VoIP Programmen.<br />
<br />
Mit freundlichen Grüssen<br />
<br />
Jürgen aKa Xanadu... ach guggt einfach letzte Zeile ;-) ich denk da stehen alle Nicks, QRA etc. komplett *fg*<br />
<br />
This Tutorial is the German Translation of the ACL Tutorial made by SF.net User Javitonino. The Original Tutorial in English Language you can find, if you [[ACL_tutorial|click here]].<br />
Javitonino have do a very good Tut here and for that a big Thank you out of my heart ;-). Now i check out in a good way, how ACL will and can work for me. I have noticed, that Mumble ACL is very mighty, mightier than the ACL of other VoIP Programs.<br />
<br />
Ok best Regards<br />
<br />
Jürgen aKa Xanadu aKa BarefeetXanadu aKa 13 TSDX 001 ok i think i have my Nicks QRA etc. now complete ;-)</div>PatPeterhttps://wiki.mumble.info/index.php?title=ACL_Tutorial/Deutsch&diff=2146ACL Tutorial/Deutsch2008-08-03T05:31:24Z<p>PatPeter: ACL tutorial (Deutsch) moved to ACL Tutorial/Deutsch</p>
<hr />
<div>= Dieses Tutorial in anderen Sprachen =<br />
<br />
Dieses Tutorial ist verfügbar in folgenden Sprachen:<br><br />
[[ACL_tutorial_(English)|English]]&nbsp;&nbsp; [[ACL_tutorial_(Deutsch)|Deutsch]]&nbsp;&nbsp;<br />
<br />
=ACL Tutorial=<br />
<br />
Dieses Tutorial will euch helfen, zu verstehen wie die Rechteverwaltung in Mumble funktioniert. Details findet ihr in der [[ACL_FAQ_DEUTSCH|ACL FAQ]], hier sind einige Beispiele und Erklärungen von speziellen Gruppen etc.<br />
<br />
==Was wollen wir tun==<br />
Wir setzen einen Server auf, mit einem ''General chat'' Kanal wo jeder sprechen kann. Ebenso erstellen wir einen ''Custom channels'' Kanal wo jeder registrierte Benutzer seinen eigenen Kanal erstellen und administrieren kann. <br />
Dann, als normaler registrierter Benutzer wollen wir einige Kanäle für ein FPS Spiel erstellen, wo Leute zu ihrem Team oder zu jedem sprechen können, dazu muss dann nur eine Sprechtaste gedrückt werden.<br />
<br />
Genug geredet, lasst uns anfangen!<br />
<br />
==Rechte setzen für den gesamten Server==<br />
Zuerst brauchen wir ein Passwort für den SuperUser. Hat dieser noch kein Passwort, dann kannst Du ihm jetzt eines geben. Gib einfach an der Konsole bzw. am Befehlsprompt folgendes ein:<br />
murmur -ini /path/to/murmur.ini -supw meinganztollesgeheimespasswort<br />
<br />
Dann öffnen wir Mumble und verbinden uns mit dem Server. Login: SuperUser und das Passwort welches wir ihm gegeben haben. Dann schaut das in etwa so aus:<br />
<br />
http://img361.imageshack.us/img361/6586/mumbletut1dx8.png<br />
<br />
Lasst uns anfangen mit den Berechtigungen. Öffne den ACL Editor, Du kannst das mit einem Rechtsklick machen. Wenn geschehen, dann siehst Du ein Fenster mit zwei Tabs. Der erste dient der Gruppenadministration, wo man Benutzer Gruppen zuordnen kann, etc. Der zweite ordnet Berechtigungen den Gruppen zu.<br />
<br />
In eben jenem ACL Tab (wo die Berechtigungen den Gruppen zugeordnet werden) sollen zwei Regeln gesetzt werden:<br />
<br />
Die erste erlaubt registrierten Benutzern (allen in der @auth Gruppe), Kanäle im Root Channel zu erstellen sowie deren Unterkanäle.<br />
Die zweite erlaubt allen Benutzern in der @admin Gruppe, Berechtigungen zu schreiben / zu setzen.<br />
<br />
Jetzt erstmal löschen wir die Regel die mit der @auth Gruppe verbunden ist, indem wir diese selektieren und auf "Entfernen" klicken. Wir sagen, dass wir niemanden im Root Kanal (Allerersten Kanal) wollen. Wir wollen einen ''General Chat'' Kanal dafür. Wir fügen also eine Regel hinzu, um die User aus dem Root Kanal rauszuhalten. Um dies zu tun, klicke auf Hinzufügen und klick jede Checkbox in der Spalte "Ablehnen" an, ausser Traverse.<br />
<br />
Warum nicht Traverse anklicken:<br />
Ganz einfach, dies würde Leuten verbieten, den Root Kanal UND alle Unterkanäle zu betreten. Da jeder andere Kanal ein Unterkanal von ROOT ist, kann dann kein User irgendeinen Kanal betreten. Also lassen wir Traverse ohne Haken. Ihr müsst bei TRAVERSE nicht erlaubt anklicken, da TRAVERSE standardmässig erlaubt ist. Standardeinstellungen sind:<br />
*Erlaubt: TRAVERSE, BETRETEN, SPRECHEN und ALTERNATIV SPRECHEN<br />
*ABLEHNEN: SCHREIBEN, STUMM/TAUBSTELLEN, VERSCHIEBEN/KICK, CHANNEL ERSTELLEN und CHANNEL VERBINDEN.<br />
<br />
Falls Du dich wunderst, ja wir haben Schreiben, Stumm/Taubstellen, Verschieben/Kick, Channel erstellen und Channel verbinden nicht markiert und sie sind verboten. Man muss diese Rechte nicht auf ablehnen stellen, da diese per Standard abgelehnt sind (wenn wir diese nicht explizit erlauben). <br />
Jetzt schaut euer Bildschirm aus wie dieser hier (ausgenommen ihr habt einige nutzlose Checks deaktiviert):<br />
<br />
http://img361.imageshack.us/img361/9215/mumbletut2hw0.png<br />
<br />
Regeln werden in Mumble von oben nach unten ausgeführt. Das bedeutet, die <br />
@admins allow write<br />
Regel ist nutzlos, sie wird überschrieben durch die <br />
@all deny write ...<br />
Also müssen wir das reparieren. Wähle einfach die Regel welche @all regelt und klicke auf "Hoch". Das bringt diese Regel ganz nach oben. Du hast nun einige Standardeinstellungen für den gesamten Server etabliert.<br />
<br />
http://img363.imageshack.us/img363/3368/mumbletut3if8.png<br />
<br />
==Erstellung des ''General Chat'' Kanal und die Einstellung seiner Berechtigungen==<br />
Dieser Kanal soll als Chatraum für jeden der unseren Kanal betritt, zur Verfügung stehen. Solange wir ihnen nicht das sprechen im Root Kanal erlauben und sie müssen diesen Kanal ''General Chat'' betreten wenn sie chatten (sprechen) wollen, dann sollten wir eine Willkommensnachricht einrichten auf dem Server, die darauf hinweist. Ok weiter gehts.<br />
Zuerst erstelle den Kanal. Das ist ganz einfach, klick Channel->Add (oder Rechtsklick in den Channel den du möchtest, und klick Add um einen Unterkanal zu erstellen, aber du weisst, der Root Kanal wird nicht angezeigt, so benutzen wir das Menü). In der Box welche erscheint, gib den Kanal Name ''General Chat'' ein und klicke "Ok", das wars.<br />
<br />
Jetzt wollen wir jedem das Recht einräumen, in diesem Kanal zu sprechen. Also gehen wir zu "ACL editieren" (vergiss nicht, vorher den neuen Kanal auszuwählen). Du siehst die Regeln des Root Kanals im ''General Chat'' Kanal, aber wenn du diese anwählst, dann siehst du dass diese ausgegraut sind. Warum? Diese Regeln wurden vom übergeordneten Kanal (in diesem Fall dem ''Root Kanal'' vererbt.<br />
Wenn Du die Checkbox ACLs erben deaktivierst, dann verschwinden sie, aber wir wollen das nicht. Füge einfach nur eine neue Regel hinzu welche jedem (Gruppe = @all) erlaubt, den Raum zu betreten, zu sprechen oder AltSpeak zu nutzen und klicke "Ok" um das zu speichern. Wir sind fertig mit diesem Kanal. Einfach, oder nicht?<br />
<br />
http://img372.imageshack.us/img372/2854/mumbletut4wu0.png<br />
<br />
==Erstellen des ''Custom channels'' Kanal und dessen Konfiguration==<br />
<br />
So wie wir sagten, wir wollen jeden, der registriert ist, hier seine eigenen Kanäle erstellen lassen. Der erste Schritt ist einfach, erstelle den Kanal wie zuvor den anderen. Du solltest etwas in der Art wie hier gezeigt vor der Nase haben:<br />
<br />
http://img361.imageshack.us/img361/1720/mumbletut5qo2.png<br />
<br />
Nun wollen wir das Recht ''Channel erstellen'' jedem registrierten (@auth) Benutzer geben. Geh einfach in den ACL Editor für diesen Kanal (auswählen des Kanals nicht vergessen), füge eine neue Regel ein, in der Gruppenliste wähle oder schreibe auth und wähle die Channel Erstellen Checkbox in der Spalte Erlauben.<br />
'''Warnung:''' Wenn Du den Gruppennamen eingibst, stelle sicher dass Du "ENTER" drückst wenn du fertig bist mit dem eingeben. Das aktualisiert die Regelgruppe. Du kannst sehen, wenn Du kein "ENTER" drückst, dann wird in der Anzeige oben der Name der Gruppe nicht geändert (in unserem Fall in @auth, da steht dann immer noch @all).<br />
<br />
http://img356.imageshack.us/img356/7333/mumbletut6vl9.png http://img387.imageshack.us/img387/6638/mumbletut6bsq9.png<br />
<br />
Und nun haben wir einen hübschen Kanal wo Leute ihre eigenen Kanäle kreieren können. Beachte das sie den ''Custom Channels'' Kanal nicht betreten können. Aber sie können ihre Unterkanäle kreieren. Ist das nicht Cool?<br />
<br />
=Registrierte Benutzer=<br />
Hier wollen wir einen registrierten und authentifizierten Spieler spielen mit einem seeeeeehr originellen Namen: AuthedPlayer. Er möchte seine eigenen Kanäle kreieren, um ein paar öffentliche Kanäle und zwei private Unterkanäle anzubieten, einen für jedes Team eines FPS Spiels. Er möchte dass sie zu ihrem Team oder zu beiden Teams sprechen können. Wir schauen wie wir das mit AltSpeak machen können, Kanäle verbinden und mehr.<br />
<br />
==Erstellen des Hauptkanals==<br />
Nach dem Einloggen, spielen wir ein bisschen in Mumble um zu prüfen dass wir den Root Kanal nicht betreten können nachdem wir ihn verlassen haben (wenn du den Server das erste mal connectest, dann landest Du im Root Kanal), weiterhin auch um zu prüfen, dass wir den ''Custom channels'' Kanal nicht betreten können, etc. Wenn wir uns überzeugt haben, dass dies funktioniert wie wir es uns vorgestellt haben, erstellen wir unseren ersten Kanal. Einfach Rechtsklick in ''Custom channels'' (Vergiss nicht, du kannst auch das Menü verwenden, nachdem der Kanal markiert wurde) und klicke "Hinzufügen", um einen neuen Kanal unter ''Custom channels'' zu erstellen. Da ich (Javitonino) sehr kreativ bin, nenne ich ihn ''My Private Channel''. Wir wurden in diesem Kanal automatisch der @admin Gruppe hinzugefügt, so können wir auf ihm schreiben (die ACLs) (Vergiss nicht die Regeln im ''Root Kanal?''Sie sind vererbt komplett runter bis in unseren Kanal). Aber das bedeutet auch, das wir das ''Channel erstellen'' Recht vererbt bekommen haben, so kann jeder registrierte Benutzer in UNSEREM Kanal Kanäle erstellen. Das wollen wir so nicht haben.<br />
<br />
http://img400.imageshack.us/img400/2249/mumbletut7dw7.png<br />
<br />
Unsere Regel überschreibt die vererbte, weil vererbte Regeln oben stehen (werden durch darunter folgende Regeln überschrieben). So wenn wir UNSEREN Kanal gesichert haben, dann geben wir die Erlaubnis, diesen zu betreten und darin zu sprechen:<br />
<br />
http://img387.imageshack.us/img387/2315/mumbletut8lu5.png<br />
<br />
Beachte, dass wir ''Betrifft Unterkanäle'' deaktiviert haben. Genauso wie Unterkanäle nicht öffentlich sind, wollen wir auch nicht dass diese das ''Betreten'' Recht gewähren. Wenn wir diese Option nicht deaktiviert haben, dann müssen wir eine andere Regel erstellen um das ''Betreten'' Recht abzulehnen. Dies ist der einfachere Weg. Und nun haben wir diesen Kanal bereit. Lasst uns mit den Unterkanälen fortfahren.<br />
<br />
==Erstellen der Team Unterkanäle==<br />
Erst erstellen wir zwei Unterkanäle unseres eigenen Kanals. Weil nützlich, benenne ich sie sehr kreativ .... Team1 und Team2. Wir können Regel definieren für jeden der beiden, aber es ist schneller, diese im übergeordneten Kanal (My Private Channel) zu definieren und lassen die Unterkanäle diese Regeln erben. Erst wollen wir, das die Leute in einem Teamkanal auch reden können, also machen wir das so wie hier:<br />
<br />
http://img452.imageshack.us/img452/2127/mumbletut9ix7.png<br />
<br />
Beachte, dass wir ''Betrifft diesen Kanal'' demarkiert haben, weil wir die Regel NUR für die Unterkanäle definieren. Interessanter ist die Nutzung der speziellen Gruppe ''in''. Diese Gruppe umfasst die Leute welche sich IN dem Kanal befinden, auf den sich die Regel bezieht. Es schaut so aus, als ob das dasselbe ist wie @all aber es ist recht unterschiedlich:<br />
<br />
Wir verbinden beide Kanäle. Das bedeutet, dass Leute in verschiedenen Kanälen jeden im anderen verbundenen Kanal hört. Aber wir wollen, dass Leute nur ihre Teamkollegen hören können. So benutzen wir ''in'' um das Recht ''Sprechen'' den Leuten im selben Kanal zu geben. Das bedeutet, dass Leute in Team2 nicht die Leute in Team1 hören können, weil die Leute in Team1 nicht das Sprachrecht in Team2 haben weil die ''in'' Gruppe ihnen die Rechte nur im eigenen Kanal gibt. Am Anfang ist es ein bisschen kompliziert, das zu verstehen, aber es ist sehr nützlich. Um es zu verstehen, verstehe erst, dass jeder Kanal seine eigenen ''in''-Gruppen hat. Das bedeutet dass die ''in'' Gruppe in Team1 nicht dieselbe ist wie die ''in'' Gruppe in Team2.<br />
<br />
Um das besser zu erklären benutze ich einige Namen...<br />
*Jack ist in Team1<br />
*John ist in Team2<br />
Beide Kanäle sind verbunden, so dass die Stimme von einem Kanal in den anderen übertragen wird so die Sprecher im Zielkanal (wo die Stimme hinübertragen wird) Sprachrechte haben. Jack spricht aber John hört ihn nicht, weil Jack kein Recht hat, in Team2 zu sprechen da er nicht in Team2's ''in'' Gruppe ist. So wird seine Stimme nicht über den Kanallink übertragen und John hört Jack nicht. <br />
Hätten wir ''all'' anstelle von ''in'' für die Regel benutzt, dann würden Jack und John sich gegenseitig ohne Probleme hören, weil beide in der ''@all'' Gruppe sind.<br />
<br />
Ok lasst uns weitermachen. Wir wollen, dass die Leute zum anderen Team sprechen können. Da ist dann AltSpeak praktisch.<br />
Wir fügen eine Regel ein wie diese:<br />
<br />
http://img359.imageshack.us/img359/7660/mumbletut10sq9.png<br />
<br />
Dies erlaubt jedem (beiden Teams) zum jeweils anderen Team zu sprechen wenn AltSpeak gedrückt wird. AltSpeak wird aktiviert solange eine Taste gedrückt wird, welche in den Shortcuts definiert wurde (In Mumble Konfiguration->Einstellungen->Shortcuts). Solange wir diese Taste drücken, wird die Stimme durch die AltSpeak Rechte übertragen. Wenn wir jedem das Recht ''AltSpeak'' erlaubt haben und beide Kanäle sind verbunden bedeutet das, dass wenn jemand spricht solang er diese Taste drückt, wird er von beiden Teams gehört.<br />
<br />
Und wir sind fertig ;-)<br />
<br />
==Wie schaut es aus für unregistrierte Spieler==<br />
Erst lädst du sie in deine Teamkanäle ein (Du kannst sie von deinem öffentlichen Kanal in deinen Teamkanal ziehen mittels drag-and-drop). Sie müssen dazu in Deinem öffentlichen Kanal sein, da du das ''Move/Kick'' Recht in beiden, dem Original und Zielkanal brauchst. Wenn kein AltSpeaking...<br />
<br />
http://img361.imageshack.us/img361/3603/mumbletut11zg8.png http://img358.imageshack.us/img358/6740/mumbletut11bkf8.png<br />
<br />
Wenn AltSpeaking:<br />
<br />
http://img361.imageshack.us/img361/5271/mumbletut12ef3.png http://img462.imageshack.us/img462/8103/mumbletut12bko1.png<br />
<br />
=Abschliessende Erklärungen=<br />
Dies ist ein Schnelltutorial und ich habe einiges nicht erklärt. Zum Beispiel ''Benutzerdefinierte Gruppen''. Sie sind einfach zu erklären aber hier eine Schnellerklärung:<br />
<br />
*Du definierst Rechte für diese Gruppe ganz simpel, schreibe den gewünschten Gruppennamen (z.B. ''Freunde'') in die Gruppenbox (Vergiss nicht, ENTER ist Dein Freund;)) und markiere die entsprechenden Checkboxen.<br />
*Um eine Person dieser Gruppe hinzuzufügen, gehe zum unteren Button Hinzufügen im ACL Editor, wähle den Gruppenname in der Gruppenbox (oder schreibe die Gruppe rein + ENTER), dann schreib den Namen den Du in der Box haben möchtest unten an der ''Hinzufügen'' Liste und drücke den zugehörigen "Hinzufügen" Knopf. Du kannst nur registrierte Nicknamen der Liste hinzufügen.<br />
Gruppen sind pro Kanal und vererbar. Wenn du einige Gruppenmitglieder beerben möchtest, dann kannst du "vererben" markieren und die Mitglieder welche du in der Gruppe nicht haben möchtest, in die ''Entfernen'' Liste aufnehmen (da ist ein Knopf am Ende der Vererbungsliste um es einfach zu machen).<br />
Ich hab also noch einige Möglichkeiten übrig vor der Benutzung der ''@sub'' Gruppe. Mehr Infos darüber in [[ACL_FAQ_DEUTSCH|ACL und Gruppen]]<br />
<br />
Es gibt viele Regeln welche einfacher gemacht werden könnten. Als Beispiel, im letzten Abschnitt des Tutorials, du kannst das ''Ablehnen Channel erstellen'' und das ''Erlauben AltSpeak'' in der selben Regel festmachen und das für beide Kanäle und Unterkanäle. Das hier ist nur ein Beispiel was man machen kann, ohne zu sehr in die Tiefe zu gehen, fühl Dich frei deine eigenen unmöglich zu verstehenden Entwürfe zu kreieren und füge sie der Beispielsektion in [[ACL_FAQ_DEUTSCH|ACL und Gruppen]] dazu.<br />
<br />
=Anmerkung von Xanadu Jürgen CB-Radio 13 TSDX 001=<br />
<br />
Dieses Tutorial ist die deutsche Übersetzung des Tutorials von SF.net User Javitonino. Das Originaltutorial in Englisch findet ihr, wenn ihr [[ACL_tutorial|hier klickt]].<br />
Javitonino hat ein super Tut hier auf die Beine gestellt und dafür ein herzliches Dankeschön. Jetzt kapier ich endlich auch mal vernünftig, wie das mit den ACL funktioniert. Ich habe festgestellt dass die ACL in Mumble mächtig sind, mächtiger als bei vergleichbaren VoIP Programmen.<br />
<br />
Mit freundlichen Grüssen<br />
<br />
Jürgen aKa Xanadu... ach guggt einfach letzte Zeile ;-) ich denk da stehen alle Nicks, QRA etc. komplett *fg*<br />
<br />
This Tutorial is the German Translation of the ACL Tutorial made by SF.net User Javitonino. The Original Tutorial in English Language you can find, if you [[ACL_tutorial|click here]].<br />
Javitonino have do a very good Tut here and for that a big Thank you out of my heart ;-). Now i check out in a good way, how ACL will and can work for me. I have noticed, that Mumble ACL is very mighty, mightier than the ACL of other VoIP Programs.<br />
<br />
Ok best Regards<br />
<br />
Jürgen aKa Xanadu aKa BarefeetXanadu aKa 13 TSDX 001 ok i think i have my Nicks QRA etc. now complete ;-)</div>PatPeterhttps://wiki.mumble.info/index.php?title=ACL_Tutorial/English&diff=2145ACL Tutorial/English2008-08-03T05:30:44Z<p>PatPeter: Typo</p>
<hr />
<div>{{Languages|ACL Tutorial}}<br />
<br />
= This Document in other Languages =<br />
<br />
This Document is available in following Languages:<br><br />
[[ACL_tutorial_(English)|English]]&nbsp;&nbsp; [[ACL_tutorial_(Deutsch)|Deutsch]]<br />
<br />
<br />
=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 -ini /path/to/murmur.ini -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 this by selecting "Edit ACL" from the Channel menu. Once we are there, you can see a window with two tabs. The first one is for defining people who are 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>PatPeterhttps://wiki.mumble.info/index.php?title=ACL_Tutorial/English&diff=2144ACL Tutorial/English2008-08-03T05:30:31Z<p>PatPeter: Template</p>
<hr />
<div>{{Langauges|ACL Tutorial}}<br />
<br />
= This Document in other Languages =<br />
<br />
This Document is available in following Languages:<br><br />
[[ACL_tutorial_(English)|English]]&nbsp;&nbsp; [[ACL_tutorial_(Deutsch)|Deutsch]]<br />
<br />
<br />
=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 -ini /path/to/murmur.ini -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 this by selecting "Edit ACL" from the Channel menu. Once we are there, you can see a window with two tabs. The first one is for defining people who are 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>PatPeterhttps://wiki.mumble.info/index.php?title=ACL_Tutorial/English&diff=2142ACL Tutorial/English2008-08-03T05:29:20Z<p>PatPeter: ACL tutorial (English) moved to ACL Tutorial/English</p>
<hr />
<div>= This Document in other Languages =<br />
<br />
This Document is available in following Languages:<br><br />
[[ACL_tutorial_(English)|English]]&nbsp;&nbsp; [[ACL_tutorial_(Deutsch)|Deutsch]]<br />
<br />
<br />
=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 -ini /path/to/murmur.ini -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 this by selecting "Edit ACL" from the Channel menu. Once we are there, you can see a window with two tabs. The first one is for defining people who are 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>PatPeterhttps://wiki.mumble.info/index.php?title=ACL_and_Groups/English&diff=2141ACL and Groups/English2008-08-03T05:03:52Z<p>PatPeter: Section no longer necessary</p>
<hr />
<div>{{Languages|{{PAGENAME}}}}<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>PatPeterhttps://wiki.mumble.info/index.php?title=ACL_and_Groups/Italiano&diff=2140ACL and Groups/Italiano2008-08-03T05:03:24Z<p>PatPeter: Template</p>
<hr />
<div>{{Languages|ACL and Groups}}<br />
<br />
== Chi desiderano tradurli ==</div>PatPeterhttps://wiki.mumble.info/index.php?title=ACL_and_Groups/Italiano&diff=2138ACL and Groups/Italiano2008-08-03T05:02:56Z<p>PatPeter: ACL FAQ (Italiano) moved to ACL and Groups/Italiano</p>
<hr />
<div>= Chi desiderano tradurli =</div>PatPeterhttps://wiki.mumble.info/index.php?title=Template:Languages&diff=2137Template:Languages2008-08-03T05:01:14Z<p>PatPeter: Fix</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}}}/Español|Español]] — [[{{{1}}}/Francais|Français]] — [[{{{1}}}/Italiano|Italiano]] — [[{{{1}}}/Deutsch|Deutsch]]<br />
</div><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|Name of page without language tag}}</nowiki><br />
<br />
=Example=<br />
Look at the ACL_and_Groups page. It is using the template right now.</noinclude></div>PatPeterhttps://wiki.mumble.info/index.php?title=ACL_and_Groups/Francais&diff=2136ACL and Groups/Francais2008-08-03T04:59:19Z<p>PatPeter: Languages</p>
<hr />
<div>{{Languages|ACL and Groups}}<br />
<br />
= Tutorial =<br />
<br />
Vous pouvez trouver un tutorial illustré et un guide rapide sur Comment administrer les groupes et les permissions: [[ACL tutorial_(French)|ACL Tutorial]] pour la version francaise qui n'existe pas pour le moment.<br />
Sinon il y a toujours la version Anglaise de disponible ici ===> [[ACL tutorial_(English)|ACL Tutorial]]<br />
<br />
= Les Groupes =<br />
<br />
Les groupes sont liés à un canal spécifique, mais vous pouvez aussi les faire hériter a des sous canaux. Les groupes sont des façons commodes d'administrer des canaux, de definir les ACLs tout en haut de l'arborescence "that should have similar privilege structure, and just change the group memberships on subchannels."<br />
<br />
<br />
Pour chaque canal, un groupe a 3 parties specifiques qui sont:<br />
<br />
- La liste des joueurs pour ajouter au groupe.<br />
- La liste des joueurs héritée du meme groupe sur le canal parent.<br />
- Et pour terminer, la liste des joueurs pour enlever du groupe.<br />
<br />
Un groupe héritera seulement des joueurs du canal parent si seulement l'heritage est activé et que le groupe a été marque comme pouvant hériter du parent. La plupart du temps, vous "want both of these to be set."<br />
<br />
= Exemple =<br />
<br />
Regardez cet exemple pratique; sur le groupe admin. A chaque fois qu'un joueur crée un canal, il est automatiquement ajouté au groupe des admins. Cela ne lui donne pas automaniquement des privileges, il est juste marqué comme membre de ce groupe, cependant l'installation par défaut de Murmur installe une ACL qui donne au groupe admin le bit d'écriture (Tous les accès).<br />
<br />
Dans une structure comme celle-ci:<br />
<br />
* Root<br />
o A<br />
+ B <br />
o C<br />
+ D <br />
<br />
<br />
En Root, le joueur "Big Boss" est tout seul dans le groupe administrateur. Dans le canal A "BossA" est dans la Addlist, et "BossB" est dans le meme canal B.<br />
Depuis que le groupe admin est herité et génétique, Un joueur qui est un membre à n'importe quel parent du canal actuel est aussi un membre dans le canal actuel.<br />
Donc la liste totale des membres du canal B est "Big Boss, BossA, BossB".<br />
<br />
La commodité de ce systeme est que si plus tard on ajoute "Super Boss" en tant que admin dans le root, il sera automatiquement dans le groupe administrateur de chaque canaux en dessous.<br />
<br />
Disons maintenant que le joueur "BossC" est dans la Add list dans le canal C, mais ici l'administration est marquée comme pas héritent.<br />
Cela signifie que "Big Boss" n'est pas dans la liste d'administration et on ne verra pas de changements pour l'administration dans la Racine ici.<br />
<br />
Le Canal D héritera la liste de C, à moins que C ne marque aussi l'administration comme non génétique.<br />
<br />
= Les ACL =<br />
<br />
ACL (Access Control Lists) sont attachée a un canal spécifique. Un canal peut spécifier si il veut hériter l'ACL sur le parent, mais il ne peut pas spécifier lequel; Il est tout ou rien l'affaire. <br />
Les ACL sont évaluées dans l'ordre, de haut en bas le long de la liste des canaux.<br />
<br />
Pour chaque entrée, un utilisateur ou un groupe correspondront. <br />
Un utilisateur doit être un utilisateur spécifique, inscrit, pendant qu'un groupe peut être n'importe quel groupe valide dans le canal l'ACL est défini dessus. (<== a revoir un peu celle la).<br />
Note, cette adhésion de groupe est évaluée dans le canal dans lequel l'ACL est exécuté, qui est important pour les ACL hérités.<br />
Si un groupe commence avec un !, c'est l'adhésion qui est inversé, si un groupe commence avec un ~, il est évalué dans le contexte du canal. <br />
L'ACL est défini dessus (et non sur le canal actif).<br />
<br />
all<br />
<br />
Chaqu'un<br />
<br />
auth <br />
<br />
Tous les utilisateurs authetifiés<br />
<br />
in <br />
<br />
Tous les utilisateurs actuellement dans le canal<br />
<br />
out <br />
<br />
Tous les utilisateurs en dehors du canal actuel<br />
<br />
Pour chaqe entrée, permissions are either allowed or denied; en cas d'un conflit la dernière entrée a la priorité. <br />
Rappelez-vous que toutes les entrées sont évaluées pour, ainsi si vous avez le jeu suivant d'entrées :<br />
<br />
* @all deny speak<br />
* @all allow speak <br />
<br />
Alors on permettra chacun de parler. D'autre part<br />
<br />
* @all allow speak<br />
* @all deny speak <br />
<br />
Interdira de parler pour tout le monde.<br />
<br />
Chaque entrée peut être marquée comme application dans le canal actuel, dans les sous-canaux ou tous les deux.<br />
La plupart du temps vous voudrez tous les deux. Souvenez-vous que pour une entrée qui est appliquée sur un sous-canal, vous devez l'appliquer pour souscanaliser et permettre la succession dans les sous-canaux.<br />
<br />
= The @sub group =<br />
<br />
(a venir ;-) )<br />
<br />
"Je continue plus tard car j'ai fait ca rapidement a la va vite ;-) Gecko64"</div>PatPeterhttps://wiki.mumble.info/index.php?title=ACL_and_Groups/Francais&diff=2134ACL and Groups/Francais2008-08-03T04:58:54Z<p>PatPeter: ACL FAQ (Francaise) moved to ACL and Groups/Francais</p>
<hr />
<div>= Tutorial =<br />
<br />
Vous pouvez trouver un tutorial illustré et un guide rapide sur Comment administrer les groupes et les permissions: [[ACL tutorial_(French)|ACL Tutorial]] pour la version francaise qui n'existe pas pour le moment.<br />
Sinon il y a toujours la version Anglaise de disponible ici ===> [[ACL tutorial_(English)|ACL Tutorial]]<br />
<br />
= Les Groupes =<br />
<br />
Les groupes sont liés à un canal spécifique, mais vous pouvez aussi les faire hériter a des sous canaux. Les groupes sont des façons commodes d'administrer des canaux, de definir les ACLs tout en haut de l'arborescence "that should have similar privilege structure, and just change the group memberships on subchannels."<br />
<br />
<br />
Pour chaque canal, un groupe a 3 parties specifiques qui sont:<br />
<br />
- La liste des joueurs pour ajouter au groupe.<br />
- La liste des joueurs héritée du meme groupe sur le canal parent.<br />
- Et pour terminer, la liste des joueurs pour enlever du groupe.<br />
<br />
Un groupe héritera seulement des joueurs du canal parent si seulement l'heritage est activé et que le groupe a été marque comme pouvant hériter du parent. La plupart du temps, vous "want both of these to be set."<br />
<br />
= Exemple =<br />
<br />
Regardez cet exemple pratique; sur le groupe admin. A chaque fois qu'un joueur crée un canal, il est automatiquement ajouté au groupe des admins. Cela ne lui donne pas automaniquement des privileges, il est juste marqué comme membre de ce groupe, cependant l'installation par défaut de Murmur installe une ACL qui donne au groupe admin le bit d'écriture (Tous les accès).<br />
<br />
Dans une structure comme celle-ci:<br />
<br />
* Root<br />
o A<br />
+ B <br />
o C<br />
+ D <br />
<br />
<br />
En Root, le joueur "Big Boss" est tout seul dans le groupe administrateur. Dans le canal A "BossA" est dans la Addlist, et "BossB" est dans le meme canal B.<br />
Depuis que le groupe admin est herité et génétique, Un joueur qui est un membre à n'importe quel parent du canal actuel est aussi un membre dans le canal actuel.<br />
Donc la liste totale des membres du canal B est "Big Boss, BossA, BossB".<br />
<br />
La commodité de ce systeme est que si plus tard on ajoute "Super Boss" en tant que admin dans le root, il sera automatiquement dans le groupe administrateur de chaque canaux en dessous.<br />
<br />
Disons maintenant que le joueur "BossC" est dans la Add list dans le canal C, mais ici l'administration est marquée comme pas héritent.<br />
Cela signifie que "Big Boss" n'est pas dans la liste d'administration et on ne verra pas de changements pour l'administration dans la Racine ici.<br />
<br />
Le Canal D héritera la liste de C, à moins que C ne marque aussi l'administration comme non génétique.<br />
<br />
= Les ACL =<br />
<br />
ACL (Access Control Lists) sont attachée a un canal spécifique. Un canal peut spécifier si il veut hériter l'ACL sur le parent, mais il ne peut pas spécifier lequel; Il est tout ou rien l'affaire. <br />
Les ACL sont évaluées dans l'ordre, de haut en bas le long de la liste des canaux.<br />
<br />
Pour chaque entrée, un utilisateur ou un groupe correspondront. <br />
Un utilisateur doit être un utilisateur spécifique, inscrit, pendant qu'un groupe peut être n'importe quel groupe valide dans le canal l'ACL est défini dessus. (<== a revoir un peu celle la).<br />
Note, cette adhésion de groupe est évaluée dans le canal dans lequel l'ACL est exécuté, qui est important pour les ACL hérités.<br />
Si un groupe commence avec un !, c'est l'adhésion qui est inversé, si un groupe commence avec un ~, il est évalué dans le contexte du canal. <br />
L'ACL est défini dessus (et non sur le canal actif).<br />
<br />
all<br />
<br />
Chaqu'un<br />
<br />
auth <br />
<br />
Tous les utilisateurs authetifiés<br />
<br />
in <br />
<br />
Tous les utilisateurs actuellement dans le canal<br />
<br />
out <br />
<br />
Tous les utilisateurs en dehors du canal actuel<br />
<br />
Pour chaqe entrée, permissions are either allowed or denied; en cas d'un conflit la dernière entrée a la priorité. <br />
Rappelez-vous que toutes les entrées sont évaluées pour, ainsi si vous avez le jeu suivant d'entrées :<br />
<br />
* @all deny speak<br />
* @all allow speak <br />
<br />
Alors on permettra chacun de parler. D'autre part<br />
<br />
* @all allow speak<br />
* @all deny speak <br />
<br />
Interdira de parler pour tout le monde.<br />
<br />
Chaque entrée peut être marquée comme application dans le canal actuel, dans les sous-canaux ou tous les deux.<br />
La plupart du temps vous voudrez tous les deux. Souvenez-vous que pour une entrée qui est appliquée sur un sous-canal, vous devez l'appliquer pour souscanaliser et permettre la succession dans les sous-canaux.<br />
<br />
= The @sub group =<br />
<br />
(a venir ;-) )<br />
<br />
"Je continue plus tard car j'ai fait ca rapidement a la va vite ;-) Gecko64"</div>PatPeterhttps://wiki.mumble.info/index.php?title=Template:Languages&diff=2133Template:Languages2008-08-03T04:56:24Z<p>PatPeter: Test subpages</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|{{BASEPAGENAME}}}}}|English]] — [[{{{1|{{BASEPAGENAME}}}}}/Español|Español]] — [[{{{1|{{BASEPAGENAME}}}}}/Deutsch|Deutsch]]<br />
</div><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|Name of page without language tag}}</nowiki><br />
<br />
=Example=<br />
Look at the ACL_and_Groups page. It is using the template right now.</noinclude></div>PatPeterhttps://wiki.mumble.info/index.php?title=ACL_and_Groups/Espa%C3%B1ol&diff=2132ACL and Groups/Español2008-08-03T04:54:16Z<p>PatPeter: Template</p>
<hr />
<div>{{Languages}}<br />
<br />
= ACL FAQ en otros idiomas =<br />
<br />
Las preguntas frecuentes de este ACL puedes encontrarlas en las siguientes lenguas:<br><br />
[[ACL_and_Groups|English]]&nbsp;&nbsp; [[ACL_FAQ_(Deutsch)|Deutsch]]&nbsp;&nbsp; [[ACL_FAQ_(Espanol|Español]]&nbsp;&nbsp; [[ACL_FAQ_(Francaise)|Français]]&nbsp;&nbsp; [[ACL_FAQ_(Italiano)|Italiano]]<br />
<br />
=Tutorial=<br />
Puedes encontrar una guía rápida de cómo administrar grupos y permisos aquí: [[ACL tutorial_(English)|ACL Tutorial]]</div>PatPeterhttps://wiki.mumble.info/index.php?title=ACL_and_Groups/Espa%C3%B1ol&diff=2130ACL and Groups/Español2008-08-03T04:53:39Z<p>PatPeter: ACL and Groups (Español) moved to ACL and Groups/Español</p>
<hr />
<div>= ACL FAQ en otros idiomas =<br />
<br />
Las preguntas frecuentes de este ACL puedes encontrarlas en las siguientes lenguas:<br><br />
[[ACL_and_Groups|English]]&nbsp;&nbsp; [[ACL_FAQ_(Deutsch)|Deutsch]]&nbsp;&nbsp; [[ACL_FAQ_(Espanol|Español]]&nbsp;&nbsp; [[ACL_FAQ_(Francaise)|Français]]&nbsp;&nbsp; [[ACL_FAQ_(Italiano)|Italiano]]<br />
<br />
=Tutorial=<br />
Puedes encontrar una guía rápida de cómo administrar grupos y permisos aquí: [[ACL tutorial_(English)|ACL Tutorial]]</div>PatPeterhttps://wiki.mumble.info/index.php?title=ACL_and_Groups/Deutsch&diff=2128ACL and Groups/Deutsch2008-08-03T04:53:12Z<p>PatPeter: ACL and Groups (Deutsch) moved to ACL and Groups/Deutsch</p>
<hr />
<div>{{Languages|ACL and Groups}}<br />
<br />
= 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>PatPeterhttps://wiki.mumble.info/index.php?title=ACL_and_Groups/Deutsch&diff=2127ACL and Groups/Deutsch2008-08-03T04:52:43Z<p>PatPeter: Template</p>
<hr />
<div>{{Languages|ACL and Groups}}<br />
<br />
= 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>PatPeterhttps://wiki.mumble.info/index.php?title=Template:Languages&diff=2126Template:Languages2008-08-03T04:27:08Z<p>PatPeter: Attempting fix</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}}} (Español)|Español]] — [[{{{1}}} (Deutsch)|Deutsch]]<br />
</div><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|Name of page without language tag}}</nowiki><br />
<br />
=Example=<br />
Look at the ACL_and_Groups page. It is using the template right now.<br />
</noinclude></div>PatPeterhttps://wiki.mumble.info/index.php?title=Template:Languages&diff=2125Template:Languages2008-08-03T04:24:50Z<p>PatPeter: Wiki does not have parserfunctions, will try later</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><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>PatPeterhttps://wiki.mumble.info/index.php?title=Template:Languages&diff=2124Template:Languages2008-08-03T04:23:21Z<p>PatPeter: Adding parserfunctions for all languages</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]]{{#ifeq:{{{german}}}|yes| — [[{{{1}}}_(Deutsch)|Deutsch]]|}}{{#ifeq:{{{spanish}}}|yes| — [[{{{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>PatPeter