Salt Rosters¶

Salt rosters are pluggable systems added in Salt 0.17.0 to facilitate the salt-ssh system. The roster system was created because salt-ssh needs a means to identify which systems need to be targeted for execution.

How Rosters Work¶

The roster system compiles a data structure internally referred to as targets. The targets is a list of target systems and attributes about how to connect to said systems. The only requirement for a roster module in Salt is to return the targets data structure.

Targets Data¶

The information which can be stored in a roster target is the following:

<Salt ID>:       # The id to reference the target system with
    host:        # The IP address or DNS name of the remote host
    user:        # The user to log in as
    passwd:      # The password to log in with

    # Optional parameters
    port:        # The target system's ssh port number
    sudo:        # Boolean to run command via sudo
    sudo_user:   # Str: Set this to execute Salt as a sudo user other than root.
                 # This user must be in the same system group as the remote user
                 # that is used to login and is specified above. Alternatively,
                 # the user must be a super-user.
    tty:         # Boolean: Set this option to True if sudo is also set to
                 # True and requiretty is also set on the target system
    priv:        # File path to ssh private key, defaults to salt-ssh.rsa
                 # The priv can also be set to agent-forwarding to not specify
                 # a key, but use ssh agent forwarding
    priv_passwd: # Passphrase for ssh private key
    timeout:     # Number of seconds to wait for response when establishing
                 # an SSH connection
    minion_opts: # Dictionary of minion opts
    thin_dir:    # The target system's storage directory for Salt
                 # components. Defaults to /tmp/salt-<hash>.
    cmd_umask:   # umask to enforce for the salt-call command. Should be in
                 # octal (so for 0o077 in YAML you would do 0077, or 63)
    ssh_pre_flight: # Path to a script that will run before all other salt-ssh
                    # commands. Will only run the first time when the thin dir
                    # does not exist, unless --pre-flight is passed to salt-ssh
                    # command or ssh_run_pre_flight is set to true in the config
                    # Added in 3001 Release.
    set_path:    # Set the path environment variable, to ensure the expected python
                 # binary is in the salt-ssh path, when running the command.
                 # Example: '$PATH:/usr/local/bin/'. Added in 3001 Release.

ssh_pre_flight¶

A Salt-SSH roster option ssh_pre_flight was added in the 3001 release. This enables you to run a script before Salt-SSH tries to run any commands. You can set this option in the roster for a specific minion or use the roster_defaults to set it for all minions. This script will only run if the thin dir is not currently on the minion. This means it will only run on the first run of salt-ssh or if you have recently wiped out your thin dir. If you want to intentionally run the script again you have a couple of options:

Wipe out your thin dir by using the -w salt-ssh arg.
Set ssh_run_pre_flight to True in the config
Run salt-ssh with the --pre-flight arg.

Target Defaults¶

The roster_defaults dictionary in the master config is used to set the default login variables for minions in the roster so that the same arguments do not need to be passed with commandline arguments.

roster_defaults:
  user: daniel
  sudo: True
  priv: /root/.ssh/id_rsa
  tty: True

thin_dir¶

Salt needs to upload a standalone environment to the target system, and this defaults to /tmp/salt-<hash>. This directory will be cleaned up per normal systems operation.

If you need a persistent Salt environment, for instance to set persistent grains, this value will need to be changed.