Work In Progress
Once you get a Bukkit server started up, the 1st thing you should do is choose a permission plugin, install it and learn how to use it. Make sure you pick just one, you cannot have multiple permissions installed at the same time. Every plugin you install after this will make use of it.
There are various plugins to consider such as PermissionsEx, GroupManager, bPermissions, PermissionsBukkit etc.
I used to use bPermissions for my private LAN servers but switched to PermissionsEx (PEX) when I created a public server in order to make it easier to work with inherited permissions and donation systems and it was enjoying active development.
This tutorial will cover how to setup PermissionsEx (PEX) version 1.22.1 for a Bukkit 1.7.9 server.
You can find more detailed information about PEX on their wiki documentation site.
- Make sure your Bukkit server is stopped
- Download the version of PermissionsEx that matches the version of Bukkit server you are running.
For example, PermissionsEx 1.22.1 for CraftBukkit/Spigot 1.7.9
- Place the plugin in <server folder>\plugins\PermissionsEx.jar
- Start the server and let it finish loading. This will generate the initial configuration files.
- When the server is done loading, type "stop" on the console to shutdown the server.
Here is the default config.yml for version 1.22.1 Permissions File
Here is the default permissions.yml for version 1.22.1: NOTE: The "permissions:" should really be set under the group name and the "default: true" in this version should really be set under options as follows: Permission Nodes
Developers of plugins can assign each permission node 1 of 3 default states: true, false, op
If you do not explicitly define the permission node, it will use the default setting as defined by the plugin author.
If the default is set to true, everyone gets that permission node. If false, everyone is denied access to that permission. If op, only operators has access to that permission.
When we assign permissions, we are overriding the default setting and making it work the way we want.
You can grant or negate permissions to users or groups and even use weighting on groups to override the same permission setting by a lower group.
Permission nodes in PermissionsEx, Group Manager and bPermissions look like this: Negative permission nodes (that take access away) in PermissionsEx and Group Manager look like this: Negative permission nodes in bPermissions look like this: Groups
Groups are used to organize permission nodes.
Without groups, you would have to manage every player that comes on your server by assigning each permission node (nobody in their right mind would do this and it would be impossible to keep up with demand)
There are many different ways you can go about using groups. You could put all the permission nodes in 1 group so that everyone has the exact same access. Or you could make 2 groups where everyone has a certain set of permissions and another group can have a different set or a set in addition to the other.
With inheritance, you could setup groups that are never directly attached to any players but instead are attached to other groups that the player is assigned. This can also reduce the amount of permission nodes that are repeated, thus keeping the list smaller and easier to maintain.
Syntax: Deleting Groups
A very powerful feature to PermissionsEx is inheritance. This means that one group can inherit (get the same permission nodes) another group...which can inherit any groups that group inherits (recursive inheritance)
This is particularly helpful when you have groups that build upon the rights of others. For example, admins can inherit all the permissions that moderators have and moderators can inherit all the permissions of a chat moderator. This means that admins have the same permissions that moderators AND chat moderators have because of recursive inheritance.
Permissions are assigned based on a pre-defined order and it is important to understand especially when you have conflicting nodes such as one group granting a permission with another group taking it away. Based on the order in which permission nodes are assigned, if a negative node has been assigned and later a positive node is granted, it will ignore the positive node so take care in the order of your assignments. Here is how PEX assigns nodes in order:
- Player settings are evaluated before group settings. If a players has a prefix of "Hello" and belongs to a group with a prefix set to "Goodbye," they will end up having the prefix of "Hello"
- Group settings that a player is directly associated with are evaluated before inherited groups. If a player is a member of the group "Crazy" and that group inherits another group called "Sane," the permission nodes in "Crazy" are assigned before the nodes in "Sane"
- Permission nodes are inherited in order of the permission tree. If you have a player that inherits from Donor and then Member, it will go through all the nodes in Donor and any inherited groups under Donor all the way down until it reaches the end of the inheritance chain. Then it looks at the Member group and goes through all the nodes in Member and any inherited groups under Member all the way down until it reaches the end of that inheritance chain.
- A group that inherits from another group will inherit everything from that group including any inherited groups (recursive inheritance).
Syntax: Examples: Prefix / Suffix
A prefix and suffix are not part of the basic Minecraft server. Permission plugins add prefix and suffix support capability but it requires a chat plugin in order to use the prefix/suffix and see the result in-game.
A player can be associated to many groups which all have a prefix and/or suffix but only one of them will be assigned. You cannot combine the prefix of two or more groups. Just like the permission node inheritance rules, the same order applies here. If a player has a prefix or suffix directly to their account, it will override any group setting. If the player does not have a prefix/suffix directly set, they will get the prefix/suffix of their primary (1st) group if it has one. With clever planning, one could inherit a prefix from one group and a suffix from another group. On my servers, the prefix is always the rank of a player and every player has a rank of some kind. Staff member have additional groups and those groups have suffix settings so that any player attached to a staff position will have a suffix.
Syntax: Examples: Rank / Priority
The Rank / Priority is primarily for promotion ladders. It allows you to determine the order in which one travels up and down a ladder when there are multiple groups available in a ladder.
It also has a protection system such that if you can promote someone else, you can never promote them higher than your own level. For example, an admin could promote a chat moderator to full moderator and then promote them again to an admin but could not promote again to owner status.
Syntax: Examples: Rank Ladders / Promotion and Demotion
When a new player joins the server, they fall into the default group we setup. In this case, the group is called "Guest" which is part of the ladder system called "Player"
If we promote a new player, they will go up the "Player" ladder to the "Member" group.
If you want to promote a staff member, they must 1st be added to an existing staff group. Once they are in that group, only then can they be promoted or demoted in that ladder system.
The following will promote the newly joined player from the Guest group to the Member group The following will add this player to the ChatMod staff group in addition to his existing "Member" player group and then promote him to the Mod group. The following will move this player down one group from Mod to ChatMod. MySQL
If you want to use a MySQL database, this is how you can convert back and forth between file and MySQL
If you have both "sql" and "file" backends correctly configured in config.yml, you can move data between them using the command: "/pex import <backend>"
YAML to MySQL
NOTE: This assumes you have all your permissions defined in the "permissions.yml" file and you do not need anything currently residing in the MySQL database...because the import will override whatever is there.
- Stop the server.
- Edit config.yml and set the backend to "sql" and setup the connection info correctly.
- Start the server.
- Make sure PEX successfully connected to the database.
- At the console, type "pex import file"
NOTE: This assumes you have all your permissions defined in MySQL and you do not need anything currently residing in the "permissions.yml" file...because the import will override whatever is there.
- Stop the server.
- Edit config.yml and set the backend to "file" and make sure the MySQL connection info is correct.
- Start the server.
- Make sure PEX successfully initialized the file backend.
- At the console, type "pex import sql"