Is there a distro-agnostic configuration management software?
Clash Royale CLAN TAG#URR8PPP
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
shell-script debian arch-linux ansible stability
add a comment |
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
shell-script debian arch-linux ansible stability
add a comment |
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
shell-script debian arch-linux ansible stability
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
shell-script debian arch-linux ansible stability
shell-script debian arch-linux ansible stability
edited Jan 9 at 15:58
JohnDoea
asked Jan 9 at 15:42
JohnDoeaJohnDoea
531133
531133
add a comment |
add a comment |
4 Answers
4
active
oldest
votes
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) vsapache2
(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
Thepackage
module just calls the module defined in theansible_pkg_mgr
fact for that system. So any packaging system that Ansible supports will work.
– Michael Hampton
Jan 9 at 20:34
add a comment |
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
pacman:
name: foo
state: present
- name: Upgrade package foo
pacman:
name: foo
state: latest
update_cache: yes
- name: Remove packages foo and bar
pacman:
name: foo,bar
state: absent
- name: Recursively remove package baz
pacman:
name: baz
state: absent
recurse: yes
add a comment |
package is Ansible "Generic OS package manager".
An option would be to include OS specific list_of_packages
- include_vars: " item "
with_first_found:
- 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 "
add a comment |
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)
add a comment |
Your Answer
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "106"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f493485%2fis-there-a-distro-agnostic-configuration-management-software%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
4 Answers
4
active
oldest
votes
4 Answers
4
active
oldest
votes
active
oldest
votes
active
oldest
votes
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) vsapache2
(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
Thepackage
module just calls the module defined in theansible_pkg_mgr
fact for that system. So any packaging system that Ansible supports will work.
– Michael Hampton
Jan 9 at 20:34
add a comment |
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) vsapache2
(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
Thepackage
module just calls the module defined in theansible_pkg_mgr
fact for that system. So any packaging system that Ansible supports will work.
– Michael Hampton
Jan 9 at 20:34
add a comment |
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) vsapache2
(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.
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) vsapache2
(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.
edited Jan 12 at 13:20
Jeff Schaller
39.9k1054126
39.9k1054126
answered Jan 9 at 16:05
user1529891user1529891
2,07262346
2,07262346
1
Thepackage
module just calls the module defined in theansible_pkg_mgr
fact for that system. So any packaging system that Ansible supports will work.
– Michael Hampton
Jan 9 at 20:34
add a comment |
1
Thepackage
module just calls the module defined in theansible_pkg_mgr
fact for that system. So any packaging system that Ansible supports will work.
– Michael Hampton
Jan 9 at 20:34
1
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.– Michael Hampton
Jan 9 at 20:34
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.– Michael Hampton
Jan 9 at 20:34
add a comment |
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
pacman:
name: foo
state: present
- name: Upgrade package foo
pacman:
name: foo
state: latest
update_cache: yes
- name: Remove packages foo and bar
pacman:
name: foo,bar
state: absent
- name: Recursively remove package baz
pacman:
name: baz
state: absent
recurse: yes
add a comment |
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
pacman:
name: foo
state: present
- name: Upgrade package foo
pacman:
name: foo
state: latest
update_cache: yes
- name: Remove packages foo and bar
pacman:
name: foo,bar
state: absent
- name: Recursively remove package baz
pacman:
name: baz
state: absent
recurse: yes
add a comment |
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
pacman:
name: foo
state: present
- name: Upgrade package foo
pacman:
name: foo
state: latest
update_cache: yes
- name: Remove packages foo and bar
pacman:
name: foo,bar
state: absent
- name: Recursively remove package baz
pacman:
name: baz
state: absent
recurse: yes
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
pacman:
name: foo
state: present
- name: Upgrade package foo
pacman:
name: foo
state: latest
update_cache: yes
- name: Remove packages foo and bar
pacman:
name: foo,bar
state: absent
- name: Recursively remove package baz
pacman:
name: baz
state: absent
recurse: yes
answered Jan 9 at 16:09
DopeGhotiDopeGhoti
44.4k55684
44.4k55684
add a comment |
add a comment |
package is Ansible "Generic OS package manager".
An option would be to include OS specific list_of_packages
- include_vars: " item "
with_first_found:
- 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 "
add a comment |
package is Ansible "Generic OS package manager".
An option would be to include OS specific list_of_packages
- include_vars: " item "
with_first_found:
- 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 "
add a comment |
package is Ansible "Generic OS package manager".
An option would be to include OS specific list_of_packages
- include_vars: " item "
with_first_found:
- 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 "
package is Ansible "Generic OS package manager".
An option would be to include OS specific list_of_packages
- include_vars: " item "
with_first_found:
- 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 "
answered Jan 9 at 17:18
Vladimir BotkaVladimir Botka
24616
24616
add a comment |
add a comment |
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)
add a comment |
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)
add a comment |
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)
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)
answered Jan 18 at 2:00
HVNSweetingHVNSweeting
1314
1314
add a comment |
add a comment |
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f493485%2fis-there-a-distro-agnostic-configuration-management-software%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown