Example PermissionsBukkit Config

# This is a simple procedure for setting up commands with PermissionsBukkit so
# that users can have access to simple commands without having access to every
# single command available on the server.

# For now, I'm going to limit it to the basic 62 lines that will provide six
# different groups with all of Minecraft's initial commands, as well as three
# CraftBukkit-only commands and the ability for users to place and break blocks.

# If a line has # in front of it, it is a comment and is therefore disregarded
# in the code. You can delete everything in the # and the program will run fine.

# YML format is based solely on spacing. If the spaces are off, the entire plugin
# will not properly function.

# The spacing tends to get reset when the document saves and is used. Therefore,
# the spacing on this document could look like the area shown below. Please note
# that it will be read as code without the # in front of it, so imagine that the
# first letter after the # is the far-left side of the document. (If you erase
# the # and the space after it, it will be aligned properly, but will be read as
# code. You'll see what I mean by that soon.)

# groups:
#   default:
#     permissions:

# In actuality, the document was typed along these premeses:

#  groups:
#      default:
#          permissions:

# If you don't want to take any risks with improper spaces, it is suggested that
# four spaces are used instead of two. While two work, there is a likely chance
# that the code could be ruined due to faulty spacing.

# Now to actually begin the code. Make sure the only plugin you have installed
# currently is PermissionsBukkit. You can have other plugins in, and they will
# still work, only operators will have access to the commands until the groups
# are configured in this document.

# First, we start off with users. This is a list of all users and what group or
# groups they belong to. This can be configured with commands in game, or you
# can modify it here.

# You must put a colon after almost everything you type for the program to
# recognize what to perform.

users:
    username:
        groups:
        - default

# This has placed the player "username" into the group "default". You can feel
# free to change the sample username to your username, and set whatever group
# you want, as long as it is listed below.

# You can also set per-user commands like this:

# users:
#     username:
#         permissions:
#             permission.node: true
#         groups:
#         - default

# A permission node is basically the code that allows a command to be wired to a
# certain group. You can't simply put "/tp" under their permissions and expect
# it to recognize that you want the teleport permission - come on, this is code.
# It's designed to be as difficult as it can possibly be. You will also need to
# add : true or : false to the end to determine whether or not it's enabled or
# disabled.

# Now, let's start off with the default group. When a new user joins the game,
# what commands should they have? Should they be able to see the version, or
# see the plugins installed on the server? That's a benefit to griefers, in my
# opinion. Let's disable those. And while we're at it, let's disable /kill as
# well. They don't deserve it. Should they still be able to use /tell and /me,
# the other commands immediately available? Yes, if they need to contact someone
# or talk in third person, why not let them? And should we give them the ability
# to break and place blocks? I think so. If they turn out to be griefers, we can
# ban them and repair the damage.

groups:
    default:
        permissions:
            bukkit.command.version: false
            bukkit.command.plugins: false
            bukkit.command.tell: true
            bukkit.command.kill: false
            bukkit.command.me: true
            bukkit.command.list: true
            permissions.build: true

# So now, when our new users join, they immediately get build rights and can use
# /tell, /list, and /me, but not /version, /plugins, and /kill. But what about other
# groups? We've disabled some commands that they immediately had access to, but
# what about /gamemode? And /give? We don't want to give all of our new users
# operator, do we? That's a bad idea. So, we can set up ranks like this.

# Let's have a rank called VIP. These people have access to the game-oriented
# commands, like switching game modes and changing the weather. They won't be
# able to disable saving, ban people, and stop the server. They have six more
# commands at their disposal for gameplay only.

    vip:
        permissions:
            bukkit.command.teleport: true
            bukkit.command.give: true
            bukkit.command.time: true
            bukkit.command.gamemode: true
            bukkit.command.xp: true
            bukkit.command.toggledownfall: true

# But they also need the commands from Default, right? Set an inheritance.

        inheritance:
        - default

# Now all users in the VIP rank can use /tp, /give, /time set, /time add, /xp,
# /gamemode, and /toggledownfall on top of the Default commands.

# What about the people who police the server and make sure everything's going
# all right? We need moderators, but we don't want them to be operators, either.
# Here's some basic commands for them.

    moderator:
        permissions:
            bukkit.command.kill: true
            bukkit.command.kick: true
            bukkit.command.ban.player: true
            bukkit.command.teleport: true
        inheritance:
        - default

# Now moderators have access to all Default commands plus /tp, /kick, /ban, and
# /kill. But what if there's someone you trust to be both VIP and Mod, but not
# with administrator powers? There's two ways to do this. One is to add both
# VIP and Moderator to their list of groups under users at the top. The other is
# to create a third group for both of them. If you want to use rank prefixes,
# you will have to use the separate rank.

    vip-mod:

# Does the VIP-Mod actually have any new commands? No, actually. Therefore, you
# can safely do this:

        inheritance:
        - vip
        - moderator

# And you can't have a server without admins. Now, we don't want other people being
# able to shut down the server at the press of a button, do we? Well, I guess that
# one is up to you. As for me, I'd suggest making two more ranks.

    admin:
        permissions:
            bukkit.command.version: true
            bukkit.command.plugins: true
            bukkit.command.ban.list: true
            bukkit.command.ban.ip: true
            bukkit.command.unban.player: true
            bukkit.command.unban.ip: true
        inheritance:
        - vip-mod

# If you didn't do the VIP-Mod rank, simply replace that with the same inheritance as
# I showed for VIP-Mod.

# Now, onto you, the founder of the server...

# You could easily add in bukkit.command.op: true as this group's only permission, but
# what if you can't get into it for some reason? It's safest to include all the other
# permissions as well, just in case.

    founder:
        permissions:
            bukkit.command.reload: true
            bukkit.command.help: true
            bukkit.command.op: true
            bukkit.command.stop: true
            bukkit.command.say: true
            bukkit.command.save: true
            bukkit.command.whitelist.enable: true
            bukkit.command.whitelist.disable: true
            bukkit.command.whitelist.add: true
            bukkit.command.whitelist.remove: true
            bukkit.command.whitelist.list: true
            bukkit.command.whitelist.reload: true
        inheritance:
        - admin

# By doing all of that, we have given founder access to every initial Minecraft command
# and the permission(s) to build. Keeping in check with my 62 lines (and the fact that
# I haven't memorized them yet), I haven't included the PermissionsBukkit commands for
# the Founder group. They have access to OP, so they can do that themselves. Lazy.

# With that, here's a few PermissionsBukkit commands you should memorize:

# /permissions player setgroup <username> <group>

# This changes a user's group in-game. It can be used with the server's command prompt or
# through commands in-game.

# /permissions group setperm <group> <permission.node>

# This allows you to add permission nodes to a group instantly without having to stop the
# server. You can also replace setperm with unsetperm to remove one from the entire group
# if you find it necessary.

# /permissions player setperm <user> <permission.node>

# This allows you to set (or remove, using unsetperm) a permission node for a specific
# user. If someone keeps teleporting people around, if a moderator becomes ban-happy
# and begins banning innocent users, or if you don't want a specific user to build, if
# you've heard griefing reports, just use this command to remove the corresponding
# node.

# That's about all there is to it. If you don't think you need these tutorials anymore,
# you can get rid of these lines with the # marks prefacing them and all the empty lines
# to make the document look smoother.

# That's about it. Thanks for checking this out!