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.

Important: UUIDs

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 /whitelist, /ban, and /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.

Whitelisting procedure

This section describes the technical procedure to whitelist a player on the server.

1. Open Minecraft and connect to the server
2. Type the following commands in order into chat, replacing playerName with the name of the player to be whitelisted:
   • /whitelist add playerName
   • /whitelist reload
3. That's it! The player should now be whitelisted.

Banning procedure

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:

1. The ban can be made global per MCBans' Global Ban Rules.
2. The operator is willing to document screenshot or YouTube video proof of the violations.
3. 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 <m, h, d, w> <reason>

/tban <name|uuid> <m(minute), h(hour), d(day), w(week)> [reason]

Ban a user locally, and automatically use CoreProtect to rollback all changes they made in the last 20 days (use with caution)

/rban <name|uuid> [reason]

Ban a user globally, and automatically use CoreProtect to rollback all changes they made in the last 20 days (use with caution)

/rban <name|uuid> g <reason>

Ban a user locally, temporarily, and automatically use CoreProtect to rollback all changes they made in the last 20 days (use with caution)

/rban <name|uuid> t <m, h, d, w> <reason>

Ban an IP address

/banip <ip> [reason]

/ban-ip <ip|name> [reason]

Unban a player, IP, or UUID (rescinds local and global bans)

/unban <name|ip|uuid>

After running any of the commands above, run the /mcbans sync command to synchronize changes.

When setting a global ban, please follow MCBans' Global Banning Guide.

Although you can now (and should) set a reason for the ban that will be displayed to the user in the ban command, operators should - after setting a ban - visit the ban tracking spreadsheet on Google Docs and append their ban to the bottom of the list, as the ban reason stored in Minecraft is very short and the spreadsheet provides room to explain your ban in more detail. The format of the file should be self-explanatory. Bans should not be removed from the list when the bans are themselves removed on the server; instead, the fields for ban removal date and ban removal reason should be filled out and the ban entry left in the spreadsheet. Bans should be added to the spreadsheet even though MCBans keeps track of all bans, so a record can be kept (MCBans retains no record of removed bans).

Operators can access the server dashboard in MCBans at this location. From here, operators can set and rescind bans remotely, convert global bans to local bans (and potentially vice-versa), as well as respond to global ban appeals. Operators can also, as they should, submit proof for a global ban by selecting it in the dashboard (proof should be submitted immediately after the ban is set).

It may occasionally be desirable, when unbanning a player, to clear the player's player.dat file; for example, if a player had been stealing items and you want his inventory cleared before unbanning him. In this case, let FastLizard4 know who you want to unban, and he'll delete the player's data and unban him for you.

Ban Appeals

Users are allowed to submit ban appeals to request that a ban against them be removed. That form is here. Operators can see the list of appeals, both past and current, at this spreadsheet.

There is one exception to this: If you, as banning operator, feel that the offense you are banning for is so severe and unforgivable that you believe that the perpetrator's access should be permanently revoked with no appeal, add "NO APPEAL" to the beginning of your ban reason as noted in the ban tracking spreadsheet. "NO APPEAL" bans can only be removed by operators; appeals will not be considered.

Further, there are restrictions on the ban appeal process that are noted on the first page of the form.

With that in mind, here is the procedure for handling ban appeals:

• When a ban appeal is added to the form results spreadsheet, the handling operator (usually the operator who set the ban in the first place) should first ensure that the appeal is not an automatic discard (e.g., the appeal is obviously spam or garbage, if the ban is a "NO APPEAL" ban, if the banned player hasn't yet passed the minimum time between appeals, etc.), then verify the email address.
  • To do this, create a new OTRS ticket directed at the email address provided in the ban appeal submission. Using the minecraft-s2-support queue, send a ticket with the contents of the "Ban appeal email address verification" template, and close it with the state Pending Reminder, setting a Pending Date about one week in the future. After sending the email, note the OTRS ticket number in the appropriate place in the ban appeals spreadsheet and set the email address verification status to "Not yet confirmed".
  • If the ticket goes into a Reminder state because the player didn't reply to it within the allotted week, or if the reply to the email indicates that the email address holder is unaffiliated with the player, mark the email address as invalid in the spreadsheet and mark the request as discarded. Close the ticket as "closed successful", sending a reply if deemed necessary.
  • On the other hand, if an email reply to the ticket is received that positively indicates that the email address is held by the banned player, respond to the ticket using the "Ban appeal email address verified" reply template and close the ticket as closed successful. Then set the email address verification cell to "Confirmed".
• Once a ban appeal email address is verified, it's passed on to the banning operator to consider the appeal. The banning operator has the final say on whether or not the appeal will be granted.
  • Unless the banning operator can't be reached within about a week, then another operator will handle the appeal.
• If the appeal was approved, the banning operator may remove the ban immediately (remember to also update the ban tracking spreadsheet with the ban removal date and reason)
• If the appeal is rejected, the banning operator should note such in the ban appeals spreadsheet, as well as their reason for rejecting.
• Finally, the handling operator should go back to the same OTRS ticket used to verify the player's email address and send a new reply - either based on the template "Ban appeal approve" or on "Ban appeal rejected", as appropriate. Either way, close the ticket as "closed successful".
• Again, only the banning operator should close an appeal as Approved or Rejected. However, anyone may close an appeal as Discarded if the appeal is obviously spam or garbage, if the ban in question is a "NO APPEAL" ban, or if the banned player hasn't yet passed the minimum time between appeals.

If a new ticket at OTRS is received asking for a ban appeal, please reply to the ticket with the "Use form to submit a ban appeal" canned response and close the ticket as "closed successful'.

Note that global bans submitted through MCBans can also be contested (within 60 days) on MCBans itself - however, this should only reset a ban as local instead of global, and users will still need to contest the ban using the form to have the local ban removed.

Abuse Reports

A unified abuse reporting form exists here with a results spreadsheet here. When there is a new abuse report, any operator may pick one to investigage if they aren't already investigating one, and should follow this procedure:

• First, the operator should indicate that they are handling the abuse report by putting their username in the appropriate spot ("handling operator") and marking status as "Investigation in progress".
• If a report is clearly in bad faith or is spam/garbage/etc., simply mark the report as Discarded
• The operator can then proceed with the investigation. If more information is needed, open an OTRS ticket to the reporting player with the "Abuse report - more information needed" templated text.
• Use CoreProtect logs and whatever else is at your disposal to perform your investigation.
• Once the investigation is completed, mark the abuse report has handled and note your findings in the spreadsheet. Also reply to/create a ticket to the reporting player using the "Abuse report - closed" canned response to explain the outcome of the investigation. Take any action you see fit (within the bounds of the server rules, of course) to handle the report.

Note that at whichever point above you open a new OTRS ticket for the report, remember to note the ticket number in the spreadsheet! Additionally, if someone tries to directly email an abuse report to OTRS, please use the "Use form to submit abuse/incident reports" canned response as we need the report on the spreadsheet for proper tracking (as well as the form guides the users in answering the appropriate questions).