neulab/tldr huggingface dataset:
--tr-keep-ttl Keep the TTL fixed in traceroute mode, so you can monitor just one hop in the route. For example, to monitor how the 5th hop changes or how its RTT changes you can try hping2 host --traceroute --ttl 5 --tr-keep-ttl.
--tr-stop If this option is specified hping will exit once the first packet that isn't an ICMP time exceeded is received. This better emulates the traceroute behavior.
--tr-no-rtt Don't show RTT information in traceroute mode. The ICMP time exceeded RTT information aren't even calculated if this option is set.
--tcpexitcode Exit with last received packet tcp->th_flag as exit code. Useful for scripts that need, for example, to known if the port 999 of some host reply with SYN/ACK or with RST in response to SYN, i.e. the service is up or down.
The standard TCP output format is the following:
len=46 ip=192.168.1.1 flags=RA DF seq=0 ttl=255 id=0 win=0 rtt=0.4 ms
len is the size, in bytes, of the data captured from the data link layer excluding the data link header size. This may not match the IP datagram size due to low level transport layer padding.
ip is the source ip address.
flags are the TCP flags, R for RESET, S for SYN, A for ACK, F for FIN, P for PUSH, U for URGENT, X for not standard 0x40, Y for not standard 0x80.
If the reply contains DF the IP header has the don't fragment bit set.
seq is the sequence number of the packet, obtained using the source port for TCP/UDP packets, the sequence field for ICMP packets.
id is the IP ID field.
win is the TCP window size.
rtt is the round trip time in milliseconds.
If you run hping using the -V command line switch it will display additional information about the packet, example:
len=46 ip=192.168.1.1 flags=RA DF seq=0 ttl=255 id=0 win=0 rtt=0.4 ms tos=0 iplen=40 seq=0 ack=1223672061 sum=e61d urp=0
tos is the type of service field of the IP header.
iplen is the IP total len field.
seq and ack are the sequence and acknowledge 32bit numbers in the TCP header.
sum is the TCP header checksum value.
urp is the TCP urgent pointer value.
The standard output format is:
len=46 ip=192.168.1.1 seq=0 ttl=64 id=0 rtt=6.0 ms
The field meaning is just the same as the TCP output meaning of the same fields.
An example of ICMP output is:
ICMP Port Unreachable from ip=192.168.1.1 name=nano.marmoc.net
It is very simple to understand. It starts with the string "ICMP" followed by the description of the ICMP error, Port Unreachable in the example. The ip field is the IP source address of the IP datagram containing the ICMP error, the name field is just the numerical address resolved to a name (a dns PTR request) or UNKNOWN if the resolution failed.
The ICMP Time exceeded during transit or reassembly format is a bit different:
TTL 0 during transit from ip=192.168.1.1 name=nano.marmoc.net
TTL 0 during reassembly from ip=192.70.106.25 name=UNKNOWN
The only difference is the description of the error, it starts with TTL 0.
Salvatore Sanfilippo <antirez@invece.org>, with the help of the people mentioned in AUTHORS file and at http://www.hping.org/authors.html
Even using the --end and --safe options to transfer files the final packet will be padded with 0x00 bytes.
Data is read without care about alignment, but alignment is enforced in the data structures.  This will not be a problem under i386 but, while usually the TCP/IP headers are naturally aligned, may create problems with different processors and bogus packets if there is some unaligned access around the code (hopefully none).
On solaris hping does not work on the loopback interface. This seems a solaris problem, as stated in the tcpdump-workers mailing list, so the libpcap can't do nothing to handle it properly.
ping(8), traceroute(8), ifconfig(8), nmap(1)
WIPEFS(8)                     System Administration                    WIPEFS(8)
wipefs - wipe a signature from a device
wipefs [options] device...
wipefs [--backup] -o offset device...
wipefs [--backup] -a device...
wipefs can erase filesystem, raid or partition-table signatures (magic strings) from the specified device to make the signatures invisible for libblkid. wipefs does not erase the filesystem itself nor any other data from the device.
When used without any options, wipefs lists all visible filesystems and the offsets of their basic signatures. The default output is subject to change. So whenever possible, you should avoid using default outputs in your scripts. Always explicitly define expected columns by using --output columns-list in environments where a stable output is required.
wipefs calls the BLKRRPART ioctl when it has erased a partition-table signature to inform the kernel about the change. The ioctl is called as the last step and when all specified signatures from all specified devices are already erased. This feature can be used to wipe content on partitions devices as well as partition table on a disk device, for example by wipefs -a /dev/sdc1 /dev/sdc2 /dev/sdc.
Note that some filesystems and some partition tables store more magic strings on the device (e.g., FAT, ZFS, GPT). The wipefs command (since v2.31) lists all the offset where a magic strings have been detected.
When option -a is used, all magic strings that are visible for libblkid(3) are erased. In this case the wipefs scans the device again after each modification (erase) until no magic string is found.
Note that by default wipefs does not erase nested partition tables on non-whole disk devices. For this the option --force is required.
-a, --all Erase all available signatures. The set of erased signatures can be restricted with the -t option.
-b, --backup Create a signature backup to the file $HOME/wipefs-<devname>-<offset>.bak. For more details see the EXAMPLE section.
-f, --force Force erasure, even if the filesystem is mounted. This is required in order to erase a partition-table signature on a block device.
--lock[=mode] Use exclusive BSD lock for device or file it operates. The optional argument mode can be yes, no (or 1 and 0) or nonblock. If the mode argument is omitted, it defaults to "yes". This option overwrites environment variable $LOCK_BLOCK_DEVICE. The default is not to use any lock at all, but itâ€™s recommended to avoid collisions with udevd or other tools.
-i, --noheadings Do not print a header line.
-O, --output list Specify which output columns to print. Use --help to get a list of all supported columns.
-n, --no-act Causes everything to be done except for the write(2) call.
-o, --offset offset Specify the location (in bytes) of the signature which should be erased from the device. The offset number may include a "0x" prefix; then the number will be interpreted as a hex value. It is possible to specify multiple -o options.
The offset argument may be followed by the multiplicative suffixes KiB (=1024), MiB (=1024*1024), and so on for GiB, TiB, PiB, EiB, ZiB and YiB (the "iB" is optional, e.g., "K" has the same meaning as "KiB"), or the suffixes KB (=1000), MB (=1000*1000), and so on for GB, TB, PB, EB, ZB and YB.
-p, --parsable Print out in parsable instead of printable format. Encode all potentially unsafe characters of a string to the corresponding hex value prefixed by '\x'.
-q, --quiet Suppress any messages after a successful signature wipe.
-t, --types list Limit the set of printed or erased signatures. More than one type may be specified in a comma-separated list. The list or individual types can be prefixed with 'no' to specify the types on which no action should be taken. For more details see mount(8).
LIBBLKID_DEBUG=all enables libblkid(3) debug output.
wipefs /dev/sda* Prints information about sda and all partitions on sda.
wipefs --all --backup /dev/sdb Erases all signatures from the device /dev/sdb and creates a signature backup file ~/wipefs-sdb-<offset>.bak for each signature.
dd if=~/wipefs-sdb-0x00000438.bak of=/dev/sdb seek=$0x00000438 bs=1 conv=notrunc Restores an ext2 signature from the backup file ~/wipefs-sdb-0x00000438.bak.
blkid(8), findfs(8)
The wipefs command is part of the util-linux package which can be downloaded from Linux Kernel Archive <https://www.kernel.org/pub/linux/utils/util-linux/>.
COMM(1P)                    POSIX Programmer's Manual                   COMM(1P)
comm — select or reject lines common to two files
comm [-123] file1 file2
The comm utility shall read file1 and file2, which should be ordered in the current collating sequence, and produce three text columns as output: lines only in file1, lines only in file2, and lines in both files.
If the lines in both files are not ordered according to the collating sequence of the current locale, the results are unspecified.
If the collating sequence of the current locale does not have a total ordering of all characters (see the Base Definitions volume of POSIX.1‐2017, Section 7.3.2, LC_COLLATE) and any lines from the input files collate equally but are not identical, comm should treat them as different lines but may treat them as being the same. If it treats them as different, comm should expect them to be ordered according to a further byte-by-byte comparison using the collating sequence for the POSIX locale and if they are not ordered in this way, the output of comm can identify such lines as being both unique to file1 and unique to file2 instead of being in both files.
The comm utility shall conform to the Base Definitions volume of POSIX.1‐2017, Section 12.2, Utility Syntax Guidelines.
-1        Suppress the output column of lines unique to file1.
-2        Suppress the output column of lines unique to file2.
-3        Suppress the output column of lines duplicated in file1 and file2.
file1     A pathname of the first file to be compared. If file1 is '-', the standard input shall be used.
file2     A pathname of the second file to be compared. If file2 is '-', the standard input shall be used.
If both file1 and file2 refer to standard input or to the same FIFO special, block special, or character special file, the results are undefined.
The standard input shall be used only if one of the file1 or file2 operands refers to standard input. See the INPUT FILES section.
The input files shall be text files.
The following environment variables shall affect the execution of comm:
LC_COLLATE Determine the locale for the collating sequence comm expects to have been used when the input files were sorted.
The comm utility shall produce output depending on the options selected. If the -1, -2, and -3 options are all selected, comm shall write nothing to standard output.
If the -1 option is not selected, lines contained only in file1 shall be written using the format:
"%s\n", <line in file1>
If the -2 option is not selected, lines contained only in file2 are written using the format:
"%s%s\n", <lead>, <line in file2>
where the string <lead> is as follows:
<tab>     The -1 option is not selected.
null string The -1 option is selected.
If the -3 option is not selected, lines contained in both files shall be written using the format:
"%s%s\n", <lead>, <line in both>
<tab><tab> Neither the -1 nor the -2 option is selected.
<tab>     Exactly one of the -1 and -2 options is selected.
null string Both the -1 and -2 options are selected.
If the input files were ordered according to the collating sequence of the current locale, the lines written shall be in the collating sequence of the current locale. If the input files contained any lines that collated equally but were not identical and within each file those lines were ordered according to a further byte-by-byte comparison using the collating sequence for the POSIX locale, and comm treated them as different lines, then lines written that collate equally but are not identical should be ordered according to a further byte-by-byte comparison using the collating sequence for the POSIX locale.
0    All input files were successfully output as specified.
If the input files are not properly presorted, the output of comm might not be useful.
When using comm to process pathnames, it is recommended that LC_ALL, or at least LC_CTYPE and LC_COLLATE, are set to POSIX or C in the environment, since pathnames can contain byte sequences that do not form valid characters in some locales, in which case the utility's behavior would be undefined. In the POSIX locale each byte is a valid single-byte character, and therefore this problem is avoided.
If the collating sequence of the current locale does not have a total ordering of all characters, this can affect the behavior of comm in the following ways:
*  If comm treats lines as being the same only if they are identical, some lines can be misleadingly identified as being both unique to file1 and unique to file2.
*  If comm treats lines as being the same if they collate equally and a line from file1 collates equally with a line from file2 but is not identical to it, one of the lines is misleadingly identified as being in both files and the other is not written to the output at all.
Such problems can be avoided by forcing the use of the POSIX locale; for example, the following identifies lines in both file1 and file2:
LC_ALL=POSIX sort file1 > file1.posix LC_ALL=POSIX sort file2 > file2.posix LC_ALL=POSIX comm -12 file1.posix file2.posix | sort
The final sort re-sorts the output of comm according to the collating sequence of the original locale. Doing this might be difficult if more than one column is output and leading <blank>s cannot be ignored.
If a file named xcu contains a sorted list of the utilities in this volume of POSIX.1‐2017, a file named xpg3 contains a sorted list of the utilities specified in the X/Open Portability Guide, Issue 3, and a file named svid89 contains a sorted list of the utilities in the System V Interface Definition Third Edition:
comm -23 xcu xpg3 | comm -23 - svid89
would print a list of utilities in this volume of POSIX.1‐2017 not specified by either of the other documents:
comm -12 xcu xpg3 | comm -12 - svid89
would print a list of utilities specified by all three documents, and:
comm -12 xpg3 svid89 | comm -23 - xcu
would print a list of utilities specified by both XPG3 and the SVID, but not specified in this volume of POSIX.1‐2017.
A future version of this standard may require that if any lines from the input files collate equally but are not identical, then comm treats them as different lines and expects them to be ordered according to a further byte-by-byte comparison using the collating sequence for the POSIX locale.
A future version of this standard may require that if the input files contained any lines that collated equally but were not identical and within each file those lines were ordered according to a further byte-by- byte comparison using the collating sequence for the POSIX locale, then lines written that collate equally but are not identical are ordered according to a further byte-by-byte comparison using the collating sequence for the POSIX locale.
cmp, diff, sort, uniq
The Base Definitions volume of POSIX.1‐2017, Section 7.3.2, LC_COLLATE, Chapter 8, Environment Variables, Section 12.2, Utility Syntax Guidelines
ENVSUBST(1)                       User Commands                      ENVSUBST(1)
envsubst - substitutes environment variables in shell format strings
envsubst [OPTION] [SHELL-FORMAT]
Substitutes the values of environment variables.
Operation mode: -v, --variables output the variables occurring in SHELL-FORMAT
In normal operation mode, standard input is copied to standard output, with references to environment variables of the form $VARIABLE or ${VARIABLE} being replaced with the corresponding values.  If a SHELL-FORMAT is given, only those environment variables that are referenced in SHELL-FORMAT are substituted; otherwise all environment variables references occurring in standard input are substituted.
When --variables is used, standard input is ignored, and the output consists of the environment variables that are referenced in SHELL-FORMAT, one per line.
Written by Bruno Haible.
Copyright Â© 2003-2020 Free Software Foundation, Inc.  License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it.  There is NO WARRANTY, to the extent permitted by law.
The full documentation for envsubst is maintained as a Texinfo manual. If the info and envsubst programs are properly installed at your site, the command
info envsubst
cmark(1)                     General Commands Manual                    cmark(1)
cmark - convert CommonMark formatted text to HTML
cmark [options] file*
cmark converts Markdown formatted plain text to either HTML, groff man, CommonMark XML, LaTeX, or CommonMark, using the conventions described in the CommonMark spec.  It reads input from stdin or the specified files (concatenating their contents) and writes output to stdout.
--to, -t FORMAT Specify output format (html, man, xml, latex, commonmark).
--width WIDTH Specify a column width to which to wrap the output. For no wrapping, use the value 0 (the default).  This option currently only affects the commonmark, latex, and man renderers.
--hardbreaks Render soft breaks (newlines inside paragraphs in the CommonMark source) as hard line breaks in the target format. If this option is specified, hard wrapping is disabled for CommonMark output, regardless of the value given with --width.
--nobreaks  Render soft breaks as spaces.  If this option is specified, hard wrapping is disabled for all output formats, regardless of the value given with --width.
--sourcepos Include source position attribute.
--validate-utf8 Validate UTF-8, replacing illegal sequences with U+FFFD.
--smart     Use smart punctuation.  Straight double and single quotes will be rendered as curly quotes, depending on their position.  -- will be rendered as an en-dash.  --- will be rendered as an em-dash.  ... will be rendered as ellipses.
--safe      Omit raw HTML and potentially dangerous URLs (default).  Raw HTML is replaced by a placeholder comment and potentially dangerous URLs are replaced by empty strings.  Potentially dangerous URLs are those that begin with `javascript:`, `vbscript:`, `file:`, or `data:` (except for `image/png`, `image/gif`, `image/jpeg`, or `image/webp` mime types).
--unsafe    Render raw HTML or potentially dangerous URLs, overriding the default (--safe) behavior.
--help      Print usage information.
--version   Print version.
John MacFarlane, Vicent Marti, Kārlis Gaņģis, Nick Wellnhofer.
CommonMark spec:  https://spec.commonmark.org.
SALT(7)                               Salt                               SALT(7)
salt - Salt Documentation
Salt Project License: Apache v2.0PyPi Package DownloadsPyPi Package DownloadsSalt Project Slack CommunitySalt Project Twitch ChannelSalt Project subredditFollow SaltStack on Twitter.INDENT 0.0 [image: Salt Project Logo] [image]
• Latest Salt Documentation
• Open an issue (bug report, feature request, etc.)
Salt is the world’s fastest, most intelligent and scalable automation engine.
About Salt Built on python, Salt uses simple and human-readable YAML combined with event-driven automation to deploy and configure complex IT systems. In addition to leveling-up vRealize Automation SaltStack Config, Salt can be found under the hood of products from Juniper, Cisco, Cloudflare, Nutanix, SUSE, and Tieto, to name a few.
About SaltStack SaltStack was acquired by VMware in 2020.  Salt Project remains an open source ecosystem that VMware supports and contributes to.
Download Salt Salt is tested and packaged to run on CentOS, Debian, RHEL, Ubuntu, MacOS, Windows, and more. Download Salt and get started now.
• https://repo.saltproject.io/
• Installation Instructions
Salt Project Documentation Installation instructions, getting started guides, in-depth API documentation, and contributing to Salt.
• Getting Started with Salt
• Salt’s Contributor Guide
Security Advisories Keep an eye on the Salt Project Security Announcements landing page. Salt Project recommends subscribing to the Salt Project Security RSS feed to receive notification when new information is available regarding security announcements.
Other channels to receive security announcements include the Salt Community mailing list and the Salt Project Community Slack.
Responsibly Reporting Security Vulnerabilities When reporting security vulnerabilities for Salt or other SaltStack projects, refer to the SECURITY.md file found in this repository.
Engage the Salt Project and The Community Please be sure to review our Code of Conduct.  Also, check out some of our community resources including:
• Salt Project Community Wiki
• Salt Project Community Slack
• Salt Project: IRC on LiberaChat
• Salt Project YouTube channel
• Salt Project Twitch channel
There are lots of ways to get involved in our community. Every month, there are around a dozen opportunities to meet with other contributors and the Salt Core team and collaborate in real time. The best way to keep track is by subscribing to the Salt Project Community Events Calendar on the main https://saltproject.io website.
If you have additional questions, email us at saltproject@vmware.com or reach out directly to the Community Manager, Janae Andrus via Slack. We’d be glad to have you join our community!
License Salt is licensed under the Apache 2.0 license. Please see the LICENSE file for the full text of the Apache license, followed by a full summary of the licensing used by external modules.
A complete list of attributions and dependencies can be found here: salt/DEPENDENCIES.md
We’re not just talking about NaCl.
The 30 second summary Salt is:
• A configuration management system. Salt is capable of maintaining remote nodes in defined states. For example, it can ensure that specific packages are installed and that specific services are running.
• A distributed remote execution system used to execute commands and query data on remote nodes. Salt can query and execute commands either on individual nodes or by using an arbitrary selection criteria.
It was developed in order to bring the best solutions found in the world of remote execution together and make them better, faster, and more malleable. Salt accomplishes this through its ability to handle large loads of information, and not just dozens but hundreds and even thousands of individual servers quickly through a simple and manageable interface.
Simplicity Providing versatility between massive scale deployments and smaller systems may seem daunting, but Salt is very simple to set up and maintain, regardless of the size of the project. The architecture of Salt is designed to work with any number of servers, from a handful of local network systems to international deployments across different data centers. The topology is a simple server/client model with the needed functionality built into a single set of daemons. While the default configuration will work with little to no modification, Salt can be fine tuned to meet specific needs.
Parallel execution The core functions of Salt:
• enable commands to remote systems to be called in parallel rather than serially
• use a secure and encrypted protocol
• use the smallest and fastest network payloads possible
• provide a simple programming interface
Salt also introduces more granular controls to the realm of remote execution, allowing systems to be targeted not just by hostname, but also by system properties.
Builds on proven technology Salt takes advantage of a number of technologies and techniques. The networking layer is built with the excellent ZeroMQ networking library, so the Salt daemon includes a viable and transparent AMQ broker. Salt uses public keys for authentication with the master daemon, then uses faster AES encryption for payload communication; authentication and encryption are integral to Salt.  Salt takes advantage of communication via msgpack, enabling fast and light network traffic.
Python client interface In order to allow for simple expansion, Salt execution routines can be written as plain Python modules. The data collected from Salt executions can be sent back to the master server, or to any arbitrary program. Salt can be called from a simple Python API, or from the command line, so that Salt can be used to execute one-off commands as well as operate as an integral part of a larger application.
Fast, flexible, scalable The result is a system that can execute commands at high speed on target server groups ranging from one to very many servers. Salt is very fast, easy to set up, amazingly malleable and provides a single remote execution architecture that can manage the diverse requirements of any number of servers.  The Salt infrastructure brings together the best of the remote execution world, amplifies its capabilities and expands its range, resulting in a system that is as versatile as it is practical, suitable for any network.
Open Salt is developed under the Apache 2.0 license, and can be used for open and proprietary projects. Please submit your expansions back to the Salt project so that we can all benefit together as Salt grows.  Please feel free to sprinkle Salt around your systems and let the deliciousness come forth.
Salt Community Join the Salt!
There are many ways to participate in and communicate with the Salt community.
Salt has an active IRC channel and a mailing list.
Mailing List Join the salt-users mailing list. It is the best place to ask questions about Salt and see whats going on with Salt development! The Salt mailing list is hosted by Google Groups. It is open to new members.
Additionally, all users of Salt should be subscribed to the Announcements mailing list which contains important updates about Salt, such as new releaes and security-related announcements. This list is low-traffic.
IRC The #salt IRC channel is hosted on the popular LiberaChat network. You can use the LiberaChat webchat client right from your browser.  Logs of the IRC channel activity are also available.
If you wish to discuss the development of Salt itself join us in #salt-devel.
Follow on Github The Salt code is developed via Github. Follow Salt for constant updates on what is happening in Salt development:
https://github.com/saltstack/salt
Long-term planning and strategic decisions are handled via Salt Enhancement Proposals and can be found on GitHub.
Blogs SaltStack Inc. keeps a blog with recent news and advancements:
http://www.saltstack.com/blog/
Example Salt States The official salt-states repository is: https://github.com/SS-archive/salt-states
A few examples of salt states from the community:
• https://github.com/blast-hardcheese/blast-salt-states
• https://github.com/kevingranade/kevingranade-salt-state
• https://github.com/uggedal/states
• https://github.com/mattmcclean/salt-openstack/tree/master/salt
• https://github.com/rentalita/ubuntu-setup/
• https://github.com/brutasse/states
• https://github.com/bclermont/states
• https://github.com/pcrews/salt-data
Follow on Open Hub https://www.openhub.net/p/salt
Other community links • Salt Project
• Subreddit
• YouTube
• Facebook
• Twitter
• Wikipedia page
• Stack Overflow
Hack the Source If you want to get involved with the development of source code or the documentation efforts, please review the contributing documentation!
Overview This page provides a high-level overview of the Salt system architecture and its different components.
What is Salt? Salt is a Python-based open-source remote execution framework used for:
• Configuration management
• Automation
• Provisioning
• Orchestration
The Salt system architecture The following diagram shows the primary components of the basic Salt architecture: [image]
The following sections describe some of the core components of the Salt architecture.
Salt Masters and Salt Minions Salt uses the master-client model in which a master issues commands to a client and the client executes the command. In the Salt ecosystem, the Salt Master is a server that is running the salt-master service. It issues commands to one or more Salt Minions, which are servers that are running the salt-minion service and that are registered with that particular Salt Master.
Another way to describe Salt is as a publisher-subscriber model. The master publishes jobs that need to be executed and Salt Minions subscribe to those jobs. When a specific job applies to that minion, it will execute the job.
When a minion finishes executing a job, it sends job return data back to the master. Salt has two ports used by default for the minions to communicate with their master(s). These ports work in concert to receive and deliver data to the Message Bus. Salt’s message bus is ZeroMQ, which creates an asynchronous network topology to provide the fastest communication possible.
Targets and grains The master indicates which minions should execute the job by defining a target. A target is the group of minions, across one or many masters, that a job's Salt command applies to.
NOTE: A master can also be managed like a minion and can be a target if it is running the salt-minion service.
The following is an example of one of the many kinds of commands that a master might issue to a minion. This command indicates that all minions should install the Vim application:
salt -v '*' pkg.install vim
In this case the glob '*' is the target, which indicates that all minions should execute this command. Many other targeting options are available, including targeting a specific minion by its ID or targeting minions by their shared traits or characteristics (called grains in Salt).
Salt comes with an interface to derive information about the underlying system.  This is called the grains interface, because it presents Salt with grains of information. Grains are collected for the operating system, domain name, IP address, kernel, OS type, memory, and many other system properties. You can also create your own custom grain data.
Grain data is relatively static. However, grain data is refreshed when system information changes (such as network settings) or when a new value is assigned to a custom grain.
Open event system (event bus) The event system is used for inter-process communication between the Salt Master and Salt Minions. In the event system:
• Events are seen by both the master and minions.
• Events can be monitored and evaluated by both.
The event bus lays the groundwork for orchestration and real-time monitoring.
All minions see jobs and results by subscribing to events published on the event system. Salt uses a pluggable event system with two layers:
• ZeroMQ (0MQ) - The current default socket-level library providing a flexible transport layer.
• Tornado - Full TCP-based transport layer event system.
One of the greatest strengths of Salt is the speed of execution. The event system’s communication bus is more efficient than running a higher-level web service (http). The remote execution system is the component that all components are built upon, allowing for decentralized remote execution to spread load across resources.
Salt states In addition to remote execution, Salt provides another method for configuring minions by declaring which state a minion should be in, otherwise referred to as Salt states. Salt states make configuration management possible. You can use Salt states to deploy and manage infrastructure with simple YAML files.  Using states, you can automate recursive and predictable tasks by queueing jobs for Salt to implement without needing user input. You can also add more complex conditional logic to state files with Jinja.
To illustrate the subtle differences between remote execution and configuration management, take the command referenced in the previous section about Targets and grains in which Salt installed the application Vim on all minions:
┌─────────────────┬──────────────────────┬───────────────────────┐ │Methodology      │ Implementation       │ Result                │ ├─────────────────┼──────────────────────┼───────────────────────┤ │Remote execution │                      │                       │ │                 │        • Run salt -v │        • Remotely     │ │                 │          '*'         │          installs     │ │                 │          pkg.install │          Vim on the   │ │                 │          vim from    │          targeted     │ │                 │          the         │          minions      │ │                 │          terminal    │                       │ └─────────────────┴──────────────────────┴───────────────────────┘
│Configuration    │                      │                       │ │management       │        • Write a     │        • Ensures      │ │                 │          YAML state  │          that Vim is  │ │                 │          file that   │          always       │ │                 │          checks      │          installed    │ │                 │          whether Vim │          on the       │ │                 │          is          │          targeted     │ │                 │          installed   │          minions      │ │                 │                      │                       │ │                 │        • This state  │        • Salt         │ │                 │          file is     │          analyzes     │ │                 │          then        │          the state    │ │                 │          applied to  │          file and     │ │                 │          the         │          determines   │ │                 │          targeted    │          what         │ │                 │          minions     │          actions      │ │                 │                      │          need to be   │ │                 │                      │          taken to     │ │                 │                      │          ensure the   │ │                 │                      │          minion       │ │                 │                      │          complies     │ │                 │                      │          with the     │ │                 │                      │          state        │ │                 │                      │          declarations │ │                 │                      │                       │ │                 │                      │        • If Vim is    │ │                 │                      │          not          │ │                 │                      │          installed,   │ │                 │                      │          it           │ │                 │                      │          automates    │ │                 │                      │          the          │ │                 │                      │          processes    │ │                 │                      │          to install   │ │                 │                      │          Vim on the   │ │                 │                      │          targeted     │ │                 │                      │          minions      │ └─────────────────┴──────────────────────┴───────────────────────┘
The state file that verifies Vim is installed might look like the following example:
# File:/srv/salt/vim_install.sls
install_vim_now: pkg.installed: - pkgs: - vim
To apply this state to a minion, you would use the state.apply module, such as in the following example:
salt '*' state.apply vim_install
This command applies the vim_install state to all minions.
Formulas are collections of states that work in harmony to configure a minion or application. For example, one state might trigger another state.
The Top file It is not practical to manually run each state individually targeting specific minions each time. Some environments have hundreds of state files targeting thousands of minions.
Salt offers two features to help with this scaling problem:
• The top.sls file - Maps Salt states to their applicable minions.
• Highstate execution - Runs all Salt states outlined in top.sls in a single execution.
The top file maps which states should be applied to different minions in certain environments. The following is an example of a simple top file:
# File: /srv/salt/top.sls
base: '*': - all_server_setup
'01webserver': - web_server_setup
In this example, base refers to the Salt environment, which is the default.  You can specify more than one environment as needed, such as prod, dev, QA, etc.
Groups of minions are specified under the environment, and states are listed for each set of minions. This top file indicates that a state called all_server_setup should be applied to all minions '*' and the state called web_server_setup should be applied to the 01webserver minion.
To run the Salt command, you would use the state.highstate function:
salt \* state.highstate
This command applies the top file to the targeted minions.
Salt pillar Salt’s pillar feature takes data defined on the Salt Master and distributes it to minions as needed. Pillar is primarily used to store secrets or other highly sensitive data, such as account credentials, cryptographic keys, or passwords.  Pillar is also useful for storing non-secret data that you don't want to place directly in your state files, such as configuration data.
Salt pillar brings data into the cluster from the opposite direction as grains.  While grains are data generated from the minion, the pillar is data generated from the master.
Pillars are organized similarly to states in a Pillar state tree, where top.sls acts to coordinate pillar data to environments and minions privy to the data. Information transferred using pillar has a dictionary generated for the targeted minion and encrypted with that minion’s key for secure data transfer. Pillar data is encrypted on a per-minion basis, which makes it useful for storing sensitive data specific to a particular minion.
Beacons and reactors The beacon system is a monitoring tool that can listen for a variety of system processes on Salt Minions. Beacons can trigger reactors which can then help implement a change or troubleshoot an issue. For example, if a service’s response times out, the reactor system can restart the service.
Beacons are used for a variety of purposes, including:
• Automated reporting
• Error log delivery
• Microservice monitoring
• User shell activity
• Resource monitoring
When coupled with reactors, beacons can create automated pre-written responses to infrastructure and application issues. Reactors expand Salt with automated responses using pre-written remediation states.
Reactors can be applied in a variety of scenarios:
• Infrastructure scaling
• Notifying administrators
• Restarting failed applications
• Automatic rollback
When both beacons and reactors are used together , you can create unique states customized to your specific needs.
Salt runners and orchestration Salt runners are convenience applications executed with the salt-run command. Salt runners work similarly to Salt execution modules. However, they execute on the Salt Master instead of the Salt Minions. A Salt runner can be a simple client call or a complex application.
Salt provides the ability to orchestrate system administrative tasks throughout the enterprise. Orchestration makes it possible to coordinate the activities of multiple machines from a central place. It has the added advantage of being able to control the sequence of when certain configuration events occur.  Orchestration states execute on the master using the state runner module.
This section contains instructions to install Salt. If you are setting up your environment for the first time, you should install a Salt master on a dedicated management server or VM, and then install a Salt minion on each system that you want to manage using Salt. For now you don't need to worry about your architecture, you can easily add components and modify your configuration later without needing to reinstall anything.
The general installation process is as follows:
1. Install a Salt master using the instructions for your platform or by running the Salt bootstrap script. If you use the bootstrap script, be sure to include the -M option to install the Salt master.
2. Make sure that your Salt minions can find the Salt master.
3. Install the Salt minion on each system that you want to manage.
4. Accept the Salt minion keys after the Salt minion connects.
After this, you should be able to run a simple command and receive salt version returns from all connected Salt minions.
salt '*' test.version
Quick Install On most distributions, you can set up a Salt Minion with the Salt bootstrap.
Platform-specific Installation Instructions These guides go into detail how to install Salt on a given platform.
Arch Linux Installation Salt (stable) is currently available via the Arch Linux Official repositories.  There are currently -git packages available in the Arch User repositories (AUR) as well.
Stable Release Install Salt stable releases from the Arch Linux Official repositories as follows:
pacman -S salt
Tracking develop To install the bleeding edge version of Salt (may include bugs!), use the -git package. Installing the -git package as follows:
wget https://aur.archlinux.org/packages/sa/salt-git/salt-git.tar.gz tar xf salt-git.tar.gz cd salt-git/ makepkg -is
NOTE: yaourt
If a tool such as Yaourt is used, the dependencies will be gathered and built automatically.
The command to install salt using the yaourt tool is:
yaourt salt-git
Post-installation tasks systemd
Activate the Salt Master and/or Minion via systemctl as follows:
systemctl enable salt-master.service systemctl enable salt-minion.service
Start the Master
Once you've completed all of these steps you're ready to start your Salt Master. You should be able to start your Salt Master now using the command seen here:
systemctl start salt-master
Now go to the Configuring Salt page.
Debian GNU/Linux / Raspbian Debian GNU/Linux distribution and some derivatives such as Raspbian already have included Salt packages to their repositories. However, current stable Debian release contains old outdated Salt releases. It is recommended to use SaltStack repository for Debian as described below.
Installation from official Debian and Raspbian repositories is described here.
Installation from the Official SaltStack Repository Packages for Debian 10 (Buster) and Debian 9 (Stretch) are available in the Official SaltStack repository.
Instructions are at https://repo.saltproject.io/#debian.
NOTE: Archived builds from unsupported branches:
• Archive 1
• Archive 2
If looking to use archives, the same directions from the Debian install directions can be used by replacing the URL paths with the appropriate archive location. The repository configuration endpoint also needs to be adjusted to point to the archives. Here is an example sed command:
# Salt repo configurations are found in the /etc/apt/sources.list.d/salt.list directory sed -i 's/repo.saltproject.io/archive.repo.saltproject.io/g' /etc/apt/sources.list.d/salt.list
WARNING: Regular security support for Debian 8 ended on June 30th 2018. As a result, 3000.3 and 2019.2.5 will be the last Salt releases for which Debian 8 packages are created. Debian 8 also reached LTS EOL on June 30 2020.
Regular security support for Debian 7 ended on April 25th 2016. As a result, 2016.3.1 and 2015.8.10 will be the last Salt releases for which Debian 7 packages are created. Debian 7 also reached LTS EOL on May 31 2018.
Installation from the Debian / Raspbian Official Repository The Debian distributions contain mostly old Salt packages built by the Debian Salt Team. You can install Salt components directly from Debian but it is recommended to use the instructions above for the packages from the official Salt repository.
On Jessie there is an option to install Salt minion from Stretch with python-tornado dependency from jessie-backports repositories.
To install fresh release of Salt minion on Jessie:
1. Add jessie-backports and stretch repositories:
Debian:
echo 'deb http://httpredir.debian.org/debian jessie-backports main' >> /etc/apt/sources.list echo 'deb http://httpredir.debian.org/debian stretch main' >> /etc/apt/sources.list
Raspbian:
echo 'deb http://archive.raspbian.org/raspbian/ stretch main' >> /etc/apt/sources.list
2. Make Jessie a default release:
echo 'APT::Default-Release "jessie";' > /etc/apt/apt.conf.d/10apt
3. Install Salt dependencies:
apt-get update apt-get install python-zmq python-systemd/jessie-backports python-tornado/jessie-backports salt-common/stretch
apt-get update apt-get install python-zmq python-tornado/stretch salt-common/stretch
4. Install Salt minion package from Latest Debian Release:
apt-get install salt-minion/stretch
Install Packages Install the Salt master, minion or other packages from the repository with the apt-get command. These examples each install one of Salt components, but more than one package name may be given at a time:
• apt-get install salt-api