05 Jun

    How to set up a fairly basic Minecraft server.




    • Get the crazy notion to build and run an internet accessible multiplayer Minecraft server.  Find and configure a machine to run it on.
    • Download buildtools, make a spigot.jar
    • Copy the spigot.jar to a server folder, make a startup batch/shell file, and run it.
    • Learn how to update spigot.
    • Stop the server, download and copy a bunch of plugins to the plugins folder.
    • Start the server, configure the plugins, stop the server
    • Start the server, start Minecraft client, design, build, and protect your world.
    • Stop the server, back it up, start it again.
    • Fettle your router, or whatever, to allow Minecraft clients outside your LAN to connect to your server.
    • Profit.


    This HOWTO doesn’t deal with a Totally Basic Minecraft server.


    To build a totally basic Minecraft server, you just need to download the server software from https://minecraft.net/download and install it on a suitable machine on your LAN.

    There’s some more in depth information, and a warning, at http://minecraft.gamepedia.com/Setting_up_a_server

    That’s fine within the confines of your own LAN, but as soon as you want to open your server to the big bad Internet, you expose yourself to griefers, ne’erdowells and the French.

    You’ll have to set yourself up with a more robust solution if you want to let people beyond your own LAN come to play, without exposing yourself to excessive vexation.

    This HOWTO doesn’t deal with an all-singing all-dancing Major Public Minecraft Server either: if you’re clever enough to install and run one of those, you are beyond the scope of this.

    This HOWTO targets those of you with a modicum of computer savvy, and a desire to run a Fairly Basic Minecraft Server.

    In my case, it’s so my kids can play Minecraft with their friends from school, without my having to invite all the little nose-miners round here and letting them loose on my computers.

    If your scenario is similar, and it’s no biggie if it all goes horribly wrong, you’re probably in the right place. So…


    How to set up a fairly basic Minecraft server

    We’ll be installing Spigot, because that’s what I did and so I know how to explain to you. Spigot is a resource-efficient and configurable branch of one of the most popular servers, Bukkit. It’s got a wide community, and lots of plugins.


    Step One [^]

    • Choose a suitable machine, and prepare it to install the server.

    You can have Linux (more efficient) or Windows (less scary), but it will need at least 1Gb of free disk space and 2Gb of RAM (of which at least 1Gb is free to use).

    That’ll let us run the BuildTools.jar which will fetch, configure and compile an up-to-date server for us.  More on that later, but you can read ahead here: http://www.spigotmc.org/threads/buildtools-updates-information.42865



    Step Two [^]

    Get the server together

    The process looks scary, but is in fact quite simple.  We’ll be running an excellent utility called BuildTools, which fetches all of the components necessary to compile and build the latest version of spigot.

    BuildTools creates quite a lot of navel-fluff in order to build the spigot jar file we want, but it’s so excellent, we’ll forgive that.  We will make it do its thing in a separate directory from our server, though, to avoid getting too much fluff in our navel.  So to speak.

    I’m running on Windows so, while the principle remains the same, on Linux you’ll have to interpret what I say….

    • Make an empty directory to contain your server. ‘MineServer’ is a lovely name. Or ‘MeinServer’ if you’re German and/or edgy.
    • Make an empty directory in which to build Spigot.  I call mine ‘SpigotFactory’.  Cute, huh?
    • Get yourself the latest ‘BuildTools.jar’: run Bash in your new spigot-building directory (in windows, you can right-click in the directory window, and select ‘Git Bash’) and use curl to download it:
    curl "https://hub.spigotmc.org/jenkins/job/BuildTools/lastSuccessfulBuild/artifact/target/BuildTools.jar" -o BuildTools.jar
    • still in the Bash window, execute BuildTools.jar to build your yummy new server:
    java -jar BuildTools.jar

    A load of scary magic will happen, taking a quite a while and generating a scrolly wall of text (1.8.7 on my fairly crappy laptop just took 7 minutes and 18 seconds:  ideal time for a cuppa or a cigarette), or….

    When it’s finished, your previously empty spigot-building directory will be full of delicious Bukkit/Spigot serversauce (301MB in 14,225 files of it, last time I looked. Mmmm!)

    But we only want one: the spigot-x.x.x.jar

    back to top [^]


    • Make yourself a batch file to run the server. The latest Spigot JAR file is in the root of your spigot-building folder (something like spigot-x.y.z.jar).  Copy it to your server folder.
    • Make a batch file in your server folder. Mine is called _start.bat (the underscore makes it go to the top of the file list) and it contains three lines that tell it to 1)be quiet, 2) use java to run the spigot jar file, with a minimum allocation of 1024M RAM and a maximum allocation of 1024M RAM (that’ll be 1024M RAM, then), and 3) wait until I press a key before exiting (so I can read any interesting shutdown messages):
    @echo off
     java -Xms1024M -Xmx1024M -jar spigot-1.8.7.jar

    That’s it, you’ve got a server.

    Run your batch file to start it, and away you go. Type ‘stop’ at the server console to stop it.

    The first run bug out until you edit the EULA to say yes (finding out how is an exercise for the reader).

    Second time it’ll build all the missing config files, directories and the Minecraft world itself.

    Subsequent starts are quicker.


    Updating Spigot [^]

    Like it says in the spigotmc.org link above ‘To update your server, simply run BuildTools again. It is also recommended to update BuildTools.jar at least weekly‘.

    Working in your spigot-building directory:

    Get yourself the latest ‘BuildTools.jar’ (Buildtools doesn’t update as often as Spigot does, generally, but it takes seconds to download it):  as before, run Bash in your spigot-building directory and use curl to download it:

    curl "https://hub.spigotmc.org/jenkins/job/BuildTools/lastSuccessfulBuild/artifact/target/BuildTools.jar" -o BuildTools.jar

    still in the Bash window, execute BuildTools.jar to update your Spigot build:

    java -jar BuildTools.jar

    This takes quite a long time, as before.

    When it’s finished, copy your new spigot-x.x.y.jar file into your server directory, and adjust your start-up file to point to it.

    It’s a good idea to keep a few of your previous spigot jar files in your server directory, so that you can revert to one in case you need to. Maybe a plugin didn’t update yet, and the new build kills it.


    That was the easy bit…



    Step Three [^]

    Add some plugins, and configure that sucker.

    Asking ‘which plugins should I have?’ is like asking ‘which car is best’. Aside from everyone agreeing that you don’t want a Humvee, you’ll get a different answer whoever you ask, so…. for the sake of showing the way, I’m going to show you the following:

    PermissionsEX (aka PEX) & Modifyworld

    PEX lets you put users into groups, and assign both the groups and the users rights to do stuff (or withhold those rights).  That way you can let admins fly in god mode, and make it so that casual passers-by can’t even build or break blocks before you’ve vetted them.

    PEX is widely adopted by other plugins to handle their permissions too.

    Modifyworld used to be part of PEX, but now needs downloading separately – it’s the bit that lets us prevent guests from breaking or placing blocks…


    WorldEdit gives groovy building tools that (given the necessary rights, see above) you can use to build excellent stuff quickly – need sphere with a 27 block radius? No problem! Clear all these trees, and plant a forest over there? You gotcha!


    WorldGuard allows admins (or people with the necessary permissions) to set up regions, and then control how those regions behave. How about a mob-free spawn area in Survival Mode? Or a town where nobody can break the sexy pink baroque buildings you designed?


    GriefPrevention allows users to set up their own territories and prevent anyone
    (other than those they choose to trust) from altering, opening, trampling or otherwise ruining their afternoons. Also includes global ‘admin’ measures to curb the antics of ten-year-olds with anger-management issues – things like curbing chat spam.

    There will doubltess be others that you’d like, need, or want.  By the time we’ve got these four going, you’ll have enough of an idea to make informed choices, and install/configure them yourselves. Go you!


    PermissionsEX [^]

    • As the guide says, get the latest version that suits your server from http://dev.bukkit.org/bukkit-plugins/permissionsex/files/. At the time of writing, for example, I took PermissionsEx v1.23.2.
      ModifyWorld can be downloaded at http://dev.bukkit.org/bukkit-plugins/modifyworld/
    • Drop the downloaded .jar files into the /plugins directory of your server.
    • Stop and restart the server. On the first restart, it’ll build the directories it needs, and some default configuration files. In this case the [server]/plugins/PermissionsEx and [server]/plugins/ModifyWorld directories, their config.yml files (which control how the plugin itself behaves) and, for PEX, the permissions.yml that controls the users, groups and their permissions.

    The config.yml files are probably fine as-is. The default permissions.yml needs some work: it has no users, and one group ‘default’ who is given permission to break stuff.

    While you can edit the permissions.yml directly, yml syntax is picky and doing so is a quick way to fall victim to strange bugs.  So, We’ll be using PEX commands from the server console.

    For now, we’re going to create four basic groups, and some users. After that, you can tinker…

    • From the server command line, enter
      pex group default delete

      to remove the pre-installed default group

    • Then
      pex group Guest create

      to create a ‘Guest‘ group

    • pex group User create

      for ‘User‘ types,…  and then the same exercise for ‘Mod‘ and ‘Admin‘.

    • Now make the Guest group the default group for users to belong to, if they’re not added to any others:
      pex group Guest set default true

    Now for some inheritance [^].

    Inheritance in this context means that if a Group has another Group as its parent, it inherits all of the permissions of that other group.  This can save a lot of typing.

    So we will have Users be able to do everything that Guests can, plus a bunch more. Mods will be able to do everything that Users can, plus some more. Admin will be able to do everything that Mods can, plus even more still…

    • pex group User parents add Guest
    • pex group Mod parents add User
    • pex group Admin parents add Mods

    Next, rankings [^].

    The ‘rank’ is an arbitrary value given to each group to indicate it’s seniority.  The smaller the number, the higher up the ladder they are, and the larger numbers sink to the bottom.   This will allow you to use the easy-to-remember pex promote <user>  and pex demote <user> commands to move users into and out of positions of UNIMAGINABLE POWER.

    • pex group Guest set rank 1000
    • pex group User set rank 900
    • pex group Mod set rank 100
    • pex group Admin set rank 1

    Finally Permissions [^].

    • Time to remove all the fun from the Guest group:
      pex group Guest add -modifyworld.*
      (the ‘-‘ means we are adding a ‘you may not…’ rule)
    • … but let them beg to come and play:
      pex group Guest add modifyworld.chat
    • Let’s let the Users group (and above – because inheritance) mine, and craft:
      pex group User add modifyworld.*
    • How about if Mods and above were ignored by hostile mobs?
      pex group Mod add -modifyworld.mobtarget.monster.*
    • … and Admin can do anything!
      pex group Admin add *

    The ‘*’ character is a ‘wildcard’ and stands for ‘and anything else’. So a permission ‘foo.*’ would include ‘foo.bar’, ‘foo.bash’ and ‘foo.manchu’

    ‘*’ on its own, as in the Admin Permission above, means ‘anything and anything else’ and essentially gives all permissions. That may seem fine on the face of it, but be careful: if a plugin contains a permission for ‘spontaneously combust every three minutes’, then you’ll have that one too. That may not be what you want.

    To test PEX, run Minecraft and join your server.  On the first try, before you’ve been allocated to any group, try to break some blocks. You shouldn’t be able to.

    Then, from the server console enter pex promote YourUserNameWhateverThatMayBe

    Switching back to Minecraft, you should now be able to break blocks.

    Use ‘/promote’ and ‘/demote’ from the server console to check out that you have the permissions you’d expect at each group level.

    You can use the console command ‘pex user SomeUserName set group SomeGroup‘ to put a user directly into a group.

    You can use ‘user SomeUserName‘ to examine the current details of a given user.

    Any user who has the ‘permissions.*’ permission, will be able to issue pex commands from the minecraft chat window, by using the format ‘/pex <somecommand...>‘ ; for example, ‘/pex promote MyMateDave‘. Note the leading ‘/’.

    It’s a good habit to test your permission set as you adjust your server, before some North Korean script-kiddie does it for you. Either recruit a willing friend, or ‘/promote’ and ‘/demote’ yourself and try stuff out.

    As you add new plugins that are PEX-aware, they will give you new permissions that you can add or revoke: pex group Mod add fireworkdisplay.oohahh.red, or pex group Mod add madplugin.fever.herpes. What fun!

    You’ll likely want to tune your permissions as we go along, but hopefully now you have the hang of it, and we can talk about other plugins.

    WorldGuard and WorldEdit [^]

    WorldGuard depends on WorldEdit, so we’ll install them as a pair.

    WorldGuard is a little more complicated.

    • For us, permissions is the easy bit.  As above, admin has ‘*’, or we could give worldguard.* to the relevant group.

    WorldGuard has a global configuration file at the root of the ..\plugins\WorldGuard\ directory.   The settings in this file cover all worlds.

    Then there’s the ..\plugins\WorldGuard\worlds directory, which has subdirectories for each of your worlds.  In each of those, there’s a config.yml that can be used to override settings for that world only.

    The various configuration options are explained in detail at http://docs.enginehub.org/manual/worldguard/latest/config/

    They are changed by editing the yml file(s) directly, but be careful.  YML is fussy about indentation… no tabs!

    • Let’s auto de-op people on join, to avoid hacked clients that give op status. Find the section
       deop-everyone-on-join: false
       block-in-game-op-command: false

      and edit it to make both ‘true’ (I can op myself from the console).

    • I also set block-creeper-block-damage to true, so that creeper explosions can still blow up people, but not their creations.  I also set disable-enderman-griefing and block-zombie-door-destruction to true.  Your taste may vary.
    • Stop and restart your server.

    Now it’s time to use WorldEdit to build some amazing creations to wow the visitors to your world, and WorldGuard to protect them using regions.

    There’s some useful tutorial videos at http://dev.bukkit.org/bukkit-plugins/worldedit/ and http://dev.bukkit.org/bukkit-plugins/worldguard/