This article assumes that the reader has a basic understanding of how Salt works and regular Salt usage experience with master and minions. The goal of this post is to show how to use Salt-ssh in a non-root environment without a master or minion.
Why Would You Use Salt-ssh to Execute States and Modules?
- If you already have invested time and effort in a SaltStack installation and you have some machines that aren’t being maintained under an existing SaltStack installation, and installing the minion isn’t feasible.
- If you have a small project that you want to execute and require the project to be distinct and separate from your existing SaltStack installation, but installing a Salt master isn’t desired.
- If you are using Salt in a masterless mode for a Vagrant development environment and you are ready to push out your changes to a live environment, but you don’t have a Salt master running.
- If you want to use a bootstrapping tool to install a number of machines as Salt minions.
How Do You Set-up salt-ssh to Run as a Non-root User?
Much of this post is based on this existing documentation, however it does not provide a novice user with a complete working example and work flow on how to get things up and running. So, let’s get started.
Install the latest stable version of Salt-ssh with your Linux distribution’s package manager. In our example we will use Ubuntu 14.10 as the ‘master’ from which where all the Salt-ssh commands will be launched and Debian wheezy as a test machine to target. Install Salt-ssh by doing the following:
sudo add-apt-repository ppa:saltstack/salt sudo apt-get install salt-ssh
For other distributions see http://docs.saltstack.com/en/latest/topics/installation/index.html#platform-specific-installation-instructions. It is also possible to install Salt-ssh into a virtualenv via pip:
mkdir saltenv virtualenv saltenv source saltenv/bin/activate pip install salt-ssh
Once installed, the default place that Salt-ssh will look for its configuration files, states and keys will be in the root of your file system in the usual places: /etc, /var, /srv and so on. This means that you will need to run Salt-ssh via the root account as Salt-ssh will want to store its logs and data in a root-only writable location.
To have Salt-ssh run purely as a non-root user requires that Salt-ssh be configured to look for its configuration in a location that you have read/write access to.
To start things off, create a directory for storing the configuration.
mkdir make-it-salty cd make-it-salty
Now create a ‘Saltfile’ which which will tell Salt-ssh where to look for configuration files, where to store its working and, where to store temporary files. The Saltfile should contain this:
salt-ssh: config_dir: etc/salt max_procs: 30 wipe_ssh: True
Create a roster with a machine that you can log in as root. For this example I have a Debian Wheezy based virtual machine which I can login to and execute things as root.
node0: host: 192.168.192.10 user: root passwd: password
If you wish to use sudo to execute commands as root you need to configure sudo accordingly with NOPASSWD. This roster file can obviously have more than one machine.
You will also need to create a minimalistic Salt master configuration file in etc/salt/master with this:
root_dir: . file_roots: base: - srv/salt pillar_roots: base: - srv/pillar
To test if this worked or not, execute the following command in the root of the make-it-salty directory, salt-ssh must be executed here as all the paths for the master configuration are now relative.
$ salt-ssh node0 test.ping node0: True
Another test to try out is:
$ salt-ssh node0 cmd.run uptime node0: 13:25:32 up 50 min, 3 users, load average: 0.07, 0.03, 0.05
A prototype repository with a basic template for starting off a project can be found here https://github.com/jcftang/make-it-salty. In this example, there is a small formula to install the Logentries daemon. The repository has the following structure:
./etc/salt/master ./etc/salt/roster ./Saltfile ./srv/formulas/logentries-agent-formula/LICENSE ./srv/formulas/logentries-agent-formula/logentries_agent/defaults.yaml ./srv/formulas/logentries-agent-formula/logentries_agent/files/config ./srv/formulas/logentries-agent-formula/logentries_agent/init.sls ./srv/formulas/logentries-agent-formula/logentries_agent/map.jinja ./srv/formulas/logentries-agent-formula/pillar.example ./srv/formulas/logentries-agent-formula/README.rst ./srv/pillar/common.sls ./srv/pillar/logentries_agent.sls ./srv/pillar/top.sls ./srv/salt/common.sls ./srv/salt/top.sls
It has a near identical layout to a typical system install of a Salt master except the data, configurations and working files are all rooted in the make-it-salty directory.
The above scenario works well if the pillar data does not need to be merged, see this current issue at https://github.com/saltstack/salt/issues/22131.
In the above scenario it is possible to execute the states and modules that SaltStack provides.
Outcome of Using Salt-ssh to Execute Modules and States
If you are already invested in SaltStack you will most likely be able to re-use and share states and modules that are written by your co-workers. It also provides a somewhat light-weight means of testing new Salt states and formulas that you might be writing. It also means you can write a small set of states for bootstrapping new minions in the modes that you require.
Alternative Tools That Provide Similar Functionality…
- knife-solo (a plugin for Chef’s knife) can execute cookbooks against nodes via ssh; the configuration of the nodes is a bit clunky.
- Ansible is an alternative to the SaltStack tool set and it does an equally, if not better job, at using ssh as a transport to run playbooks against nodes and groups of nodes.
- Fabric is a python library and tool to execute commands over ssh against node; this tool requires more experience and effort with writing scripts.