Linux Log Detective

Investigate mock server logs and automate a repeatable incident report.

Introduction

30 Second Summary

When a server starts misbehaving, the clues are often scattered across pages of status messages. Checking every line by eye makes important patterns easy to miss.

In this project, you will investigate a mock server incident from a Linux terminal. You will create a reusable shell script that turns log evidence into a readable incident report.

What You'll Build

Picture running one triage command to see a clear incident report listing exact error counts plus failed-login counts.

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

  • A verified Linux shell showing your user identity at an absolute working-directory path.
  • A focused evidence trail with dedicated files for application errors. A separate file captures failed-login attempts.
  • A repeatable incident report generated by triage.sh with accurate counts for every finding.
  • Secret Mission: Add warning detection to triage.sh so incident-report.txt reports warning events from evidence/warnings.txt.

Are there any prerequisites?

You need a PC running Windows 10 version 2004 or later, or Windows 11, plus an internet connection for initial setup. The primary route uses Windows Subsystem for Linux (WSL), with LinuxOnTab as the no-admin browser fallback.

Before We Start

Before the investigation begins, take a moment to commit to the case you are about to solve. Your goal is to turn raw server logs into organized evidence and a repeatable report instead of inspecting every event manually.

Open a Real Linux Shell

You have committed to turning a mock incident into repeatable evidence. The investigation depends on Linux commands that behave consistently.

A genuine Linux shell gives you the filesystem behavior that this investigation needs. In this step, you will open that shell on Windows or use a browser fallback.

In this step, get ready to:
  • Check whether Ubuntu already runs with WSL 2.
  • Choose the primary setup route or the no-admin fallback.
  • Confirm your Linux username and current location.
Check for an existing WSL distribution

Windows Subsystem for Linux gives Windows a direct route into Linux tools. Your first check reveals whether an Ubuntu distribution is already available through Windows Subsystem for Linux (WSL).

Why WSL for this project?

WSL runs Linux command-line tools directly on Windows. It avoids the extra setup of managing a traditional virtual machine.

  • Press the Windows key to open Windows search.
  • Type Windows PowerShell into the search field.
  • Press Enter to open Windows PowerShell.
  • Check for installed WSL distributions by running this command:
wsl.exe --list --verbose

What does this command show?

The command lists each installed Linux distribution. The version column shows whether that distribution uses WSL 2.

Your result determines which setup route you need. Choose the matching tab below.

Choose your Linux setup route

An existing Ubuntu distribution gives you the quickest route into Linux. The other routes create an environment or provide one in your browser.

✔️ Ubuntu is listed with version 2

Your Ubuntu environment is already configured for WSL 2. Enter it from PowerShell.

  • Enter the installed Ubuntu distribution by running this command:
wsl.exe

What does this command do?

This command enters the default installed WSL distribution. Your prompt changes when the Linux shell opens.

You are now inside the Linux shell. Keep this terminal open for the final checks.

ⓧ No distribution is installed

Installing WSL requires administrator access because Windows enables system components. The installation also adds Ubuntu as your Linux distribution.

  • Close the current PowerShell window.
  • Press the Windows key to open Windows search.
  • Type Windows PowerShell into the search field.
  • Select Run as administrator.
  • Approve the Windows permission prompt.
  • Install the Linux environment by running this command:
wsl --install

What does this command do?

Windows enables the components required by WSL. It sets WSL 2 as the default and installs Ubuntu.

The installation can take a few minutes while Windows enables WSL and downloads Ubuntu. A restart may be required before the first Ubuntu launch.

  • Restart Windows when prompted.
  • Press the Windows key after signing back in.
  • Type Ubuntu into the search field.
  • Press Enter to launch Ubuntu.
  • Enter a Linux username when Ubuntu asks.
  • Enter a password when Ubuntu asks.
  • Re-enter the password when Ubuntu asks.

The password prompt can feel unresponsive because no characters appear while you type. Ubuntu still records every character.

Installation did not finish?

Confirm that PowerShell was opened with administrator access. Restart Windows if the installer requested it.

Use the browser fallback in the next tab if administrator access remains blocked.

help me troubleshoot WSL installation on my Windows PC.

Ubuntu opens a Linux prompt after the account setup finishes. Keep this terminal open for the final checks.

ⓧ Administrator access is blocked

LinuxOnTab runs an Alpine Linux environment inside your browser. This fallback needs no administrator access or package installation.

  • Press the Windows key to open Windows search.
  • Type the name of your preferred browser into the search field.
  • Press Enter to open the browser.
  • Open the LinuxOnTab shell in the browser.
  • Wait for the Alpine Linux terminal prompt to become ready.

The prompt confirms that the browser-based Linux shell is running. Keep this browser tab open for the final checks.

Confirm the shell identity and location

The shell now needs to prove three facts about itself. You will check its system information and current user before confirming its location.

  • Return to the Linux shell you opened through Ubuntu or LinuxOnTab.

Before you run the checks, what three details do you expect the shell to reveal?

  • Run the system and identity checks with these commands:
uname -a
whoami
pwd

What do these commands reveal?

  • The uname command prints the available system information.
  • The whoami command prints your current Linux username.
  • The pwd command prints the full path of your current directory.

All three commands should return output. The final line should be an absolute path that starts with /.

Missing one of the three results?

Confirm that you ran the commands inside Ubuntu or LinuxOnTab. PowerShell uses different commands for these checks.

Run each command on its own line if your terminal pasted them together.

help me check why a Linux identity or location command is not returning output.

Your Linux shell is ready and has proven its identity. Next, you will turn it into a mock incident workspace with logs to investigate.

Build the Incident Scene

The Linux shell from the last step is ready for real casework. You have already confirmed your identity plus location.

Raw logs need a visible home before you can investigate them. This workspace gives every navigation command plus file command a concrete purpose.

In this step, get ready to:
  • Build an organized workspace for logs plus evidence.
  • Populate an application log with eight timestamped events.
  • Add authentication records before inspecting the incident scene.
Lay out the investigation

A dedicated case directory keeps raw logs separate from evidence. The archive directory leaves space for records that are no longer active.

  • Build the workspace structure by running these commands:
cd ~
mkdir linux-log-detective
cd linux-log-detective
mkdir logs evidence archive

What do these commands do?

  • The first cd command returns your shell to its home directory.
  • The mkdir command creates the linux-log-detective directory.
  • The second cd command moves your shell into the new workspace.
  • The final mkdir command creates logs, evidence, plus archive.
  • Confirm your location plus directory structure by running these commands:
pwd
ls

What does this check prove?

  • The pwd command prints the absolute path to your current directory.
  • The ls command lists the workspace contents.

Good start. Your path ends in linux-log-detective, while the listing shows logs, evidence, plus archive.

Do the directories look different?

If the path does not end in linux-log-detective, the shell did not enter the workspace. Run the workspace commands again from your home directory.

If a directory is missing, check its spelling in the final mkdir command.

Ask for help with the workspace commands.

Record application activity

A here-document lets the shell write several lines into one file. The quoted delimiter preserves the log text exactly as entered.

  • Write the eight application events to logs/app.log by running this command:
cat > logs/app.log <<'EOF'
2026-10-19T09:00:01Z INFO api started
2026-10-19T09:02:14Z ERROR database connection timeout
2026-10-19T09:02:20Z WARN retry scheduled
2026-10-19T09:03:07Z INFO health check passed
2026-10-19T09:05:42Z ERROR payment request failed
2026-10-19T09:06:10Z WARN disk usage at 82 percent
2026-10-19T09:07:31Z ERROR database connection timeout
2026-10-19T09:08:00Z INFO health check passed
EOF

How does the application log get created?

  • The cat command collects every line between the two delimiters.
  • The > operator writes that content to logs/app.log.
  • The quoted EOF delimiter keeps the timestamps plus event text literal.
  • Display the new application log by running this command:
cat logs/app.log

What does this command show?

The cat command prints the complete file in its original order. This gives you a direct check of every saved event.

You will see eight timestamped events from 09:00:01Z through 09:08:00Z.

Is the shell still waiting for input?

Enter EOF by itself on a new line. Extra spaces prevent the shell from recognizing the closing delimiter.

If the file has fewer than eight lines, run the application log command again so the redirection replaces the incomplete content.

Ask for help with the application log.

✔️ Awesome, I've got everything!

Your logs/app.log file now contains all eight application events. The incident has a realistic mix of routine activity plus failures plus warning signals.

ⓧ I'd like to double check the full code

2026-10-19T09:00:01Z INFO api started
2026-10-19T09:02:14Z ERROR database connection timeout
2026-10-19T09:02:20Z WARN retry scheduled
2026-10-19T09:03:07Z INFO health check passed
2026-10-19T09:05:42Z ERROR payment request failed
2026-10-19T09:06:10Z WARN disk usage at 82 percent
2026-10-19T09:07:31Z ERROR database connection timeout
2026-10-19T09:08:00Z INFO health check passed

What should match?

Every timestamp plus event level should match this reference. The file should finish with the second successful health check.

Complete the incident scene

Authentication activity gives the investigation a second evidence source. Successful sessions sit beside failed login attempts from outside addresses.

  • Write the six authentication events to logs/auth.log by running this command:
cat > logs/auth.log <<'EOF'
2026-10-19T09:01:12Z INFO login user=maya status=success ip=10.0.0.8
2026-10-19T09:02:45Z FAILED login user=admin ip=203.0.113.10
2026-10-19T09:03:16Z INFO login user=lee status=success ip=10.0.0.9
2026-10-19T09:04:22Z FAILED login user=root ip=203.0.113.10
2026-10-19T09:05:11Z INFO logout user=maya ip=10.0.0.8
2026-10-19T09:06:39Z FAILED login user=admin ip=198.51.100.24
EOF

What does this log capture?

The command writes six authentication events to logs/auth.log. Three records describe normal account activity.

The remaining three records contain FAILED login attempts. Those records become security evidence in the next step.

✔️ Awesome, I've got everything!

The authentication log is now part of your incident scene. Your workspace contains both application activity plus account activity.

ⓧ I'd like to double check the full code

2026-10-19T09:01:12Z INFO login user=maya status=success ip=10.0.0.8
2026-10-19T09:02:45Z FAILED login user=admin ip=203.0.113.10
2026-10-19T09:03:16Z INFO login user=lee status=success ip=10.0.0.9
2026-10-19T09:04:22Z FAILED login user=root ip=203.0.113.10
2026-10-19T09:05:11Z INFO logout user=maya ip=10.0.0.8
2026-10-19T09:06:39Z FAILED login user=admin ip=198.51.100.24

What should match?

Every username plus address should match this reference. The file should contain three INFO records plus three FAILED records.

Before you run the final check, what should the three commands reveal about your location plus workspace plus application data?

  • Verify the complete incident scene by running this command:
pwd; ls; cat logs/app.log

What does the final check prove?

  • The pwd command proves your shell is inside the investigation workspace.
  • The ls command proves the three top-level directories exist.
  • The cat command proves the application log contains readable incident data.

You will see an absolute path ending in linux-log-detective. The output also shows logs, evidence, archive, plus eight application events.

Does the final check look incomplete?

If the directory listing is incomplete, rerun the workspace creation commands. Existing directories remain available.

If the application events do not print, compare logs/app.log with the full reference above.

Ask for help with the final workspace check.

Your mock incident now has a complete case scene with raw application plus authentication activity. Next, you will replace manual scanning with focused evidence extraction.

Extract the Evidence

The mock incident scene you built is ready inside ~/linux-log-detective. Its raw logs mix useful clues with routine events.

Manual scanning makes incident counts slow. In this step, you will turn that noise into focused evidence files with exact counts.

In this step, get ready to:
  • Compare the mixed raw logs with focused incident evidence.
  • Extract incident records into separate evidence files.
  • Verify each evidence count with shell input tools.
Experience the noisy version first

A raw incident view can contain several event types at once. Your attention has to jump between patterns across both logs.

Before you run the combined view, how quickly do you think you can count both incident types without a filter?

  • Display both raw logs together by running this command:
cat logs/app.log logs/auth.log

What does this command show?

  • The command prints every record from logs/app.log.
  • It immediately continues with every record from logs/auth.log.
  • Count the ERROR records by eye.
  • Count the FAILED records by eye.

You have to track two patterns across 14 mixed records. That manual count is slow enough to invite mistakes.

Don't see both logs?

  • Use pwd to confirm you are still inside ~/linux-log-detective.
  • Review the file paths in the command for missing letters.

Help me troubleshoot missing log output in this incident workspace.

Filter matches into evidence files

The grep command selects lines that contain one exact pattern. Output redirection sends those selected lines into a file.

  • Create both evidence files by running these commands:
grep "ERROR" logs/app.log > evidence/app-errors.txt
grep "FAILED" logs/auth.log > evidence/failed-logins.txt

How do these filters work?

  • The first command searches logs/app.log for ERROR records.
  • Its > writes those matches to evidence/app-errors.txt.
  • The second command searches logs/auth.log for FAILED records.
  • Its > writes those matches to evidence/failed-logins.txt.
  • Inspect both filtered evidence files by running these commands:
cat evidence/app-errors.txt
cat evidence/failed-logins.txt

What should you see?

  • The first file contains the three ERROR records from the application log.
  • The second file contains the three FAILED records from the authentication log.
  • Routine records no longer compete for your attention.

Are the evidence files empty?

  • Check that ERROR uses uppercase letters.
  • Check that FAILED uses uppercase letters.
  • Confirm each output path starts with evidence/.

Help me fix empty evidence files after filtering the incident logs.

Count the findings two ways

A shell pipeline connects one command's output to the next command's input. Input redirection feeds a saved file into a command.

  • Compare both counting methods by running these commands:
grep "FAILED" logs/auth.log | wc -l
wc -l < evidence/app-errors.txt

How do these counting methods differ?

  • The | sends matching login records directly into wc -l.
  • The < feeds the saved application evidence into wc -l.
  • Both methods count newline-separated records.

You will see 3 from the pipeline. You will see 3 from the saved application evidence.

Before the final check, do you expect both saved evidence files to return the same line count?

  • Verify both stored counts by running this command:
wc -l < evidence/app-errors.txt; wc -l < evidence/failed-logins.txt

What does this final check prove?

  • The first count measures the stored application errors.
  • The second count measures the stored failed logins.
  • Matching counts confirm that both filters captured three incident records.

You will see 3 on each line. Solid work. Your case now has two defensible evidence counts.

Do the counts differ?

  • Confirm the two evidence file names match the paths shown above.
  • Repeat the filtering commands if either evidence file contains the wrong records.
  • Inspect both evidence files for routine events that slipped through.

Help me diagnose an unexpected evidence count in this mock incident.

The raw logs now lead to focused evidence with verified counts. Next, you will automate the same investigation with a reusable triage script.

Create the Triage Script

The evidence files now separate application errors from failed logins. Repeating those filters manually becomes slow as an investigation grows.

In this step, you will package the investigation into a reusable shell script. The script also creates a readable incident report from the refreshed evidence.

In this step, get ready to:
  • Create a portable shell script that refreshes both evidence files.
  • Write a grouped report block that records the user and finding counts.
  • Reproduce a direct-execution permission wall.
Create the portable script

A POSIX shell script can run in Ubuntu or the browser fallback used in this project. The #!/bin/sh declaration tells the system which interpreter should read the file.

  • Create triage.sh inside your current ~/linux-log-detective directory by running this command:
cat > triage.sh <<'EOF'
#!/bin/sh

grep "ERROR" logs/app.log > evidence/app-errors.txt
grep "FAILED" logs/auth.log > evidence/failed-logins.txt

{
  echo "Linux Incident Report"
  echo "Generated by: $(whoami)"
  echo "Application errors: $(wc -l < evidence/app-errors.txt)"
  echo "Failed logins: $(wc -l < evidence/failed-logins.txt)"
} > incident-report.txt

cat incident-report.txt
EOF

What does this script do?

  • The two grep commands refresh the focused evidence files from the unchanged logs.
  • The grouped block sends every report line into incident-report.txt.
  • The whoami command records the user who generated the report.
  • The wc commands count the stored evidence through input redirection.
  • The final cat command prints the finished report in the terminal.
  • Confirm that triage.sh exists by running this command:
ls -l triage.sh

What should you see?

The long listing includes a file named triage.sh. This confirms that the here-document saved the script in your current directory.

Script file missing?

Check that your shell is still inside ~/linux-log-detective. Make sure the closing EOF started at the beginning of its line.

help me troubleshoot why triage.sh was not created by my shell here-document.

✔️ Awesome, I've got everything!

Your script now matches the investigation workflow.

ⓧ I'd like to double check the full code

#!/bin/sh

grep "ERROR" logs/app.log > evidence/app-errors.txt
grep "FAILED" logs/auth.log > evidence/failed-logins.txt

{
  echo "Linux Incident Report"
  echo "Generated by: $(whoami)"
  echo "Application errors: $(wc -l < evidence/app-errors.txt)"
  echo "Failed logins: $(wc -l < evidence/failed-logins.txt)"
} > incident-report.txt

cat incident-report.txt
Remove execute permission

Linux tracks whether each user category may run a file through execute permission. Removing that permission recreates a script that has been delivered as a readable file without direct execution rights.

  • Remove execute permission from triage.sh by running these commands:
chmod a-x triage.sh
ls -l triage.sh

What do these commands show?

  • The a applies the permission change to the owner, group, and other users.
  • The -x removes permission to execute the file.
  • The -l option displays the file's permission characters.

You will see triage.sh in the long listing. None of its user, group, or other permission sections contains x.

Test direct execution

The script contents are complete. Its permission state now determines whether the shell can start it as a program.

Before you run it, consider this question: can the shell start the script directly from this permission state.

  • Test direct execution by running this command:
./triage.sh

The permission wall is expected

The shell returns a permission-denied error. This intended failure proves that valid script contents do not grant permission to execute the file.

  • Confirm the permission state behind the failure by running this command:
ls -l triage.sh

What proves the obstacle?

The long listing still shows no x in the permission characters. The direct-run failure now has a visible cause.

Did the script run instead?

Return to the permission-removal command if the report printed successfully. Confirm that the long listing contains no execute character before testing direct execution again.

help me reproduce the missing execute permission on triage.sh.

You have built the complete triage script and proved the permission wall that blocks it. Next, you will repair that exact permission state and generate the incident report.

Run the Incident Report

Your shell script triage.sh already turns raw logs into a report. The previous direct run showed that Linux blocks the file without execute permission.

Owner execute permission closes that gap. A successful direct run turns your investigation into a reusable command.

In this step, get ready to:
  • Grant execute permission to the owner of triage.sh.
  • Run triage.sh directly to regenerate the report.
  • Inspect the finished incident case files.
Grant execute permission to the owner

The owner permission triplet controls what the file owner can do with triage.sh. Adding x allows that owner to run the script as a program.

  • Grant owner execute permission by running the first command below.
  • Display the updated permission characters by running the second command below.
chmod u+x triage.sh
ls -l triage.sh

What changed?

The chmod command updates file permissions. The u+x mode adds execute permission for the file owner.

The ls -l command displays the updated permission characters. The owner's triplet now contains x.

You'll see x in the owner's permission triplet. The group and other triplets still have no execute permission.

Owner Permission Still Missing?

  • Confirm that the long listing shows the file named triage.sh.
  • Return to the Linux shell from earlier if you entered the command somewhere else.
  • Repeat the permission command if the owner triplet still lacks x.

Help me understand why the owner execute permission is still missing.

This permission update changes the file's metadata. The script contents remain identical.

  • Choose the matching tab to confirm that your case files still contain the target content:

✔️ Awesome, I've got everything!

Your logs and script match the target files. The script is ready for its repaired direct run.

ⓧ I'd like to double check the full code

The application log remains the source of application events in your case file.

2026-10-19T09:00:01Z INFO api started
2026-10-19T09:02:14Z ERROR database connection timeout
2026-10-19T09:02:20Z WARN retry scheduled
2026-10-19T09:03:07Z INFO health check passed
2026-10-19T09:05:42Z ERROR payment request failed
2026-10-19T09:06:10Z WARN disk usage at 82 percent
2026-10-19T09:07:31Z ERROR database connection timeout
2026-10-19T09:08:00Z INFO health check passed

What does this log contain?

This unchanged log contains eight timestamped application events. Its three ERROR records provide the application evidence for the report.

The authentication log remains the source of login activity in your case file.

2026-10-19T09:01:12Z INFO login user=maya status=success ip=10.0.0.8
2026-10-19T09:02:45Z FAILED login user=admin ip=203.0.113.10
2026-10-19T09:03:16Z INFO login user=lee status=success ip=10.0.0.9
2026-10-19T09:04:22Z FAILED login user=root ip=203.0.113.10
2026-10-19T09:05:11Z INFO logout user=maya ip=10.0.0.8
2026-10-19T09:06:39Z FAILED login user=admin ip=198.51.100.24

What does this log contain?

This unchanged log contains six timestamped authentication events. Its three FAILED records provide the failed-login evidence for the report.

The triage script refreshes both evidence files before generating the report.

#!/bin/sh

grep "ERROR" logs/app.log > evidence/app-errors.txt
grep "FAILED" logs/auth.log > evidence/failed-logins.txt

{
  echo "Linux Incident Report"
  echo "Generated by: $(whoami)"
  echo "Application errors: $(wc -l < evidence/app-errors.txt)"
  echo "Failed logins: $(wc -l < evidence/failed-logins.txt)"
} > incident-report.txt

cat incident-report.txt

How does the script build the report?

  • The two grep commands refresh the focused evidence files from the raw logs.
  • The grouped report block calculates both line counts before writing incident-report.txt.
  • The final cat command displays the generated report in your terminal.
Run the repaired script

Direct execution now has the permission it needs. The script can refresh the evidence before rebuilding the report with your current Linux username.

Before you run it, do you expect the script to complete or hit the same permissions wall?

  • Run the executable script directly by entering:
./triage.sh

What does this run do?

  • The script refreshes evidence/app-errors.txt from the application log.
  • The script refreshes evidence/failed-logins.txt from the authentication log.
  • The report block uses whoami to record the current Linux username.
  • The final command displays the generated report.

You'll see Linux Incident Report at the top. The next line shows your current Linux username.

You'll see Application errors: 3 followed by Failed logins: 3. That permission repair has turned your investigation into a working command.

Script Still Blocked?

  • Return to the permission check above if the shell still blocks direct execution.
  • Confirm that the script is named triage.sh.
  • Confirm that your prompt still points to ~/linux-log-detective.

Help me troubleshoot why the script still cannot run directly.

Inspect the finished case files

A useful incident case preserves both the focused evidence and its summary. Inspecting each file confirms that the automation kept the supporting records available.

  • Display the evidence listing and finished case files by running:
ls -l evidence
cat evidence/app-errors.txt
cat evidence/failed-logins.txt
cat incident-report.txt

What does this inspection prove?

  • The long listing confirms that both evidence files remain inside evidence.
  • The next two commands display the exact records supporting each count.
  • The final command displays the readable summary stored in incident-report.txt.

You'll see three application error records in evidence/app-errors.txt. You'll also see three failed-login records in evidence/failed-logins.txt.

The report preserves those totals in a compact summary. Your raw logs remain unchanged.

Before the final check, do you expect regenerating the report to preserve both counts?

  • Regenerate the incident report and display the saved file by running:
./triage.sh; cat incident-report.txt

Why does the report appear twice?

The script prints the report after generating it. The second command prints the saved file again to confirm its final contents.

The regenerated report shows Application errors: 3. It also shows Failed logins: 3.

You have repaired the exact permissions failure from the previous step. Your repeatable incident report now runs successfully from start to finish.

Secret mission

Add Warning Detection

Two warning signals are still missing from your incident report. Extend the executable triage script so it captures warning evidence and includes the warning count in every regenerated report.

Clean Up Your Resources

Clean Up Your Resources

Choose whether to keep your incident workspace, pause your shell session, or remove the workspace entirely. This project uses local files inside your Linux environment, so there are no paid cloud resources or ongoing costs.

Resources you used:

  • The local ~/linux-log-detective directory with the complete incident workspace.

Keep everything running

No action is needed. Choose this option if you want to reuse the incident workspace for more Linux practice.

  • Leave the ~/linux-log-detective directory in place.
  • Keep your Linux environment available for another terminal project.

Pause - I'll come back to this later

Shut down the current shell session while keeping every project file. You can return to the workspace later.

  • Save a persistent snapshot in LinuxOnTab if you used the browser fallback.
  • Leave the Linux shell by running this command:
exit

What Happens When You Exit?

The exit command ends the current shell session. Your ~/linux-log-detective directory remains available for your next session.

Delete - I don't want to use this again

Remove the complete project workspace if you want to start fresh. Your Linux environment remains available after this cleanup.

Check Before You Delete

Deleting this folder is permanent. The Linux rm command does not use a recycle bin.

This cleanup removes only the project workspace. It does not remove Ubuntu, WSL, or LinuxOnTab.

  • Confirm the deletion target by running these commands:
cd ~
pwd
ls

What Do These Checks Prove?

The cd ~ command moves you to your home directory. The pwd command prints its full path.

The ls output should include linux-log-detective. This confirms the workspace exists at the expected location.

  • Remove the project workspace by running these commands:
rm -r linux-log-detective
ls

What Should You See?

The rm -r linux-log-detective command recursively removes the project directory. The final ls output should no longer include linux-log-detective.

Your mock logs, evidence files, triage.sh, and incident-report.txt are now deleted. Your Linux environment is ready for another project.

Nice Work!

Nice Work!

Case closed. You've built a repeatable Linux terminal investigation that turns raw server logs into a readable incident report.

You've learned how to:

  • Navigate the Linux filesystem to create an organized incident workspace in ~/linux-log-detective.
  • Turn noisy logs into focused evidence with grep. Produce repeatable counts through pipes plus redirection with wc.
  • Fix execute permissions with chmod. Run a portable sh script that regenerates incident-report.txt.
  • Secret Mission: Extend the script with warning detection while preserving the existing error counts.

Your case file now contains organized evidence. One reusable command refreshes the report whenever the logs change.

Ready to quiz yourself?