When running a high-state on the salt-master to deploy itself, the run fails
with an Authentication error occurred because the master restarts half way though.
Instead of the default service.running + enabled, you can control
the actual state, via pillar.
And you can even say 'state = ignore' and no state will be generated
to control the service
```bash
Examining salt/minion.sls of type state
[210] Numbers that start with `0` should always be encapsulated in quotation marks
salt/minion.sls:20
- mode: 0644
```
* Add MacOS support; fix Issue #352
* On MacOS, only attempt download if condition
Add if salt_settings.install_packages to requisites for an attempt to download the minion package on MacOS
* Update example pillar for MacOS support
Describe how to use MacOS specific options
* Add MacOS notes
* Update README.rst
* Update README.rst
Salt writes it's schedule file to /etc/salt/{minion,master}.d/_schedule.conf
We don't want to stomp all over Salt's files, but we do want a pristine
starting point to lay down our managed config. So we use clean: True on the
file.recurse call, but we tell it to ignore files that start with an _
We have to rename the current config file (_defaults.conf) because it will be
ignored by the rule that ignores Salt's _* config files.
This also means we need to clean up old config files (_defaults.conf) and
restart the service if we cleaned it up.
If you are installing Salt via git/pip, the formula will try to overwrite your
install with packaged versions. This setting makes it possible to avoid that.
New versions of Salt put config files in /etc/salt/{minion,master}.d. We don't
want to erase them by using a clean: True on the file.recurse. This is a
backward incompatible change, but it's necessary to avoid deleting Salt config
files.
Resolves#104