ACL and Groups/Deutsch

From Mumble Wiki
< ACL and Groups
Revision as of 21:48, 8 August 2007 by Xanadu (talk | contribs) (ACL FAQ in anderen Sprachen)
Jump to: navigation, search

ACL FAQ in anderen Sprachen

Die ACL FAQ ist verfügbar in folgenden Sprachen:
English   Deutsch   Espanol   Francaise   Italiano

Tutorial

Ein ausführliches bebildertes Tutorial von User "Javitonino" wie man ACL und Gruppen administriert, findet ihr, wenn ihr hier klickt

Gruppen

Gruppen sind an einen bestimmten Kanal (Channel) geknüpft, können aber auch von Unterkanälen (Subchannels) geerbt (übernommen) werden. 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.

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.

Eine Gruppe wird Spieler nur dann vom Elternkanal (übergeordneten Kanal) vererben, wenn erben auf "wahr" gesetzt ist und die Gruppe als "vererbbar" markiert ist im übergeordneten Kanal. Meist sollte beides gesetzt sein.

Beispiele


Ein praktisches Beispiel: Die admin Gruppe.

Immer wenn ein Spieler einen Kanal erstellt, dann ist er automatisch der Admin Gruppe hinzugefügt.

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).

In einer Struktur wie dieser:
Root   A      B   C      D
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.

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. Wer also in A in der Gruppe Admin ist, ist auch im Unterkanal B in der Gruppe Admin. So ist die Liste der Mitglieder in "admin" im Kanal B folgende: Big Boss, Boss A und Boss B.

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.

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.

ACL

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.
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.
Beachte, dass die Gruppenzugehörigkeit bewertet ist in dem Kanal in dem die ACL ausgeführt wird, was für vererbte ACL wichtig ist.
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).

all (Alle/Jeder)
auth (Alle registrierte User)
in (Alle User in dem aktuellen Kanal)
out (Alle User ausserhalb des aktuellen Kanals)

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.). Erinnere Dich daran, dass alle Einträge der Reihe nach ausgewertet werden, hast Du also folgende Reihenfolge:

@all deny speak (@all verbiete sprechen)
@all allow speak (@all erlaube sprechen)

Dann kann jeder sprechen.

@all allow speak
@all deny speak

wird jedem das Sprechen verbieten.
(siehe auch meine Anmerkung bzgl. Raum betreten oder nicht).

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 und die Vererbung in den Unterkanälen erlaubst.



Die @sub Gruppe


Es gibt eine spezielle Gruppe, die sich @sub nennt, welche genau wie @all eine spezielle Bedeutung hat.
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:

b ist die minimale und c die maximale Pfadlänge, gemessen von dem Kanal auf den a sich bezieht.
Fehlt irgendeiner dieser Parameter, dann gibt es keine minimale/maximale Pfadlänge.

Es ist etwas komplex, aber ferner recht machtvoll. Ein Beispiel, lasst uns folgende Baumstruktur annehmen:

Root   A
    A1
      Sub1
      Sub2
    A2
    A3
  B
    B1
    B2

Lasst uns @all das Betreten verbieten in root für den Anfang. Dann in A definieren wir:

    @~sub,0,1 +enter 



Als allererstes, diese ACL wird im Kontext des definierenden Kanals gesehen (da die Gruppe mit einer Tilde ~ beginnt, wir erinnern uns).

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~).

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.

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).

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.)

Lasst uns dem Kanal A1 eine neue Regel geben.
@sub,-1,0 +link
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.

Zum Abschluss einfach um zu zeigen wie derangiert es gehen kann, lasst uns zu Kanal B folgende Regel hinzufügen:
@~sub,-1,2,2 +enter

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.


Write (Schreiben)


Dies gibt totale Kontrolle über den Kanal, inkl. der Fähigkeit, die ACL zu editieren. Dieses Privileg schliesst alle anderen Privilegien mit ein.

Traverse (Traverse)


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).

Enter (Betreten)


Erlaubt Spielern, den Kanal zu betreten. Ohne das Privileg kann ein Spieler dennoch in den Kanal gemoved werden (vom Admin der Spieler moven kann).

Speak (Sprechen)


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.
Auf diese Weise hören Spieler irgendeinen anderen zum Gruppenführer sprechen und hören mit Sprechen (hoffentlich) auf für kurze Zeit.
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.


Mute/Deafen (Stumm/Taub)


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.


Move/Kick (Spieler ziehen/Kicken)


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.)


== Make Channel (Erstelle Kanal)==
Erlaubt einem Spieler, in einem Kanal einen Unterkanal zu erstellen. Der Player wird automatisch der admin 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.


Link Channel (Verbinde Kanäle)


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.


AltSpeak (Alternativ Sprechen)


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.

Beispiele

Gruppen von FPS Game Servern


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:

Servers   "Servername"     Team 1       Squad 1       Squad 2       ............     Team 2       Squad 1       Squad 2       ............     .............   ..................

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.

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.

  1.  @all deny enter
2. @~sub,2,2 allow enter, allow link


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.


MMORPG Raid


Wir nehmen diese Einrichtung an:

Root
  Raid
    Healers
    Tanks
    Damage Dealers
    Wussards and other Pets

Unser Wunsch ist es, einen Führer pro Gruppe zu haben, plus ein paar Leute als Raidführer.

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.

Im "Raid" Kanal definiere folgende ACL:

  1.  @all deny enter, deny speak [Apply Here only]
2. @raidleaders allow enter, allow speak, allow link, allow mute, allow kick [Apply Here and Apply Subs]
3. @groupleaders allow speak, allow link [Apply Here only]
4. @groupleaders allow link, allow mute, allow kick [Apply Subs only]


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.

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.