Minecraft servers/s2/Operator procedures
This page documents the various procedures operators of Minecraft server s2 should follow. These procedures may change from time to time!
This page assumes that you have access to and are familiar with OTRS. All LizardNet Minecraft servers ops should have OTRS access. If you don't have access or don't know how to access OTRS, please read the OTRS guide.
With Minecraft 1.8, Mojang will be changing the user authentication scheme for Minecraft from username-based to UUID-based - in other words, a player will now be uniquely identified in-game by a unique identity code instead of their username. This is to allow players to change their usernames. UUIDs won't be seen by players, as the translation from UUID to current username is handled automatically by the game, but whitelisting, bans, access control, etc. will be handled by UUIDs from 1.8 onwards instead of usernames.
Note that commands like
/op will accept usernames as their arguments, but it is not the username that will be stored in the relevant database, but the UUID. More information about the transition from usernames to UUIDs can be found here.
When the 1.8 release nears, some changes to these operator procedures will likely result - one of note may be that the new player application form may also request a player's UUID in addition to their (current) username. However, we'll worry about this when the release of 1.8 is more imminent. So, for now, just familiarize yourself with the caveats of the transition to UUIDs, and be ready for some changes in the future.
Finally, this tool can be used to convert usernames to UUIDs and back again. It can also be used to determine if a UUID/username actually exists - a nonexistent UUID/username will return a "No information was found for this account!" error.
Reviewing whitelisting applications
The Google Docs spreadsheet with the data collected from the whitelisting application form here is at this location. All current and active operators have access to the spreadsheet, and these are the procedures for handling whitelisting applications.
- Remember that the data in the spreadsheet is considered private and confidential. Do not under any circumstances leak the information. Doing so will result in immediate revocation of all access to the spreadsheet and the Minecraft servers.
- Requests, even after being handled, should not be deleted.
- Operators should periodically check the spreadsheet to see if there are new requests, but usually FastLizard4 will do this and poke everyone else. We should aim for a one to two business day turnaround time for applications.
- An example entry will be at the top of the spreadsheet data section with some specific examples of what to look for in applications. This is kept private for obvious reasons.
- Application decisions must be unanimous amongst operators that can be reached to comment on the application within a reasonable but undefined timeframe.
- If there is not unanimity, operators should discuss the application until a consensus is reached
- Though, again, please aim for a one-to-two day turnaround time
- Exception: Applications that are clearly patent nonsense or spam can be closed unilaterally by an operator as "Discarded"
- Once consensus is reached amongst operators as to the resolution of a request, an operator will close the request as either "Accepted" or "Rejected"
- If "Rejected", the closing operator should send to the email address provided by the user in the form, a new ticket from the minecraft-s2-support queue with the template "Whitelisting application rejected", and note the OTRS ticket number in the appropriate place in the spreadsheet. Close the ticket as "closed successful".
- If "Accepted", any operator my add the player to the whitelist, and preferably the same operator should close the request and send the email to the user. The closing op should create a ticket, sent to the player's email address from the minecraft-s2-support queue, and containing the "Whitelisting application approved" template and state set to "closed successful".
- "Discarded" resolution is only used for requests that are patent nonsense, spam, etc. Discarded is like Rejected, except no notification is sent to the requester that their application was discarded.
- Individual operators may leave comments in the appropriate column in the spreadsheet (e.g., "Vote and comments: OperatorName")
If you receive a new ticket in OTRS asking for whitelisting, please reply to the ticket with the "Use form to submit whitelisting requests" answer template to direct them to the web form.
A note about application completeness and recommendations
The purpose of this application is like a finding of fact - to help establish who a user is and whether or not they can be trusted with server access. Incomplete applications from players none of the operators know should be considered sufficient grounds for denial because there is not enough information to establish this "trust line" if you will. However, for users whom one of the operators knows and trusts, and/or who is also a well-known and trusted user in Minecraft communities or the wider Internet world, an incomplete application should not be considered disqualifier because the trust line can be established using factors outside of the application. However, it should be noted that an operator's vote is up to the operator. In the end, this is just a suggestion on how to treat vouchers from other operators (and perhaps from other players, to a lesser extent), and in any case where there is disagreement amongst operators on the outcome of an application (i.e., differing votes), this should be reconciled in discussion instead of relying on well- and clearly-defined rules.
This section describes the technical procedure to whitelist a player on the server.
- Open Minecraft and connect to the server
- Type the following commands in order into chat, replacing playerName with the name of the player to be whitelisted:
/whitelist add playerName
- That's it! The player should now be whitelisted.
Occasionally, it may become necessary to ban a user due to violations of the server rules. Banning can be done unilaterally, but other operators should be notified of your reasons for a ban.
When banning a user, you should use the /ban commands in Minecraft, and not remove them from the whitelist. This is because bans can be temporary, and may be lifted at a later date.
s2 uses MCBans to manage bans. Bans can either be local (i.e., only applies to LizardNet Minecraft), or global (applies to LizardNet Minecraft and affects a player's global reputation in MCBans). Global MCBans apply to LizardNet Minecraft as well - any player with a reputation less than 3 (usually meaning they were globally banned on seven servers) will be automatically disallowed access unless overridden from within MCBans.
Remember that all bans made on s2 are automatically applied to m1 as well. However, it may take a server restart cycle for m1 to "see" the new banlist and apply them. Note that m1 won't have access to the ban reasons since it doesn't have MCBans installed; players will need to connect to s2 to see their ban reason. Likewise, for an offense on m1, an operator should set the ban on s2, and use the Minecraft server restart script on LizardNet Continuous Integration to force m1 to restart and thus apply the ban (if you don't have access to the script, poke FastLizard4; if you don't have a Jenkins account, simply create one yourself first). Any ban set for an infraction on m1 should never be made global on MCBans.
Operators can choose whether bans should be local or global. Bans may (and should) be made global if:
- The ban can be made global per MCBans' Global Ban Rules.
- The operator is willing to document screenshot or YouTube video proof of the violations.
- The operator has a MCBans account.
- MCBans accounts can be acquired by going to this page; the process does involve verifying your Minecraft identity by visiting a special server one-time.
- Even if you don't already have an account, you can create one and you will already have privileges to modify bans on LizardNet - the operators list has already been provided to MCBans.
Here are the commands:
- Ban a user locally
/ban <name|uuid> [reason]
- Ban a user globally
/ban <name|uuid> g <reason>
/gban <name|uuid> <reason>
- Ban a user locally, temporarily
/ban <name|uuid> t