Getting Started with Salt Stack-the Other Configuration Management System Built with Python

Minion Configuration

For this tutorial, I cover issuing salt-master and salt-minion commands on the
same machine. If you are configuring multiple machines, choose one to be the
master, and all the others will be minions. The choice of master or minion is
yours, and there are many reasons to configure one machine as the master. I
explain how to
set one as a master and the other(s) as minions next.

Salt's configuration files are located in /etc/salt.
By default, these
files are named minion and master. If you've installed the salt-master and
salt-minion on the same machine, you will see two respective files, master and
minion.

You first need to tell your minion how to locate and communicate with your
master. Even though you are running both on the same server, you still need to
tell your minion where your master is.

Using your favorite text editor, open the minion file.

Uncomment the line # master: salt by removing the
# and replacing salt with
the your master's IP address. It now should look like this: master:
your.ip.address.here. (If you're doing this locally on the same machine, you
can add 127.0.0.1.)

Give your minion a nickname. Locate the line #id:, and again remove
the # and add a name id:
1st-Salt-Minion. (This name can be anything
you want.)

Restart your minion using sudo salt-minion -d in order
for it to read the new
configuration settings. The -d flag dæmonizes the process and starts
the minion in the background, so you still can access your
command-line to issue more commands.

Accept Your Minion's Keys

Now that your minion knows where your master is, it's time for them to authenticate
one another.
Salt uses public key
encryption
to secure the
communication between master and minions. You need to notify the master
and minion that they can trust each other by accepting the minion's keys on the
master.

Accept your minion's keys using the salt-key command. Salt automatically
takes care of generating these keys for you, so you simply need to accept the
minion(s) you want.

Type salt-key -L to get a list of all pending, accepted and rejected keys.

You should see an unaccepted key for 1st-Salt-Minion (or whatever ID you
chose for your minion).

Accept this key using sudo salt-key -a 1st-Salt-Minion.

Test Communications

Now that you have a salt-master and a salt-minion, and the minion and master
trust one another, you can check the connection by issuing a test ping command
from the master. This will return "True" if your master can communicate with your
minion.
Type salt '*' test.ping, and it should return:

>{1st-Salt-Minion: True}

Note that the wild-card '*' targets every minion, and as
you have only one,
this is basically moot (it's just faster than typing
salt
'1st-Salt-Minion' test.ping).

If you receive a "True" response back from your minion, you have
installed Salt Stack successfully and configured your master and minion to
communicate properly.

The Salt command syntax involves the command, the target(s) and the action. So,
for this example, '*' targets everything (it's a wild
card), and test.ping is the
action.

You can now execute any available command on any connected and authenticated
minion. Important note: these commands must be available on the targeted minion in
order to execute them.
For instance, a command like:

sudo salt '*' cmd.run "service apache2 restart"

would work only for a distribution that calls the Apache Web server apache2 and
that has the Apache Web server installed. For others, you would need to issue the
command:

sudo salt '*' cmd.run "service httpd restart"

Some other examples might include querying the amount of time your servers have been
running. You can do that with:

sudo salt '*' cmd.run "uptime"

If you had, for example, Apache Bench installed on a master but not on a minion,
the command:

would fail if you tried to execute it on a minion, since Apache Bench isn't
installed on the minion.

The possibilities here are practically limitless. You can reboot all of your
machines at once, update system software and check your machines' health from one
terminal instead of logging in to each machine and issuing these commands
independently.

You also can target specific groups, based upon criteria that you select. See
the -G flag documentation at http://saltstack.org for more options.

Very rarely should you ever need to log in to a minion again. All configuration
and execution can be handled remotely, quickly and simultaneously.

Now that you've installed Salt and can execute remote commands, why stop there?
The second part of Salt's power comes from the configuration management tools
included with Salt.

Ben Hosmer is a DEVOP with RadiantBlue Technologies where he develops and maintains Drupal sites and administers various servers. He is an open-source advocate and helps spread the use of Linux and other open-source software within the US government.

Itѕ liκе уou rеаd my mіnd!
You aрpеar to know ѕo much about this, lіke you ωrоte the boοk
in іt oг somethіng. I thіnκ that you
сould do ωіth a few pics to ԁrіve
the message hοmе a littlе bit, but οthег than that, thiѕ is еxcеllеnt blog.
A greаt reаd. I'll certainly be back.

How would you deploy multiple folders, say your application files. can we use something http://www.hairwigs.de/ like RSYNC ? I know Puppet has such a module. Salt also has a CI module in Github. Would anyone know more ?

Do you mind if I quote a few of your posts as long as I provide credit
and sources back to your webpage? My website is in the exact same niche as yours and my
visitors would certainly benefit from a lot of the information you present
here. Please let me know if this alright with you.
Cheers!

You've mentioned that system package manager should be available with the package that we are trying to install. Is there any way to perform tasks like source compiling as we do while accessing the machine remotely via SSH. And thank you very much for the fantastic Blog.

As Linux continues to play an ever increasing role in corporate data centers and institutions, ensuring the integrity and protection of these systems must be a priority. With 60% of the world's websites and an increasing share of organization's mission-critical workloads running on Linux, failing to stop malware and other advanced threats on Linux can increasingly impact an organization's reputation and bottom line.

Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.

In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.