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.
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:
salt-cloud -u
If the default deploy script was used, there should be a file in the /tmp/
directory called 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
for problems:
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 0700
.
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
by the root
user.
The /tmp/.saltcloud/
directory should the following files:
A deploy.sh
script. This script should have permissions of 0755
.
A .pem
and .pub
key named after the minion. The .pem
file should
have permissions of 0600
. Ensure that the .pem
and .pub
files have
been properly copied to the /etc/salt/pki/minion/
directory.
A file called minion
. This file should have been copied to the
/etc/salt/
directory.
Optionally, a file called grains
. This file, if present, should have been
copied to the /etc/salt/
directory.
Some cloud hosts, most notably EC2, are configured with a different primary user.
Some common examples are ec2-user
, ubuntu
, fedora
, and bitnami
.
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
to require sudo
users to provide a password, other hosts are configured
that way.
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:
sudo_password: mypassword
/tmp/
is Mounted as noexec
¶It is more secure to mount the /tmp/
directory with a noexec
option.
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
following command:
mount | grep tmp
The if the output of this command includes a line that looks like this, then
the /tmp/
directory is mounted as noexec
:
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
profile config:
deploy_command: sh /tmp/.saltcloud/deploy.sh
Please note that by default, Salt Cloud will place its files in a directory
called /tmp/.saltcloud/
. This may be also be changed in the provider or
profile configuration:
tmp_dir: /tmp/.saltcloud/
If this directory is changed, then the deploy_command
need to be changed
in order to reflect the tmp_dir
configuration.
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