I don't want to label myself to specific configuration-manager modules like Ansible's apt module or yum module.

Is there a distro-agnostic configuration management software, or at least one with distro-agnostic code to install the following packages for Arch Linux as well?

I ask this because I didn't find a suitable Ansible galaxy-role to install LAMP on Arch Linux and the following Bash script for Debian isn't fit for Arch:


apt update -y
apt upgrade ufw sshguard unattended-upgrades wget curl git zip unzip tree -y

ufw --force enable
ufw allow 22,25,80,443

apt upgrade lamp-server^ ssmtp  -y
apt upgrade python-certbot-apache  -y
apt upgrade php-{cli,curl,mbstring,mcrypt,gd} phpmyadmin  -y

4 Answers 4


Technically, Ansible is that; because it's agent-less; I've used it to manage routers, switches, servers, etc.

What it seems like you're asking for is if the package module supports Arch Linux? I'm too lazy to test if that supports Arch; but if it doesn't there is always the pacman module... And if that doesn't work... There is always writing your own module.

What you're speaking of though is a larger problem with running multiple different distributions in a production environment. It becomes painful to manage long term. This is why it's good practice to not run multiple distributions in production, as from a management perspective (purely from code), it's a lot of work. The most obvious way to get around this is with Ansible using when in combination with os_family:

      name: apache2
    when: ansible_facts['os_family'] == "Debian"

      name: nginx
    when: ansible_facts['os_family'] == "Archlinux"

I've been in a situation where I had to manage Debian Servers and CentOS servers in production; eventually I made the choice to go pure Debian because:

  • The codebase for CM was cut in half (all the logic for distro specific quirks was removed).
  • Testing became less painful (if you're not testing your CM code, then you're doing it wrong).

You'll also run into major differences anyways; for example:

  • Some packages are named differently; httpd (RHEL) vs apache2 (Debian).
  • Different "default" configuration directories; /etc/default (Debian) vs /etc/sysconfig (RHEL).
  • Different init systems; although systemd has largely taken over.
  • No SSH; for example WinRM for Windows.

Configuration Management systems are a way of abstracting the environment into code; and they give you logic/conditionals to do that yourself.

  • 1
    The package module just calls the module defined in the ansible_pkg_mgr fact for that system. So any packaging system that Ansible supports will work. Jan 9, 2019 at 20:34

Maintaining a meta-package-manager seems to me to be a Sisyphean task, as someone would have to be maintaining some sort of "apache2" in Debian-likes is "httpd" in RHEL-likes (et cetera) Rosetta Stone.

However, there is a pacman module for Ansible which is purpose-made for using Ansible (the disto-agnostic management tool you're looking for) to manage packages on Arch-like systems. From the Examples section of the linked module's documentation:

- name: Install package foo
    name: foo
    state: present

- name: Upgrade package foo
    name: foo
    state: latest
    update_cache: yes

- name: Remove packages foo and bar
    name: foo,bar
    state: absent

- name: Recursively remove package baz
    name: baz
    state: absent
    recurse: yes

package is Ansible "Generic OS package manager".

An option would be to include OS specific list_of_packages

- include_vars: "{{ item }}"
     - files:
         - "{{ ansible_distribution }}-{{ ansible_distribution_release }}.yml"
         - "{{ ansible_distribution }}.yml"
         - "{{ ansible_os_family }}.yml"
         - "default.yml"
       paths: "{{ role_path }}/vars"

and install the packages

- package:
    state: present
    name: "{{ item }}"
  loop: "{{ list_of_packages }}"

Nix is a standalone package manager that not tightly bind to any os. I use it on MacOS and also Ubuntu https://nixos.org/nix/

Saltstack (Ansible compatitor) has nicer abstraction with pkg.installed and you don't need to care underlying system is apt or rpm or arch... (still neee to set diff pkg name if they diff on systems, e.g httpd or apache2)

You must log in to answer this question.