Difference between revisions of "ACL and Groups/Francais"

From Mumble Wiki
Jump to: navigation, search
(Les ACL)
(Les ACL)
Line 78: Line 78:
  
 
Chaque entrée peut être marquée comme application dans le canal actuel, dans les sous-canaux ou tous les deux.
 
Chaque entrée peut être marquée comme application dans le canal actuel, dans les sous-canaux ou tous les deux.
La plupart du temps vous voulez 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.
+
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.
  
 
"Je continue plus tard car j'ai fait ca rapidement a la va vite ;-)  Gecko64"
 
"Je continue plus tard car j'ai fait ca rapidement a la va vite ;-)  Gecko64"

Revision as of 22:36, 4 September 2007

Tutorial

Vous pouvez trouver un tutorial illustré et un guide rapide sur Comment administrer les groupes et les permissions: ACL Tutorial

Les Groupes

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


Pour chaque canal, un groupe a 3 parties specifiques qui sont:

- La liste des joueurs pour ajouter au groupe. - La liste des joueurs héritée du meme groupe sur le canal parent. - Et pour terminer, la liste des joueurs pour enlever du groupe.

Un groupe héritera seulement des joueurs du canal parent si seulement l'heritage est activé et que le groupe a été marque comme pouvent hériter du parent. La plupart du temps, vous "want both of these to be set."

Exemple

Regardez cet exemple pratique; sur le groupe admin. A chaque fois qu'un joueur cree un canal, il est automatiquement ajouté au groupe des admins. Cela ne lui donne pas automaniquement des privileges, il est juste marque comme membre de ce groupe, cependant l'installation par defaut de Murmur installe une ACL qui donne au groupe admin le bit d'écriture (Tous les accès).

Dans une structure comme celle-ci:

   * Root
         o A
               + B 
         o C
               + D 


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. 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. Donc la liste totale des membre du canal B est "Big Boss, BossA, BossB".

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.

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

Le Canal D héritera la liste de C, à moins que C ne marque aussi l'administration comme non génétique.

Les ACL

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. Les ACL sont évaluées dans l'ordre, de haut en bas le long de la liste des canaux.

Pour chaque entrée, un utilisateur ou un groupe correspondront. Un utilisateur doit etre spécifique et enregistré, "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)."

   all

Chaqu'un

   auth 

Tous les utilisateurs authetifiés

   in 

Tous les utilisateurs actuellement dans le canal

   out 

Tous les utilisateurs en dehors du canal actuel

Pour chaqe entrée, permissions are either allowed or denied; en cas d'un conflit la dernière entrée a la priorité. Rappelez-vous que toutes les entrées sont évaluées pour, ainsi si vous avez le jeu suivant d'entrées :

   * @all deny speak
   * @all allow speak 

Alors on permettra chacun de parler. D'autre part

   * @all allow speak
   * @all deny speak 

Interdira de parler pour tout le monde.

Chaque entrée peut être marquée comme application dans le canal actuel, dans les sous-canaux ou tous les deux. 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.

"Je continue plus tard car j'ai fait ca rapidement a la va vite ;-) Gecko64"