Real-World Projects

Architecture: a single Ubuntu Server VM running Nginx, reachable only via hardened SSH for administration and via HTTP/HTTPS for public traffic — every other port closed by default. This project deliberately combines Levels 9 (SSH), 10 (Firewalls), and 14 (Web Servers) into one coherent build, which is exactly the shape a real "set up a web server" work ticket actually takes — no single level in isolation.

Requirements: a fresh Ubuntu Server 24.04 VM; a non-root administrative user with sudo access; an SSH key pair already generated. Implementation order matters here specifically to avoid locking yourself out: set up the administrative user and confirm sudo access first, confirm SSH key-based login works in a second session before touching sshd_config, harden SSH (disable root login and password auth), enable the firewall allowing only 22/80/443 (confirming SSH is allowed before enabling), then install and configure Nginx to serve a test site.

Verification: confirm SSH key login works and password login is rejected; confirm `ufw status` shows exactly the three intended ports; confirm the site loads over HTTP; confirm any other port (test with a throwaway service on an unlisted port) is unreachable from outside. Cleanup: if this was a genuinely temporary lab VM, destroy it once verification is complete rather than leaving an unused, unpatched server running indefinitely — an idle, forgotten VM is itself a real security liability.

Architecture: an application server whose data directory needs to grow over time in unpredictable increments — the wrong approach is a single fixed-size partition sized by guesswork upfront; the right approach is LVM specifically because it supports growing a logical volume later without needing to have predicted the exact right size at creation time.

Implementation: build the PV → VG → LV chain from Level 8 with room to grow (either an oversized initial disk, or a VG designed to accept an additional PV later), format with a filesystem that supports online growth (ext4 or XFS), mount it via `/etc/fstab` referenced by UUID so the mount survives a reboot, and point the application's data directory at the mounted location.

Verification: write test data, confirm it persists across a reboot (proving the fstab entry is correct), then simulate growth by extending the LV and filesystem live (Level 8's `lvextend` + `resize2fs`/`xfs_growfs`) while the application keeps running, confirming zero downtime was required for the storage expansion — the entire point of choosing LVM over a plain partition in the first place.

Architecture: a lightweight monitoring approach for a small deployment that doesn't yet justify a full observability platform — a scheduled Bash script (Level 13) checking disk usage, service status, and a basic HTTP health check, logging results in a way that survives the individual server (Level 12), and alerting (even just via a log entry or simple email/webhook) if a threshold is crossed.

Implementation: extend the disk-monitoring script pattern from Level 13's lab with a service-status check (`systemctl is-active <service>`) and an HTTP health check (`curl -f` against a health endpoint, checking its exit status). Schedule it via a systemd timer or cron to run every few minutes (Level 5's systemd knowledge applies directly to building the timer unit). Ensure output is logged somewhere that survives the individual server going down entirely — even appending to a file synced elsewhere, or emitting to the journal with a distinct identifiable tag, is a meaningful step up from "no record at all if the server itself is the thing that failed".

Verification: intentionally stop the monitored service and confirm the check correctly detects and logs the failure within one check interval; intentionally fill the test disk close to the configured threshold and confirm the disk-usage warning fires correctly; confirm a genuinely healthy state produces no false-positive alerts.