Category: saltstack

SaltStack – Configuration Management ”; Previous Next Configuration management is one of the most significant concept in SaltStack. It is used to create a reusable configuration template, called a state. The state describes everything required to put a system component or an application into a known configuration. Salt State Salt state is a reusable configuration for a specific part of a system. States are easier to understand and described using a simple YAML. Create a Salt State Salt states are easy to create. Let us create a simple state in this chapter. Move to the directory “salt-vagrant-demo/saltstack/salt/” and create a file named samples.sls and add the following lines in it. samples.sls install_network_packages: pkg.installed: – pkgs: – rsync – lftp – curl Now, save the file and run the following command in the Salt master. root@saltmaster:/home/vagrant# salt ”minion1’ state.apply samples Here, we installed rsync, lftp and curl through the pkg.installed module using the Salt state in a salt minion, minion1. If it works properly, you could see the response as shown below. It will produce the following output − minion1: ———- ID: install_network_packages Function: pkg.installed Result: True Comment: All specified packages are already installed Started: 08:08:48.612336 Duration: 545.385 ms Changes: Summary for minion1 ———— Succeeded: 1 Failed: 0 ———— Total states run: 1 Total run time: 545.385 ms Apply Salt State Now that we have created a state using the ‘.sls’ file and applied it by specifically calling it. Salt has a default state file called as the top.sls file. The top file is used to apply multiple state files to Salt minions. The top file describes where states should be applied. Well, States and the Top file work together to create the core of SaltStack’s configuration management capability. Let us now create a simple top.sls file in the directory saltstack/salt and add the following. top.sls base: ”*”: – common ”minion1”: – samples Here, the state, commonly applies to all system state, samples applies to minion1. Next, run the Salt master and apply the state as shown below. root@saltmaster:/home/vagrant# salt ”*” state.apply It will produce the following output − minion1: ———- ID: common_packages Function: pkg.installed Result: True Comment: All specified packages are already installed Started: 09:33:35.642355 Duration: 588.21 ms Changes: Summary for minion1 ———— Succeeded: 1 Failed: 0 ———— Total states run: 1 Total run time: 588.210 ms minion2: ———- ID: common_packages Function: pkg.installed Result: True Comment: All specified packages are already installed Started: 09:33:35.890331 Duration: 602.79 ms Changes: Summary for minion2 ———— Succeeded: 1 Failed: 0 ———— Total states run: 1 Total run time: 602.790 ms Apply Batch Size If you have a large number of connected minions, then you can limit how many systems are updated at once. It is performed by using the –batch-size option, which is defined below. root@saltmaster:/home/vagrant# salt –batch-size 5 ”*” state.apply It will produce the following output − Executing run on [”minion2”, ”minion1”] jid: 20170314094638482664 minion1: ———- ID: common_packages Function: pkg.installed Result: True Comment: All specified packages are already installed Started: 09:46:41.228519 Duration: 582.24 ms Changes: Summary for minion1 ———— Succeeded: 1 Failed: 0 ———— Total states run: 1 Total run time: 582.240 ms retcode: 0 jid: 20170314094638482664 minion2: ———- ID: common_packages Function: pkg.installed Result: True Comment: All specified packages are already installed Started: 09:46:41.153609 Duration: 605.235 ms Changes: Summary for minion2 ———— Succeeded: 1 Failed: 0 ———— Total states run: 1 Total run time: 605.235 ms retcode: 0 Salt State Functions Salt state functions are used to install and configure applications on your remote system. Let us install a “Vim” package using the Salt state function. Create and Apply State Function Create a file named “sample.sls” under the directory “salt-vagrant-demo/saltstack/salt/sample.sls” and add the following − sample.sls install vim: pkg.installed: – name: vim Once, Vagrant environment is up, run the salt master and apply the sample.sls by running the following command. root@saltmaster:/home/vagrant# sudo salt ”minion2’ state.apply sample It will produce the following output − minion2: ———- ID: install vim Function: pkg.installed Name: vim Result: True Comment: Package vim is installed Started: 15:07:45.752764 Duration: 553.506 ms Changes: Summary for minion2 ———— Succeeded: 1 Failed: 0 ———— Total states run: 1 Total run time: 553.506 ms Now, we have added a package “Vim”. Let us now test the package using the Salt testing method. Salt State Testing The test run is mandated by adding the “test = True” option to the states. The return information will show states that will be applied in yellow and the result is reported as ‘None’. The following command is used to test the state − root@saltmaster:/home/vagrant# sudo salt ”minion2’ state.apply sample test = True It will produce the following output − minion2: ———- ID: install vim Function: pkg.installed Name: vim Result: True Comment: Package vim is already installed Started: 15:07:45.752764 Duration: 553.506 ms Changes: Summary for minion2 ———— Succeeded: 1 Failed: 0 ———— Total states run: 1 Total run time: 553.506 ms SaltStack ─ Pillar Component Pillar is an essential component to make Salt states reusable. It is used to define secure data for minions assigned using targets. Salt pillar data stores values such as ports, file paths, configuration parameters and passwords. Pillar config File The configuration for the pillar_roots in the master config file is shown below − pillar_roots: base: – /srv/pillar Here, the file is in the “/srv/pillar” directory. Consider, the top file located in /srv/pillar/top.sls has the following structure − base: ”*”: – default Now, move to the default.sls file located in /srv/pillar/default.sls and add the following code. # Default pillar values apache git After saving the file, refresh the pillar to update all the changes. Refreshing the Pillar You can refresh the pillar using the following command. root@saltmaster:/home/vagrant# salt ”*” saltutil.refresh_pillar The above command is used to refresh the Salt pillar data on all the minions. List Pillar Data To list out the pillar data, you can use the command given below. root@saltmaster:/home/vagrant# salt ”*” pillar.ls It will produce the following output − minion2: – apache – git minion1: – apache –

SaltStack – Quick Guide ”; Previous Next SaltStack – Overview In this chapter, we will learn the basics of SaltStack. SaltStack’s remote execution capabilities allow administrators to run commands on various machines in parallel with a flexible targeting system. Salt configuration management establishes a master-minion model to quickly, very easily, flexibly and securely bringing infrastructure components in line with a given policy. What is SaltStack? Salt is a very powerful automation framework. Salt architecture is based on the idea of executing commands remotely. All networking is designed around some aspect of remote execution. This could be as simple as asking a Remote Web Server to display a static Web page, or as complex as using a shell session to interactively issue commands against a remote server. Salt is an example of one of the more complex types of remote execution. Salt is designed to allow users to explicitly target and issue commands to multiple machines directly. Salt is based around the idea of a Master, which controls one or more Minions. Commands are normally issued from the Master to a target group of Minions, which then execute the tasks specified in the commands and then return the resulting data back to the Master. Communications between a master and minions occur over the ZeroMQ message bus. SaltStack modules communicate with the supported minion operating systems. The Salt Master runs on Linux by default, but any operating system can be a minion, and currently Windows, VMware vSphere and BSD Unix variants are well supported. The Salt Master and the minions use keys to communicate. When a minion connects to a master for the first time, it automatically stores keys on the master. SaltStack also offers Salt SSH, which provides an “agent less” systems management. Need for SaltStack SaltStack is built for speed and scale. This is why it is used to manage large infrastructures with tens of thousands of servers at LinkedIn, WikiMedia and Google. Imagine that you have multiple servers and want to do things to those servers. You would need to login to each one and do those things one at a time on each one and then you might want to do complicated things like installing software and then configuring that software based on some specific criteria. Let us assume you have ten or maybe even 100 servers. Imagine logging in one at a time to each server individually, issuing the same commands on those 100 machines and then editing the configuration files on all 100 machines becomes very tedious task. To overcome those issues, you would love to update all your servers at once, just by typing one single command. SaltStack provides you exactly the solution for all such problems. Features of SaltStack SaltStack is an open-source configuration management software and remote execution engine. Salt is a command-line tool. While written in Python, SaltStack configuration management is language agnostic and simple. Salt platform uses the push model for executing commands via the SSH protocol. The default configuration system is YAML and Jinja templates. Salt is primarily competing with Puppet, Chef and Ansible. Salt provides many features when compared to other competing tools. Some of these important features are listed below. Fault tolerance − Salt minions can connect to multiple masters at one time by configuring the master configuration parameter as a YAML list of all the available masters. Any master can direct commands to the Salt infrastructure. Flexible − The entire management approach of Salt is very flexible. It can be implemented to follow the most popular systems management models such as Agent and Server, Agent-only, Server-only or all of the above in the same environment. Scalable Configuration Management − SaltStack is designed to handle ten thousand minions per master. Parallel Execution model − Salt can enable commands to execute remote systems in a parallel manner. Python API − Salt provides a simple programming interface and it was designed to be modular and easily extensible, to make it easy to mold to diverse applications. Easy to Setup − Salt is easy to setup and provides a single remote execution architecture that can manage the diverse requirements of any number of servers. Language Agnostic − Salt state configuration files, templating engine or file type supports any type of language. Benefits of SaltStack Being simple as well as a feature-rich system, Salt provides many benefits and they can be summarized as below − Robust − Salt is powerful and robust configuration management framework and works around tens of thousands of systems. Authentication − Salt manages simple SSH key pairs for authentication. Secure − Salt manages secure data using an encrypted protocol. Fast − Salt is very fast, lightweight communication bus to provide the foundation for a remote execution engine. Virtual Machine Automation − The Salt Virt Cloud Controller capability is used for automation. Infrastructure as data, not code − Salt provides a simple deployment, model driven configuration management and command execution framework. Introduction to ZeroMQ Salt is based on the ZeroMQ library and it is an embeddable networking library. It is lightweight and a fast messaging library. The basic implementation is in C/C++ and native implementations for several languages including Java and .Net is available. ZeroMQ is a broker-less peer-peer message processing. ZeroMQ allows you to design a complex communication system easily. ZeroMQ comes with the following five basic patterns − Synchronous Request/Response − Used for sending a request and receiving subsequent replies for each one sent. Asynchronous Request/Response − Requestor initiates the conversation by sending a Request message and waits for a Response message. Provider waits for the incoming Request messages and replies with the Response messages. Publish/Subscribe − Used for distributing data from a single process (e.g. publisher) to multiple recipients (e.g. subscribers). Push/Pull − Used for distributing data to connected nodes. Exclusive Pair − Used for connecting two peers together, forming a pair. ZeroMQ is a highly flexible networking tool for exchanging messages among clusters, cloud and other multi system environments. ZeroMQ is

SaltStack – Python API ”; Previous Next Salt provides programmatic access to all of its commands. Salt provides different modules for every section of the Salt system. Let us learn the basics of the python API and about how to run the basic salt commands in this chapter. Configuration The salt.config module is used to access Salt configuration details. import salt.config opts = salt.config.client_config(”/etc/salt/master”) Here, the client_config reads the salt configuration file and returns the configuration details as dictionary. Loader The salt.loader module is used to load each modules in Salt such as grains, minions, etc. import salt.loader opts = salt.config.minion_config(”/etc/salt/minion”) grains = salt.loader.grains(opts) Here, grains reads the details of the grains in the Salt system and returns it. Client Module The salt.client module is used to execute salt, salt-call and the salt-SSH commands programmatically. The most important python classes are as follows − salt.client.LocalClient salt.client.Caller salt.client.ssh.client.SSHClient The main function provided by most of the client module is cmd. This function wraps the CLI options and executes it, which is similar to the command line and returns the results as python data structures. LocalClient The LocalClient is used to send commands from the master to the salt minions and return the results to the master. import salt.client local = salt.client.LocalClient() local.cmd(”*”, ”test.ping”) It will produce the following output − {”minion1”: True, ”minion2”: True } Caller The Caller is used to run salt-call programmatically and return the results. import salt.client caller = salt.client.Caller() caller.cmd(”test.ping”) It will produce the following output − True SSHClient The SSHCient is used to run the salt-ssh programmatically and return the results. import salt.client.ssh.client ssh = salt.client.ssh.client.SSHClient() ssh.cmd(”*”, ”test.ping”) It will produce the following output − {”minion1”: True, ”minion2”: True } CloudClient The salt.cloud module is used to execute the salt-cloud commands programmatically. client = salt.cloud.CloudClient(path = ”/etc/salt/cloud”) Cloud module provides functions to create VMs (create), to destroy VMs (destroy), list images provided by a cloud provider (list_images), list locations of a cloud provider (list_locations), list machine sizes of a cloud provider (list_sizes), etc. Print Page Previous Next Advertisements ”;

Discuss SaltStack ”; Previous Next SaltStack is an open-source configuration management and remote execution engine. It remotely executes commands across all machines. It is a python based software. Thomas S Hatch is the creator and the principal architect of SaltStack. SaltStack uses the ZeroMQ messaging library to process high-speed requirements for all networking layers. Salt is simple, scalable and fast. This tutorial will explore the basic principles of SaltStack, SaltStack setup, Minion file system and then walk through with remote execution steps, configuration management, cloud management, Python API operations and finally conclude with a complete working example. Print Page Previous Next Advertisements ”;

SaltStack – Orchestration ”; Previous Next In general, orchestration is an automated coordination and arrangement of systems. Orchestrate runner is used to perform the orchestration in SaltStack. Orchestrate Runner he Orchestrate Runner offers all the functionality of the OverState (previous system). It is originally called as the state.sls runner. This orchestrate runner is used to generalize the Salt state system to a Salt master context. The state.sls and the state.highstate functions are executed on each Salt minion, but the state.orchestrate runner is executed on the master. The state.orchestrate runner allows you to manage your entire infrastructure as state fully. Let us understand how to go through a simple execution process. Simple Execution The Orchestrate Runner command is same as the state.sls function, but you can execute it with the “salt-run” instead of salt. Assume that you have a sample.sls file located at /srv/salt/orch/samples.sls. Add the following code in that file. sample.sls install_nginx: salt.state: – tgt: ”web*” – sls: – nginx The following command is used to run on the master and it will apply the states defined in that file. salt-run state.orchestrate orch.sample It will produce the following output − saltmaster.local_master: ———- ID: install_nginx Function: salt.state Result: True Comment: States ran successfully. Started: 11:54:56.308078 Duration: 63.401 ms Changes: Summary for saltmaster.local_master ———— Succeeded: 1 Failed: 0 ———— Total states run: 1 Total run time: 63.401 ms root@saltmaster:/home/vagrant# Here, according to the Current Version, the runner function was renamed to state.orchestrate. This will be helpful to avoid confusion with the state.sls execution function, but the previous versions of state.sls must be used. Execute Function To execute a function, you should use the salt.function. Consider a file data.sls located at /srv/salt/orch/data.sls. Now, add the following changes in that file. data.sls cmd.run: salt.function: – tgt: ”*” – arg: – rm -rf /tmp/data The following command is used to execute the Salt function. root@saltmaster:/home/vagrant# salt-run state.orchestrate orch.data It will produce the following output − saltmaster.local_master: ———- ID: cmd.run Function: salt.function Result: True Comment: Function ran successfully. Function cmd.run ran on minion1, minion2. Started: 12:14:54.791635 Duration: 234.615 ms Changes: minion1: minion2: Summary for saltmaster.local_master ———— Succeeded: 1 (changed = 1) Failed: 0 ———— Total states run: 1 Total run time: 234.615 ms Print Page Previous Next Advertisements ”;

SaltStack – Working Example ”; Previous Next In this working example, we will create a Salt formula that will configure the apache web server along with the PHP software. Salt is a great way to execute ad-hoc commands, but you would not really want to continually configure your infrastructure this way. By creating a set of Salt formulas, you can reliably reproduce any configuration over. Salt Formulas are simple YAML text files and by default reside on your Salt Master in /srv/salt/*. Let us start by creating a Salt Formula to install the Apache web server and PHP at the same time. Create a file named “websetup.sls” under /srv/salt/ directory and add the following code. websetup.sls websetup: pkg: – installed – pkgs: – apache2 – php5 – php5-mysql In this example, notice the “- pkgs:” argument. Each item in the list below “- pkgs:” will be passed together to OS”s package manager to be installed together. Whenever you have a large list of packages to install this is the most efficient way to install them. Apply this Formula to Salt master using the following command. root@saltmaster:/home/vagrant# salt ”minion2” state.sls websetup Now, you will see the following output − minion2: ———- ID: websetup Function: pkg.installed Result: True Comment: 3 targeted packages were installed/updated. Started: 01:50:53.978396 Duration: 86738.132 ms Changes: ———- apache2: ———- new: 2.4.7-1ubuntu4.13 old: apache2-api-20120211: ———- new: 1 old: apache2-bin: ———- new: 2.4.7-1ubuntu4.13 old: apache2-data: ———- new: 2.4.7-1ubuntu4.13 old: libapache2-mod-php5: ———- new: 5.5.9+dfsg-1ubuntu4.21 old: libapr1: ———- new: 1.5.0-1 old: libaprutil1: ———- new: 1.5.3-1 old: libaprutil1-dbd-sqlite3: ———- new: 1.5.3-1 old: libaprutil1-ldap: ———- new: 1.5.3-1 old: php5: ———- new: 5.5.9+dfsg-1ubuntu4.21 old: php5-cli: ———- new: 5.5.9+dfsg-1ubuntu4.21 old: php5-common: ———- new: 5.5.9+dfsg-1ubuntu4.21 old: php5-json: ———- new: 1.3.2-2build1 old: php5-mhash: ———- new: 1 old: php5-mysql: ———- new: 5.5.9+dfsg-1ubuntu4.21 old: php5-readline: ———- new: 5.5.9+dfsg-1ubuntu4.21 old: phpapi-20121212: ———- new: 1 old: ssl-cert: ———- new: 1.0.33 old: Summary for minion2 ———— Succeeded: 1 (changed = 1) Failed: 0 ———— Total states run: 1 Total run time: 86.738 s Now, you have installed the packages in minion2. Highstate A “highstate” is a way for Salt to determine which of the Salt Formulas should be applied to a certain minion. Execute a “highstate” using the following command. root@saltmaster:/home/vagrant# salt <targets> state.highstate top.sls When the minion request to execute a highstate, as mentioned before, the minion requests the top.sls from the Salt master and searches for formulas that it matches. By default, this file is located at /srv/salt/top.sls. Let us add our formula to the top.sls file and set minion2 as target. base: ”*”: – common ”minion2’: – websetup Now, execute the highstate targeting minion2 as shown below. root@saltmaster:/home/vagrant# salt ”minion2” state.highstate After applying this, you could see the following output − minion2: ———- ID: common_packages Function: pkg.installed Result: True Comment: All specified packages are already installed Started: 01:55:17.998824 Duration: 461.615 ms Changes: Summary for minion2 ———— Succeeded: 1 Failed: 0 ———— Total states run: 1 Total run time: 461.615 ms Now, Apache web server and PHP is installed in the minion2. In this way, we have to target minions using both top.sls and highstate and install the required software with minimal work and maximum flexibility. Print Page Previous Next Advertisements ”;

SaltStack – Competitors ”; Previous Next Salt, Puppet, Chef, and Ansible are the leading configuration management and orchestration tools, each of which takes a different path to server automation. They were built to make it easier to configure and maintain dozens, hundreds or even thousands of servers. Let us understand how SaltStack competes primarily with Puppet, Chef, and Ansible. Platforms and Support Following is a list of all the platforms that support SaltStack and its competitors. SaltStack − SaltStack software runs on and manages many versions of Linux, Windows, Mac OS X and UNIX. Puppet − Red Hat Enterprise Linux, CentOS, Oracle Linux, Scientific Linux, SUSE Linux Enterprise Server and Ubuntu. Chef − Chef is supported on multiple platforms such as AIX, RHEL/CentOS, FreeBSD, OS X, Solaris, Microsoft Windows and Ubuntu. Ansible − Fedora distribution of Linux, CentOS, and Scientific Linux via Extra Packages for Enterprise Linux (EPEL) as well as for other operating systems. Origin Language SaltStack − Python Puppet − Ruby Chef − Ruby and its CLI uses ruby-based DSL Ansible − Python Supported Language SaltStack − Any language Puppet − Ruby Chef − Ruby and its CLI uses ruby-based DSL Ansible − Any language Web UI SaltStack − Web UI offers views of running jobs, minion status and event logs. Puppet − Web UI handles reporting, inventorying and real-time node management. Chef − Web UI lets you search and inventory nodes, view node activity and assign Cookbooks, roles and nodes. Ansible − Web UI lets you configure users, teams and inventories and apply Playbooks to inventories. Management Tools SaltStack − SaltStack Enterprise is positioned as the main tool for managing the orchestration of cloud and IT operations, as well as DevOps. Puppet − Puppet comes in two flavors, Puppet Enterprise and Open Source Puppet. In addition to providing functionalities of the Open Source Puppet, Puppet Enterprise also provides GUI, API and command line tools for node management. Chef − CFEngine is the configuration management tool. Ansible − Ansible 1.3 is the main tool for management. Performance SaltStack − Salt is designed for high-performance and scalability. Salt’s communication system establishes a persistent data pipe between the Salt master and minions using ZeroMQ. Puppet − Secure as well as high-performance and no agents required. Chef − The most apparent struggle for Chef Server is search; Search is slow and is not requested concurrently from clients. Ansible − Secure, high-performance and no agents required. Price and Value SaltStack − Free open source version. SaltStack Enterprise costs $150 per machine per year. Puppet − Free open source version. Puppet Enterprise costs $100 per machine per year. Chef − Free open source version; Enterprise Chef free for 5 machines, $120 per month for 20 machines, $300 per month for 50 machines. Ansible − Free open source version; Ansible free for 10 machines, then $100 or $250 per machine per year depending on the support you needed. Usage SaltStack − SaltStack is used by Cisco and Rackspace. It can integrate with any cloud-based platform. Puppet − Puppet is used by Zynga, Twitter, the New York Stock Exchange, PayPal, Disney, Google and so on. Chef − Chef can integrate with cloud-based platforms such as Internap, Amazon EC2, Google Cloud Platform, OpenStack, Microsoft Azure and Rackspace. Ansible − Ansible can deploy to virtualization environments, cloud environments including Amazon Web Services, Cloud Stack, DigitalOcean, and Google Cloud Platform and so on. Print Page Previous Next Advertisements ”;

SaltStack – Salt Package Manager ”; Previous Next Salt formulas are packaged and distributed to Salt masters using the package manager. This concept was influenced from RPM, Yum and Pacman packaging systems. Salt state, pillar, file templates and other files are used by the formula and then packaged into a single file. After a formula package is created, it is copied to the Repository System to make it to use for Salt masters. Before moving to the package manager, let us have a look at how to install an “nginx” package using the Salt basic command. The following syntax is used to install a “nginx” package. root@saltmaster:/home/vagrant# salt ”*” pkg.install nginx Here, the pkg.install nginx command is used to install a package. After execution, you will see the following response. It will produce the following output − minion2: ———- httpd: ———- new: 1 old: httpd-cgi: ———- new: 1 old: libxslt1.1: ———- new: 1.1.28-2build1 old: nginx: ———- new: 1.4.6-1ubuntu3.7 old: nginx-common: ———- new: 1.4.6-1ubuntu3.7 old: nginx-core: ———- new: 1.4.6-1ubuntu3.7 old: minion1: ———- httpd: ———- new: 1 old: httpd-cgi: ———- new: 1 old: libxslt1.1: ———- new: 1.1.28-2build1 old: nginx: ———- new: 1.4.6-1ubuntu3.7 old: nginx-common: ———- new: 1.4.6-1ubuntu3.7 old: nginx-core: ———- new: 1.4.6-1ubuntu3.7 old: Now, you have installed a package. To start the services for that package, use the command given below. root@saltmaster:/home/vagrant# salt ”*” service.start nginx After running this command, the result looks as shown in the code block below. minion1: True minion2: True Therefore, we have installed and started the services for the “nginx” package using the basic command. Let us now discuss how to build and install packages in the Salt package manager. Building Packages Packages can be built on any system where you can install Salt. There are three type of packages and they are follows. Formula Reactor Conf Let us now understand how to build packages using the Fomula File. Formula File Most files from the package are located at the – /srv/spm/salt/ directory by default, but the pillar file can be placed in the – /srv/spm/pillar/ directory. The Formula file describes the package. Example name: apache os: RedHat os_family: RedHat version: 201607 release: 2 summary: Formula for installing Apache description: Formula for installing Apache Here, Name − The name of the package. Here, the package name is apache. os − It is used to know which operating systems can support this package. os_family − It is used to know which operating system families can support this package. Version − The version of the package. It is specified in an YYYYMM format. Release − This field refers primarily to a release of a version. Summary − Short lines description of the package. Description − A more detailed description of the package. REACTOR The reactor files resides in the /srv/spm/reactor/ directory. CONF The files in this type of a package are configuration files for Salt, which normally live in the /etc/salt/ directory. Configuration files for packages other than Salt can and should be handled with a Salt State (using a formula type of package). Let us continue with the following steps to build a package. Create a FORMULA file and place it in the root of the package folder. Assemble the formula files in a folder on the build system. Run spm build. The package is built and placed in the /srv/spm_build folder. The following command is used to build a package. spm build /path/to/salt-packages-source/formula Now, copy the .spm file to a folder on the repository system. You can share the srv/spm_build folder on the network, or copy the files to your FTP or the Webserver. Generate repo metadata using the following command. spm create_repo /srv/spm_build Installing Packages This section explains about installing Salt package manager packages. Configure Remote Repositories To configure remote repositories, the Salt Master needs to know where the repository is through a configuration process. Files are in the /etc/salt/spm.repos.d/spm.repo directory. Example file_repository: url: https://spm.example.com/ Here, the file contains the name of the repository and the link to the repository. You can also use http, https, ftp, or the file path. To use file path, you can access it using the URL: file:///srv/spm_build. Update Metadata After the repository is configured on the Salt master, repository metadata is downloaded using the command below. spm update_repo Update File Roots The SPM packages are located in the srv/spm/salt directory. Add the following path to the file roots on the Salt master, file_roots: base: 1. /srv/salt 2. /srv/spm/salt Now, restart the salt master. Install Apache Package To install the package apache, use the following command. spm install apache You can also install directly from the SPM file using the command below. spm local install /srv/spm/apache-201607-1.spm Removing a Package To remove a package, for example – apache, use the following command, spm remove apache Note that, if any files have been modified, they will not be removed. Print Page Previous Next Advertisements ”;

SaltStack – Using Cron with Salt ”; Previous Next Salt can be used along with the Cron application. Using both applications together provides a great opportunity to automate Salt. While Salt provides an option to execute commands remotely, Cron enables it to run in a pre-scheduled or automated manner. Let us learn how to use Cron and Salt together in this chapter. What is Cron? Cron is very useful application in the Linux Environment. It enables to preset a command or script to run in a specific date and time. It also enables to run an application in a regular interval, say daily, weekly or every first day of the month. Cron starts when the system starts and check the /etc/crontab file for configuration details. The /etc/crontab has every application and its schedule in a separate line as shown below. 15 * * * * root echo “This command runs at 15 minutes past every hour” 15 10 * * * root echo “This command is run daily at 10:15 am” Every line has the following seven entry points, which are separated by space and they are as follows − minute − minute of the hour and is between ‘0’ and ‘59’. hour − hour and is specified in the 24-hour clock. day_of_month − Day of the Month and is between 1 and 31. For example, the 10th of each month is 10. month − A month specified and is specified numerically (0-12), or as the name of the month (e.g. May). day_of_week − Day of the week is specified numerically (0-7) or as the name of the day (e.g. Sun). user − User account under which the command runs. cmd − The actual command and its arguments. Here, * replaces, if nothing is assigned. Salt Caller (salt-call) Salt provides a CLI (Command Line Interface), salt-call to run the modules in the local minion system itself instead of from the master server using the salt command. The salt call CLI supports all the options supported by salt command, but run locally. Salt Caller was initially designed to support debugging, but now, it can be used as a standalone application. salt-call test.ping Using salt-call in cron The salt-call CLI is useful to schedule salt operation using Cron. For example, to check the state of the minion every day at midnight, we can use salt-call along with the option – state.apply as shown below. /etc/crontab PATH = /bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin:/opt/bin 0 0 * * * salt-call state.apply Here, The state.apply function will check the salt configuration file for the minion and check whether all action defined for the minion is properly configured. Setting the path is a good practice because sometimes the salt command may not be available in the system path. In the next chapter, we will learn Remote Execution, which is a core concept of Salt. Print Page Previous Next Advertisements ”;

SaltStack – Using MinionFS as the File Server ”; Previous Next The MinionFS is a special file server provided by Salt for the minions to exchange the files between them. The files served by the MinionFS are the files intentionally shared by minions. To share the files, a Minion has to follow steps given below. Source minion has to push the file to the salt master using the cp.push function. Once the files are pushed by the source minion, the deployed files can be accessed by any other minion using the MinionFS file server. Enable Pushing By default, pushing the files by minions to a master is disabled. To accept the files from minions, the master needs to have the “file_recv” option in the config file and its value must be set to True. By default, the value if “file_recv” is false. file_recv: True Once the option is enabled, restart the master service. Pushing Files Minions can push the files to the master. It is performed by the cp.push function. This cp.push function provides an easy mechanism to push the files by minion using the minion id. salt ”minion-id” cp.push /path/to/the/file Here, the minion-id is used to identify which minion is pushing the file. This command will store the file in a subdirectory named minions under the master”s cachedir. Usually, the path is – /var/cache/salt/master/minions. For minion, m1 and the file – /var/log/mylog.txt, the file will be stored in the – /var/cache/salt/master/minions/m1/var/log/mylog.txt. Enable MinionFS To enable the MinionFS, simply add minion in the fileserver backend setting as shown in the following code block. fileserver_backend: – roots – minion Once MinionFS is enabled, the minion pushed files are available as − salt://<minion-id>/path/to/pushed/file For minion, m1 and the pushed file – /var/log/mylog.txt, the pushed file will be served from salt://m1/var/log/mylog.txt. This minionFS can be mounted in a special directory using the following configuration. It will separate the minionFS files from other files and will help in organizing the minion files. minionfs_mountpoint: salt://minionfs For the above configuration, the file will available under the minionfs directory as – salt://minionfs/m1/var/log/mylog.txt MinionFS Advanced Options The MinionFS also provides an option to enable / disable the availability of pushed files from a certain minion. The options are minionfs_whitelist, to enable minions and minionfs_blacklist, to disable the minions. minionfs_whitelist: – webserver – develop* – ‘maild+.mysite.com” minionfs_blacklist: – testing In the above configuration, all minions except testing are allowed to share the file using minionFS. Webserver1 Minions whose ids matches the regular expression develop * Minions whose ids matches the regular expression maild+.mysite.com. Testing In the next chapter, we will learn how to use Cron with Salt. Print Page Previous Next Advertisements ”;