Manual excellence doesn’t scale. This last module is the gateway: make cron reliable, then aim at config-as-code and the DevOps roadmap — without abandoning sysadmin judgment.
Bootcamp hub · Prev: Module 5
Learning goals
- Write a cron job with absolute paths, logs, and flock
- Know when to prefer systemd timers
- See the path into Ansible/CI without skipping fundamentals
Required posts
- Cron Job Not Running? Pro checklist
- SysAdmin to DevOps in 2026 roadmap
- Bonus for site owners: WordPress contact form not sending
Lab
- Schedule a script every 5 minutes that appends a timestamp to a log; verify with
grep CRON/ journal. - Break PATH on purpose; fix with absolute paths.
- Sketch (on paper) an Ansible role that creates your labadmin user + SSH key policy.
You’re done — now what?
Revisit any troubleshooting post when production bites. Keep the courses hub bookmarked. Ship notes publicly; teaching locks learning in.
From manual to repeatable
Anything you’ve done thrice should be a script. Anything several machines need should be config management. Anything humans forget at 2 AM should be monitored.
Cron mastery checklist
- Absolute paths
- Logging redirects
- flock / overlap protection
- Freshness alert
- Runs as least privilege user
Drill: Cron job not running.
Gateway to DevOps
Ansible for OS desired state, Git for history, CI for not SSHing to deploy. The order matters — read the 2026 roadmap and pick Phase 1 only until it sticks.
Capstone ideas
- Ansible role: create labadmin + harden sshd (lab)
- Timer/cron: nightly lab package cache clean + log
- One-page runbook linking your favorite troubleshooting posts
- Optional: fix a WordPress form mail path on a staging site using the form checklist
Closing note
You don’t graduate from fundamentals. You get faster at them. Keep the bootcamp bookmarks; return when production invents a new Tuesday surprise.
Idempotence in plain language
Run it twice, get the same end state without stacking mess. Cron that appends blindly isn’t idempotent. Ansible tasks usually aim to be. Train your eye for “safe to re-run.”
Secrets discipline
No secrets in Git. No secrets in world-readable cron lines. Use env files with mode 600, vaults, or cloud secret stores. Rotate when people leave.
Your next thirty days
- Week 1: automate one personal lab setup step
- Week 2: add monitoring freshness for one job
- Week 3: read the DevOps roadmap Phase 1 and start an Ansible role
- Week 4: write a short public note about something you fixed
Congrats on finishing the bootcamp path — now go break a lab on purpose and fix it faster than last month.
Extended lab: one role, one timer
Write an Ansible playbook (even locally against localhost) that ensures a directory, a script, and a cron/timer exist. Apply twice; confirm no duplication mess. Then break the cron PATH and fix using the cron checklist.
Finish by skimming DevOps roadmap Phase 1 exit criteria.
What “done” looks like for automation juniors
- You can explain why a job didn’t run using logs
- You can re-run config management without fear
- You refuse to store secrets in public Git
- You prefer small reviewed changes over weekend cowboy edits
If that list feels true, you’re ready to help a team — keep learning in public, keep labs messy on purpose, and keep the troubleshooting posts close.
Cron vs timer decision guide
- Simple user job on a laptop — cron is fine
- Needs dependencies / better logs / catch-up after downtime — timer
- Fleet-wide — config management + one scheduler pattern
Don’t run both for the same task. Duplicated schedules create duplicated outages.
Git as operational memory
Even for homelab: commit Ansible roles and unit files. History answers “what changed before it broke?” Write commit messages that future you can search at 2 AM.
Graduation checklist
- Bootcamp modules 1–6 labs completed
- Three troubleshooting posts practiced in lab
- One automated job with logging + freshness check
- Roadmap Phase 0–1 started
- Notes published or stored where you can find them