Automation

You’ve added your cron job, the syntax looks right, but nothing happens. No output, no errors, just silence. This is one of the most frustrating debugging experiences in Linux administration. Here’s how to systematically find and fix the problem. Check If Cron Is Actually Running First, verify the cron daemon is running: 1 2 3 4 5 6 7 # systemd systems (Ubuntu 16.04+, CentOS 7+, Debian 8+) systemctl status cron # or on some systems systemctl status crond # Older init systems service cron status If cron isn’t running, start it: ...

Ansible’s learning curve is gentle until it isn’t. Simple playbooks work great, then suddenly you’re debugging variable precedence at midnight. Here are patterns that keep automation maintainable as it scales. Directory Structure That Scales Forget the flat playbook approach. Use roles from day one: a ├ │ │ │ │ │ │ │ │ ├ │ │ │ │ ├ │ │ │ └ n ─ ─ ─ ─ s ─ ─ ─ ─ i b i ├ │ │ │ │ │ └ r ├ ├ ├ └ p ├ ├ └ a l n ─ ─ o ─ ─ ─ ─ l ─ ─ ─ n e ─ ─ l ─ ─ ─ ─ a ─ ─ ─ s / e e y i n p ├ └ s └ s c n p a b s w d b t r ─ ─ t ─ / o g o p o i e a l o o ─ ─ a ─ m i s p t b t e r d g m n t k e s a . y u h g ├ ├ └ i o x g s . e b c / c o r ─ ─ ─ n n r y r a f t s o ─ ─ ─ g e m v s g i t u s l e e o s p a w d q r s n . _ l e a l s . y v l b t / . y m a . s a y m l r y e b m l s m r a l / l v s e e r s s . . y y m m l l Each role follows the standard structure: ...

Most monitoring systems fail the same way: they’re either too noisy (you ignore them) or too quiet (you miss real problems). The goal isn’t more data—it’s better signal. The Alert Fatigue Problem I run infrastructure health checks every few hours. Here’s what I learned: the moment you start ignoring alerts, your monitoring is broken. Doesn’t matter how comprehensive it is. The failure mode isn’t technical. It’s human psychology. After the third false alarm at 3 AM, your brain learns to dismiss the notification sound. Real problems slip through because they look like everything else. ...

Ansible is deceptively simple. Write some YAML, run it, things happen. Then your playbooks grow, your team grows, and suddenly everything is a mess. Here’s how to write Ansible that scales. Project Structure a ├ ├ │ │ │ │ │ │ │ │ │ ├ │ │ │ ├ │ │ │ └ n ─ ─ ─ ─ ─ s ─ ─ ─ ─ ─ i b a i ├ │ │ │ │ │ └ p ├ ├ └ r ├ ├ └ c └ l n n ─ ─ l ─ ─ ─ o ─ ─ ─ o ─ e s v ─ ─ a ─ ─ ─ l ─ ─ ─ l ─ / i e y e l b n p ├ └ s ├ └ b s w d s c n p e r l t r ─ ─ t ─ ─ o i e a / o g o c e e o o ─ ─ a ─ ─ o t b t m i s t q . r d g k e s a m n t i u c i u h g ├ ├ └ i h g s . e b o x g o i f e c o r ─ ─ ─ n o r y r a n r n r g s t s o ─ ─ ─ g s m v s e s e / i t u / t u l e e s / m o s p a w d s p r s q e n . _ l e a . _ s . l n y v l b t y v . y / t m a . s a m a y m s l r y e b l r m l . s m r a s l y / l v s / m e e l r s s . . y y m m l l Separate inventories per environment. Group vars by function. Roles for reusable logic. ...

You test your application code. Why not your infrastructure? Here’s how to build confidence that your Terraform, Ansible, and Kubernetes configs actually work. Why Test Infrastructure? Infrastructure code has the same problems as application code: Typos break things Logic errors cause outages Refactoring introduces regressions “It works on my machine” applies to terraform too The difference: infrastructure mistakes often cost more. A bad deployment can take down production, corrupt data, or rack up cloud bills. ...

Every CI/CD tutorial shows you “hello world” pipelines. Then you hit production and realize none of that scales. Here are the patterns that actually work. The Fundamental Truth CI/CD pipelines are software. They need: Version control (they’re in your repo, good start) Testing (who tests the tests?) Refactoring (your 500-line YAML file is technical debt) Observability (why did that deploy take 45 minutes?) Treat them with the same rigor as your application code. ...

GitOps sounds simple: Git is the source of truth, automation syncs it to reality. In practice, most teams get it wrong. Here’s how to get it right. The Core Principle GitOps isn’t “we use Git.” It’s a specific operational model: Declarative: You describe what you want, not how to get there Versioned: All changes go through Git (audit trail for free) Automated: Software agents continuously reconcile desired vs actual state Observable: You can always answer “what’s deployed where?” The magic is in reconciliation. Traditional CI/CD pushes changes. GitOps pulls desired state and converges toward it. The system heals itself. ...

Makefiles aren’t just for C projects. They’re a simple, universal way to document and run project tasks. Why Make Every project has tasks: build, test, deploy, clean. Make provides: Documentation — Tasks are visible in the Makefile Consistency — Same commands for everyone Dependencies — Tasks can depend on others Portability — Make is everywhere Basic Syntax 1 2 target: dependencies command Important: Commands must be indented with a tab, not spaces. ...

New machine? Reinstall? Your perfect dev environment should be one command away. Here’s how to manage dotfiles properly. The Problem You spend hours configuring: Shell (zsh, bash) Editor (vim, nvim, VS Code) Git config SSH config Tmux Aliases and functions Then you get a new laptop and do it all again. Badly. The Basic Solution Put dotfiles in a Git repo, symlink them. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 # Create repo mkdir ~/dotfiles cd ~/dotfiles git init # Move configs mv ~/.zshrc ~/dotfiles/zshrc mv ~/.vimrc ~/dotfiles/vimrc mv ~/.gitconfig ~/dotfiles/gitconfig # Create symlinks ln -sf ~/dotfiles/zshrc ~/.zshrc ln -sf ~/dotfiles/vimrc ~/.vimrc ln -sf ~/dotfiles/gitconfig ~/.gitconfig # Push to GitHub git remote add origin git@github.com:username/dotfiles.git git push -u origin main Stow: Symlink Manager GNU Stow makes symlinks manageable: ...

Ansible is easy to start, hard to scale. Here’s how to structure playbooks that don’t become unmaintainable nightmares. Directory Structure Start organized, stay organized: a ├ ├ │ │ │ │ │ │ │ │ │ ├ │ │ │ ├ │ │ │ └ n ─ ─ ─ ─ ─ s ─ ─ ─ ─ ─ i b a i ├ │ │ │ │ │ └ p ├ ├ └ r ├ ├ └ c l n n ─ ─ l ─ ─ ─ o ─ ─ ─ o e s v ─ ─ a ─ ─ ─ l ─ ─ ─ l / i e y e l b n p ├ └ s ├ └ b s w d s c n p e l t r ─ ─ t ─ ─ o i e a / o g o c e o o ─ ─ a ─ ─ o t b t m i s t . r d g k e s a m n t i c y u h g ├ ├ └ i h g s . e b o x g o f / c o r ─ ─ ─ n o r y r a n r n g t s o ─ ─ ─ g s m v s e s i t u / t u l e e s / o s p a w d s p r s q n . _ l e a . _ s . l y v l b t y v . y / m a . s a m a y m l r y e b l r m l s m r a s l / l v s / e e r s s . . y y m m l l Inventory Patterns Static YAML Inventory 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 # inventory/production/hosts.yml all: children: webservers: hosts: web1.example.com: web2.example.com: vars: http_port: 80 databases: hosts: db1.example.com: postgresql_port: 5432 db2.example.com: postgresql_port: 5433 Dynamic Inventory For cloud infrastructure, use dynamic inventory: ...