Reloading Salt grains

The official answer:

salt-run manage.up

Also useful are:

salt-run manage.status

salt-run manage.down

You're thinking about this the wrong way, Salt is not designed to provide you with a history of the changes you've made on a machine but instead to dictate a "high" state the machine should be in. etckeeper follows changes made locally, logging changes made locally into git, while salt makes your boxes follow any changes in the git repo. If the minion has any local changes it'll show you when you do a highstate. Can you guess which one scales?

So here's a simple example of how to do this (this happens to use bitbucket for git):

1) Setup your salt master /etc/salt/master with:

file_roots:
  base:
    - /srv/salt

fileserver_backend:
  - git
  - roots

gitfs_remotes:
  - git@bitbucket.org:user/your-salt-repo.git

pillar_roots:
  base:
    - /srv/pillar

2) In the root of your git repo create a simple top.sls:

base:
  '*.domain.com':
    - core

3) Create some additional directories inside your git repo:

mkdir core
mkdir servers
mkdir servers/default
mkdir servers/minion01

4) Create a simple core/init.sls file:

/etc/ssh/ssh_config:
  file.managed:
    - source:
      - salt://servers/{{ grains['id'] }}/ssh_config
      - salt://servers/default/ssh_config

5) Create a default ssh_config under servers/default/ssh_config.

6) Create a minion-specific ssh_config under servers/minion01/ssh_config

7) Commit and push changes back up to your git repository (bitbucket).

8) From the salt master run: sudo salt '*' state.highstate test=true to see what changes will be applied.

When minion01 contacts the salt master it'll get servers/minion01/ssh_config, but any other minion (say minion02) where there's no ssh_config file under /servers/minion.id.whatever/ and moves down the list to the next source (servers/default). Instead of doing this by minion_id you can also do this based on other grains like os, fqdn, domain, etc (see a list of grains on a minion with salt 'minion-id' grains.items).

Once you've captured the initial state of these files you can make changes in a central place (the git repo) and then run state.highstate to roll further changes out. This initial pain is worth the effort. You could automate some of it, but what you're really looking to do is to find outliers which will by definition require some manual intervention to identify. I recommend you start with something like ssd_config and run state.highstate test=true one minion at a time. If there are changes from the default it will show you the diff and you can judge whether that warrants an exception to the default.

Note: You'll need to setup ssh keys for the root user on the salt master to have permission to read your git repository (bitbucket calls these deployment keys).