Ops 1: Manual Minecraft Server

The CEO of Obsidian Dynamics read an article about “employee engagement” on a cross-country flight and landed with a vision: a company Minecraft server, live by Friday. The IT budget for this initiative is zero dollars. The headcount assigned to it is you. There was no discussion.

Your stakeholders do not care how it runs; they care that it is reachable, stable, and well-operated. You have one EC2 instance, an SSH key, and whatever dignity you brought to work this morning. Build the server completely manually on AWS Academy.

Learning Objectives

• Configure a Linux server to run a persistent network service.
• Apply baseline security controls (least privilege, SSH hygiene, network exposure).
• Demonstrate operational competence: start/stop, validate, and troubleshoot service behavior.
• Produce documentation that another operator could follow.

Constraints (AWS Academy)

• You must use AWS Academy resources only.
• Use EC2 for compute.
• Public exposure must be minimized:
  • SSH should be restricted to known IPs
  • The Minecraft port must be exposed only as required by the assignment.
• You must document cost controls (instance size choice + how/when you stop resources).
• If you use EC2 user-data for bootstrapping, it must be idempotent and defensible (e.g., for installing updates or a runtime). You may not use it to “bake in” configuration that you would otherwise do manually.

Requirements

A. Infrastructure and Access

• One Linux EC2 instance in a public subnet. You can choose the distribution you prefer.
• A Security Group that:
  • Allows Minecraft traffic on 25565/tcp (port could be different if you choose a non-default Minecraft server configuration).
  • Allows administrative access with a clear restriction strategy.
• A dedicated minecraft operating system user.

B. Service Operation

• A Minecraft Java Edition server (Paper recommended) runs as a managed service.
• You may use any defensible process manager/init approach (e.g., systemd or equivalent).
• The server starts automatically on reboot and restarts on failure.
• The world state persists across service restarts.

C. Documentation

Create an operator-facing, step-by-step tutorial runbook that includes:

• Exact setup steps from a fresh EC2 instance to a working Minecraft service.
• A dedicated section: How to Connect (admin SSH + player connection flow).
• A connection verification step using (port can differ if you choose a non-default Minecraft server configuration):

  nmap -sV -Pn -p T:25565 <public-endpoint>

• How to start/stop/restart and confirm service health.
• Where logs are, and what “healthy startup” looks like.
• How to apply updates safely.
• A dedicated section: Cost-Control Strategy (instance sizing choice, stop schedule, and guardrails).

Hints

These pointers will save you time on setup so you can focus on the operational skills this assignment is really about.

• Paper requires Java 21 or later. Once installed, verify with java -version.
• Download the latest Paper build from papermc.io/downloads/paper. Use curl -o paper.jar <url> on the server to download it directly.
• The server will refuse to start until you accept the Minecraft EULA. Run the server once; it will generate eula.txt and exit. Change eula=false to eula=true in that file, then start again.
• Your MOTD is set via the motd= line in server.properties.
• Review the webapp.service example in the Linux Server Planning and Configuration lecture and adapt it to your needs.

You can use any Minecraft server software you like. You can choose the Linux distribution you prefer. You can choose any process manager you like. The key is to ensure your documentation is clear and reproducible for another operator.

What You’ll Submit

1. Tutorial Runbook (PDF) written as a reproducible step-by-step setup guide that another operator with basic Linux knowledge could follow without asking you questions. Include:
   • setup from fresh EC2 to working service,
   • a How to Connect section,
   • the nmap connection test command and expected result,
   • a Cost-Control Strategy section,
   • all operations content required above.
2. Narrated screen recording (max 3 minutes). Your server MOTD must include your name or student ID. Submit timestamps alongside the video (e.g., “Checkpoint 1: 0:00, Checkpoint 2: 0:38, …”):
   1. Show the AWS console with your account ID visible, SSH into the instance, and run id minecraft (or equivalent) to prove the dedicated user exists.
   2. Reboot the instance, then run nmap -sV -Pn -p T:25565 <public-endpoint> showing the service is reachable and your custom MOTD (port can differ if you choose a non-default Minecraft server configuration).
   3. Show systemctl status <your-service> (or equivalent) confirming the service is active and enabled after the reboot.
   4. Stop the service, show it is stopped, start it again, and confirm health (e.g., nmap, systemctl status, or log output).

Rubric

Always refer to Canvas for the most up-to-date rubric information. Canvas's rubric will be used for grading.

Manual Minecraft Server on EC2 (Total: 100 pts)

Criteria	Ratings
Video: Instance and user setup (10) Video checkpoint 1: AWS console visible with account ID, SSH login shown, dedicated `minecraft` user existence proven (e.g., `id minecraft`).	10 pts Complete All three elements clearly shown in the video. 5 pts Partial One element is missing or unclear. 0 pts Missing Two or more elements are missing or not visible.
Video: Post-reboot nmap verification (15) Video checkpoint 2: instance is rebooted, then `nmap -sV -Pn -p T:25565 <public-endpoint>` output shows port open and Minecraft service responding with custom MOTD containing name or student ID. Server port can differ from default.	15 pts Complete Reboot shown or evidenced, nmap output shows 25565/tcp open with Minecraft service and custom MOTD. Server port can differ from default. 8 pts Partial Reboot or nmap shown but one detail is weak (e.g., MOTD missing name, incomplete output, or timing unclear). 0 pts Missing No credible post-reboot nmap verification shown.
Video: Auto-start confirmation (10) Video checkpoint 3: after reboot, `systemctl status` (or equivalent) confirms the service is active and enabled; uptime/PID is consistent with a post-reboot start.	10 pts Complete Service shown active and enabled after reboot with consistent uptime. 5 pts Partial Status shown but enabled state or post-reboot timing not clearly evidenced. 0 pts Missing No auto-start evidence after reboot.
Video: Stop/start cycle (10) Video checkpoint 4: service is stopped, status confirms it is stopped, service is restarted, and health is confirmed (e.g., nmap, status, or log output).	10 pts Complete Full stop/start cycle with health confirmation clearly shown. 5 pts Partial Cycle shown but health confirmation missing or unclear. 0 pts Missing No stop/start cycle demonstrated.
Runbook: Reproducible setup tutorial (20) Runbook walks through every step from a fresh EC2 instance to a running Minecraft service: instance creation, OS user setup, Java/runtime installation, server files, process manager configuration, and first successful start.	20 pts Exemplary All required steps present, correctly ordered, and specific enough that a new operator could follow without guesswork. 15 pts Proficient Most steps present and usable; minor gaps (e.g., a missing flag or ambiguous path) that would not block setup. 8 pts Developing Several steps missing or unclear; substantial inference required to complete setup. 0 pts Insufficient Instructions are incomplete, incorrect, or not reproducible.
Runbook: Security posture (15) Three controls documented: (1) dedicated `minecraft` OS user, (2) SSH restricted to specific IPs (not 0.0.0.0/0) or restriction strategy justified, (3) only ports 22 and 25565 open inbound. Server port can differ from default.	15 pts All controls All three security controls documented and correctly configured. 10 pts Two controls Two of three controls present and correct. 5 pts One control Only one control present or major misconfiguration in multiple controls. 0 pts No controls Security configuration missing or not evidenced.
Runbook: Operations procedures (10) Four operational items documented: (1) start/stop/restart commands, (2) health-check method, (3) log location with example of healthy output, (4) safe update procedure.	10 pts All items All four operational procedures documented clearly with expected outputs. 7.5 pts Three items Three of four items present and usable. 5 pts Two items Two of four items present. 0 pts Insufficient One or zero items documented.
Runbook: Cost-control strategy (10) Cost strategy includes: (1) instance size choice with rationale, (2) stop/shutdown schedule, (3) at least one guardrail (e.g., billing alert, lab session discipline, terminate when done).	10 pts Complete All three elements present and realistic. 7 pts Mostly complete Two of three elements present or one element is vague. 4 pts Partial Only one element present or strategy is generic. 0 pts Missing Cost-control strategy absent or not actionable.

Extra Credit (up to +10)

• Service/Process Hardening (+3): Apply at least 3 meaningful hardening controls for your chosen service manager/process approach and justify each in the runbook.
• Operational Diagnostics (+4): Add a short diagnostics section to the runbook with command-driven checks (e.g., ss, manager logs/status tools) and expected outputs for a healthy service.
• In-Service Administration (+3): Show how to administer the Minecraft server while it runs under your chosen manager (e.g., secure RCON setup), including at least 3 successful admin commands and safety notes.

Extra credit must stay within this assignment’s manual-operations scope (no Docker/Kubernetes, IaC, configuration-management frameworks, or backup/restore workflows).