Q:

hostname of minion in salt command

I'm fairly new to salt so it's possible that I just missed something, but I can't figure this out.
I am using salt as a command execution tool (no config management so far). I couldn't find a way to fetch configs from minions with salt and put them into git repository.
What I ultimately try to achieve is to give the salt master a list of configfiles like this
/etc/ssh/ssh_config
/etc/vim/vimrc
etc.

and get salt-master to run fetch these files, put it in folders like 
/srv/salt/minions/configs/minion01/etc/ssh/ssh_config
/srv/salt/minions/configs/minion02/etc/ssh/ssh_config

then I could just let the master push whole thing to our git server and have all configs versioned. 
I know that salt can handle states but everything I find is about pushing the file from the master to the minion in order to keep the state like it should be, But I just want to collect all the updates configs from all servers and version them automatically.
There is a command called
salt \* cp.push /etc/ssh/ssh_config

that pushes the config file to /var/cache/salt/minion/minion01/files/etc/ssh/ssh_config, which seems perfect, but I don't know how to tell salt to do that whenever a file changes (we have quite a few servers and a lot of configs to version...) and to only fetch it if it has changed so I don't have to fetch all files every five minutes or so (via cron).
Anyone has an idea how to do this with salt?
Regards,
Mohrphium

A:

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

