This capstone lab ties together everything from Labs 01–19. You will simulate a complete server onboarding workflow: provisioning users, configuring SSH, setting up cron jobs, monitoring processes, analyzing logs, and writing a production-grade server health-check and hardening script.
Prerequisites: Labs 01–19 completed. This lab uses skills from every previous lab.
Step 1: User Provisioning & Privilege Setup (Labs 07, 09)
A new server needs the right users and groups before anything else.
dockerrun-it--rmubuntu:22.04bash# Create application and admin usersuseradd-m-s/bin/bash-c"Web Application"webuseruseradd-m-s/bin/bash-c"Deploy Bot"deployuseradd-m-s/bin/bash-c"SRE Admin"sreadmin# Create functional groupsgroupaddwebappsgroupadddeployersgroupaddmonitoring# Assign users to groupsusermod-aGwebappswebuserusermod-aGwebapps,deployersdeployusermod-aGmonitoring,sudosreadmin# Set passwords (in real systems use: passwd -e user to force reset)echo"webuser:Secr3tW3b!"|chpasswdecho"deploy:D3pl0yB0t!"|chpasswdecho"sreadmin:Adm1nPa$$!"|chpasswd# Verify user setupecho"=== Users created ==="grep-E'webuser|deploy|sreadmin'/etc/passwd|awk-F:'{printf "%-12s UID:%-5s Shell: %s\n", $1, $3, $7}'echo""echo"=== Group memberships ==="foruserinwebuserdeploysreadmin;dogroups_list=$(id-Gn$user|tr''',')printf"%-12s → %s\n""$user""$groups_list"doneecho""echo"=== Home directories ==="ls-la/home/
📸 Verified Output:
💡 Principle of least privilege: Give each user only the access they need. webuser has no sudo access. deploy can deploy but not admin. Only sreadmin has sudo. This limits blast radius if any account is compromised.
Step 2: SSH Key Authentication Setup (Lab 16)
Every server should use key-based SSH authentication with password auth disabled.
📸 Verified Output:
💡 Test SSH config before reloading. Always run sshd -t -f /etc/ssh/sshd_config to test config syntax before systemctl reload sshd. A broken sshd config + reload locks you out of the server. Keep a second terminal session open before reloading.
Proper directory structure and permissions are the foundation of a secure, organized server.
📸 Verified Output:
💡 The sticky bit (chmod +t) on /tmp-style directories prevents users from deleting files they don't own. The T or t in drwxrwxrwt shows it's set. Use chmod 1777 or chmod +t. This is how /tmp itself works on every Linux system.
Step 4: Cron Jobs & Scheduled Tasks (Lab 13)
Automate recurring tasks: backups, log rotation, health checks.
📸 Verified Output:
💡 Always redirect cron output. Without >> /var/log/myapp/cron.log 2>&1, cron emails output to root — and on most servers, nobody reads those emails. Log to a file and monitor the log file. Add || true at the end of cron commands to prevent failed jobs from generating email spam.
Step 5: Log Setup & Structured Logging (Lab 17)
📸 Verified Output:
💡 Use a consistent log format across all your services. The format TIMESTAMP LEVEL [component] message key=value is grep-friendly, awk-parseable, and human-readable. Many centralized logging platforms (Elasticsearch, Splunk, Datadog) can auto-parse key=value pairs.
Step 6: Process Monitoring & System Performance (Labs 10, 18)
📸 Verified Output:
💡 /proc/[PID]/fd/ shows all open file descriptors for a process.ls /proc/1/fd | wc -l counts them. If a process has thousands of open FDs and is growing, it's probably leaking file handles. Check ulimit -n for the system limit and adjust in /etc/security/limits.conf.
Step 7: Text Processing — Log Analysis Pipeline (Lab 19)
📸 Verified Output:
💡 Pipe your log reports to tee for both screen display and file archiving.bash log-report.sh | tee /var/log/reports/daily-$(date +%Y%m%d).txt. This lets you read the output in real-time while saving it. Use gzip to compress old reports: find /var/log/reports -name "*.txt" -mtime +7 | xargs gzip.
Step 8: Capstone — Complete Server Hardening & Health Script
Scenario: Write the definitive server health-check and hardening script that integrates all skills from Labs 01–19.
📸 Verified Output:
💡 Evolve this script into your team's standard runbook. Add checks for: open ports (ss -tlnp), failed systemd services (systemctl --failed), certificate expiry (openssl s_client), kernel updates needed (needs-restarting), and unauthorized cron jobs (crontab -l for each user). Schedule it daily and alert on score drops.
SUID scan, world-writable check, brute force detection
Labs 09, 16
Reporting
Formatted output, score calculation, exit codes
All labs
🎓 Congratulations — you've completed the Linux Practitioner series!
You can now: manage users and groups, configure SSH securely, handle file permissions, write shell scripts, manage processes, schedule cron jobs, analyze logs, monitor system performance, and build automated administration tools. These are the daily tools of a working Linux systems administrator.