System recovery often begins with small, exact interventions: remove the right file, stop the right process, narrow the right permissions, and make configuration persist. This challenge-based project puts those decisions into four independent Linux rescue scenarios rather than a guided command walkthrough.
You will clean a prepared filesystem, investigate a deliberate CPU hog, harden a sensitive directory, and standardize a developer's Zsh environment. Each phase checks the resulting machine state, so success depends on choosing commands carefully and verifying their effects.
What You Will Learn
- Search
/tmpby file size and remove the identified oversized temporary file - Create an archive directory and move only
.logfiles while preserving unrelated downloads - Inspect system load, identify the highest-CPU process by PID, terminate it, and confirm it is gone
- Create a Linux group and assign it as the group owner of a protected directory
- Apply mode
770to permit owner and group access while removing all access for others - Persist
PROJECT_ENV=productionand adeployalias in.zshrc, then reload and verify them
Who This Course Is For
This project is for Linux and DevOps learners who want to test foundational administration skills in realistic, outcome-driven tasks.
Prerequisites: Familiarity with Linux navigation, file search and movement, process inspection, permissions and ownership, and shell startup files; this is an assessment-style project rather than a beginner tutorial.
Learning environment: A browser-accessible Linux host with Zsh, standard GNU/Linux utilities, prepared files and processes, and elevated privileges for group and /srv/config changes; no cloud account is required.
Frequently Asked Questions
Is this project guided step by step?
No. Each challenge states the target state, requirements, examples, and optional hints, but you choose and run the Linux commands yourself.
Will I delete or change real personal data?
No. The environment contains prepared targets such as /tmp/garbage_data.tmp, sample downloads, a deliberate stress_test_proc, and /srv/config. You should still resolve exact paths before destructive commands.
What security hardening is performed?
You create the devops group, make it the group owner of /srv/config, and set permissions to rwxrwx--- (770). The project does not configure ACLs, sudo policy, SELinux, or secret encryption.
What makes the developer settings persistent?
The project requires an exact export PROJECT_ENV=production entry and a deploy alias pointing to /home/labex/deploy_script.sh in ~/.zshrc, followed by reloading the file for the current shell.
