With a simple pillar like this::

    $ sudo salt-call --config-dir /srv/etc/bootstrap --pillar-root /srv/pillar pillar.get salt:pillar_roots
    local:
        ----------
        base:
            - /srv/pillar

This was generated in /etc/salt/master.d/f_defaults.conf::

    # highstate format, and is generally just key/value pairs.
    pillar_roots:base:- /srv/pillar
    #

Resulting in parse errors by salt::

    $ sudo salt '*' state.highstate
    [ERROR   ] Error parsing configuration file: /etc/salt/master.d/f_defaults.conf - while scanning a simple key
      in "<string>", line 531, column 1:
        pillar_roots:base:- /srv/pillar
        ^
    could not found expected ':'
      in "<string>", line 532, column 1:
        #
        ^
    [ERROR   ] Error parsing configuration file: /etc/salt/master.d/f_defaults.conf - while scanning a simple key
      in "<string>", line 531, column 1:
        pillar_roots:base:- /srv/pillar
        ^
    could not found expected ':'
      in "<string>", line 532, column 1:
        #
        ^

This patch will fix it as such::

          ID: salt-master
    Function: file.recurse
        Name: /etc/salt/master.d
      Result: True
     Comment: Recursively updated /etc/salt/master.d
     Started: 11:37:12.946823
    Duration: 6255.296 ms
     Changes:
              ----------
              /etc/salt/master.d/f_defaults.conf:
                  ----------
                  diff:
                      ---
                      +++
                      @@ -528,7 +528,9 @@
                       # Pillar is laid out in the same fashion as the file server, with environments,
                       # a top file and sls files. However, pillar data does not need to be in the
                       # highstate format, and is generally just key/value pairs.
                      -pillar_roots:base:- /srv/pillar
                      +pillar_roots:
                      +  base:
                      +    - /srv/pillar
                       #

Resulting in::

    # highstate format, and is generally just key/value pairs.
    pillar_roots:
      base:
        - /srv/pillar
    #

This key defaults to a value of `python-git`.

On FreeBSD salt-ssh gets bundled into a single package with the other
SaltStack components (minion, master, etc.).

This reverts commit 7bb82b0178.

This reverts commit 8a1b8dc9db.

This reverts commit 90282eff03.

This reverts commit c5ae289fa1.

This reverts commit b03831c0b0.

This reverts commit 22b8dde1ff.

This reverts commit 14b466e022.

Done at the maintainer's request.

Seems there are several colons missing for salt.api to work correctly, hope I found all of them

This change tweaks the GitPython package installation state to support
alternate package names (on FreeBSD, it's called "py27-GitPython").
Also, on FreeBSD salt-ssh is included in the "py27-salt" package by
default, requiring an update to `distro_map`.

Signed-off-by: René Jochum <rene@jochums.at>

Signed-off-by: René Jochum <rene@jochums.at>

Signed-off-by: René Jochum <rene@jochums.at>

Signed-off-by: René Jochum <rene@jochums.at>

The syndic service was depending upon itself, which caused the salt run
to fail. This commit fixes that by depending on the salt-master service
rather than the salt-syndic service. I also made it more general by
using IDs to specify the provider rather than the name, which is a bit
less reliable.

* Install pygit from package
* Add Official Salt ZeroMQ 4 COPR repository

Note that Salt itself is assumed to already to be available to the system via yum, via EPEL for example

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

Needed because salt-cloud will attempt to load them even if they are
filled with invalid default values, creating error spam.

Added config setting for:

* pillar_source_merging_strategy

The 'require' statement needs a list as input, but doesn't get
any input when install_packages is set to False.

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.

This obsoletes the salt:cloud:folders and salt:cloud:providers pillar
entries. Provider keys have been moved to /etc/salt/pki/cloud.

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.

Please refer to issue https://github.com/saltstack-formulas/salt-formula/issues/113.

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.