Shell – distro-agnostic configuration management software

ansiblearch linuxdebianshell-scriptstability

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:

#!/bin/bash

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

Best Answer

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:

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

    pacman:
      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.

Related Question