This commit fixes how `pillar_roots` are generated and after this fix the
generated configuration does not contain any unnecessary new lines:
```yaml
pillar_roots:
base:
/srv/salt/dir1
dev:
/srv/salt/dir2
/srv/salt/dir3
locale:
/srv/salt/dir4
```
Before this commit the pillar_roots in `f_defaults.conf` for master would be
generated with a lot of empty lines in between directories, like this:
```yaml
pillar_roots:
base:
/srv/salt/dir1
dev:
/srv/salt/dir2
/srv/salt/dir3
local:
/srv/salt/dir4
```
The minion configuration is not affected and renders fine.
The user will already have it's /etc/salt/minion file, so it doesn't need all this info, and it makes easier to know what has been generated and what not
As mentioned in issue #118, provider files may contain passwords
or API keys and should be restricted. Profiles/maps are probably
OK with the defaults.
These aren't intended to function; they're here to allow the use of
file.recurse on the provider folder, without requiring the user
to provide pillar data for templates they're not using.
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