I created a Wiki account and inserted new introductory material focusing on the basics and on basic Mumble access control vocabulary. All of that work went into this page:
However, when I access that page as a regular user, I never see that new content. I'm not sure if I am doing something wrong in my attempt to get it published. To prevent loss of this work, I insert a copy here:
====== BEGIN COPY OF NEW WIKI INSERTION =======
Mumble Access Control Vocabulary
Mumble has a rich and powerful set of tools for controlling access. In order to understand those tools, it's essential to understand certain fundamental terms as follows:
The most basic tool for separating Mumble conversations is the "Channel". In its most basic configuration, Mumble servers create just one Channel, and all users communicate with one another simultaneously by entering and speaking within that channel. As simple Mumble servers attract more users, it is commonplace for them to be expanded with several distinct Channels, allowing different groups of people to isolate their conversations within those distinct Channels. In these simple situations, conversations within one Channel are not heard in any of the other Channels.
Related Mumble Channels can be organized Hierarchically, like members of a family. Channels can have "Children", "Parents", and "Siblings". This can go on for several "Generations", so that one Channel can be the Child of its Parent and it can also be the Parent of its own Children. The depth of this Parents/Children hierarchy can continue to grow. In large Mumble Channel Hierarchies, we might refer to a channel's "Ancestors" and "Descendants", and we might refer to the common ancestry between two related Channels according to the number of "Generations" back to a common Ancestor. Here is a picture of a very simple Channel Hierarchy:
Code: Select all
In that example, the Channel named "Mission1" has two Children, named "Team1" and "Team2". The Channel named "Team1" has one Parent ("Mission1") and one Sibling ("Team2"). Following the same pattern, the Channel named "Team2" has one Parent ("Mission1") and one Sibling ("Team1"). Even though all three of these Mumble Channels have an obvious Hierarchical relationship, conversations within one of them are still isolated from the others unless additional Mumble tools are put into place.
After a Mumble server grows enough to support several channels, it is sometimes desirable for two or more channels to be "Linked" so that their conversations can be shared. For example, suppose that the simple Channel Hierarchy shown in the prior example grows into a larger Channel Hierarchy like this:
Code: Select all
In this larger situation supporting two different Missions, it might be desirable for everybody participating in Mission1 to communicate with one another in one large group, without interfering with conversations associated with Mission2, and vice versa. Mumble allows this through a tool that it calls "Channel Links". By joining a Mumble Channel and then right-clicking on the name of one of its Children or Descendants, a Mumble Administrator is presented with a menu option that can be used to "Link" them. Two or more Linked Channels of this type are known as "Link Communities". Within one of these Link Communities, all conversations are heard by everybody in any of the Linked Channels. Referring to the diagram immediately above, it would be easy for a Mumble Administrator to create one Link Community for Mission1 with its Children, and a second Link Community for Mission2 with its Children, so that players participating in those missions can communicate within their own mission, regardless of the team they have joined, without interfering with the other mission.
Channel Links of this type are, however, unsophisticated; they merge ALL conversations within the Link Community. As a Mumble server attracts more and more users for more and more advanced use, it can sometimes become desirable to restrict this merging of a Link Community's conversations. For example, suppose players of Mission1's "Team1" want to put together a secret plan, unknown to "Team2". In fact, in situations like that illustrated in the diagram above, it is commonplace for team-oriented players to want to speak in private on their own channel some of the time, while preserving the option to speak to the entire Link Community at other times. Mumble provides various different kinds of tools to help with this.
Access Control Lists ("ACLs")
: Use of every Mumble Channel is restricted by a list of rules known as its "Access Control List" or "ACL". Upon initial creation of a new Channel, its ACL is populated with default rules that allow sensible access with few restrictions. Usually those rules are simply "inherited" from the Channel's Parent. However, authorized Mumble Administrators that right-click on the name of a Mumble Channel will see a pop-up menu allowing them to modify its ACL by eliminating or modifying existing rules, or by adding new ones.
Mumble's "Groups" serve as a convenient way to define or limit the scope the rules in an "Access Control List" or "ACL". Because each rule in each Access Control List operates on some group of users in order to grant or limit what can be done in a Mumble Channel, it's important to understand Mumble's Groups before creating any of those rules.
Whenever a Mumble Channel is created, Mumble automatically gives it several specially named Groups, each with a descriptive name and purpose. They are:
Everybody using this channel by any means.
People with administrative authority for this channel.
Everybody tuned to this channel
Everybody NOT tuned to this channel.
Everybody in a channel with parent or ancestor in common with this channel. Optional parameters designate maximum and minimum parental separation
Those names suggest the purpose of each group and the scope of any rule written for that group. For example, any rule written for the "all" group of any channel will apply to everybody using the channel in any way, even if they have some kind of access to the channel without actually being tuned to it (such as access through a Mumble "Link"). Any rule written for the "in" group of that channel will apply only to everybody that is currently tuned to that channel. The tilde ("~") character limits the associated group to the channel in which it is defined, eliminating any effect of inheritance or links. In addition to those predefined groups, appropriately authorized users can create additional ones, assigning descriptive names to help clarify their purpose. These allow specific groups of people, referenced by their Mumble usernames, to enjoy defined privileges or protection as defined by rules referencing those new groups.
Continuing our discussion of Groups, ACLs, Links, and Channels, let's return to our first little Channel Hierarchy diagram:
Code: Select all
Suppose we want to isolate the two Siblings "Team1" and "Team2" from one another so that they can hold private conversations, but we DON'T want that isolation to apply to the Parent channel "Mission1". That way, it's easy to share mission-wide conversations by hopping into the "Mission1" channel. Anybody lurking in "Mission1" can hear and interact with every conversation throughout that Mission1 Link Community, but when team members want a private conversation they can all gather in their own team channel and share secrets. After setting up the Link Community across all three of those Channels as described above, the desired Sibling isolation can be achieved by appending two new Rules onto the end of the Access Control List for the Parent Channel ("Mission1"). Those rules are:
New Rule 1 of 2: For group "~sub 0,1": deny speak, operating only on Children of "Mission1"
New Rule 2 of 2: For group "in": allow speak, operating on "Mission1" and its Children ("Team1" and "Team2").
The first of those two new rules, expressed as "~sub 0,1" denies speaking privileges into the first-generation Children. Because it is propagated only to the Children of "Mission1", this prevents those tuned to the "Team1" channel from speaking to "Team2" and vice versa.
The second of those two new rules, expressed as "in", allows permits speaking privileges to those tuned in to "Mission1". Because it is propagated to Mission1 and its children, it permits those tuned in to the "Mission1" channel to converse freely with "Team1" and "Team2".
====== END COPY OF NEW WIKI INSERTION =======