Skip to main content

k1.4 — Safety & Learning Workflow 🛡️

The goal here is to make you fast at learning without “mystery breakage” or data loss. Your two pillars are:

  • Reversibility (you can undo changes)
  • Traceability (you can explain what changed and why)

1) Always have a rollback

  1. Use snapshots for “big steps”

    • If you’re learning in a VM, take a snapshot before:
      • installing a web stack
      • changing firewall rules
      • editing service configs (Nginx/PHP-FPM/SSH)
      • doing major upgrades
    • Name snapshots clearly, e.g. pre-nginx, before-php82, working-tls.

  2. Back up configs before you edit

    • Use simple, consistent backups:
      • cp /etc/nginx/nginx.conf /etc/nginx/nginx.conf.bak
      • Or add a timestamp:
        • cp file file.$(date +%F_%H%M).bak

  3. Keep “known good” copies

    • For key files, keep a minimal working baseline you can restore quickly (especially useful for Nginx virtual hosts and PHP-FPM pools).

2) Make changes intentionally (one variable at a time)

  1. Change one thing → test → observe

    • After each change, immediately validate:
      • Is the service still running?
      • Did logs change?
      • Is the port listening?
      • Does the browser/curl test pass?

  2. Prefer small edits over big rewrites

    • Comment or duplicate blocks rather than deleting until you’re confident.

  3. Avoid “random fix” spirals

    • If you try 5 things at once, you won’t know which one worked (or what caused the break).

3) Keep a tiny change log (it pays off quickly)

Use a simple text file (e.g. ~/lab-notes.md) and record:

  • What you changed (file/service)
  • Why you changed it
  • How you tested it
  • What happened (success/error + log snippet)

Example format:

  • 2026-04-04 — edited /etc/nginx/sites-available/example
    • Reason: add reverse proxy to app on :3000
    • Test: nginx -t, systemctl reload nginx, curl -I http://localhost
    • Result: OK / or error + relevant line from logs

This becomes your personal “ops memory” ✅

4) Practice in layers (a safe progression)

Follow this order to minimize confusion:

  1. Shell basics
    • navigation, reading files, pipes/redirection
  2. Files & permissions
    • ownership, chmod, web root safety, troubleshooting 403/permission errors
  3. Services + logs
    • systemctl, journalctl, knowing where to look when something fails
  4. Networking + firewall
    • ports, DNS basics, local vs public reachability
  5. Web stack + TLS
    • Nginx/Apache, PHP-FPM, DB, Let’s Encrypt renewals

Each layer assumes the previous one—this prevents “I don’t even know what I broke” moments.

5) A minimal “safe workflow” you can reuse

When making a change to a service (Nginx/PHP/SSH), do this every time:

  1. Backup
    • Copy the config file you’re touching.
  2. Validate config
    • Example pattern:
      • Nginx: nginx -t
      • (Other services have equivalents; you’ll learn them as we go.)
  3. Reload, don’t restart (when possible)
    • Reload applies changes with less downtime and less risk.
  4. Check logs immediately
    • Use service logs to confirm it started cleanly.
  5. Test from the client side
    • curl, browser, or a health endpoint.

Optional: tell me your practice setup

To tailor the labs, which environment will you use first?

  1. VM (VirtualBox/VMware/Proxmox)
  2. VPS (a real server over SSH)
  3. WSL/macOS terminal + remote Linux
  4. Containers only (Docker)
Back to top