Over the years I’ve been using Salt CLI extensively for day-to-day system administration tasks and, in my opinion, there’s nothing quite like it. Faster, more capable, and easier to learn than the rest of the CAPS.

I’m getting old, that’s the thing! What’s in me now won’t be there anymore.Leo Tolstoy, 'War and Peace'

My interest in SaltStack generally is confined to its remote execution capabilities. As a sysadmin with HPC cluster background, I know the challenges of managing a large number of dissimilar servers. Using old tools like pdsh is an option, but even the simplest of tasks – such as running a basic command on all servers – immediately presents the first challenge: getting the list of servers up to date.

Salt’s advanced targeting, remote command, and script execution capabilities are very attractive, even if you have no interest in using Salt for server deployment and centralized configuration management. Much of what you will find on this site will be limited to remote execution and monitoring tasks, and I will not get much into the Puppet-vs-Salt-vs-Ansible-vs-Chef debate.

If you support a lot of servers, the trivial effort it takes to set up a Salt master server and to deploy the agents is well justified. Similar to Ansible, Salt can work without the agents, via SSH, but why deny yourself the convenience of near-instantaneous response from thousands of managed systems? And Salt agents work on Windows as well, if you’re into that sort of thing.

Unlike agentless server provisioning tools, with Salt, you don’t need to maintain lists and complex group hierarchies of managed nodes. You can target the systems you need on the fly using a myriad of different options you get with Salt. None of that Ansible slowness while “gathering facts”. Of course, maybe if you get paid by the hour…

In an attempt to be concise, I will go straight to troubleshooting the four most common problems I’ve encountered running Salt in a large environment (and none of these problems are really with Salt itself).

  1. Salt agents maintain a runtime cache in /var/cache/salt. The /var filesystem tends to run out of space because that’s where /var/log is. When this happens, the salt-minion stops working. I wish it had an option of designating a secondary cache location.For now, the solution is to use salt-ssh to access the problem nodes and clean up /var. I mean, you would have to do this anyway. And, by the way, pretty much all of the salt .* cmd.run ... commands you will see below also work as salt-ssh .* cmd.run ..., as long as you have your passwordless SSH configured the same way you would with, say, Ansible.
  2. From time to time virtualization clusters lose access to storage. Why? It’s complicated and right now not really important. What is important, however, is when this happens, local filesystems tend to become read-only. This may include /var. I am sure that now you can guess how this affects the Salt agent.
  3. Some people have a bad habit of cloning VMs instead of using whatever VM deployment process that they should’ve been using. When they clone VMs they invariably forget to update /etc/salt/minion_id file that usually contains the node’s FQDN. This, understandably, causes some confusion.Once again, you can use salt-ssh to automate a quick process that will periodically scan your environment to identify and fix this issue: just delete the minion_id file and bounce the salt-minion service. And then you can deal with the real culprits personally.
  4. Finally, and I should’ve mentioned this first, make sure your firewall rules are in place to work with Salt. I can’t tell you how many times this happened: new VLAN is created, standard firewall rules not implemented. The minions talk to the master via an encrypted ZMQ connection on ports 4505 and 4506, so these need to be opened from minions to the master (or to the Salt proxies if you use those). Additionally, port 22 should be opened from the master to the minions if you plan on using salt-ssh (and you should have that option).

I have to admit that, when it comes to scripting, I have a soft spot for the convoluted. Here’s a characteristic example:

Imagine you have four environments – Dev, QA, UAT, and Prod – and you need to compare the CPU utilization of all Tomcat servers by the environment. Let’s also imagine that your host-naming convention looks something like this: devl-tomcat-01 or qal-tomcat-01, where “l” after the environment abbreviation stands for “Linux”. This is just to help you understand the mess below.

The simple truth of what I do with Salt becomes evident. From everything above, this is the only Salt command:

That’s it. The rest is just shell scripting. Having said that, accomplishing the same task with pdsh would have been quite a bit more complicated.

So why don’t I use Salt to the fullest of its abilities? To make a short story long, back in the earlier days of HPC clusters I’ve been using Scali, which became Platform Manager in 2007, and after five more years was acquired by IBM. Scali was an interested but unstable and poorly-documented tool. It had excellent core functionality, but this advantage has been entirely undermined by many buggy features of dubious value.

I am certain I’ve spent more time fixing issues with Scali itself than it would have taken me to deploy and manage my HPC clusters using Clonezilla and pdsh. And I would have done exactly that, has it not been for my management’s determination to continue using Scali/PM/whatever, since they already spend the money on licensing.

I can deploy servers faster with scripts and FTP than most DevOps folks can with Puppet and Ansible. I can provide much more responsive and flexible configuration management using pdsh and flat files than most automation guys can with SaltStack or Chef. So, if I can do all this right now knowing what I already know, why bother with anything else, unless there’s some clear advantage?

There are many DevOps engineers out there who have never heard of Scali or even pdsh. They truly believe they’re onto something new here with their Ansible, Jenkins, OpenShift, and endless layers of virtualization.  As a Russian saying goes, everything new is just well-forgotten old. Having said that, I do recognize a superior tool when I see one and so here we go.

Table of Contents

Basic Operations

Run a command on QA nodes

Identify QA nodes with local filesystem utilization above 95%

Identify QA nodes that haven’t been rebooted in the past week

Identify QA nodes with security advisories (RHEL)

Get RHEL version of QA nodes

Running commands as another user on QA Tomcat servers

Get a list of physical servers and their hardware models, sorted by generation (HPE)

Get a list of unique subnets used by Salt minions

Advanced Operations

Check for Puppet errors on QA nodes

Get the total number of CPU cores across all 32-bit nodes

Compound matching, count VMs:

Get the total LVM size across all DEV WebLogic nodes

Show total memory allocated to all DEV Tomcat nodes

See which DEV nodes are favored by a particular user

Find RHEL 6 nodes with the highest swap utilization

Salt understands POSIX regex expressions

Salt can read a list of nodes from a file

Similar to above, but the hostnames are not FQDN

Salt can read a list of nodes from CLI

Salt can use Boolean operators

Targeting minions using “salt grains”

Target minions by subnet

Target minions by subnet and Salt grains

Identify PROD servers with 15-min load average in double-digits:

Get a list of NFS mounts on QA nodes

Install Wireshark on minions that don’t already have it

Find “/opt” filesystem on “prod-db*” servers with the utilization of 80-100%

Get allocated LVM size of minions in the “/root/list” containing short hostnames

Get total memory size of minions in the “/root/list” containing short hostnames

Get the total number of CPU cores of minions in the “/root/list” containing short hostnames

Get a list of mounted NFS shares for minions in the “/root/list” containing short hostnames

Display HP ILO IP address on all physical hosts using ipmitool

Show top ten UAT nodes by CPU utilization for the “java” process running under “weblogic” username

Similar to the previous example, but sorted by memory utilization

Copying Files and Folders

Copy a single file from the Salt master to minions

The source location must be inside Salt server home (i.e. /srv/salt/). Also, the target folder must already exist on the minions (in this example, /var/tmp). Also, keep in mind that for security reasons, any file copied from the Salt master to a minion will have its permissions changed to 644. You will need to run another Salt command to set the desired permissions on the file.

Copy a directory with contents from master to minions

This example will copy the contents of /srv/salt/myfiles/ to the minion:/tmp/myfiles

Copy contents of a directory from minions to the master

The data you copy will end up on the Salt master in /var/cache/salt/master/minions/<minion_id>/files/folder/on/minions(for the example below), so be mindful of the available disk space.

Running Scripts via Salt

The scripts are usually located on the Salt master server in /srv/salt(on RHEL). They don’t need to be executable.

Basic Syntax

Run yum_health_check.shscript on all of the QA servers:

Cleaning up output

Text output of cmd.scriptis very busy and not very readable. I found it useful to create the following /usr/bin/cleanhelper script that will sanitize the output of cmd.script:

And here’s how to use it with a script:

Passing arguments to a script

In this example script app_find.shwill try to locate an application called “webstore01” on various WebLogic servers:

Salt-Cloud Operations

This is a brief listing of the more common salt-cloudcommands with some VMWare-specific examples. You can see all available salt-cloudcommands here.

Working with VMWare

The primary configuration file that allows salt-cloudto interact with VMWare is usually located in /etc/salt/cloud.providers.d/vmware.confand looks something like this:

There is one important detail to keep in mind: with VMWare salt-cloudhas two modes of operation – vmwareand vsphere. The two are similar for the most part. However, in the vspheremode you need to specify the name of the vCenter. In the vmwaremode, the desired operation will be performed on all configured vCenters.

Let’s say you want to create a snapshot of a VM called prod-tomcat-test-01. The following command will do this for you:

Notice how I did not specify the name of the vCenter. Salt already knows which vCenter has this VM. However, if more than one vCenter has a VM with that name, snapshots will be created for all VMs matching the name.

List configured cloud providers

List clusters in a vCenter

List VM build profiles

List VMs in a vCenter

List all VM snapshots in a vCenter

Use jqto parse output

Similar to the previous example, but we extract only the names of VMs that have snapshots.

List snapshots for a particular VM

Create a snapshot

 Note:  by default, salt-cloudwill prompt you for confirmation before modifying a VMs configuration state, a snapshot, an ESX host, a cluster, or a vCenter. You can use – carefully – the --assume-yesor -yoption to assume an affirmative response and proceed with the operation.

Revert to a snapshot

Merge all snapshots for a VM