Build a Help Desk Troubleshooting Lab

Deploy a ticketing system and resolve real support scenarios in Docker.

Introduction

30 Second Summary

When something breaks at work, someone has to figure out why. That someone is a support technician, and the skill that separates great ones from the rest is a structured, repeatable approach to diagnosing problems.

In this project, you will build a complete help desk troubleshooting lab on your local machine. You will deploy a real ticketing system, work through three realistic support scenarios, and document every fix like a professional technician.

What You'll Build

A self-hosted help desk lab using Docker containers, featuring a Peppermint ticketing system and an isolated "problem server" for hands-on troubleshooting practice.

By the end of this project, you'll have:

A running Peppermint ticketing system deployed with Docker Compose for creating and managing support tickets.
Three completed support tickets following the CompTIA troubleshooting methodology, with full diagnostic documentation.
Hands-on experience with Linux diagnostic tools like ping, nslookup, htop, and traceroute in realistic scenarios.
Secret Mission: Write a reusable knowledge base article that helps future technicians solve problems faster.

Are there any prerequisites?

You should have basic familiarity with the Linux terminal, like navigating directories and running commands. Some networking knowledge (what DNS and IP addresses are) is also helpful. No prior Docker or ticketing system experience is needed.

Before We Start

Before We Start...

Install Docker and Launch Peppermint

Before you can troubleshoot anything, you need two things: a way to run isolated environments and a ticketing system to document your work.

In this step, you will install Docker (the tool that runs containers) and launch Peppermint, an open-source ticketing system where you will log every support scenario like a real technician.

In this step, get ready to:

Install Docker Engine and Docker Compose on your Linux machine.
Launch the Peppermint ticketing system using Docker Compose.
Log into Peppermint and explore the interface.

Install Docker Engine and Docker Compose

Docker lets you run applications inside lightweight, isolated containers instead of installing them directly on your machine. You will install Docker from its official apt repository, which also gives you the Docker Compose plugin for managing multi-container applications.

Open your terminal.
Remove any older Docker packages that might conflict by running this command:

sudo apt-get remove docker docker-engine docker.io containerd runc 2>/dev/null

Set up Docker's official apt repository by running these commands:

sudo apt-get update
sudo apt-get install -y ca-certificates curl
sudo install -m 0755 -d /etc/apt/keyrings
sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc
sudo chmod a+r /etc/apt/keyrings/docker.asc

echo \
  "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/ubuntu \
  $(. /etc/os-release && echo "${UBUNTU_CODENAME:-$VERSION_CODENAME}") stable" | \
  sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

sudo apt-get update

What do these commands do?

These commands add Docker's official signing key and package repository to your system. This tells apt where to find the latest Docker packages and how to verify they are legitimate.

Install Docker Engine, the CLI tools, and the Compose plugin by running:

sudo apt-get install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

What does this install?

docker-ce is the Docker Engine that runs containers.
docker-ce-cli gives you the docker command you type in the terminal.
docker-compose-plugin provides the docker compose command (no hyphen) for managing multi-container setups.

Verify Docker is working by running the hello-world test container:

sudo docker run hello-world

You should see a message that says "Hello from Docker!" followed by an explanation of what just happened.

Not seeing "Hello from Docker!"?

If you see "permission denied", make sure you included sudo at the start of the command.
If you see "Cannot connect to the Docker daemon", the Docker service may not have started. Run sudo systemctl start docker and try again.
If the install command failed, double-check you are running Ubuntu (or a Debian-based distribution).

Still stuck? Help me troubleshoot my Docker installation on Linux.

Right now you need to type sudo before every Docker command. Adding your user to the docker group removes that requirement.

Add your user to the docker group by running:

sudo usermod -aG docker $USER

Apply the group change by running:

newgrp docker

Confirm it worked by running the hello-world container without sudo:

docker run hello-world

You should see the same "Hello from Docker!" message, this time without needing sudo.

Still getting "permission denied" without sudo?

The group change sometimes requires a full logout and log back in. Try closing your terminal completely, logging out of your Linux session, then logging back in and opening a fresh terminal.

Need help? Help me fix Docker group permissions on Linux.

Create the project directory and launch Peppermint

Peppermint needs two containers to run: one for the application itself and one for its PostgreSQL database. A docker-compose.yml file defines both containers so Docker can start them together with a single command.

Move to your Desktop by running this command:

cd ~/Desktop

Create your project folder and move into it by running these commands:

mkdir peppermint-lab
cd peppermint-lab

Confirm the folder exists by running:

ls ~/Desktop

You should see peppermint-lab in the output.

Create the docker-compose.yml file by running:

nano docker-compose.yml

Paste the following configuration into the editor:

# Defines the two services that make up the Peppermint ticketing system
version: '3'
services:
  # PostgreSQL database that stores all ticket data
  db:
    image: postgres:latest
    restart: always
    environment:
      POSTGRES_USER: peppermint
      POSTGRES_PASSWORD: peppermint
      POSTGRES_DB: peppermint
    volumes:
      - pgdata:/var/lib/postgresql/data
  # The Peppermint web application
  peppermint:
    image: peppermintsh/peppermint:latest
    restart: always
    ports:
      - '3000:3000'
    environment:
      DB_USERNAME: peppermint
      DB_PASSWORD: peppermint
      DB_HOST: db
      DB_PORT: 5432
      DB_NAME: peppermint
    depends_on:
      - db
# Named volume so your database data persists between restarts
volumes:
  pgdata:

What does this file define?

db is a PostgreSQL database container. It stores all your tickets, users, and settings.
peppermint is the web application container. It connects to the database and serves the ticketing interface on port 3000.
pgdata is a named volume that keeps your database data safe, even if the container restarts.
depends_on tells Docker to start the database before the Peppermint app.

Save the file by pressing Ctrl+O, then press Enter to confirm the filename.
Exit the editor by pressing Ctrl+X.

Start both containers in the background by running:

docker compose up -d

Docker will download the PostgreSQL and Peppermint images, then start both containers. This may take 1-3 minutes depending on your internet speed.

Confirm both containers are running by running:

docker compose ps

You should see two services listed with a status of "Up" or "running".

Containers not starting?

If you see a YAML error, check your indentation. YAML uses spaces, not tabs. Every nested line must be indented by exactly 2 spaces.
If the Peppermint container keeps restarting, the database may not be ready yet. Wait 30 seconds and run docker compose ps again.
If you see "port 3000 already in use", another application is using that port. Stop it first, or change the port mapping in your file to '3001:3000'.

Still stuck? Help me troubleshoot my Docker Compose setup for Peppermint.

✔️ Awesome, I've got everything!

Great. Double check you saved docker-compose.yml and both containers show a "running" status.

ⓧ I'd like to double check the full code

Here is the complete docker-compose.yml file. Compare it with yours and make sure every line matches.

version: '3'
services:
  db:
    image: postgres:latest
    restart: always
    environment:
      POSTGRES_USER: peppermint
      POSTGRES_PASSWORD: peppermint
      POSTGRES_DB: peppermint
    volumes:
      - pgdata:/var/lib/postgresql/data
  peppermint:
    image: peppermintsh/peppermint:latest
    restart: always
    ports:
      - '3000:3000'
    environment:
      DB_USERNAME: peppermint
      DB_PASSWORD: peppermint
      DB_HOST: db
      DB_PORT: 5432
      DB_NAME: peppermint
    depends_on:
      - db
volumes:
  pgdata:

Log into Peppermint and explore the interface

Peppermint is now running as a web application on your machine. You will use it throughout this project to create, document, and close support tickets.

Open your web browser.
Navigate to http://localhost:3000.

Give it a moment

Peppermint can take 30-60 seconds to fully initialize on first launch. If you see a blank page or a connection error, wait a minute and refresh.

You should see the Peppermint login screen.

Enter admin@admin.com in the email field.
Enter 1234 in the password field.
Click the Login button.

Why are we using default credentials?

These are the built-in admin credentials that come with every fresh Peppermint install. In a production environment, you would change these immediately. For this lab running on your local machine, they are fine to keep.

You should now see the Peppermint dashboard. Take a minute to explore the interface.

Look for the Tickets section in the sidebar. This is where all support tickets are listed and managed.
Find the option to create a new ticket. You will use this in the next step to log your first troubleshooting scenario.
Look for the Notebook section in the sidebar. This is where you can write internal documentation using markdown.

Can't reach http://localhost:3000?

Go back to your terminal and run docker compose ps to confirm both containers are running.
If the peppermint container shows "restarting", check the logs by running docker compose logs peppermint. The database may still be initializing.
Make sure you are using http:// and not https:// in the URL.

Need help? Help me get Peppermint running in my browser.

Your lab environment is ready. You have Docker running, a ticketing system live at localhost:3000, and a place to document every troubleshooting step. Next up, you will create your first "problem server" and start diagnosing real issues.

Set Up Your Troubleshooting Lab Environment

Your ticketing system is live and ready to accept work. Now you need something to actually troubleshoot.

In this step, you will spin up a separate Docker container that acts as a "problem server." You will also create your first support ticket in Peppermint and learn the structured troubleshooting methodology you will follow for every scenario.

In this step, get ready to:

Launch a problem server container with diagnostic tools pre-installed.
Create your first support ticket in Peppermint with realistic user details.
Add the CompTIA troubleshooting methodology checklist to your ticket notes.

Launch your problem server container

In a real support role, you would SSH into a remote server to diagnose issues. Here, you will use a Docker container running Ubuntu to simulate that experience safely on your own machine.

Start a new container in the background by running this command:

docker run -dit --name problem-server ubuntu:22.04

What does this command do?

This creates a container named problem-server from the ubuntu:22.04 image.

The -dit flags keep it running in the background with an interactive terminal attached. Think of it as a remote Linux server that is always on and waiting for you to connect.

Confirm the container is running by listing your active containers:

docker ps

You should see three containers listed: problem-server, and the two Peppermint containers from Step 1.

Don't see problem-server in the list?

If the container exited immediately, run docker ps -a to see all containers including stopped ones. Check the STATUS column for an error. The most common cause is a name conflict. If a container named problem-server already exists, remove it first with docker rm problem-server and try again.

Why isn't my problem-server container running?

The container is running, but it is a minimal Ubuntu installation with almost no tools. You need to install the diagnostic utilities that a support technician would use.

Connect to the problem server by running this command:

docker exec -it problem-server bash

Your terminal prompt changes to something like root@<container-id>:/#. You are now inside the container.

Update the package list and install all diagnostic tools by running this command:

apt update && apt install -y iputils-ping traceroute dnsutils htop procps iproute2 curl stress nano

What are these packages?

iputils-ping provides ping for testing basic network connectivity.
traceroute maps the network path between your server and a destination.
dnsutils provides nslookup for checking DNS resolution.
htop gives you a live view of CPU and memory usage.
procps provides free (memory stats), ps (process list), and top (system monitor).
iproute2 provides ss for checking open network ports and connections.
stress simulates high CPU load for the performance troubleshooting scenario later.

Verify the tools installed correctly by running a quick test:

ping -c 1 8.8.8.8

You should see a single successful ping reply showing 1 packets transmitted, 1 received. This confirms your problem server can reach the internet and ping is working.

Exit the container for now by typing:

exit

You are back on your host machine. The problem server keeps running in the background.

Seeing 'temporary failure in name resolution' during install?

This means the container cannot reach the internet. Make sure your host machine has a working internet connection. You can also try restarting Docker with sudo systemctl restart docker and then re-run the apt update command inside the container.

Why can't my Docker container reach the internet?

Create your first support ticket in Peppermint

Every troubleshooting scenario starts with a ticket. The ticket is your paper trail for what was reported, what you investigated, and what you did to fix it.

Open your browser and go to http://localhost:3000.
If you are not already logged in, sign in with admin@admin.com and password 1234.
Click New Issue on the dashboard.

A form opens where you can describe the issue. Fill it in as if a real user submitted this problem to your help desk.

In the Title field, enter User reports: Cannot reach company website.
In the description area, enter details that simulate a user report. For example: Reported by: Jamie Torres (Marketing). User states: 'I cannot access our company website from my workstation. The page just spins and never loads. Other websites seem to be working fine. Started happening this morning.'
Click Create Ticket to submit the issue.

Your new ticket should now appear in the ticket list. Click on it to open the ticket detail view.

Why write realistic details?

In a real help desk, the quality of your ticket documentation matters. Interviewers often ask you to walk through a past troubleshooting scenario. Practicing with realistic details now gives you a concrete example to reference later.

Don't see the New Issue button?

Make sure you are logged in as the admin account (admin@admin.com). If the page looks blank or broken, try a hard refresh with Ctrl+Shift+R. If Peppermint is not loading at all, check that the containers are still running with docker ps.

Help me troubleshoot my Peppermint dashboard.

Add the CompTIA troubleshooting methodology to your ticket

Professional support technicians do not just dive in and start changing things. They follow a structured process. The CompTIA troubleshooting methodology is the industry-standard framework tested on the A+ and Network+ certifications.

You will use this same six-step process for every ticket in this project.

What is the CompTIA troubleshooting methodology?

It is a seven-step framework (condensed here to six practical steps) that ensures you approach every problem systematically instead of guessing.

Identify the problem - Gather information from the user and reproduce the symptoms.
Establish a theory - Based on symptoms, hypothesize the most likely cause.
Test the theory - Run diagnostic commands to confirm or rule out your hypothesis.
Plan and implement - Decide on the fix, consider side effects, and apply it.
Verify - Confirm the issue is resolved and no new problems were introduced.
Document - Record everything: findings, actions, and outcome.

Now add this checklist to your ticket so you can fill it in as you work through the scenario.

Open your User reports: Cannot reach company website ticket in Peppermint.
Add a comment or note to the ticket. Peppermint supports markdown, so paste the following checklist into the comment area:

## Troubleshooting Checklist

1. **Identify the problem** - Symptoms:
2. **Establish a theory** - Probable cause:
3. **Test the theory** - Commands run and results:
4. **Plan and implement** - Fix applied:
5. **Verify** - Confirmation that it works:
6. **Document** - Summary of findings:

Why use markdown in your ticket?

Peppermint's editor supports markdown formatting. The numbered list with bold headers makes your ticket easy to scan. When you fill in each section during the troubleshooting process, anyone reviewing the ticket can quickly understand what happened.

Submit the comment to save the checklist to your ticket.

You should see the formatted checklist appear in your ticket's comment history. Each numbered step has a bold label followed by a placeholder where you will record your findings.

Your lab environment is fully set up. You have a problem server ready for diagnostics, a live ticket tracking your first scenario, and a repeatable methodology to guide your work. Next up, you will exec into the problem server and start diagnosing a real network connectivity issue.

Scenario 1 - Network Connectivity Troubleshooting

Your troubleshooting lab environment is ready to go. Peppermint is running, your problem server container is standing by, and Ticket #1 is open with the CompTIA troubleshooting checklist.

Time to work your first scenario. A user has reported they cannot reach the company website, and your job is to figure out why. You'll use Linux diagnostic tools to pinpoint the root cause, apply a fix, and document the entire process in your ticket.

In this step, get ready to:

Diagnose a DNS misconfiguration using ping, nslookup, and cat /etc/resolv.conf.
Fix the DNS issue and verify the network is fully working.
Document your troubleshooting process and close the ticket in Peppermint.

Diagnose the network issue inside your problem server

This is a training lab, so you'll set up the broken scenario first, then practice diagnosing it as if you just received the ticket from a user. This is how professional training environments work.

Exec into the problem server container by running this command:

docker exec -it problem-server bash

You should see a root@ prompt, confirming you're inside the container.

Simulate a DNS misconfiguration by overwriting the nameserver in /etc/resolv.conf:

echo "nameserver 10.0.0.1" > /etc/resolv.conf

Why am I breaking things on purpose?

In a real job, you wouldn't create the problem yourself. But in training labs, you set up the broken scenario first so you can practice diagnosing it systematically.

This command replaced the container's DNS configuration with a nameserver that doesn't exist. From this point on, pretend you're a technician who just received Ticket #1 and doesn't know what's wrong.

The CompTIA troubleshooting methodology starts with identifying the problem. The user says they can't reach a website. That could be a network issue, a DNS issue, or something else entirely. Start by testing the most basic layer: raw network connectivity.

Test basic network connectivity by pinging Google's public DNS server by IP address:

ping -c 4 8.8.8.8

You should see four replies with response times, ending with 4 packets transmitted, 4 received. This confirms the server can reach the internet at the network level.

Why ping by IP first?

Pinging by IP address bypasses DNS entirely. If this works, you've confirmed the network cable (or virtual network) is fine. That narrows the problem down to DNS or something above the network layer.

Now test DNS resolution by looking up a hostname with nslookup:

nslookup google.com

This time, you should see an error or a timeout. The command hangs or returns connection timed out; no servers could be reached. DNS resolution is broken.

What does this tell you?

The server can reach the internet by IP (ping works), but it cannot translate hostnames into IP addresses (nslookup fails). This is a classic DNS problem. Following the CompTIA methodology, your theory of probable cause is now a DNS misconfiguration.

Confirm the root cause by checking the DNS configuration file:

cat /etc/resolv.conf

You should see nameserver 10.0.0.1. This is the problem. The server is configured to use a nameserver that doesn't exist.

What is /etc/resolv.conf?

On Linux, /etc/resolv.conf is the file that tells the system which DNS server to use when translating hostnames (like google.com) into IP addresses. If the nameserver listed here is wrong, every hostname lookup on the system fails.

Ping not working either?

If ping 8.8.8.8 also fails, the issue is with Docker networking, not your DNS simulation. Make sure your host machine has internet access. Try restarting Docker with sudo systemctl restart docker, then exec into the container again.

Help me troubleshoot why ping is failing inside my Docker container.

Fix the DNS configuration and verify

You've identified the root cause: the nameserver in /etc/resolv.conf points to a server that doesn't exist. Following the CompTIA methodology, the next steps are to plan a fix, implement it, and verify that the system is fully working.

Fix the DNS configuration by replacing the broken nameserver with Google's public DNS:

echo "nameserver 8.8.8.8" > /etc/resolv.conf

What is 8.8.8.8?

8.8.8.8 is Google's free public DNS server. It's one of the most commonly used DNS servers in the world and a reliable fallback when a system's original DNS configuration is broken.

Verify that DNS resolution now works by running:

nslookup google.com

This time, you should see an IP address in the response (something like 142.250.x.x). DNS is working again.

Confirm end-to-end connectivity by pinging a hostname instead of an IP:

ping -c 4 google.com

You should see four successful replies. This confirms the server can now resolve hostnames AND reach the internet.

Run a traceroute to confirm the full network path is healthy:

traceroute google.com

You should see a list of numbered hops showing each router between your container and Google's servers. Some hops may show * * * if a router blocks ICMP packets. That's normal.

What does traceroute show?

Traceroute maps every router hop between your machine and the destination. Support technicians use it to pinpoint where along the path a connection is failing. In your case, seeing the full path confirms there are no routing problems between your server and the internet.

Traceroute hanging or showing all asterisks?

Some networks block ICMP packets that traceroute relies on. If it hangs indefinitely, press Ctrl+C to stop it. As long as nslookup and ping both succeeded, your fix is confirmed.

Help me understand why traceroute is not working inside my Docker container.

Document your findings and close the ticket

The last step of the CompTIA methodology is documentation. Professional technicians record everything they did so that future team members can learn from the resolution. This is what separates a junior tech from someone who's ready for the job.

Exit the problem server container by running:

exit

Open your browser and go to http://localhost:3000.
Navigate to your open ticket ("User reports: Cannot reach company website").
Add a detailed comment or note to the ticket documenting your full troubleshooting process.

Your documentation should cover each of the following sections. Write it in your own words, as if a coworker will read it tomorrow.

Symptoms observed: the user cannot reach websites by hostname. The server has internet connectivity (ping by IP works) but DNS resolution fails.
Diagnostic commands run: ping -c 4 8.8.8.8 (success, 4 packets received), nslookup google.com (failed, connection timed out), cat /etc/resolv.conf (showed misconfigured nameserver).
Root cause: /etc/resolv.conf contained a non-existent nameserver (10.0.0.1), causing all DNS lookups to fail.
Solution applied: updated /etc/resolv.conf to use Google's public DNS server (8.8.8.8).
Verification: nslookup google.com returned an IP address. ping -c 4 google.com succeeded. traceroute google.com showed the full network path.

Write it in your own words

Don't just copy-paste the list above. Rephrase it in your own words and include the actual output you saw in your terminal. Hiring managers reviewing your portfolio want to see that you understand what you did, not that you can follow a script.

After adding your documentation, change the ticket status to Resolved or Closed (depending on the options Peppermint shows).

Your ticket should now show as resolved with a complete diagnostic trail.

Can't find where to close the ticket?

In Peppermint, look for a status dropdown or a Mark as Done button on the ticket detail page. If you don't see one, try clicking the ticket's current status label to see if it opens a dropdown.

Help me find how to close or resolve a ticket in Peppermint.

Your first ticket is closed with a full diagnostic trail. Next up, you'll tackle a system performance issue where a user says everything is running slow.

Scenario 2 - System Performance Troubleshooting

Your first ticket is in the books. You tracked down a misconfigured DNS nameserver, fixed it, and documented the entire resolution in Peppermint.

Now a different kind of problem has landed on your desk. A user is reporting that everything is painfully slow. System performance issues are trickier than network problems because the root cause could be CPU, memory, disk, or something else entirely.

In this step, get ready to:

Identify a resource-hogging process using system monitoring tools.
Gather diagnostic data from disk, memory, and system logs.
Kill the runaway process and document the full resolution in Peppermint.

Create a ticket and identify the CPU hog

Following the CompTIA troubleshooting methodology, your first move is to identify the problem and document it. Open a new ticket before you touch anything on the server.

Open Peppermint in your browser at http://localhost:3000.
Click Create Ticket.
Set the title to User reports: Everything is slow, applications take forever to open.
Fill in the initial details as if a real user submitted this ticket. Note who reported it, when, and what they described.

Now you need a performance problem to investigate. In a real job, the runaway process would already be consuming resources when the ticket arrives. For your lab, you will start the process yourself.

Open your terminal. Make sure you are on your host machine, not inside any container.
Start a CPU stress process inside the problem-server container by running this command:

docker exec -d problem-server stress --cpu 2 --timeout 600

What does this command do?

The -d flag runs the command in the background (detached mode) inside the problem-server container.

The stress --cpu 2 command spawns two workers that consume as much CPU as possible. The --timeout 600 flag makes it run for 10 minutes, giving you plenty of time to diagnose.

Exec into the problem-server container by running this command:

docker exec -it problem-server bash

You are now inside the "slow server." Time to figure out what is eating up resources.

Launch the process monitor by running:

htop

How to read htop

htop shows a live view of every process on the system, sorted by resource usage. The bars at the top represent CPU and memory utilization.

Look at the CPU% column. You should see two stress processes near the top, each consuming close to 100% CPU. Note the PID (process ID) and CPU percentage of one of these processes. You will need these details for your ticket documentation.

You should see two stress processes at the top of the list, each showing close to 100% in the CPU% column. The CPU utilization bars at the top of the screen should be nearly full.

Don't see any stress processes?

The stress process has a 10-minute timeout. If you took a while between starting it and running htop, it may have already stopped. Exit the container with exit, then run the docker exec -d stress command again.

If htop itself is not found, try top instead. It shows the same information in a simpler layout.

Help me figure out why I can't see the stress process in htop.

Check disk, memory, and system logs

You found the CPU hog, but a thorough technician does not stop at the first symptom. Checking disk space, memory, and system logs rules out other problems that might be contributing to the slowdown.

Press q to exit htop and return to the terminal.
Check disk space usage by running:

df -h

Check memory usage by running:

free -h

Check the most recent system logs by running:

journalctl --no-pager -n 50

What do these results tell you?

df -h shows disk space usage for each mounted filesystem. Look for any partition close to 100% full. In your container, disk usage should be low.
free -h shows total, used, and available memory. If the available column is very low, memory is the bottleneck. In your case, memory should look healthy.
journalctl --no-pager -n 50 displays the last 50 system log entries. On a real server, this would show service crashes and kernel messages that might explain the slowdown.

The conclusion from all three checks is clear. Disk and memory are fine. CPU is the bottleneck, and the stress process is responsible.

Why does journalctl show limited output in my container?

Docker containers do not run a full init system like systemd. That means journalctl may show an error or no entries at all. This is expected.

On a real Linux server, journalctl would be one of your most valuable tools. Note this difference in your ticket so your documentation reflects what happened in your lab.

Switch to your browser and open your Ticket #2 in Peppermint.
Add your diagnostic findings to the ticket notes. Document each command you ran, the output you observed, and your conclusion that CPU is the bottleneck caused by the stress process.

Write like a real technician

Include the exact PID, CPU percentage, and command name from htop. Paste the key lines from df -h and free -h. A good ticket lets anyone reading it understand exactly what you saw without having to re-run the commands.

Kill the runaway process and close the ticket

You have identified the root cause and documented your findings. Time to fix it. The stress process is consuming all available CPU, so killing it should restore normal performance.

Switch back to your terminal. Make sure you are still inside the problem-server container.
Kill the stress process by running:

pkill stress

What does pkill do?

pkill sends a termination signal to every process matching the name you provide. This kills the parent stress process and both of its CPU-spinning worker processes in one command.

You could also use kill with a specific PID to target a single process. pkill is more convenient when you want to stop all instances of the same program at once.

Now verify that the system is back to normal. This is step 6 of the CompTIA methodology: verify full system functionality.

Run htop again to confirm the stress processes are gone:

htop

The CPU utilization bars at the top should now be nearly empty. No stress processes should appear in the list.

Press q to exit htop.
Confirm memory is healthy by running:

free -h

Memory usage should look similar to before. The fix is confirmed.

Exit the problem-server container by running:

exit

Still seeing stress processes in htop?

If pkill stress did not work, try pkill -9 stress to force-kill the processes. The -9 flag sends an unignorable kill signal.

Help me kill a process that won't stop in my Docker container.

The last step of the CompTIA methodology is documentation. A closed ticket without a clear trail is a missed opportunity for your team to learn from the resolution.

Switch to your browser and open Ticket #2 in Peppermint.
Update the ticket notes with your resolution. Include the root cause (runaway stress process consuming excessive CPU), the fix you applied (pkill stress), and the verification results (htop and free -h confirmed normal resource usage).
Close or resolve the ticket.

What should a complete performance ticket look like?

Your closed ticket should tell the full story in order.

Symptoms reported by the user (everything is slow).
Diagnostic commands and output (htop showed stress at ~100% CPU, df -h showed healthy disk, free -h showed healthy memory).
Root cause identified (runaway process consuming all available CPU).
Resolution applied (pkill stress).
Verification that the fix worked (htop and free -h confirmed normal usage).

Two tickets down, one to go. Your next scenario involves file permissions and introduces something new: the escalation workflow. Not every problem should be fixed by the first technician who touches it.

Scenario 3 - User Access and Permissions

Two scenarios down, two tickets closed. You have diagnosed a DNS misconfiguration and tracked down a runaway process eating CPU. Both tickets sit in Peppermint with full diagnostic documentation.

This final scenario tackles something every support technician deals with regularly: file permissions. A user is locked out of a shared folder they need for their work. You will diagnose the issue, fix it, and practice writing a professional escalation note.

In this step, get ready to:

Diagnose a Linux file permissions issue using ls -la, groups, and id.
Fix the access problem by adding a user to the correct group with usermod -aG.
Document the resolution and write a professional escalation note in Peppermint.

Create a ticket and simulate the permissions issue

Just like the previous two scenarios, you will follow the CompTIA troubleshooting methodology from start to finish. The first step is always the same: identify the problem and log a ticket.

Switch to your browser and open Peppermint at http://localhost:3000.
Click Create ticket.
Enter the title: User reports: Cannot access the shared-projects folder, getting Permission denied.
In the ticket description, write the initial report details: who reported it (a team member), when, and what error message they saw ("Permission denied").
Save the ticket.

Now you need to simulate the permissions problem inside your lab container. In a real job, the problem already exists on the server. In your lab, you create it yourself so you can practice diagnosing it.

If you exited the problem server container, exec back in by running this command in your terminal:

docker exec -it problem-server bash

Set up the permissions scenario by running these commands:

# Create a team group for the shared directory
groupadd devteam

# Create and configure the restricted directory
mkdir /shared-projects
chown root:devteam /shared-projects
chmod 770 /shared-projects

# Create a user who needs access but doesn't have it yet
useradd -m techuser

What does this set up?

You created a group called devteam and a directory called /shared-projects that only members of devteam can access.

chmod 770 means the owner and group get full read/write/execute permissions. Everyone else gets nothing. Since techuser is not in the devteam group, they fall into "everyone else" and are locked out.

Confirm the directory was created and inspect its permissions by running:

ls -la / | grep shared-projects

You should see output like drwxrwx--- root devteam ... shared-projects. The rwx for owner and group, and --- for others, tells you exactly who can and cannot access this directory.

Now simulate what the user experiences by trying to access the directory as techuser:

su - techuser -c "ls /shared-projects"

You should see ls: cannot open directory '/shared-projects': Permission denied. This confirms the user's report. Step one of the CompTIA methodology (identify the problem) is complete.

How do Linux file permissions work?

Every file and directory in Linux has three permission sets: one for the owner, one for the group, and one for others (everyone else).

When you run ls -la, the first column shows these permissions. r means read, w means write, x means execute (or access for directories). A dash (-) means that permission is denied.

Seeing 'group already exists' or 'user already exists'?

If you ran the setup commands more than once, you may see errors like groupadd: group 'devteam' already exists. These are safe to ignore. The group and user already exist from your first run.

Having a different issue? Help me troubleshoot permissions setup errors in my Docker container.

Confirm the root cause and fix the issue

You know techuser cannot access the directory, and you know the directory is restricted to the devteam group. Your theory: the user is not a member of that group. Time to test it.

Check the user's current group membership and apply the fix by running these commands:

# Step 3 of CompTIA methodology: test the theory
# Check which groups techuser belongs to
id techuser
groups techuser

# Theory confirmed - apply the fix
# Step 4-5: plan, implement the solution
usermod -aG devteam techuser

What do these commands do?

id techuser shows the user's UID, GID, and all group memberships. Before the fix, you will only see the default techuser group.
groups techuser shows just the group names. This confirms the user is missing from devteam.
usermod -aG devteam techuser adds the user to the devteam group. The -a flag means "append" so existing group memberships are preserved. The -G flag specifies a supplementary group.

Verify the fix by confirming group membership and testing access:

# Step 6 of CompTIA methodology: verify full system functionality
# Confirm the group was added
id techuser

# Test that techuser can now read the directory
su - techuser -c "ls /shared-projects"

# Test that techuser can write to the directory
su - techuser -c "touch /shared-projects/test-file.txt && echo 'Write access confirmed'"

What should I see?

id techuser should now show devteam in the groups list.
The ls command should run without errors. If the directory is empty, that is expected.
The touch command should print Write access confirmed. This proves the user has both read and write access.

Still seeing Permission denied?

Double check that the usermod command ran as root, not as techuser. Only root can modify group memberships. Your terminal prompt should show root@ before you run usermod.

Also confirm you included the -a flag. Without it, usermod -G replaces all supplementary groups instead of appending.

Need more help? Help me debug why usermod -aG did not fix my permissions issue.

Document the resolution and write an escalation note

This scenario introduces something the first two did not: an escalation note. In a real production environment, adding a user to a group that controls access to shared resources is not something a junior technician would do unilaterally. It typically requires approval from a senior admin or goes through a formal change management process.

Your job as the technician is to diagnose the issue, document what you found, explain the fix, and note why it needs approval. This shows hiring managers that you understand the boundaries of your role.

Switch back to Peppermint in your browser.
Open your third ticket.
Update the ticket with your full diagnostic documentation. Include each of the following sections:

Symptoms observed: "Permission denied" when accessing /shared-projects.
Diagnostic commands run: ls -la to check directory ownership, id and groups to check user membership.
Root cause: user was not a member of the devteam group that owns the directory.
Fix applied: usermod -aG devteam techuser to add the user to the correct group.
Verification: confirmed read and write access after group change.

What makes a good escalation note?

An escalation note communicates three things to the senior admin who reviews it. First, what you diagnosed and what evidence you collected. Second, what fix you recommend (or already applied in a lab setting). Third, why this change needs approval before being applied in production.

For this scenario, the key reason is that group membership changes affect access control across shared resources. Adding a user to the wrong group could expose sensitive files. In production, this kind of change goes through a formal approval process.

Add an escalation note to your ticket. Include these points:

The recommended fix is adding the user to the devteam group using usermod -aG.
This change affects access to shared team resources and should be approved by the team lead or a senior administrator.
In production, group membership changes should go through the organization's change management process to maintain an audit trail.

Close the ticket with the status set to resolved.

Your third ticket is now closed with a complete diagnostic trail and a professional escalation note. This is the kind of documentation that sets strong candidates apart in interviews.

Three scenarios complete. Three tickets closed. You have built a solid foundation of diagnostic skills and professional documentation. Next up is an optional challenge: turning one of your resolutions into a reusable knowledge base article that could help an entire support team.

Secret mission

Write a Knowledge Base Article

You've resolved three support tickets with full diagnostic documentation. Now write a reusable knowledge base article that could help future technicians solve the same problem faster. This is the kind of internal documentation that separates good technicians from great ones.

Before you go

Clean Up Your Resources

The Docker containers you created are running on your local machine and use minimal resources (roughly 500MB of RAM total). This project runs entirely locally, so there are no ongoing costs.

Decide whether to keep your resources running, pause them to come back later, or delete them entirely.

Resources you used:

Peppermint ticketing system (Docker container on port 3000).
PostgreSQL database (Docker container).
Problem server container (ubuntu:22.04 based).
Docker volume (pgdata) storing your PostgreSQL data.
Project directory with docker-compose.yml and Dockerfile.

Keep everything running

No action needed. Choose this if you want to practice more troubleshooting scenarios or reference your completed tickets later.

Your Peppermint ticketing system stays accessible at http://localhost:3000.
The containers restart automatically if you reboot your machine.
Your problem server container and all three completed tickets remain intact.

Pause - I'll come back to this later

Stop the running containers to free up memory while keeping all your data and tickets intact. You can start them again any time.

Stop the Peppermint containers by navigating to your project directory and running:

docker compose stop

Stop the problem server container by running:

docker stop problem-server

When you are ready to come back, start everything again with:

docker compose start
docker start problem-server

All your tickets, database data, and container files are preserved.

Delete - I don't want to use this again

Remove all project containers, volumes, and downloaded images to start completely fresh.

Remove the problem server container by running:

docker rm -f problem-server

Navigate to your project directory and remove the Peppermint containers and their data by running:

docker compose down -v

Reclaim disk space from downloaded Docker images by running:

docker system prune -a

Type y when prompted to confirm.
Optionally, delete the project directory from your Desktop.

Mission accomplished

Nice Work!

You just built a professional help desk troubleshooting lab and proved you can diagnose issues like a real support technician.

You've learned how to:

Deploy a production-style ticketing system (Peppermint) using Docker Compose to run interconnected containers on your local machine.
Diagnose and resolve three realistic support scenarios using Linux CLI tools like ping, nslookup, traceroute, htop, df, and free.
Document every scenario following the CompTIA troubleshooting methodology with proper ticket lifecycle management, including an escalation workflow.
Secret Mission: Write a reusable knowledge base article that demonstrates your documentation skills and helps future technicians solve the same problem faster.

Ready to quiz yourself?