Einleitung¶

Permissions(Rechte) sorgen bei den meisten großen Servern dafür, dass neue Spieler keinen Mist bauen können oder nur Admins cheaten können. In dieser kurzen Anleitung werden nur PermissionsEx, PermissionsBukkit und die SuperpermsBridge beschrieben, da sie die am meist genutzten Permissions Plugins sind

Eigene Permission Nodes¶

Im Root Ordner des Minecraft Servers befindet sich eine permissons.yml in der man mehrere Permissionseinträge bündeln kann. Beispiel:

admin:
   commandbook.*: true
   permissions.*: true
vip:
   commandbook.give.*: true

Diese Permissionnodes sind aber nur dazu gedacht, große Sammlungen an Permissionnodes zu einer zusammenzufassen. Um die Permissionnodes zu verteilen, muss ein Permissions Plugin installiert werden.

PermissionsBukkit¶

PermissionsBukkit ist ein relativ kleines und komfortables Permissions Plugin, welches nur auf kleineren oder Homeservern verwendet werden sollte. Ab einer gewissen Größe und Anzahl an Plugins sollte man, z.B. auf PermissionsEx umsteigen. Wenn das Plugin installiert ist, findet man im Ordner /plugins/PermissionsBukkit/ eine Datei namens config.yml. Wenn man diese öffnet, sollte das Ganze in etwa so aussehen:

# PermissionsBukkit configuration file
# 
# A permission node is a string like 'permissions.build', usually starting
# with the name of the plugin. Refer to a plugin's documentation for what
# permissions it cares about. Each node should be followed by true to grant
# that permission or false to revoke it, as in 'permissions.build: true'.
# Some plugins provide permission nodes that map to a group of permissions -
# for example, PermissionsBukkit has 'permissions.*', which automatically
# grants all admin permissions. You can also specify false for permissions
# of this type.
# 
# Users inherit permissions from the groups they are a part of. If a user is
# not specified here, or does not have a 'groups' node, they will be in the
# group 'default'. Permissions for individual users may also be specified by
# using a 'permissions' node with a list of permission nodes, which will
# override their group permissions. World permissions may be assigned to
# users with a 'worlds:' entry.
# 
# Groups can be assigned to players and all their permissions will also be
# assigned to those players. Groups can also inherit permissions from other
# groups. Like user permissions, groups may override the permissions of their
# parent group(s). Unlike users, groups do NOT automatically inherit from
# default. World permissions may be assigned to groups with a 'worlds:' entry.
#
# The cannot-build message is configurable. If it is left blank, no message
# will be displayed to the player if PermissionsBukkit prevents them from
# building, digging, or interacting with a block. Use '&' characters to
# signify color codes.

users:
    ConspiracyWizard:
        permissions:
            permissions.example: true
        groups:
        - admin
groups:
    default:
        permissions:
            permissions.build: false
    admin:
        permissions:
            permissions.*: true
        inheritance:
        - user
    user:
        permissions:
            permissions.build: true
        worlds:
            creative:
                coolplugin.item: true
        inheritance:
        - default
messages:
    build: '&cYou do not have permission to build here.'

• Unter dem Eintrag user werden später alle Nutzer inklusive ihrer Gruppen und evtl. Sonder-Permissions eingetragen. Das übernimmt PermissionsBukkit automatisch, sobald sich jemand neues einloggt.

• Unter dem Eintrag group werden alle Gruppen samt Permissionsnodes definiert

• Unter dem Eintrag messages können alternativ Nachrichten, für den Fall, dass man für etwas keine Berechtigung hat, definiert werden

Auf den meisten Servern gibt es folgende Gruppen:

Eine config.yml mit diesen Gruppen könnte z.B. so aussehen:

user:
    Bämm2000:
        permissions:
        groups:
        - member
    knorckator50:
        permissions:
        groups:
        - admin
groups:
  gast:
    permissions:
      permissions.build: false
      commandbook.spawn: true
  member:
    inheritance:
      - gast
    permissions:
      permissions.build:true
      commandbook.sethome: true
      commandbook.warp: true
  vip:
    inheritance:
      -member
    permissions:
      commandbook.give.*: true
  supporter:
    inheritance:
      -vip
    permissions:
      permissions.*: true
  admin:
    inheritance:
      -supporter
    permissions:
      commandbook.*: true
      worldedit.*: true
      worldguard.*: true
      commandhelper.*: true
      iConomy.*: true

messages:
    build: '&cYou do not have permission to build here.'

Bei den Usern ist die Einrichtung sehr simpel gehalten:

users:
    ConspiracyWizard:
        permissions:
            permissions.example: true
        groups:
        - admin
groups:
    admin:
        permissions:
            permissions.*: true
        inheritance:
messages:
    build: '&cYou do not have permission to build here.'

Wie man sieht, ist der user teil dem groups teil sehr ähnlich. Statt einem Gruppennamen wird der Username angegeben und es gibt keine inheritance, stattdessen einen groups eintrag. Der Permissionseintrag ist dazu da, um jemandem, zusätzliche Rechte zu geben oder zu nehmen. Unter dem Groupseintrag trägt man die zugehörige Gruppe ein. Für weitere Informationen zu PermissionsBukkit und seiner Einrichtung: DevBukkit Thread

SuperpermsBridge¶

Es kann vorkommen, dass ein Plugin PermissionsBukkit nicht unterstützt, sondern z.B. Permissions 3.1.6. In diesem Fall hilft die SuperpermsBridge, indem sie diesen Plugins ein anderes Permissions vorgaukelt. Wenn PermissionsEx genutzt wird ist dies nicht nötig, da PermissionsEx die API von Permissions 2&3 unterstützt. Um nun diese Permission Nodes zu verteilen, muss man nicht z.B.

xauth.register: true

sondern

superpermbridge.xauth.register: true

eingeben. Weitere Informationen gibts es im DevBukkit Thread .