Falsewould be helpful.
Xisn't available, even though the shell command it uses is installed. Why?
No. Salt is 100% committed to being open-source, including all of our APIs and the 'Halite' web interface which was introduced in version 0.17.0. It is developed under the Apache 2.0 license, allowing it to be used in both open and proprietary projects.
Minions need to be able to connect to the Master on TCP ports 4505 and 4506. Minions do not need any inbound ports open. More detailed information on firewall settings can be found here.
This is often caused by SELinux. Try disabling SELinux or putting it in permissive mode and see if the weird behavior goes away.
cmd.run state will run the corresponding command
every time (unless it is prevented from running by the
More details can be found in the documentation for the
Falsewould be helpful.¶
When you run test.ping the Master tells Minions to run commands/functions, and listens for the return data, printing it to the screen when it is received. If it doesn't receive anything back, it doesn't have anything to display for that Minion.
There are a couple options for getting information on Minions that are not
responding. One is to use the verbose (
-v) option when you run salt
commands, as it will display "Minion did not return" for any Minions which time
salt -v '*' pkg.install zsh
Another option is to use the
Also, if the Master is under heavy load, it is possible that the CLI will exit
without displaying return data for all targeted Minions. However, this doesn't
mean that the Minions did not return; this only means that the Salt CLI timed
out waiting for a response. Minions will still send their return data back to
the Master once the job completes. If any expected Minions are missing from the
CLI output, the
jobs.list_jobs runner can
be used to show the job IDs of the jobs that have been run, and the
jobs.lookup_jid runner can be used to get
the return data for that job.
salt-run jobs.list_jobs salt-run jobs.lookup_jid 20130916125524463507
If you find that you are often missing Minion return data on the CLI, only to
find it with the jobs runners, then this may be a sign that the
worker_threads value may need to be increased in the master
config file. Additionally, running your Salt CLI commands with the
option will make Salt wait longer for the return data before the CLI command
exits. For instance, the below command will wait up to 60 seconds for the
Minions to return:
salt -t 60 '*' test.ping
If the Minion id is not configured explicitly (using the
parameter), Salt will determine the id based on the hostname. Exactly how this
is determined varies a little between operating systems and is described in
Salt detects the Minion's operating system and assigns the correct package or service management module based on what is detected. However, for certain custom spins and OS derivatives this detection fails. In cases like this, an issue should be opened on our tracker, with the following information:
The output of the following command:
salt <minion_id> grains.items | grep os
The contents of
/etc/lsb-release, if present on the Minion.
In versions of Salt 0.16.3 or older, there is a bug in gitfs which can affect the syncing of custom types. Upgrading to 0.16.4 or newer will fix this.
Custom modules are only synced to Minions when
saltutil.sync_all is run. Similarly, custom states are only
synced to Minions when
saltutil.sync_all is run.
Other custom types (renderers, outputters, etc.) have similar behavior, see the
documentation for the
saltutil module for more
This is most likely a PATH issue. Did you custom-compile the software which the
module requires? RHEL/CentOS/etc. in particular override the root user's path
/etc/init.d/functions, setting it to
making software installed into
/usr/local/bin unavailable to Salt when the
Minion is started using the initscript. In version 2014.1.0, Salt will have a
better solution for these sort of PATH-related issues, but recompiling the
software to install it into a location within the PATH should resolve the
issue in the meantime. Alternatively, you can create a symbolic link within the
PATH using a
/usr/bin/foo: file.symlink: - target: /usr/local/bin/foo
This depends on the versions. In general, it is recommended that Master and Minion versions match.
When upgrading Salt, the master(s) should always be upgraded first. Backwards compatibility for minions running newer versions of salt than their masters is not guaranteed.
Whenever possible, backwards compatibility between new masters and old minions will be preserved. Generally, the only exception to this policy is in case of a security vulnerability.
Recent examples of backwards compatibility breakage include the 0.17.1 release (where all backwards compatibility was broken due to a security fix), and the 2014.1.0 release (which retained compatibility between 2014.1.0 masters and 0.17 minions, but broke compatibility for 2014.1.0 minions and older masters).
Yes. Salt provides an easy to use addition to your file.managed states that allow you to back up files via backup_mode, backup_mode can be configured on a per state basis, or in the minion config (note that if set in the minion config this would simply be the default method to use, you still need to specify that the file should be backed up!).
Updating the salt-minion package requires a restart of the salt-minion service. But restarting the service while in the middle of a state run interrupts the process of the minion running states and sending results back to the master. It's a tricky problem to solve, and we're working on it, but in the meantime one way of handling this (on Linux and UNIX-based operating systems) is to use at (a job scheduler which predates cron) to schedule a restart of the service. at is not installed by default on most distros, and requires a service to be running (usually called atd) in order to schedule jobs. Here's an example of how to upgrade the salt-minion package at the end of a Salt run, and schedule a service restart for one minute after the package update completes.
salt-minion: pkg.installed: - name: salt-minion - version: 2014.1.7-3.el6 - order: last service.running: - name: salt-minion - require: - pkg: salt-minion cmd.wait: - name: echo service salt-minion restart | at now + 1 minute - watch: - pkg: salt-minion
To ensure that at is installed and atd is running, the following states can be used (be sure to double-check the package name and service name for the distro the minion is running, in case they differ from the example below.
at: pkg.installed: - name: at service.running: - name: atd - enable: True
An alternatvie to using the atd daemon is to fork and disown the process.
restart_minion: cmd.run: - name: | nohup /bin/sh -c 'sleep 10 && salt-call --local service.restart salt-minion' - python_shell: True - order: last
For Windows machines, restarting the minion at can be accomplished by adding the following state:
schedule-start: cmd.run: - name: 'start powershell "Restart-Service -Name salt-minion"' - order: last
or running immediately from the command line:
salt -G kernel:Windows cmd.run 'start powershell "Restart-Service -Name salt-minion"'
In order to configure a master server via states, the Salt master can also be "salted" in order to enforce state on the Salt master as well as the Salt minions. Salting the Salt master requires a Salt minion to be installed on the same machine as the Salt master. Once the Salt minion is installed, the minion configuration file must be pointed to the local Salt master:
Once the Salt master has been "salted" with a Salt minion, it can be targeted
just like any other minion. If the minion on the salted master is running, the
minion can be targeted via any usual
salt command. Additionally, the
salt-call command can execute operations to enforce state on the salted
master without requiring the minion to be running.
More information about salting the Salt master can be found in the salt-formula for salt itself:
Because grains can be set by users that have access to the minion configuration files on the local system, grains are considered less secure than other identifiers in Salt. Use caution when targeting sensitive operations or setting pillar values based on grain data.
When possible, you should target sensitive operations and data using the Minion ID. If the Minion ID of a system changes, the Salt Minion's public key must be re-accepted by an administrator on the Salt Master, making it less vulnerable to impersonation attacks.