This page describes various steps for troubleshooting problems that may arise while using Salt Cloud.
Are TCP ports 4505 and 4506 open on the master? This is easy to overlook on new masters. Information on how to open firewall ports on various platforms can be found here.
This section describes a set of instructions that are useful to a large number of situations, and are likely to solve most issues that arise.
One of the most common issues that Salt Cloud users run into is import errors. These are often caused by version compatibility issues with Salt.
Salt 0.16.x works with Salt Cloud 0.8.9 or greater.
Salt 0.17.x requires Salt Cloud 0.8.11.
Releases after 0.17.x (0.18 or greater) should not encounter issues as Salt Cloud has been merged into Salt itself.
Frequently, running Salt Cloud in debug mode will reveal information about a deployment which would otherwise not be obvious:
salt-cloud -p myprofile myinstance -l debug
Keep in mind that a number of messages will appear that look at first like errors, but are in fact intended to give developers factual information to assist in debugging. A number of messages that appear will be for cloud providers that you do not have configured; in these cases, the message usually is intended to confirm that they are not configured.
By default, Salt Cloud uses the Salt Bootstrap script to provision instances:
This script is packaged with Salt Cloud, but may be updated without updating the Salt package:
If the default deploy script was used, there should be a file in the
bootstrap-salt.log. This file contains the full output from
the deployment, including any errors that may have occurred.
Salt Cloud uploads minion-specific files to instances once they are available
via SSH, and then executes a deploy script to put them into the correct place
and install Salt. The
--keep-tmp option will instruct Salt Cloud not to
remove those files when finished with them, so that the user may inspect them
salt-cloud -p myprofile myinstance --keep-tmp
By default, Salt Cloud will create a directory on the target instance called
/tmp/.saltcloud/. This directory should be owned by the user that is to
execute the deploy script, and should have permissions of
Most cloud hosts are configured to use
root as the default initial user
for deployment, and as such, this directory and all files in it should be owned
/tmp/.saltcloud/ directory should the following files:
deploy.shscript. This script should have permissions of
.pubkey named after the minion. The
.pemfile should have permissions of
0600. Ensure that the
.pubfiles have been properly copied to the
minion. This file should have been copied to the
grains. This file, if present, should have been copied to the
Some cloud hosts, most notably EC2, are configured with a different primary user.
Some common examples are
In these cases, the
/tmp/.saltcloud/ directory and all files in it should
be owned by this user.
Some cloud hosts, such as EC2, are configured to not require these users to
provide a password when using the
sudo command. Because it is more secure
sudo users to provide a password, other hosts are configured
If this instance is required to provide a password, it needs to be configured in Salt Cloud. A password for sudo to use may be added to either the provider configuration or the profile configuration:
/tmp/is Mounted as
It is more secure to mount the
/tmp/ directory with a
This is uncommon on most cloud hosts, but very common in private
environments. To see if the
/tmp/ directory is mounted this way, run the
mount | grep tmp
The if the output of this command includes a line that looks like this, then
/tmp/ directory is mounted as
tmpfs on /tmp type tmpfs (rw,noexec)
If this is the case, then the
deploy_command will need to be changed
in order to run the deploy script through the
sh command, rather than trying
to execute it directly. This may be specified in either the provider or the
deploy_command: sh /tmp/.saltcloud/deploy.sh
Please note that by default, Salt Cloud will place its files in a directory
/tmp/.saltcloud/. This may be also be changed in the provider or
If this directory is changed, then the
deploy_command need to be changed
in order to reflect the
If all of the files needed for deployment were successfully uploaded to the correct locations, and contain the correct permissions and ownerships, the deploy script may be executed manually in order to check for other issues:
cd /tmp/.saltcloud/ ./deploy.sh