[clug] old-school remote sys configuration/management options
clug at csmart.io
Thu May 7 04:22:48 UTC 2020
On Thu, 7 May 2020, at 13:01, Bob Edwards via linux wrote:
> Back in the day, one would do all their remote system configuration
> management using SSH, bash and package management. Throw in some
> rsyslogd for remote logging and life was quite simple.
It can be again!
> These days, the preference for config management seems to be one of
> the various Ansible, Chef, Puppet, SaltStack etc. and then add in
> tools like munin, nagios, graylog etc (and/or their successors) and
> there is a whole raft of client side software to be installed,
> maintained, monitored and managed (in terms of load on the system),
> plus all the server side as well.
> With the recent SaltStack vulnerabilities , I have been reassessing
> the landscape. (we started using SaltStack some years ago, mainly due
> to it's integration with Git, at the time).
> At the risk of starting a preferred configuration management system war,
> I am now seriously considering just chucking all that and going back to
> bash scripts running over SSH - simple and well understood. Only need
> to have one port open (maybe two), instead of many ports for all the
> various monitoring and config. management etc.
Ansible goes over SSH and you can run scripts if you want to (https://docs.ansible.com/ansible/latest/modules/shell_module.html), although using built-in modules is better as it's then idempotent, more reliable and easy to collaborate on. You can store your playbook in Git and run it from a clone, pipeline or Ansible Tower or whatever.
> Wondering if anyone else has considered this and if anyone can suggest/
> recommend any existing frameworks or similar? I am looking for something
> that can do some/all of:
> - installation/upgrades
Ansible package module (https://docs.ansible.com/ansible/latest/modules/package_module.html), e.g.:
- name: install ntpdate
Install latest version of ntpdate:
- name: install ntpdate
Or use apt module (https://docs.ansible.com/ansible/latest/modules/apt_module.html) if they are all Debian boxes.
> - configuration
You can use templates (https://docs.ansible.com/ansible/latest/modules/template_module.html) with Jinja expressions in them to automatically and dynamically generate the config based on vars or discovered details about a host from the inventory, e.g.:
- name: Template a file to /etc/files.conf
Or you can do line (https://docs.ansible.com/ansible/latest/modules/lineinfile_module.html) or block in files for setting specific things, etc, e.g.:
- name: Ensure the default Apache port is 8080
regexp: '^Listen '
insertafter: '^#Listen '
line: Listen 8080
> - asset details (eg. serial no.s, RAM, CPU etc.)
The Ansible inventory will have most of these details, you can pull out whatever you want. Or you can write a task to run a specific dmidecode or whatever.
> - monitoring (S.M.A.R.T., du, load etc.)
I use Prometheus for most of my monitoring and alerting and graph things with grafana, e.g.
> - vulnerability checks
Most of my things are Red Hat, so they either take care of themselves or use Satellite for vulnerability reporting. I guess you could do whatever you used to do when life was simple?
> - some sort of reporting (I don't need fancy colour graphs - I don't
> have an MBA)
> - backups
I generally don't bother with backups except for files shares and databases. Everything else is in Git.
If a VM dies I just chuck it away, spin up a new one and re-run the Ansible and it's back online before you can sneeze.
> I already have scripts left over from years ago that can do much of
> this, but would be interested in using a framework if such exists
> (my Googling just turns up how to configure SSH etc.). Mainly targeting
> Debian and Ubuntu, with some CentOS and occasionally others thrown in.
Re-writing any tasks you need to do as Ansible tasks gets my vote, and throw your scripts away.
I converted Korora into a set of Ansible scripts for Fedora, if it helps:
More information about the linux