◆Kent, UK
Community support·Contact·My lab
CONFIGURATION MANAGEMENT

Automation that matches the size of the environment

Practical Ansible, shell and systemd work—without pretending the homelab is a thousand-node enterprise.

Where I use automation

I use automation where repeatability matters: installing packages, applying Linux defaults, deploying agents, creating users, loading nftables policy, maintaining services and documenting recovery.

  • Ansible inventories and role-based server baselines
  • Package updates and common administrative tooling
  • SSH hardening and account configuration
  • Zabbix and Wazuh agent deployment
  • Docker Compose application definitions
  • systemd units and watchdog scripts
  • nftables rules for per-user policy
roles/linux_baseline/tasks/main.yml
- name: Install baseline packages
  ansible.builtin.apt:
    name: "{{ baseline_packages }}"
    state: present
    update_cache: true

- name: Deploy service configuration
  ansible.builtin.template:
    src: service.conf.j2
    dest: /etc/example/service.conf
  notify: restart service

- name: Ensure service is enabled
  ansible.builtin.systemd_service:
    name: example
    enabled: true
    state: started
ENGINEERING PRINCIPLES

The goal is safe repeatability.

Idempotent

Running the same playbook again should converge on the intended state rather than create damage or duplicate configuration.

Reviewable

Infrastructure changes belong in readable files that can be compared, versioned and explained during troubleshooting.

Recoverable

Automation complements backups and testing; it never replaces safe upgrade planning or service-specific recovery steps.