How to Install and Use Ansible on Fedora

Ansible is an agentless automation platform for managing Linux servers, workstations, and cloud systems from a central control node. Fedora is a practical environment for learning it because packages are current, systemd is standard, and common administration tools are readily available.

This guide explains how to install Ansible, prepare an inventory, authenticate with SSH, run ad hoc commands, and create a repeatable playbook. The examples suit a Fedora laptop, a home lab, or infrastructure hosted in Sydney, Melbourne, Brisbane, or another Australian location.

The same approach works when managing RHEL, CentOS Stream, Rocky Linux, and other compatible systems. Before changing production hosts, test commands against a disposable virtual machine and keep firewall and SSH access available.

Prepare the Fedora control node

Update Fedora’s package metadata before installing automation tools:

sudo dnf upgrade --refresh
sudo dnf install ansible-core

Confirm that the executable is available:

ansible --version

Fedora generally provides ansible-core, which contains the engine, command-line utilities, and built-in modules. Collections add extra modules when required, while Python virtual environments can help keep project dependencies separate.

Create a working directory for the project:

mkdir -p ~/ansible-lab
cd ~/ansible-lab

Keeping inventories, playbooks, and variables together makes it easier to track changes. This is especially useful for a small Australian business where one administrator may maintain both office systems and cloud servers.

Configure SSH access to managed hosts

Ansible normally connects to Linux hosts over SSH, so create a key pair if you do not already have one:

ssh-keygen -t ed25519 -C "fedora-ansible"
ssh-copy-id admin@192.0.2.20

Replace the example address and username with a real managed node. Test the connection before troubleshooting Ansible:

ssh admin@192.0.2.20

For several servers, define aliases in ~/.ssh/config:

Host web01
    HostName 192.0.2.20
    User admin
    IdentityFile ~/.ssh/id_ed25519

Use SSH keys rather than passwords for routine automation. If the host is behind an Australian office firewall or a cloud security group, permit SSH only from the administrator’s trusted address range.

Create an inventory

An inventory tells Ansible which systems belong to which groups. Create inventory.ini:

[web]
web01 ansible_host=192.0.2.20
web02 ansible_host=192.0.2.21

[database]
db01 ansible_host=192.0.2.30

[all:vars]
ansible_user=admin

Check the inventory graph:

ansible-inventory -i inventory.ini --graph

If the managed account requires privilege escalation, add become=true to a playbook or pass --become during a command. Avoid storing a sudo password in plain text; use Ansible Vault when password-based escalation is unavoidable.

Test Ansible with ad hoc commands

The ping module checks connectivity and Python availability:

ansible all -i inventory.ini -m ping

A successful response contains "pong". You can gather operating system information with:

ansible all -i inventory.ini -m setup -a 'filter=ansible_distribution*'

Run a safe shell command through the command module:

ansible web -i inventory.ini -m command -a 'uptime'

Use command for simple programs and prefer dedicated modules for package installation, services, files, and users. For example, this installs Nginx on Fedora hosts:

ansible web -i inventory.ini -b -m dnf \
  -a 'name=nginx state=present'

Write a repeatable playbook

Create web.yml to install and enable Nginx:

---
- name: Configure Fedora web servers
  hosts: web
  become: true
  tasks:
    - name: Install Nginx
      ansible.builtin.dnf:
        name: nginx
        state: present

    - name: Enable and start Nginx
      ansible.builtin.service:
        name: nginx
        state: started
        enabled: true

    - name: Allow HTTP through firewalld
      ansible.posix.firewalld:
        service: http
        permanent: true
        immediate: true
        state: enabled

The firewalld task may require the relevant collection:

ansible-galaxy collection install ansible.posix

Run a syntax check and preview changes before applying them:

ansible-playbook -i inventory.ini web.yml --syntax-check
ansible-playbook -i inventory.ini web.yml --check
ansible-playbook -i inventory.ini web.yml

Idempotence is a central Ansible principle: running the same playbook again should produce no unnecessary changes. This makes scheduled maintenance safer across systems in Perth, Canberra, or regional offices connected by slower links.

Organise projects and protect data

Use a project layout that separates automation from secrets:

ansible-lab/
├── inventory.ini
├── web.yml
├── group_vars/
└── roles/

For storage planning on a Linux server, review this RAID 5 with mdadm reference before automating disk operations. Ansible can manage filesystems and mounts, but destructive storage tasks should be tested carefully and backed by verified recovery procedures.

Keep credentials out of playbooks. Encrypt sensitive variables with Ansible Vault:

ansible-vault create secrets.yml
ansible-vault edit secrets.yml
ansible-playbook -i inventory.ini web.yml --ask-vault-pass

Store the project in version control, exclude private keys, and record which Fedora release and Ansible version were used. A simple project tracker such as My Easy Projects can also help coordinate maintenance windows and approval records.

Checks for reliable automation

Before running changes across a group, verify the basic control path:

Confirm DNS or IP reachability
Test SSH with the intended account
Run ansible-inventory --graph
Use --check where module support is available

After a playbook run, inspect the resulting service state:

Check systemctl status nginx
Test with curl http://host-address
Review firewalld rules
Re-run the playbook for idempotence

Partitioning automation deserves extra caution. Compare device names, filesystem types, and mount points with a tested partitioning guide before placing parted or filesystem tasks in a production playbook.

Choose the right Ansible command

Different commands suit different stages of administration. Ad hoc commands are quick for inspection, while playbooks provide repeatability, reviewability, and a clear change history.

Task	Recommended command	Typical use
Test access	`ansible all -m ping`	Confirm SSH and Python
Inspect hosts	`ansible all -m setup`	Collect facts
Run one command	`ansible group -m command`	Quick diagnostics
Apply configuration	`ansible-playbook`	Repeatable changes
Preview changes	`ansible-playbook --check`	Safer testing
Protect secrets	`ansible-vault`	Encrypt variables

Start with a small inventory and one non-critical Fedora host. Once SSH, privilege escalation, firewalld behaviour, and playbook idempotence are verified, expand gradually and keep a tested rollback or recovery path for every production change.