[clug] old-school remote sys configuration/management options

[Chris Smart]

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 [1], 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
  package:
    name: ntpdate
    state: present

Install latest version of ntpdate:

- name: install ntpdate
  package:
    name: ntpdate
    state: latest

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
  template:
    src: /mytemplates/foo.j2
    dest: /etc/file.conf
    owner: bin
    group: wheel
    mode: '0644'

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
  lineinfile:
    path: /etc/httpd/conf/httpd.conf
    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.
:
https://blog.christophersmart.com/2019/09/08/setting-up-a-monitoring-host-with-prometheus-influxdb-and-grafana/

> - 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)

Maybe Grafana.

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

https://github.com/csmart/korora-ansible

-c