587 lines
59 KiB
JSON
587 lines
59 KiB
JSON
{
|
|
"meta": {
|
|
"version": "5.1",
|
|
"title": "Linux Operations Learning Lab",
|
|
"author": "Codex",
|
|
"updated": "2026-03-19",
|
|
"description": "A rebuilt Linux learning path that moves from command basics to real operations troubleshooting with sandbox exercises.",
|
|
"module_count": 8,
|
|
"total_lessons": 24,
|
|
"total_exercises": 82,
|
|
"pedagogy": "learning-first",
|
|
"orientation": "ops-workflow"
|
|
},
|
|
"modules": [
|
|
{
|
|
"id": "module_1_foundation",
|
|
"title": "Module 1: Build Linux spatial awareness",
|
|
"summary": "Start with location and listing so every later action has context.",
|
|
"lessons": [
|
|
{
|
|
"id": "m1_l1_pwd",
|
|
"title": "Locate yourself with pwd",
|
|
"goal": "Understand the current working directory before changing files or running scripts.",
|
|
"why_it_matters": "Many Linux mistakes come from running the right command in the wrong path.",
|
|
"concepts": ["Current working directory", "Absolute vs relative path", "Context before action"],
|
|
"command": "pwd",
|
|
"examples": ["pwd", "cd /tmp && pwd"],
|
|
"pitfalls": ["Assuming every shell opens in the same place", "Running a file command before checking the path"],
|
|
"scenarios": ["Verify where you are before editing a file", "Confirm location before launching a script"],
|
|
"troubleshooting_flow": ["Confirm the working context", "Run pwd", "Use the output to choose the next command"],
|
|
"related_commands": ["pwd", "cd", "ls"],
|
|
"classic_view": "Treat pwd as the command that restores orientation before every other action.",
|
|
"takeaways": ["Know your location before acting", "Read the full path instead of guessing", "Use location to decide the next safe step"],
|
|
"after_class": "Repeat pwd before every directory-changing command until it becomes automatic.",
|
|
"exercises": [
|
|
{ "id": "m1_l1_e1", "type": "understanding", "question": "Which command prints the full current working directory?", "answer": "pwd" },
|
|
{ "id": "m1_l1_e2", "type": "operation", "title": "Print the current working directory", "hint": "Run pwd directly.", "success_test": "cmd == 'pwd'", "solution": ["pwd"], "success_msg": "You verified the shell location correctly." },
|
|
{ "id": "m1_l1_e3", "type": "scenario", "question": "If a script fails with 'file not found', what should you check first?", "answer": "Run pwd and verify the current path before anything else." }
|
|
]
|
|
},
|
|
{
|
|
"id": "m1_l2_ls",
|
|
"title": "Inspect a directory with ls",
|
|
"goal": "Observe directory content and switch to detail views when needed.",
|
|
"why_it_matters": "Linux exploration usually begins with ls because you need to know what exists before you inspect more deeply.",
|
|
"concepts": ["Directory contents", "Hidden files", "Long listing output"],
|
|
"command": "ls",
|
|
"examples": ["ls", "ls -la", "ls -l /etc"],
|
|
"pitfalls": ["Thinking a hidden file does not exist because plain ls missed it", "Reading long output without understanding permissions or size"],
|
|
"scenarios": ["Check what files exist before deleting anything", "Inspect a config directory for hidden dotfiles"],
|
|
"troubleshooting_flow": ["List the directory first", "Switch to ls -la if details matter", "Use the listing to choose the next file command"],
|
|
"related_commands": ["ls", "find", "stat"],
|
|
"classic_view": "Observation comes before diagnosis, and ls is usually the first observation tool.",
|
|
"takeaways": ["Use ls for broad visibility", "Use ls -la for hidden files and metadata", "Treat the listing as evidence"],
|
|
"after_class": "Practice comparing ls and ls -la until you can explain why the outputs differ.",
|
|
"exercises": [
|
|
{ "id": "m1_l2_e1", "type": "understanding", "question": "Why does ls -a reveal more than plain ls?", "answer": "Because it includes hidden dotfiles." },
|
|
{ "id": "m1_l2_e2", "type": "operation", "title": "List the current directory", "hint": "Start with ls.", "success_test": "cmd == 'ls'", "solution": ["ls"], "success_msg": "You listed the current directory." },
|
|
{ "id": "m1_l2_e3", "type": "operation", "title": "Show hidden files and details", "hint": "Use ls -la.", "success_test": "cmd == 'ls -la' or cmd == 'ls -al'", "solution": ["ls -la", "ls -al"], "success_msg": "You switched from a simple listing to a full inspection view." }
|
|
]
|
|
},
|
|
{
|
|
"id": "m1_l3_cd_cat_echo",
|
|
"title": "Move, read, and confirm with cd, cat, and echo",
|
|
"goal": "Use navigation, file reads, and quick output together as one everyday workflow.",
|
|
"why_it_matters": "Many Linux tasks are just a chain of navigate, inspect, and confirm.",
|
|
"concepts": ["Changing directories", "Reading text files", "Using echo for quick verification"],
|
|
"command": "cd / cat / echo",
|
|
"examples": ["cd /tmp", "cat /etc/hosts", "echo Hello Linux"],
|
|
"pitfalls": ["Using cat on a directory", "Changing directories without verifying where you landed", "Ignoring echo as a debugging aid"],
|
|
"scenarios": ["Enter a workspace and inspect a config file", "Print quick checkpoints in a shell session"],
|
|
"troubleshooting_flow": ["Change to the right location", "Read the right file", "Echo the key assumption you want to verify"],
|
|
"related_commands": ["cd", "cat", "echo", "pwd"],
|
|
"classic_view": "These commands make context and state visible before you do more powerful operations.",
|
|
"takeaways": ["Use cd intentionally", "Use cat for quick text inspection", "Use echo to make invisible state explicit"],
|
|
"after_class": "Practice saying out loud what each command changed in your working context.",
|
|
"exercises": [
|
|
{ "id": "m1_l3_e1", "type": "operation", "title": "Enter /tmp", "hint": "Use cd /tmp.", "success_test": "cmd == 'cd /tmp' and cwd == '/tmp'", "solution": ["cd /tmp"], "success_msg": "You moved to the target working directory." },
|
|
{ "id": "m1_l3_e2", "type": "operation", "title": "Read the hosts file", "hint": "Run cat /etc/hosts.", "success_test": "cmd == 'cat /etc/hosts' and 'localhost' in output", "solution": ["cat /etc/hosts"], "success_msg": "You inspected a real text file in the sandbox." },
|
|
{ "id": "m1_l3_e3", "type": "operation", "title": "Print a confirmation message", "hint": "Run echo Hello Linux.", "success_test": "cmd == 'echo Hello Linux' and 'Hello Linux' in output", "solution": ["echo Hello Linux"], "success_msg": "You used echo to make the current step explicit." }
|
|
]
|
|
}
|
|
]
|
|
},
|
|
{
|
|
"id": "module_2_filesystem",
|
|
"title": "Module 2: Manipulate files safely",
|
|
"summary": "Learn to create, copy, move, and permission files without losing context.",
|
|
"lessons": [
|
|
{
|
|
"id": "m2_l1_create",
|
|
"title": "Create structure with mkdir and touch",
|
|
"goal": "Build directories and empty files quickly so you can prepare workspaces or examples.",
|
|
"why_it_matters": "Project setup and environment preparation often begin with directory scaffolding.",
|
|
"concepts": ["Directory creation", "Recursive directory creation", "Empty file creation"],
|
|
"command": "mkdir / touch",
|
|
"examples": ["mkdir /tmp/lab", "mkdir -p /tmp/lab/data/raw", "touch /tmp/lab/notes.txt"],
|
|
"pitfalls": ["Forgetting -p for nested paths", "Trying to touch a file under a missing directory"],
|
|
"scenarios": ["Prepare a clean lab directory", "Create a placeholder log or notes file"],
|
|
"troubleshooting_flow": ["Check the target path", "Create directories first", "Create files after the path exists"],
|
|
"related_commands": ["mkdir", "touch", "ls"],
|
|
"classic_view": "File-system work is safer when you change one layer at a time: path first, file second.",
|
|
"takeaways": ["Use mkdir for structure", "Use touch for placeholders", "Think about parent directories before file creation"],
|
|
"after_class": "Rebuild the same directory tree twice until the path feels natural.",
|
|
"exercises": [
|
|
{ "id": "m2_l1_e1", "type": "operation", "title": "Create a lab directory", "hint": "Run mkdir /tmp/lab.", "success_test": "cmd == 'mkdir /tmp/lab' and exists('/tmp/lab')", "solution": ["mkdir /tmp/lab"], "success_msg": "Your lab directory now exists." },
|
|
{ "id": "m2_l1_e2", "type": "operation", "title": "Create a nested directory tree", "hint": "Run mkdir -p /tmp/lab/data/raw.", "success_test": "cmd == 'mkdir -p /tmp/lab/data/raw' and exists('/tmp/lab/data/raw')", "solution": ["mkdir -p /tmp/lab/data/raw"], "success_msg": "You created the nested path correctly." },
|
|
{ "id": "m2_l1_e3", "type": "operation", "title": "Create a note file", "hint": "Run touch /tmp/lab/notes.txt.", "success_test": "cmd == 'touch /tmp/lab/notes.txt' and exists('/tmp/lab/notes.txt')", "solution": ["touch /tmp/lab/notes.txt"], "success_msg": "You created a new empty file in the lab path." }
|
|
]
|
|
},
|
|
{
|
|
"id": "m2_l2_copy_move_permission",
|
|
"title": "Copy, move, and permission files with intent",
|
|
"goal": "Manipulate files carefully and connect permission changes to execution behavior.",
|
|
"why_it_matters": "Safe Linux work depends on knowing when you are backing up, renaming, or changing access.",
|
|
"concepts": ["Backup copies", "Rename vs move", "Permission modes"],
|
|
"command": "cp / mv / chmod / stat",
|
|
"examples": ["cp /etc/hosts /tmp/hosts.bak", "mv /tmp/hosts.bak /tmp/hosts.backup", "chmod 755 /tmp/lab", "stat /etc/hosts"],
|
|
"pitfalls": ["Deleting before backing up", "Changing permissions without checking metadata first"],
|
|
"scenarios": ["Back up a config before editing", "Make a script or directory executable when needed"],
|
|
"troubleshooting_flow": ["Copy before editing", "Rename with a purpose", "Inspect metadata before permission changes"],
|
|
"related_commands": ["cp", "mv", "chmod", "stat"],
|
|
"classic_view": "File operations are safe when you can clearly name the step: backup, rename, inspect, or permission change.",
|
|
"takeaways": ["Back up first", "Rename with purpose", "Inspect before changing permissions"],
|
|
"after_class": "Repeat the flow copy -> rename -> stat -> chmod on a temporary file until the sequence feels obvious.",
|
|
"exercises": [
|
|
{ "id": "m2_l2_e1", "type": "operation", "title": "Back up the hosts file", "hint": "Run cp /etc/hosts /tmp/hosts.bak.", "success_test": "cmd == 'cp /etc/hosts /tmp/hosts.bak' and exists('/tmp/hosts.bak')", "solution": ["cp /etc/hosts /tmp/hosts.bak"], "success_msg": "You created a backup copy before any change." },
|
|
{ "id": "m2_l2_e2", "type": "operation", "title": "Rename the backup file", "hint": "Run mv /tmp/hosts.bak /tmp/hosts.backup.", "success_test": "cmd == 'mv /tmp/hosts.bak /tmp/hosts.backup' and exists('/tmp/hosts.backup')", "solution": ["mv /tmp/hosts.bak /tmp/hosts.backup"], "success_msg": "You renamed the file successfully." },
|
|
{ "id": "m2_l2_e3", "type": "operation", "title": "Inspect hosts metadata", "hint": "Run stat /etc/hosts.", "success_test": "cmd == 'stat /etc/hosts' and 'File:' in output", "solution": ["stat /etc/hosts"], "success_msg": "You inspected the file metadata successfully." }
|
|
]
|
|
},
|
|
{
|
|
"id": "m2_l3_cleanup_and_modes",
|
|
"title": "Clean up and change modes with rm and chmod",
|
|
"goal": "Delete temporary artifacts safely and connect permission changes to execution behavior.",
|
|
"why_it_matters": "Cleanup and permission changes are common, but both can create damage if you skip inspection.",
|
|
"concepts": ["Cleanup order", "Symbolic vs numeric modes", "Execution permission"],
|
|
"command": "rm / chmod",
|
|
"examples": ["rm /tmp/hosts.backup", "chmod 755 /tmp/lab", "chmod +x /tmp/lab/notes.txt"],
|
|
"pitfalls": ["Deleting before confirming the file is disposable", "Changing permissions without knowing why"],
|
|
"scenarios": ["Remove temporary files after verification", "Make a script or directory executable when needed"],
|
|
"troubleshooting_flow": ["Verify the target path", "Remove only temporary files", "Inspect and then change permissions with intent"],
|
|
"related_commands": ["rm", "chmod", "stat", "ls"],
|
|
"classic_view": "Cleanup and permission work should be deliberate, not reactive.",
|
|
"takeaways": ["Delete last", "Use numeric and symbolic modes intentionally", "Connect permissions to a real need"],
|
|
"after_class": "Repeat the sequence inspect -> remove or inspect -> chmod until it feels like a safe habit.",
|
|
"exercises": [
|
|
{ "id": "m2_l3_e1", "type": "operation", "title": "Remove the renamed backup", "hint": "Run rm /tmp/hosts.backup.", "success_test": "cmd == 'rm /tmp/hosts.backup' and not exists('/tmp/hosts.backup')", "solution": ["rm /tmp/hosts.backup"], "success_msg": "You cleaned up the temporary backup safely." },
|
|
{ "id": "m2_l3_e2", "type": "operation", "title": "Set the lab directory mode to 755", "hint": "Run chmod 755 /tmp/lab.", "success_test": "cmd == 'chmod 755 /tmp/lab'", "solution": ["chmod 755 /tmp/lab"], "success_msg": "You applied a numeric permission change." },
|
|
{ "id": "m2_l3_e3", "type": "operation", "title": "Add execute permission to notes.txt", "hint": "Run chmod +x /tmp/lab/notes.txt.", "success_test": "cmd == 'chmod +x /tmp/lab/notes.txt'", "solution": ["chmod +x /tmp/lab/notes.txt"], "success_msg": "You used a symbolic permission change." }
|
|
]
|
|
}
|
|
]
|
|
},
|
|
{
|
|
"id": "module_3_search",
|
|
"title": "Module 3: Search and preview with evidence",
|
|
"summary": "Move from a broad search to a precise answer using filters and short file views.",
|
|
"lessons": [
|
|
{
|
|
"id": "m3_l1_grep",
|
|
"title": "Search file content with grep",
|
|
"goal": "Find relevant lines quickly instead of reading an entire file every time.",
|
|
"why_it_matters": "Operations work often means locating one useful line inside a noisy file.",
|
|
"concepts": ["Pattern search", "Case-insensitive search", "Line-oriented inspection"],
|
|
"command": "grep",
|
|
"examples": ["grep sandbox_user /etc/passwd", "grep -i error /var/log/syslog"],
|
|
"pitfalls": ["Searching too broadly and ignoring context", "Forgetting case-insensitive mode"],
|
|
"scenarios": ["Find one user entry in passwd", "Locate error lines in a log"],
|
|
"troubleshooting_flow": ["Choose the right file first", "Search for the smallest useful keyword", "Use the matched lines to decide the next command"],
|
|
"related_commands": ["grep", "cat", "tail"],
|
|
"classic_view": "grep turns a large text space into a small set of signals you can reason about.",
|
|
"takeaways": ["Search deliberately", "Narrow the signal before changing anything", "Use matched lines as evidence"],
|
|
"after_class": "Practice moving from a broad keyword to a more precise keyword in the same file.",
|
|
"exercises": [
|
|
{ "id": "m3_l1_e1", "type": "operation", "title": "Find sandbox_user in passwd", "hint": "Run grep sandbox_user /etc/passwd.", "success_test": "cmd == 'grep sandbox_user /etc/passwd' and 'sandbox_user' in output", "solution": ["grep sandbox_user /etc/passwd"], "success_msg": "You extracted the relevant passwd line." },
|
|
{ "id": "m3_l1_e2", "type": "operation", "title": "Find error lines in syslog", "hint": "Run grep -i error /var/log/syslog.", "success_test": "cmd == 'grep -i error /var/log/syslog' and 'error' in output.lower()", "solution": ["grep -i error /var/log/syslog"], "success_msg": "You filtered the log down to the error lines." },
|
|
{ "id": "m3_l1_e3", "type": "scenario", "question": "Why is grep usually faster than reading the whole log manually?", "answer": "Because it narrows the file to only the lines that match the signal you care about." }
|
|
]
|
|
},
|
|
{
|
|
"id": "m3_l2_find_preview",
|
|
"title": "Locate files with find and preview them with tail",
|
|
"goal": "Move from path discovery to a focused log or config preview.",
|
|
"why_it_matters": "You cannot inspect the right file until you locate it precisely, and you do not need to open the whole file first.",
|
|
"concepts": ["Name-based search", "Search roots", "Tail as a recent-state preview"],
|
|
"command": "find / tail",
|
|
"examples": ["find /etc -name '*.conf'", "find /var/log -type f", "tail -n 1 /var/log/auth.log"],
|
|
"pitfalls": ["Searching from too high in the tree", "Using cat on a large file when tail would answer faster"],
|
|
"scenarios": ["Find config files under /etc", "Inspect the newest auth log line"],
|
|
"troubleshooting_flow": ["Pick the smallest reasonable root", "Add a filter", "Preview the most relevant file segment"],
|
|
"related_commands": ["find", "tail", "head"],
|
|
"classic_view": "A good search ends with an exact path and a small, readable preview.",
|
|
"takeaways": ["Use find for precise location", "Use tail for fresh log evidence", "Reduce noise early"],
|
|
"after_class": "Practice explaining the root path and every filter before you run find.",
|
|
"exercises": [
|
|
{ "id": "m3_l2_e1", "type": "operation", "title": "Find configuration files under /etc", "hint": "Run find /etc -name '*.conf'.", "success_test": "cmd == \"find /etc -name '*.conf'\" and '.conf' in output", "solution": ["find /etc -name '*.conf'"], "success_msg": "You located configuration files recursively." },
|
|
{ "id": "m3_l2_e2", "type": "operation", "title": "Find log files under /var/log", "hint": "Run find /var/log -type f.", "success_test": "cmd == 'find /var/log -type f' and '/var/log' in output", "solution": ["find /var/log -type f"], "success_msg": "You filtered the search to files under the log tree." },
|
|
{ "id": "m3_l2_e3", "type": "operation", "title": "Read the newest auth log line", "hint": "Run tail -n 1 /var/log/auth.log.", "success_test": "cmd == 'tail -n 1 /var/log/auth.log' and 'sandbox_user' in output", "solution": ["tail -n 1 /var/log/auth.log"], "success_msg": "You previewed the most recent auth log line." }
|
|
]
|
|
},
|
|
{
|
|
"id": "m3_l3_preview_and_pipeline",
|
|
"title": "Preview files with head, tail, and a simple pipeline",
|
|
"goal": "Read only the part of a file that answers your current question.",
|
|
"why_it_matters": "Large files are easier to scan when you only open the beginning or end first.",
|
|
"concepts": ["Top lines", "Bottom lines", "Simple pipelines for narrowing output"],
|
|
"command": "head / tail / cat | tail",
|
|
"examples": ["head /etc/passwd", "tail -n 1 /var/log/auth.log", "cat /var/log/auth.log | tail -n 1"],
|
|
"pitfalls": ["Using cat on a large file when a preview is enough", "Forgetting to change the line count for a focused question"],
|
|
"scenarios": ["Check whether a file starts with the right structure", "Inspect the last auth event in a log"],
|
|
"troubleshooting_flow": ["Choose the right end of the file", "Preview a small number of lines", "Switch to grep or full reads only if needed"],
|
|
"related_commands": ["head", "tail", "cat", "grep"],
|
|
"classic_view": "Preview commands reduce noise so you can decide whether the file deserves deeper inspection.",
|
|
"takeaways": ["Use head for structure", "Use tail for recent activity", "Use a pipeline when one command is not enough"],
|
|
"after_class": "Practice explaining why you chose head or tail before you run the command.",
|
|
"exercises": [
|
|
{ "id": "m3_l3_e1", "type": "operation", "title": "Preview the top of passwd", "hint": "Run head /etc/passwd.", "success_test": "cmd == 'head /etc/passwd' and 'root' in output", "solution": ["head /etc/passwd"], "success_msg": "You previewed the beginning of the file." },
|
|
{ "id": "m3_l3_e2", "type": "operation", "title": "Inspect the newest auth log line", "hint": "Run tail -n 1 /var/log/auth.log.", "success_test": "cmd == 'tail -n 1 /var/log/auth.log' and 'sandbox_user' in output", "solution": ["tail -n 1 /var/log/auth.log"], "success_msg": "You narrowed the file to the most recent line." },
|
|
{ "id": "m3_l3_e3", "type": "operation", "title": "Use a simple pipeline to preview auth.log", "hint": "Run cat /var/log/auth.log | tail -n 1.", "success_test": "cmd == 'cat /var/log/auth.log | tail -n 1' and 'sandbox_user' in output", "solution": ["cat /var/log/auth.log | tail -n 1"], "success_msg": "You combined two commands to narrow the log quickly." }
|
|
]
|
|
}
|
|
]
|
|
},
|
|
{
|
|
"id": "module_4_operations",
|
|
"title": "Module 4: Turn commands into operations workflows",
|
|
"summary": "Use process and network commands as parts of a real troubleshooting chain instead of isolated tools.",
|
|
"lessons": [
|
|
{
|
|
"id": "m4_l1_process",
|
|
"title": "Read system pressure with top and ps",
|
|
"goal": "Spot busy processes and connect process views to system pressure.",
|
|
"why_it_matters": "Incidents often begin with 'the system feels slow', and process views turn that feeling into evidence.",
|
|
"concepts": ["Process snapshots", "CPU-heavy processes", "Live system views"],
|
|
"command": "top / ps",
|
|
"examples": ["top", "ps aux --sort=-%cpu | head"],
|
|
"pitfalls": ["Jumping straight to kill before understanding the process role", "Looking at one snapshot without connecting it to symptoms"],
|
|
"scenarios": ["Find the hottest process when CPU looks high", "Explain which command gives the faster broad view"],
|
|
"troubleshooting_flow": ["Look at top for the broad picture", "Use ps sorting to confirm the hottest process", "Only then decide the next action"],
|
|
"related_commands": ["top", "ps", "kill"],
|
|
"classic_view": "System pressure is easier to reason about when you move from a broad live view to a specific process list.",
|
|
"takeaways": ["Use top for the live picture", "Use ps for a sortable snapshot", "Diagnose before you terminate anything"],
|
|
"after_class": "Compare top and ps side by side and explain what each one is better at.",
|
|
"exercises": [
|
|
{ "id": "m4_l1_e1", "type": "operation", "title": "Show a live overview", "hint": "Run top.", "success_test": "cmd == 'top' and 'load average' in output", "solution": ["top"], "success_msg": "You captured a live system overview." },
|
|
{ "id": "m4_l1_e2", "type": "operation", "title": "List processes by CPU usage", "hint": "Run ps aux --sort=-%cpu | head.", "success_test": "cmd == 'ps aux --sort=-%cpu | head' and '%CPU' in output", "solution": ["ps aux --sort=-%cpu | head"], "success_msg": "You ranked processes by CPU usage." },
|
|
{ "id": "m4_l1_e3", "type": "understanding", "question": "Why should kill come after observation rather than before it?", "answer": "Because you need evidence about what the process is doing and whether it is safe to stop." }
|
|
]
|
|
},
|
|
{
|
|
"id": "m4_l2_network",
|
|
"title": "Check the network path with ip, ping, ss, and curl",
|
|
"goal": "Diagnose connectivity step by step from interface state to application response.",
|
|
"why_it_matters": "Network incidents feel confusing when you mix layers; they become clearer when you inspect one layer at a time.",
|
|
"concepts": ["Interface address", "Basic connectivity", "Listening ports", "Application-level validation"],
|
|
"command": "ip / ping / ss / curl",
|
|
"examples": ["ip addr", "ping 127.0.0.1", "ss -ltnp", "curl http://127.0.0.1"],
|
|
"pitfalls": ["Treating DNS, port, and app failures as one category", "Checking a port without making a real request"],
|
|
"scenarios": ["A local service looks up but the app still feels unavailable", "You need to confirm whether the issue is address, reachability, port, or HTTP behavior"],
|
|
"troubleshooting_flow": ["Check interface state with ip addr", "Test connectivity with ping", "Check sockets with ss", "Validate the app layer with curl"],
|
|
"related_commands": ["ip", "ping", "ss", "curl", "dig"],
|
|
"classic_view": "The cleanest network diagnosis moves from low-level reachability to the final application response.",
|
|
"takeaways": ["Do not skip layers", "Confirm a port before blaming the app", "Use curl to verify user-facing behavior"],
|
|
"after_class": "Repeat the sequence ip -> ping -> ss -> curl until the layer transitions feel natural.",
|
|
"exercises": [
|
|
{ "id": "m4_l2_e1", "type": "operation", "title": "Inspect interface addresses", "hint": "Run ip addr.", "success_test": "cmd == 'ip addr' and 'inet' in output", "solution": ["ip addr"], "success_msg": "You confirmed interface and address information." },
|
|
{ "id": "m4_l2_e2", "type": "operation", "title": "Test local connectivity", "hint": "Run ping 127.0.0.1.", "success_test": "cmd == 'ping 127.0.0.1' and 'packet loss' in output", "solution": ["ping 127.0.0.1"], "success_msg": "You verified the local connectivity layer." },
|
|
{ "id": "m4_l2_e3", "type": "operation", "title": "Validate the application response", "hint": "Run curl http://127.0.0.1.", "success_test": "cmd == 'curl http://127.0.0.1' and 'hello localhost' in output", "solution": ["curl http://127.0.0.1"], "success_msg": "You completed the network path all the way to the application layer." }
|
|
]
|
|
},
|
|
{
|
|
"id": "m4_l3_service",
|
|
"title": "Trace service health with systemctl and journalctl",
|
|
"goal": "Move from service state to recent logs in a deliberate sequence.",
|
|
"why_it_matters": "Service incidents are easier to solve when you separate service state from application logs.",
|
|
"concepts": ["Service unit state", "Recent journal lines", "From status to explanation"],
|
|
"command": "systemctl / journalctl",
|
|
"examples": ["systemctl status nginx", "journalctl -n 20", "systemctl restart nginx"],
|
|
"pitfalls": ["Restarting a service without checking why it failed", "Reading status without following the logs"],
|
|
"scenarios": ["A service is reported down or unstable", "You need the last error before considering a restart"],
|
|
"troubleshooting_flow": ["Read service state with systemctl status", "Open the recent journal lines", "Use the message to guide the next repair"],
|
|
"related_commands": ["systemctl", "journalctl", "ss"],
|
|
"classic_view": "Service status tells you what is happening; logs tell you why.",
|
|
"takeaways": ["Start with status", "Use logs for explanation", "Restart only after you understand the failure"],
|
|
"after_class": "Say out loud what systemctl tells you that journalctl does not, and vice versa.",
|
|
"exercises": [
|
|
{ "id": "m4_l3_e1", "type": "operation", "title": "Check nginx service status", "hint": "Run systemctl status nginx.", "success_test": "cmd == 'systemctl status nginx' and 'Active:' in output", "solution": ["systemctl status nginx"], "success_msg": "You inspected the service state." },
|
|
{ "id": "m4_l3_e2", "type": "operation", "title": "Read recent journal lines", "hint": "Run journalctl -n 20.", "success_test": "cmd == 'journalctl -n 20' and 'Started nginx.service' in output", "solution": ["journalctl -n 20"], "success_msg": "You pulled recent journal evidence." },
|
|
{ "id": "m4_l3_e3", "type": "operation", "title": "Simulate a service restart command", "hint": "Run systemctl restart nginx.", "success_test": "cmd == 'systemctl restart nginx' and 'completed for nginx' in output", "solution": ["systemctl restart nginx"], "success_msg": "You practiced the restart command after inspection." }
|
|
]
|
|
}
|
|
]
|
|
},
|
|
{
|
|
"id": "module_5_incidents",
|
|
"title": "Module 5: Practice incident playbooks",
|
|
"summary": "Use the commands you learned in layered incident drills so the tools feel connected to real operations work.",
|
|
"lessons": [
|
|
{
|
|
"id": "m5_l1_disk",
|
|
"title": "Incident drill: investigate disk pressure",
|
|
"goal": "Move from broad disk visibility to specific directory evidence.",
|
|
"why_it_matters": "Disk pressure can break writes, logs, and services, so you need a repeatable inspection path.",
|
|
"concepts": ["Filesystem usage", "Directory usage", "Large-file hunting"],
|
|
"command": "df / du / find",
|
|
"examples": ["df -h", "du -sh /var/log", "find /var/log -type f"],
|
|
"pitfalls": ["Stopping at df without drilling into the heavy directory", "Deleting files before confirming what they are for"],
|
|
"scenarios": ["A host reports that disk usage is full", "A log directory appears to be growing too quickly"],
|
|
"troubleshooting_flow": ["Confirm which filesystem is full", "Measure the likely heavy directory", "Locate concrete files before deciding cleanup"],
|
|
"related_commands": ["df", "du", "find", "sort"],
|
|
"classic_view": "Disk incidents are easier when you move from filesystem view to directory view to file view in order.",
|
|
"takeaways": ["Use df for the broad picture", "Use du for directory evidence", "Use find before deleting anything"],
|
|
"after_class": "Practice saying which layer each command belongs to: filesystem, directory, or file.",
|
|
"exercises": [
|
|
{ "id": "m5_l1_e1", "type": "operation", "title": "Check filesystem usage", "hint": "Run df -h.", "success_test": "cmd == 'df -h' and 'Filesystem' in output", "solution": ["df -h"], "success_msg": "You captured the broad disk usage picture." },
|
|
{ "id": "m5_l1_e2", "type": "operation", "title": "Measure /var/log usage", "hint": "Run du -sh /var/log.", "success_test": "cmd == 'du -sh /var/log' and '/var/log' in output", "solution": ["du -sh /var/log"], "success_msg": "You narrowed the issue to a directory-level view." },
|
|
{ "id": "m5_l1_e3", "type": "operation", "title": "Locate log files under /var/log", "hint": "Run find /var/log -type f.", "success_test": "cmd == 'find /var/log -type f' and '/var/log' in output", "solution": ["find /var/log -type f"], "success_msg": "You drilled down to the file layer." },
|
|
{ "id": "m5_l1_e4", "type": "scenario", "question": "Why is deleting files before directory and file inspection risky?", "answer": "Because you can remove useful evidence or the wrong data before you understand what is consuming space." }
|
|
]
|
|
},
|
|
{
|
|
"id": "m5_l2_auth",
|
|
"title": "Incident drill: investigate login or permission failures",
|
|
"goal": "Link identity, account records, and recent auth logs into one diagnosis sequence.",
|
|
"why_it_matters": "Access problems often mix user identity, account state, and authentication evidence.",
|
|
"concepts": ["Current identity", "Account presence", "Recent authentication history"],
|
|
"command": "whoami / id / grep / tail",
|
|
"examples": ["whoami", "id", "grep sandbox_user /etc/passwd", "cat /var/log/auth.log | tail -n 1"],
|
|
"pitfalls": ["Guessing a password issue without checking logs", "Ignoring account records and group membership"],
|
|
"scenarios": ["A login fails repeatedly", "A script exists but still cannot be used by the current user"],
|
|
"troubleshooting_flow": ["Confirm the current identity", "Verify the target account exists", "Read the newest auth evidence"],
|
|
"related_commands": ["whoami", "id", "grep", "tail"],
|
|
"classic_view": "Access issues are easier when you inspect identity, account records, and logs as one chain.",
|
|
"takeaways": ["Confirm the user context first", "Use account files as evidence", "Trust logs more than guesses"],
|
|
"after_class": "Repeat the identity -> account -> log sequence until it feels like one habit.",
|
|
"exercises": [
|
|
{ "id": "m5_l2_e1", "type": "operation", "title": "Confirm your current identity", "hint": "Run whoami.", "success_test": "cmd == 'whoami' and 'sandbox_user' in output", "solution": ["whoami"], "success_msg": "You confirmed the current shell identity." },
|
|
{ "id": "m5_l2_e2", "type": "operation", "title": "Inspect uid and group information", "hint": "Run id.", "success_test": "cmd == 'id' and 'uid=' in output", "solution": ["id"], "success_msg": "You inspected the uid and group context." },
|
|
{ "id": "m5_l2_e3", "type": "operation", "title": "Check whether sandbox_user exists in passwd", "hint": "Run grep sandbox_user /etc/passwd.", "success_test": "cmd == 'grep sandbox_user /etc/passwd' and 'sandbox_user' in output", "solution": ["grep sandbox_user /etc/passwd"], "success_msg": "You verified the account record." },
|
|
{ "id": "m5_l2_e4", "type": "operation", "title": "Read the newest auth log line", "hint": "Run cat /var/log/auth.log | tail -n 1.", "success_test": "cmd == 'cat /var/log/auth.log | tail -n 1' and 'sandbox_user' in output", "solution": ["cat /var/log/auth.log | tail -n 1"], "success_msg": "You retrieved recent authentication evidence." }
|
|
]
|
|
},
|
|
{
|
|
"id": "m5_l3_service_path",
|
|
"title": "Incident drill: service is up, but the application still feels broken",
|
|
"goal": "Check service state, listening sockets, and application output in one guided drill.",
|
|
"why_it_matters": "A service can look healthy at one layer but still fail at another layer.",
|
|
"concepts": ["Service state", "Socket listening state", "Application response validation"],
|
|
"command": "systemctl / ss / curl / journalctl",
|
|
"examples": ["systemctl status nginx", "ss -ltnp", "curl http://127.0.0.1", "journalctl -n 20"],
|
|
"pitfalls": ["Trusting systemctl alone without checking sockets or a real request", "Stopping at ss without making an application-layer call"],
|
|
"scenarios": ["A team says the service is up but the page still feels unavailable", "You need to prove whether the problem is service state, port state, or HTTP behavior"],
|
|
"troubleshooting_flow": ["Check systemctl for service state", "Check ss for listening ports", "Use curl to verify the real response", "Open journal logs if behavior still looks wrong"],
|
|
"related_commands": ["systemctl", "ss", "curl", "journalctl"],
|
|
"classic_view": "Healthy service state does not guarantee healthy application behavior, so finish the chain with a real request.",
|
|
"takeaways": ["Check multiple layers", "Do not confuse a listening port with a healthy app", "End the chain with a real request and logs when needed"],
|
|
"after_class": "Practice explaining which layer each command validates: service, socket, application, or logs.",
|
|
"exercises": [
|
|
{ "id": "m5_l3_e1", "type": "operation", "title": "Check nginx service state", "hint": "Run systemctl status nginx.", "success_test": "cmd == 'systemctl status nginx' and 'Active:' in output", "solution": ["systemctl status nginx"], "success_msg": "You confirmed the service layer state." },
|
|
{ "id": "m5_l3_e2", "type": "operation", "title": "Check listening sockets", "hint": "Run ss -ltnp.", "success_test": "cmd == 'ss -ltnp' and 'LISTEN' in output", "solution": ["ss -ltnp"], "success_msg": "You confirmed the socket layer." },
|
|
{ "id": "m5_l3_e3", "type": "operation", "title": "Make a real application request", "hint": "Run curl http://127.0.0.1.", "success_test": "cmd == 'curl http://127.0.0.1' and 'hello localhost' in output", "solution": ["curl http://127.0.0.1"], "success_msg": "You verified the final application response layer." },
|
|
{ "id": "m5_l3_e4", "type": "operation", "title": "Open recent journal lines", "hint": "Run journalctl -n 20.", "success_test": "cmd == 'journalctl -n 20' and 'Started nginx.service' in output", "solution": ["journalctl -n 20"], "success_msg": "You added log evidence to the service drill." }
|
|
]
|
|
}
|
|
]
|
|
},
|
|
{
|
|
"id": "module_6_shell_environment",
|
|
"title": "Module 6: Work faster in the shell",
|
|
"summary": "Use environment variables, aliases, history, and simple text pipelines to make Linux work feel repeatable instead of manual.",
|
|
"lessons": [
|
|
{
|
|
"id": "m6_l1_env_alias",
|
|
"title": "Control shell context with env, export, and alias",
|
|
"goal": "Understand how shell state changes affect later commands and sessions.",
|
|
"why_it_matters": "A lot of Linux productivity comes from shaping the shell so common work is easier to repeat safely.",
|
|
"concepts": ["Environment variables", "Exported shell state", "Command aliases"],
|
|
"command": "env / export / alias",
|
|
"examples": ["env", "export APP_MODE=lab", "alias ll='ls -l'"],
|
|
"pitfalls": ["Assuming an echoed value is the same as an exported variable", "Creating aliases without understanding the original command"],
|
|
"scenarios": ["Prepare a temporary runtime flag", "Shorten a repeated command pattern"],
|
|
"troubleshooting_flow": ["Inspect the current shell state", "Change one variable or alias", "Verify the shell reflects the change"],
|
|
"related_commands": ["env", "export", "alias", "echo"],
|
|
"classic_view": "The shell is not just a place to type commands; it is a working environment you can shape.",
|
|
"takeaways": ["Use env to inspect state", "Use export to persist a shell variable for child processes", "Use aliases carefully and intentionally"],
|
|
"after_class": "Practice changing one variable and one alias, then explain what effect each change has.",
|
|
"exercises": [
|
|
{ "id": "m6_l1_e1", "type": "operation", "title": "Inspect the current environment", "hint": "Run env.", "success_test": "cmd == 'env' and 'HOME=' in output", "solution": ["env"], "success_msg": "You inspected the current shell environment." },
|
|
{ "id": "m6_l1_e2", "type": "operation", "title": "Export a temporary variable", "hint": "Run export APP_MODE=lab.", "success_test": "cmd == 'export APP_MODE=lab' and 'APP_MODE=lab' in output", "solution": ["export APP_MODE=lab"], "success_msg": "You exported a shell variable successfully." },
|
|
{ "id": "m6_l1_e3", "type": "operation", "title": "Create a listing alias", "hint": "Run alias ll='ls -l'.", "success_test": "cmd == \"alias ll='ls -l'\" and \"alias ll='ls -l'\" in output", "solution": ["alias ll='ls -l'"], "success_msg": "You created a shell alias." },
|
|
{ "id": "m6_l1_e4", "type": "scenario", "question": "Why is export different from simply printing a value with echo?", "answer": "Because export changes the shell environment for later commands, while echo only prints text once." }
|
|
]
|
|
},
|
|
{
|
|
"id": "m6_l2_history_replay",
|
|
"title": "Use history, date, and clear to manage command sessions",
|
|
"goal": "Review what you ran, time-stamp your work, and keep the terminal readable during longer sessions.",
|
|
"why_it_matters": "Operations work often depends on replaying what happened and keeping a clean command narrative.",
|
|
"concepts": ["Command history", "Session readability", "Time awareness"],
|
|
"command": "history / date / clear",
|
|
"examples": ["history", "date", "clear"],
|
|
"pitfalls": ["Running many commands without keeping track of sequence", "Treating a terminal as disposable when the command history is useful evidence"],
|
|
"scenarios": ["Reconstruct what you tried during an incident", "Record the time before a change or restart"],
|
|
"troubleshooting_flow": ["Review your recent commands", "Record or inspect the current time", "Clear the screen only after capturing what matters"],
|
|
"related_commands": ["history", "date", "clear", "echo"],
|
|
"classic_view": "A strong operator can explain not just what they ran, but in what order and when.",
|
|
"takeaways": ["Use history as lightweight evidence", "Use date to anchor actions in time", "Clear the screen only when it helps readability"],
|
|
"after_class": "Practice summarizing a small command session from history without looking at your notes.",
|
|
"exercises": [
|
|
{ "id": "m6_l2_e1", "type": "operation", "title": "Show your recent command history", "hint": "Run history.", "success_test": "cmd == 'history' and len(output) >= 0", "solution": ["history"], "success_msg": "You reviewed the shell history." },
|
|
{ "id": "m6_l2_e2", "type": "operation", "title": "Print the current date and time", "hint": "Run date.", "success_test": "cmd == 'date' and 'CST' in output", "solution": ["date"], "success_msg": "You time-stamped the session." },
|
|
{ "id": "m6_l2_e3", "type": "operation", "title": "Clear the terminal view", "hint": "Run clear.", "success_test": "cmd == 'clear' and 'screen cleared' in output", "solution": ["clear"], "success_msg": "You reset the visible terminal output." }
|
|
]
|
|
},
|
|
{
|
|
"id": "m6_l3_text_pipeline",
|
|
"title": "Reduce noise with sort, uniq, cut, awk, and sed",
|
|
"goal": "Use small text-processing tools to transform output instead of reading everything manually.",
|
|
"why_it_matters": "Linux operations is easier when you can shape output into something small enough to reason about.",
|
|
"concepts": ["Pipeline thinking", "Sorting and deduplication", "Field extraction", "Quick text transforms"],
|
|
"command": "sort / uniq / cut / awk / sed",
|
|
"examples": ["cat /var/log/auth.log | sort", "cat /var/log/auth.log | uniq", "cat /etc/passwd | cut -d: -f1"],
|
|
"pitfalls": ["Running multiple commands manually when a pipeline would be clearer", "Transforming output without understanding what field you are extracting"],
|
|
"scenarios": ["Normalize repeated lines before inspection", "Extract usernames from passwd"],
|
|
"troubleshooting_flow": ["Start with raw output", "Apply one transform at a time", "Stop when the output is small enough to answer the question"],
|
|
"related_commands": ["sort", "uniq", "cut", "awk", "sed", "grep"],
|
|
"classic_view": "Pipelines are how Linux turns a large question into a sequence of smaller, readable steps.",
|
|
"takeaways": ["Use sort and uniq to reduce repetition", "Use cut for simple field extraction", "Treat awk and sed as focused shaping tools rather than magic"],
|
|
"after_class": "Practice explaining what each pipeline stage contributes before you run the full chain.",
|
|
"exercises": [
|
|
{ "id": "m6_l3_e1", "type": "operation", "title": "Sort auth log lines", "hint": "Run cat /var/log/auth.log | sort.", "success_test": "cmd == 'cat /var/log/auth.log | sort' and len(output) > 0", "solution": ["cat /var/log/auth.log | sort"], "success_msg": "You sorted the auth log lines." },
|
|
{ "id": "m6_l3_e2", "type": "operation", "title": "Deduplicate auth log lines", "hint": "Run cat /var/log/auth.log | uniq.", "success_test": "cmd == 'cat /var/log/auth.log | uniq' and len(output) > 0", "solution": ["cat /var/log/auth.log | uniq"], "success_msg": "You reduced duplicate lines with uniq." },
|
|
{ "id": "m6_l3_e3", "type": "operation", "title": "Extract the first passwd field", "hint": "Run cat /etc/passwd | cut -d: -f1.", "success_test": "cmd == 'cat /etc/passwd | cut -d: -f1' and len(output) > 0", "solution": ["cat /etc/passwd | cut -d: -f1"], "success_msg": "You extracted a single field from passwd." },
|
|
{ "id": "m6_l3_e4", "type": "scenario", "question": "Why do pipelines help more than manually copying output into another tool?", "answer": "Because they preserve a clear, repeatable transformation chain directly in the shell." }
|
|
]
|
|
}
|
|
]
|
|
},
|
|
{
|
|
"id": "module_7_packages_and_delivery",
|
|
"title": "Module 7: Locate tools, inspect packages, and move artifacts",
|
|
"summary": "Learn where commands live, how package managers differ, and how archives or background jobs support basic delivery work.",
|
|
"lessons": [
|
|
{
|
|
"id": "m7_l1_locate_tools",
|
|
"title": "Locate binaries with which and whereis",
|
|
"goal": "Understand where commands come from before changing PATHs or package assumptions.",
|
|
"why_it_matters": "Operators often need to prove which binary is running and where supporting docs or manpages live.",
|
|
"concepts": ["Binary location", "PATH lookup", "Tool discovery"],
|
|
"command": "which / whereis",
|
|
"examples": ["which curl", "which ls", "whereis grep"],
|
|
"pitfalls": ["Assuming the same command path on every server", "Changing PATH without first proving what is currently used"],
|
|
"scenarios": ["Check where curl is installed", "Find the shell-visible ls binary"],
|
|
"troubleshooting_flow": ["Ask which binary the shell resolves", "Use whereis for broader discovery", "Only then adjust your assumptions or PATH"],
|
|
"related_commands": ["which", "whereis", "env"],
|
|
"classic_view": "Before you replace a binary or adjust PATH, prove what the shell is already resolving.",
|
|
"takeaways": ["Use which for shell resolution", "Use whereis for broader lookup", "Do not guess command paths"],
|
|
"after_class": "Compare which and whereis on two commands and explain why their outputs differ.",
|
|
"exercises": [
|
|
{ "id": "m7_l1_e1", "type": "operation", "title": "Locate curl", "hint": "Run which curl.", "success_test": "cmd == 'which curl' and '/usr/bin/curl' in output", "solution": ["which curl"], "success_msg": "You located the curl binary." },
|
|
{ "id": "m7_l1_e2", "type": "operation", "title": "Locate ls", "hint": "Run which ls.", "success_test": "cmd == 'which ls' and '/bin/ls' in output", "solution": ["which ls"], "success_msg": "You located the ls binary." },
|
|
{ "id": "m7_l1_e3", "type": "operation", "title": "Broaden the search for grep", "hint": "Run whereis grep.", "success_test": "cmd == 'whereis grep' and 'grep:' in output", "solution": ["whereis grep"], "success_msg": "You used whereis for broader command discovery." }
|
|
]
|
|
},
|
|
{
|
|
"id": "m7_l2_package_basics",
|
|
"title": "Read package tool output with apt, yum, rpm, and dpkg",
|
|
"goal": "Recognize the common package tools you will encounter across distributions.",
|
|
"why_it_matters": "Even if you automate package installs later, you still need to understand the native package vocabulary of the host.",
|
|
"concepts": ["Debian vs RPM ecosystems", "Package listing output", "Distribution-specific tooling"],
|
|
"command": "apt / yum / rpm / dpkg",
|
|
"examples": ["apt", "yum", "rpm", "dpkg"],
|
|
"pitfalls": ["Assuming apt exists on every Linux server", "Reading package output without identifying the distro context first"],
|
|
"scenarios": ["Check which package tool family a server likely uses", "Read enough package output to orient yourself before change work"],
|
|
"troubleshooting_flow": ["Identify the package family", "Read listing output", "Only then plan installs or version checks"],
|
|
"related_commands": ["apt", "yum", "rpm", "dpkg", "which"],
|
|
"classic_view": "Package commands are not interchangeable, so distribution context matters before action.",
|
|
"takeaways": ["Recognize Debian-style and RPM-style tooling", "Read package output without guessing", "Use package family as part of host context"],
|
|
"after_class": "Practice explaining which systems are more likely to use apt vs yum or rpm.",
|
|
"exercises": [
|
|
{ "id": "m7_l2_e1", "type": "operation", "title": "Inspect apt output", "hint": "Run apt.", "success_test": "cmd == 'apt' and 'Reading package lists' in output", "solution": ["apt"], "success_msg": "You inspected Debian-style package manager output." },
|
|
{ "id": "m7_l2_e2", "type": "operation", "title": "Inspect yum output", "hint": "Run yum.", "success_test": "cmd == 'yum' and 'Installed Packages' in output", "solution": ["yum"], "success_msg": "You inspected RPM-style package manager output." },
|
|
{ "id": "m7_l2_e3", "type": "operation", "title": "Inspect rpm output", "hint": "Run rpm.", "success_test": "cmd == 'rpm' and 'bash-' in output", "solution": ["rpm"], "success_msg": "You inspected a package-level rpm response." },
|
|
{ "id": "m7_l2_e4", "type": "operation", "title": "Inspect dpkg output", "hint": "Run dpkg.", "success_test": "cmd == 'dpkg' and 'ii bash' in output", "solution": ["dpkg"], "success_msg": "You inspected a Debian package-level response." }
|
|
]
|
|
},
|
|
{
|
|
"id": "m7_l3_archives_and_background",
|
|
"title": "Handle archives and background jobs with tar and nohup",
|
|
"goal": "Prepare simple deployment artifacts and understand why background execution changes how you observe a job.",
|
|
"why_it_matters": "Basic delivery work often includes packaging files, extracting them, and running something outside the current terminal.",
|
|
"concepts": ["Archive creation", "Archive extraction", "Background job output"],
|
|
"command": "tar / nohup",
|
|
"examples": ["tar -czf /tmp/lab.tar.gz /tmp/lab", "tar -xzf /tmp/lab.tar.gz -C /tmp/lab_restore", "nohup python3 /projects/backend/app.py"],
|
|
"pitfalls": ["Treating an archive like a backup without verifying extraction", "Starting a job with nohup without thinking about its output destination"],
|
|
"scenarios": ["Bundle a small workspace", "Extract an artifact into a staging path", "Run a long task after disconnecting"],
|
|
"troubleshooting_flow": ["Create the artifact", "Extract it into a clean target", "Use nohup only when the process should survive the terminal"],
|
|
"related_commands": ["tar", "nohup", "ps", "ls"],
|
|
"classic_view": "Packaging and background execution are useful, but only when you stay aware of where files and output go.",
|
|
"takeaways": ["Use tar for simple packaging", "Verify extraction paths", "Use nohup deliberately, not by habit"],
|
|
"after_class": "Practice explaining what changed in the filesystem after create and extract operations.",
|
|
"exercises": [
|
|
{ "id": "m7_l3_e1", "type": "operation", "title": "Create a tar archive", "hint": "Run tar -czf /tmp/lab.tar.gz /tmp/lab.", "success_test": "cmd == 'tar -czf /tmp/lab.tar.gz /tmp/lab' and exists('/tmp/lab.tar.gz')", "solution": ["tar -czf /tmp/lab.tar.gz /tmp/lab"], "success_msg": "You created an archive artifact." },
|
|
{ "id": "m7_l3_e2", "type": "operation", "title": "Extract the tar archive", "hint": "Run tar -xzf /tmp/lab.tar.gz -C /tmp/lab_restore.", "success_test": "cmd == 'tar -xzf /tmp/lab.tar.gz -C /tmp/lab_restore' and exists('/tmp/lab_restore')", "solution": ["tar -xzf /tmp/lab.tar.gz -C /tmp/lab_restore"], "success_msg": "You extracted the archive into a clean target directory." },
|
|
{ "id": "m7_l3_e3", "type": "operation", "title": "Start a background-friendly command", "hint": "Run nohup python3 /projects/backend/app.py.", "success_test": "cmd == 'nohup python3 /projects/backend/app.py' and 'nohup.out' in output", "solution": ["nohup python3 /projects/backend/app.py"], "success_msg": "You practiced a nohup-style launch." },
|
|
{ "id": "m7_l3_e4", "type": "scenario", "question": "Why should you still verify extraction or output paths after using tar or nohup?", "answer": "Because packaging or backgrounding can succeed syntactically while still writing to the wrong place." }
|
|
]
|
|
}
|
|
]
|
|
},
|
|
{
|
|
"id": "module_8_monitoring_and_scheduling",
|
|
"title": "Module 8: Read system health and time-based execution",
|
|
"summary": "Learn the commands that help you interpret a host snapshot and think about recurring work.",
|
|
"lessons": [
|
|
{
|
|
"id": "m8_l1_system_snapshot",
|
|
"title": "Take a quick host snapshot with uptime, free, w, and last",
|
|
"goal": "Build a fast first-pass host summary before deeper debugging.",
|
|
"why_it_matters": "A good operator can summarize load, memory, active sessions, and recent logins in under a minute.",
|
|
"concepts": ["Load averages", "Memory pressure", "Active users", "Login history"],
|
|
"command": "uptime / free / w / last",
|
|
"examples": ["uptime", "free", "w", "last"],
|
|
"pitfalls": ["Reading one metric in isolation", "Ignoring user/session context during troubleshooting"],
|
|
"scenarios": ["A host feels slow but you need a broad snapshot first", "You need to know whether other users are active on the system"],
|
|
"troubleshooting_flow": ["Check load with uptime", "Check memory with free", "Check active sessions with w", "Review recent logins with last"],
|
|
"related_commands": ["uptime", "free", "w", "last", "top"],
|
|
"classic_view": "Before deep investigation, collect a fast baseline of load, memory, users, and logins.",
|
|
"takeaways": ["Use multiple quick metrics together", "Include session context in your diagnosis", "Build a snapshot before diving deeper"],
|
|
"after_class": "Practice summarizing the host in one sentence using all four commands together.",
|
|
"exercises": [
|
|
{ "id": "m8_l1_e1", "type": "operation", "title": "Check uptime", "hint": "Run uptime.", "success_test": "cmd == 'uptime' and 'load average' in output", "solution": ["uptime"], "success_msg": "You read the broad load snapshot." },
|
|
{ "id": "m8_l1_e2", "type": "operation", "title": "Check memory usage", "hint": "Run free.", "success_test": "cmd == 'free' and 'Mem:' in output", "solution": ["free"], "success_msg": "You checked memory pressure." },
|
|
{ "id": "m8_l1_e3", "type": "operation", "title": "Check active users", "hint": "Run w.", "success_test": "cmd == 'w' and 'USER' in output", "solution": ["w"], "success_msg": "You reviewed active shell users." },
|
|
{ "id": "m8_l1_e4", "type": "operation", "title": "Check recent login history", "hint": "Run last.", "success_test": "cmd == 'last' and 'sandbox_user' in output", "solution": ["last"], "success_msg": "You reviewed recent login history." }
|
|
]
|
|
},
|
|
{
|
|
"id": "m8_l2_ports_and_paths",
|
|
"title": "Inspect open paths with lsof, netstat, traceroute, and dig",
|
|
"goal": "Use deeper network tools when the simple service or socket checks are not enough.",
|
|
"why_it_matters": "Real network debugging often requires more than ping and curl.",
|
|
"concepts": ["Open file and socket ownership", "Legacy vs modern network listing", "Route tracing", "DNS lookup"],
|
|
"command": "lsof / netstat / traceroute / dig",
|
|
"examples": ["lsof", "netstat", "traceroute 8.8.8.8", "dig example.com"],
|
|
"pitfalls": ["Treating all network questions as port-only problems", "Ignoring route or DNS evidence when connectivity looks inconsistent"],
|
|
"scenarios": ["Confirm which process owns a listening socket", "Trace whether the path to a remote target looks reachable", "Check if DNS is the real failure point"],
|
|
"troubleshooting_flow": ["Use lsof or netstat to inspect local ownership", "Use traceroute to reason about path", "Use dig to isolate DNS problems"],
|
|
"related_commands": ["lsof", "netstat", "traceroute", "dig", "ss"],
|
|
"classic_view": "When simple checks stop being enough, move to ownership, route, and DNS visibility.",
|
|
"takeaways": ["Use lsof for ownership clues", "Use traceroute for route intuition", "Use dig to separate DNS from transport issues"],
|
|
"after_class": "Practice describing which question each command answers before you run it.",
|
|
"exercises": [
|
|
{ "id": "m8_l2_e1", "type": "operation", "title": "Inspect open files and sockets", "hint": "Run lsof.", "success_test": "cmd == 'lsof' and 'LISTEN' in output", "solution": ["lsof"], "success_msg": "You inspected file and socket ownership." },
|
|
{ "id": "m8_l2_e2", "type": "operation", "title": "Inspect listening network state", "hint": "Run netstat.", "success_test": "cmd == 'netstat' and 'LISTEN' in output", "solution": ["netstat"], "success_msg": "You inspected network listening state with netstat." },
|
|
{ "id": "m8_l2_e3", "type": "operation", "title": "Trace a network path", "hint": "Run traceroute 8.8.8.8.", "success_test": "cmd == 'traceroute 8.8.8.8' and 'traceroute' in output", "solution": ["traceroute 8.8.8.8"], "success_msg": "You traced a network path." },
|
|
{ "id": "m8_l2_e4", "type": "operation", "title": "Check DNS resolution", "hint": "Run dig example.com.", "success_test": "cmd == 'dig example.com' and 'ANSWER SECTION' in output", "solution": ["dig example.com"], "success_msg": "You separated DNS lookup from the rest of the network path." }
|
|
]
|
|
},
|
|
{
|
|
"id": "m8_l3_time_and_schedule",
|
|
"title": "Read scheduling context with date, cal, and crontab",
|
|
"goal": "Think about when work runs, not just what runs.",
|
|
"why_it_matters": "A lot of operations work is time-based: jobs, cutovers, maintenance windows, and recurring checks.",
|
|
"concepts": ["Current system time", "Calendar context", "Recurring jobs"],
|
|
"command": "date / cal / crontab",
|
|
"examples": ["date", "cal", "crontab -l"],
|
|
"pitfalls": ["Ignoring system time when reading logs or scheduling changes", "Treating cron like magic instead of planned automation"],
|
|
"scenarios": ["Confirm the current host time before correlating logs", "Check whether a user has scheduled jobs", "Think about maintenance windows"],
|
|
"troubleshooting_flow": ["Read current time first", "Check the calendar context", "Inspect scheduled jobs before assuming nothing runs automatically"],
|
|
"related_commands": ["date", "cal", "crontab", "history"],
|
|
"classic_view": "Time is part of system state, and operations mistakes often come from forgetting that.",
|
|
"takeaways": ["Time-stamp your thinking", "Use calendar context during planning", "Check cron before assuming a task is manual"],
|
|
"after_class": "Explain how wrong time assumptions can distort a log or incident timeline.",
|
|
"exercises": [
|
|
{ "id": "m8_l3_e1", "type": "operation", "title": "Read the current system time", "hint": "Run date.", "success_test": "cmd == 'date' and 'CST' in output", "solution": ["date"], "success_msg": "You checked the system time." },
|
|
{ "id": "m8_l3_e2", "type": "operation", "title": "Open the calendar view", "hint": "Run cal.", "success_test": "cmd == 'cal' and 'March' in output", "solution": ["cal"], "success_msg": "You opened a calendar view for planning context." },
|
|
{ "id": "m8_l3_e3", "type": "operation", "title": "Inspect scheduled jobs", "hint": "Run crontab -l.", "success_test": "cmd == 'crontab -l' and 'crontab' in output", "solution": ["crontab -l"], "success_msg": "You checked for scheduled cron jobs." },
|
|
{ "id": "m8_l3_e4", "type": "scenario", "question": "Why should you check date before correlating logs from an incident?", "answer": "Because a wrong time assumption can make the event sequence look incorrect even if the commands are right." }
|
|
]
|
|
}
|
|
]
|
|
}
|
|
]
|
|
}
|