Lab 20: Capstone — Server Admin Workflow

Time: 30 minutes | Level: Practitioner | Docker: docker run -it --rm ubuntu:22.04 bash


Overview

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.

docker run -it --rm ubuntu:22.04 bash

# Create application and admin users
useradd -m -s /bin/bash -c "Web Application" webuser
useradd -m -s /bin/bash -c "Deploy Bot" deploy
useradd -m -s /bin/bash -c "SRE Admin" sreadmin

# Create functional groups
groupadd webapps
groupadd deployers
groupadd monitoring

# Assign users to groups
usermod -aG webapps webuser
usermod -aG webapps,deployers deploy
usermod -aG monitoring,sudo sreadmin

# Set passwords (in real systems use: passwd -e user to force reset)
echo "webuser:Secr3tW3b!" | chpasswd
echo "deploy:D3pl0yB0t!" | chpasswd
echo "sreadmin:Adm1nPa$$!" | chpasswd

# Verify user setup
echo "=== 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 ==="
for user in webuser deploy sreadmin; do
    groups_list=$(id -Gn $user | tr ' ' ',')
    printf "%-12s → %s\n" "$user" "$groups_list"
done

echo ""
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.


Step 3: Directory Structure & File Permissions (Labs 03, 09)

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.


Summary

Skill Area
Commands Used
Labs Referenced

User provisioning

useradd, groupadd, usermod, chpasswd

Lab 07

SSH key setup

ssh-keygen -t ed25519, authorized_keys, sshd_config

Lab 16

File permissions

chmod, chown, find -perm, sticky bit

Labs 03, 09

Cron automation

crontab, cron syntax */5 * * * *, MAILTO

Lab 13

Log management

logrotate, structured logging, tee

Lab 17

Performance monitoring

uptime, free, sar, ps aux, /proc/loadavg

Lab 18

Text processing

grep -E, awk, sed, pipelines

Lab 19

Shell scripting

set -euo pipefail, functions, arithmetic, printf

Labs 11–14

Security auditing

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.

Last updated