Saltstack Interview Questions and Answers

Salt, or SaltStack, is a high speed remote execution and configuration management system which uses zeromq. Salt has also been written with the developer in mind, Salt can be very easily extended with modules and can act as a standalone remote execution system or act as a simple to use message passing and managing broker with authentication and encryption built in. The remote execution capabilities allow administrators to run commands on various machines in parallel with a flexible targeting system. The configuration management functionality establishes a client-server model to quickly, easily, and securely bring infrastructure components in line with a given policy

It is scalable configuration management

It is a flexible and easy to setup

It is easy process in parallel execution model and language agnostic

Fault tolerance

Salt was designed to enable low-latency and high-speed communication for data collection and remote execution in systemadmin environments. Salt is designed to allow users to explicitly target and issue commands to multiple machines directly.

• It is uses Python, which is built into Linux and more widespread
• Salt is powerful and robust configuration management framework and works around tens of thousands of systems
• It is very fast performance.
• It is virtual Machine Automation
• It is easily scalable and deployable
• YAML output; easier to format and understand

 In Saltstack, 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.

Targeting minions is specifying which minions should run a command or execute a state by matching against hostnames, or system information, or defined groups, or even combinations thereof. For example the command salt web1 apache. Signal restart to restart the Apache httpd server specifies the machine web1 as the target and the command will only be run on that one minion.

Salt Cloud provides a powerful interface to interact with cloud hosts. This interface is tightly integrated with Salt, and new virtual machines are automatically connected to your Salt master after creation. Salt provides a separate module, Salt Cloud to provide virtual machines of various cloud providers like Amazon AWS, Google Compute, etc. Salt Cloud is a generic interface to configure and manage VMs of various cloud providers.

Cloud Config: The main configuration file for Salt Cloud is /etc/salt/cloud and it applies to all the VMs. The main configuration file is called Cloud Config.

Cloud Providers: To target specific cloud providers, we can use specific configuration file and they are located in /etc/salt/cloud.providers.d/*.conf, these are called as Cloud Providers.

Cloud Profiles: To target a specific VM, we can also use a special configuration file, which applies to that particular VM only and they are located at /etc/salt/cloud.profiles.d/*.conf, these are called as Cloud Profiles.

Yes. Salt provides an easy to use addition to your file. Managed states that allow you to back up files via backup _mode, backup _mode can be configured on a per state basis, or in the minion config (note that if set in the minion config this would simply be the default method to use, you still need to specify that the file should be backed up!).

The event system in Salt is a local ZeroMQ PUB interface, which fires salt events. The Salt Event System is used to fire off events enabling third party applications or external processes to react to behavior within Salt.  The event system is comprised of two primary components:

Event sockets: The event sockets which publishes events.

Event library: The event library which can listen to events and send events into the salt system.

Proxy minions are a developing Salt feature that enables controlling devices that, for whatever reason, cannot run a standard salt-minion. Examples include network gear that has an API but runs a proprietary OS, devices with limited CPU or memory, or devices that could run a minion, but for security reasons, will not. Proxy minions are not an “out of the box” feature. Because there are an infinite number of controllable devices, you will most likely have to write the interface yourself.

Salt proxy-minions provide the ‘plumbing’ that allows device enumeration and discovery, control, status, remote execution, and state management. (Ref salt doc)

Updating the salt-minion package requires a restart of the salt-minion service. But restarting the service while in the middle of a state run interrupts the process of the Minion running states and sending results back to the Master. A common way to work around that is to schedule restarting of the Minion service using master less mode after all other (SAP Training) states have been applied. This allows the minion to keep Minion to Master connection alive for the Minion to report the final results to the Master, while the service is restarting in the background.

The Minion data cache contains the Salt Mine data, minion grains and minion pillar information cached on the Salt Master. By default, Salt uses the localfs cache module to save the data in a msgpack file on the Salt Master.

Salt detects the Minion’s operating system and assigns the correct package or service management module based on what is detected. However, for certain custom spins and OS derivatives this detection fails. In cases like this, an issue should be opened on our tracker, with the following information:

The output of the following command:

salt < minion_id > grains.items | grep os

The contents of /etc/lsb-release, if present on the Minion.

Custom modules are synced to Minions when saltutil.sync_modules, or saltutil.sync_all is run. Custom modules are also synced by state.apply when run without any arguments.

Similarly, custom states are synced to Minions when state.apply, saltutil.sync_states, or saltutil.sync_all is run.custom states are also synced by state.apply when run without any arguments. Other custom types (renderers, outputters, etc.) have similar behavior, see the documentation for the saltutilmodule for more information.This reactor example can be used to automatically sync custom types when the minion connects to the master, to help with this chicken-and-egg issue.

If the Minion id is not configured explicitly (using the id parameter), Salt will determine the id based on the hostname.

This is usually the result of an upstream change in an OS distribution that replaces or removes something that Salt was using to detect the grain. Fortunately, when this occurs,

you can use Salt to fix it with a command similar to the following:

salt -G ‘grain:ChangedValue’ grains.setvals “{‘grain’: ‘OldValue’}”

(Replacing grain, ChangedValue, and OldValue with the grain and values that you want to change / set.)

You should also file an issue describing the change so it can be fixed in Salt.

 The Salt fileserver does not yet support access control, but it is still possible to do this. As of Salt 2015.5.0, thefile_tree external pillar is available, and allows the contents of a file to be loaded as Pillar data. This external pillar is capable of assigning Pillar values both to individual minions, and to node groups. See the documentation for details on how to set this up.

Once the external pillar has been set up, the data can be pushed to a minion via a file.managed state, using thecontents_pillar argument:

/etc/my_super_secret_file:

file.managed:

User: secret

Group: secret

Mode: 600

contents_pillar: secret_files:my_super_secret_file

In this example, the source file would be located in a directory called secret_files underneath the file_tree path for the minion. The syntax for specifying the pillar variable is the same one used for pillar.get, with a colon representing a nested dictionary.

• Installation process very hard for new users
• Web UI offers limited capabilities and features
• Poor, underdeveloped GUI
• Not the best option for OSs other than Linux
• The platform is new and not entirely mature as compared to Puppet and Chef
• Basic support for Windows
• Documentation is not well managed, and is challenging to review