# 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)