Getting Started with Salt Stack-the Other Configuration Management System Built with Python
If you haven't used any type of configuration management system before, here is a simple example. Say you have a set of configurations and packages that you generally install for every Web server. You can keep these configuration directives in small text files and then instruct your servers to install these packages and configure them to your liking, every time you create a new server. You also can use configuration management to keep all of your servers updated once they have been created and respond to changes in packaging or new configurations.
Let's install the libpam-cracklib package, so you can add additional requirements for user passwords. I chose this package because it is useful for almost any server connected to the Internet. It allows you to set additional password requirements regarding length, and it requires that your users' passwords contain special characters or numerals. You easily could substitute any particular package you want. These examples do require that the package be available in your system's package manager though.
Storage of the Configuration Directives
Salt's configuration management directives and files are, by default, kept within the /srv/salt directory. This is where all your configuration files and any files you want to copy to any of your minions reside. Salt also includes a file server system as part of the configuration management features. Salt doesn't touch your master's system files though, so don't worry; all configuration management takes place within the /srv/salt directory.
Salt, by default, uses PyYAML (http://pyyaml.org) syntax for its template files, but numerous other templating languages are available as well. Be sure to follow the proper formatting techniques for YAML, which involves two spaces instead of tabs. I have found the on-line YAML parser (http://yaml-online-parser.appspot.com) to be invaluable when troubleshooting syntax issues with YAML files.
Enable Configuration Management
To enable the configuration management functionality within Salt, you need to
edit your master configuration file once again.
In /etc/salt, open your master file and locate the lines that refer to
file_roots. In the default configuration, this was around line 156. Now,
uncomment this directive by removing the
# from the following lines:
file_roots: base: - /srv/salt
This tells Salt where to locate your configuration management files. Depending on how you installed Salt, you may need to create the /srv/salt directory.
Create a Top File or "Roadmap"
The base configuration file is known as a Top File, and it resides within the /srv/salt directory. Let's create one now. This file provides mappings for other files and can be used to set a base configuration for all servers. Again, with your favorite text editor, create a top.sls file within the /srv/salt directory. You can think of this file as a roadmap for different directions for each minion. Within your top.sls file, add the following lines:
base: '*' - servers
base directive lets Salt know that this configuration is a base configuration
and can be applied to all machines. The wild-card
targets every machine. The
servers directive is an arbitrary name that allows you to recognize what the
directive pertains to. Feel free to choose something that makes sense to you.
This entry also refers to a particular configuration file that you will now create
to install the libpam-cracklib.
Create a Server-Specific Configuration File
After you save your top.sls file, create a new file called servers.sls within the /srv/salt directory. This file will hold your specific configuration, including the name of the package to be installed and also a reference to a configuration file. In the new servers.sls file, add the following:
libpam-cracklib: pkg: - installed
The first line is the name of the package specifically how your package manager refers to it. For example, the Apache HTTP server is called apache2 in aptitude-based package manager distributions, but httpd in yum-based package management systems. Make sure you use the proper name for the package depending on which package manager you are using. You can target specific package names using what Salt refers to as grains. Refer to the documentation for more information and advanced examples of using grains in SLS files to target distribution-specific systems (http://salt.readthedocs.org/en/latest/topics/tutorials/states_pt3.html#using-grains-in-sls-modules).
Lines 2 and 3 tell Salt what to do with this package. For this example, you want it
installed. To remove a package, you simply would change
Remember, spacing is very important! On line two, there are two spaces before
pkg:, and on the third line, there are four spaces before
- installed. If you
receive any errors, check your syntax via an on-line YAML parser.
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.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- SUSE LLC's SUSE Manager
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Managing Linux Using Puppet
- My +1 Sword of Productivity
- Non-Linux FOSS: Caffeine!
- Doing for User Space What We Did for Kernel Space
- Google's SwiftShader Released
- SuperTuxKart 0.9.2 Released
- Parsing an RSS News Feed with a Bash Script
- Rogue Wave Software's Zend Server
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide