Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP
Browse files

Fixed several minor misspellings and acronym capitalizations.

  • Loading branch information...
commit bd499e564014aa113a92fa44688fbf793373bdd2 1 parent 8c39c17
@gdub gdub authored
Showing with 149 additions and 149 deletions.
  1. +2 −2 doc/index.rst
  2. +1 −1  doc/ref/cli/salt.rst
  3. +2 −2 doc/ref/clientacl.rst
  4. +6 −6 doc/ref/configuration/master.rst
  5. +6 −6 doc/ref/configuration/minion.rst
  6. +1 −1  doc/ref/file_server/index.rst
  7. +2 −2 doc/ref/index.rst
  8. +1 −1  doc/ref/modules/all/salt.modules.yumpkg.rst
  9. +1 −1  doc/ref/modules/index.rst
  10. +2 −2 doc/ref/python-api.rst
  11. +6 −6 doc/ref/renderers/all/salt.renderers.stateconf.rst
  12. +3 −3 doc/ref/renderers/index.rst
  13. +1 −1  doc/ref/returners/index.rst
  14. +4 −4 doc/ref/states/index.rst
  15. +3 −3 doc/ref/states/requisites.rst
  16. +1 −1  doc/ref/states/writing.rst
  17. +1 −1  doc/ref/syndic.rst
  18. +3 −3 doc/ref/topology.rst
  19. +3 −3 doc/ref/windows-package-manager.rst
  20. +4 −4 doc/topics/development/package_providers.rst
  21. +1 −1  doc/topics/eauth/access_control.rst
  22. +1 −1  doc/topics/event/index.rst
  23. +1 −1  doc/topics/git/index.rst
  24. +2 −2 doc/topics/index.rst
  25. +2 −2 doc/topics/installation/rhel.rst
  26. +2 −2 doc/topics/installation/solaris.rst
  27. +3 −3 doc/topics/reactor/index.rst
  28. +2 −2 doc/topics/releases/0.10.0.rst
  29. +2 −2 doc/topics/releases/0.10.2.rst
  30. +1 −1  doc/topics/releases/0.10.4.rst
  31. +4 −4 doc/topics/releases/0.10.5.rst
  32. +1 −1  doc/topics/releases/0.11.0.rst
  33. +2 −2 doc/topics/releases/0.12.0.rst
  34. +3 −3 doc/topics/releases/0.13.0.rst
  35. +7 −7 doc/topics/releases/0.6.0.rst
  36. +2 −2 doc/topics/releases/0.7.0.rst
  37. +3 −3 doc/topics/releases/0.8.0.rst
  38. +2 −2 doc/topics/releases/0.8.7.rst
  39. +7 −7 doc/topics/releases/0.8.8.rst
  40. +3 −3 doc/topics/releases/0.8.9.rst
  41. +3 −3 doc/topics/releases/0.9.0.rst
  42. +1 −1  doc/topics/releases/0.9.2.rst
  43. +4 −4 doc/topics/releases/0.9.3.rst
  44. +1 −1  doc/topics/releases/0.9.4.rst
  45. +5 −5 doc/topics/releases/0.9.5.rst
  46. +2 −2 doc/topics/releases/0.9.6.rst
  47. +5 −5 doc/topics/releases/0.9.8.rst
  48. +1 −1  doc/topics/releases/0.9.9.rst
  49. +1 −1  doc/topics/targeting/nodegroups.rst
  50. +1 −1  doc/topics/troubleshooting/index.rst
  51. +1 −1  doc/topics/troubleshooting/yaml_idiosyncrasies.rst
  52. +1 −1  doc/topics/tutorials/gitfs.rst
  53. +3 −3 doc/topics/tutorials/pillar.rst
  54. +2 −2 doc/topics/tutorials/starting_states.rst
  55. +2 −2 doc/topics/tutorials/states_pt1.rst
  56. +12 −12 doc/topics/tutorials/walkthrough.rst
View
4 doc/index.rst
@@ -15,7 +15,7 @@ for orchestration, remote execution, configuration management and much more.
Download
========
-Salt source releases are available for download via pypi:
+Salt source releases are available for download via PyPI:
https://pypi.python.org/pypi/salt
@@ -201,7 +201,7 @@ Salt is many splendid things.
Looking for an easy way to manage software on Windows machines?
Search no more! Salt has an integrated software package manager for
Windows machines! Install software hosted on the master, somewhere on the
- network, or any http, https, or ftp server.
+ network, or any HTTP, HTTPS, or ftp server.
Reference
---------
View
2  doc/ref/cli/salt.rst
@@ -32,7 +32,7 @@ Options
.. option:: -t TIMEOUT, --timeout=TIMEOUT
The timeout in seconds to wait for replies from the Salt minions. The
- timeout number specifes how long the command line client will wait to
+ timeout number specifies how long the command line client will wait to
query the minions and check on running jobs.
.. option:: -s, --static
View
4 doc/ref/clientacl.rst
@@ -2,10 +2,10 @@
Client ACL system
=================
-The salt client acl system is a means to allow system users other than root to
+The salt client ACL system is a means to allow system users other than root to
have access to execute select salt commands on minions from the master.
-The client acl system is configured in the master configuration file via the
+The client ACL system is configured in the master configuration file via the
``client_acl`` configuration option. Under the ``client_acl`` configuration
option the users open to send commands are specified and then a list of regular
expressions which specify the minion functions which will be made available to
View
12 doc/ref/configuration/master.rst
@@ -72,7 +72,7 @@ seeing on the console(and then salt-master crashes)::
Too many open files (tcp_listener.cpp:335)
Aborted (core dumped)
-By default this value will be the one of `ulimit -Hn`, ie, the hard limit for
+By default this value will be the one of `ulimit -Hn`, i.e., the hard limit for
max open files.
If you wish to set a different value than the default one, uncomment and
@@ -409,7 +409,7 @@ at the moment a single state fails
Default:: ``False``
-Set all state calls to only test if they are going to acctually make changes
+Set all state calls to only test if they are going to actually make changes
or just post what changes are going to be made
.. code-block:: yaml
@@ -426,7 +426,7 @@ Master File Server Settings
Default: ``base: [/srv/salt]``
-Salt runs a lightweight file server written in zeromq to deliver files to
+Salt runs a lightweight file server written in ZeroMQ to deliver files to
minions. This file server is built into the master daemon and does not
require a dedicated port.
@@ -706,7 +706,7 @@ One of 'garbage', 'trace', 'debug', info', 'warning', 'error', 'critical'.
Default: ``%H:%M:%S``
-The date and time format used in console log messages. Allowed date/time formating
+The date and time format used in console log messages. Allowed date/time formatting
can be seen on http://docs.python.org/library/time.html#time.strftime
.. code-block:: yaml
@@ -720,7 +720,7 @@ can be seen on http://docs.python.org/library/time.html#time.strftime
Default: ``%Y-%m-%d %H:%M:%S``
-The date and time format used in log file messages. Allowed date/time formating
+The date and time format used in log file messages. Allowed date/time formatting
can be seen on http://docs.python.org/library/time.html#time.strftime
.. code-block:: yaml
@@ -762,7 +762,7 @@ be seen on http://docs.python.org/library/logging.html#logrecord-attributes
Default: ``{}``
-This can be used to control logging levels more specificically. The
+This can be used to control logging levels more specifically. The
example sets the main salt library at the 'warning' level, but sets
'salt.modules' to log at the 'debug' level:
View
12 doc/ref/configuration/minion.rst
@@ -180,7 +180,7 @@ executed. By default this feature is disabled, to enable set cache_jobs to
Default: ``/var/run/salt/minion``
-The directory where unix sockets will be kept.
+The directory where Unix sockets will be kept.
.. code-block:: yaml
@@ -235,7 +235,7 @@ environment, set this value to ``False``.
Default: ``ipc``
-Windows platforms lack posix IPC and must rely on slower TCP based inter-
+Windows platforms lack POSIX IPC and must rely on slower TCP based inter-
process communications. Set ipc_mode to ``tcp`` on such systems.
.. code-block:: yaml
@@ -450,7 +450,7 @@ Default: ``True``
autoload_dynamic_modules Turns on automatic loading of modules found in the
environments on the master. This is turned on by default, to turn of
-autoloading modules when states run set this value to ``False``
+auto-loading modules when states run set this value to ``False``
.. code-block:: yaml
@@ -579,7 +579,7 @@ One of 'garbage', 'trace', 'debug', info', 'warning', 'error', 'critical'.
Default: ``%H:%M:%S``
-The date and time format used in console log messages. Allowed date/time formating
+The date and time format used in console log messages. Allowed date/time formatting
can be seen on http://docs.python.org/library/time.html#time.strftime
.. code-block:: yaml
@@ -593,7 +593,7 @@ can be seen on http://docs.python.org/library/time.html#time.strftime
Default: ``%Y-%m-%d %H:%M:%S``
-The date and time format used in log file messages. Allowed date/time formating
+The date and time format used in log file messages. Allowed date/time formatting
can be seen on http://docs.python.org/library/time.html#time.strftime
.. code-block:: yaml
@@ -635,7 +635,7 @@ be seen on http://docs.python.org/library/logging.html#logrecord-attributes
Default: ``{}``
-This can be used to control logging levels more specificically. This
+This can be used to control logging levels more specifically. This
example sets the main salt library at the 'warning' level, but sets
'salt.modules' to log at the 'debug' level:
View
2  doc/ref/file_server/index.rst
@@ -46,7 +46,7 @@ like so:
# salt '*' cp.get_file "salt://{{grains.os}}/vimrc" /etc/vimrc template=jinja
This example would instruct all Salt minions to download the vimrc from a
-directory with the same name as their os grain and copy it to /etc/vimrc
+directory with the same name as their OS grain and copy it to /etc/vimrc
For larger files, the cp.get_file module also supports gzip compression.
Because gzip is CPU-intensive, this should only be used in
View
4 doc/ref/index.rst
@@ -15,7 +15,7 @@ Client API
----------
The primary interface used to extend Salt, is to simply use it. Salt executions
-can be called via the Salt client api, making programming master side solutions
+can be called via the Salt client API, making programming master side solutions
with Salt is easy.
Adding Loadable Plugins
@@ -70,7 +70,7 @@ Renderers
`````````
Salt states are controlled by simple data structures, these structures can be
-abstracted in a number of ways. While the default is to be in a yaml file
+abstracted in a number of ways. While the default is to be in a YAML file
wrapped in a jinja template, any abstraction can be used. This means that any
format that can be dreamed is possible, so long as a renderer is written for
it.
View
2  doc/ref/modules/all/salt.modules.yumpkg.rst
@@ -4,7 +4,7 @@ salt.modules.yumpkg
.. versionadded:: 0.9.4
This module replaces the "yum" module in previous releases. It is backward
- compatibile and uses the native yum Python interface instead of the CLI
+ compatible and uses the native yum Python interface instead of the CLI
interface.
.. automodule:: salt.modules.yumpkg
View
2  doc/ref/modules/index.rst
@@ -171,7 +171,7 @@ documentation for all available modules:
salt '*' sys.doc
This function simple prints out the docstrings found in the modules, when
-writing Salt modules, please follow the formating conventions for docstrings as
+writing Salt modules, please follow the formatting conventions for docstrings as
they appear in the other modules.
Adding Documentation to Salt Modules
View
4 doc/ref/python-api.rst
@@ -9,7 +9,7 @@ built directly into third party applications as a communication layer. The Salt
client API is very straightforward.
A number of client command methods are available depending on the exact
-behaviour desired.
+behavior desired.
Using the LocalClient API
=========================
@@ -38,7 +38,7 @@ same interface used by the ``salt`` command line tool.
The tgt option is the target specification, by default a target is passed
in as a bash shell glob. The expr_form option allows the tgt to be passed
- as either a pcre regular expression or as a Python list.
+ as either a PCRE regular expression or as a Python list.
.. cmdoption:: fun
View
12 doc/ref/renderers/all/salt.renderers.stateconf.rst
@@ -9,7 +9,7 @@ salt.renderers.stateconf
:platform: all
This module provides a custom renderer that process a salt file with a
-specified templating engine(eg, jinja) and a chosen data renderer(eg, yaml),
+specified templating engine(e.g., Jinja) and a chosen data renderer(e.g., YAML),
extract arguments for any ``stateconf.set`` state and provide the extracted
arguments (including salt specific args, such as 'require', etc) as template
context. The goal is to make writing reusable/configurable/ parameterized
@@ -48,7 +48,7 @@ Here's a list of features enabled by this renderer.
The leading dot trick can be used with extending state ids as well,
so you can include relatively and extend relatively. For example, when
- extending a state in `salt://some/other_file.sls`, eg,::
+ extending a state in `salt://some/other_file.sls`, e.g.,::
#!stateconf yaml . jinja
@@ -75,7 +75,7 @@ Here's a list of features enabled by this renderer.
reference templates files used by your salt file.
- Recognizes the special state function, ``stateconf.set``, that configures a
- default list of named arguments useable within the template context of
+ default list of named arguments usable within the template context of
the salt file. Example::
#!stateconf yaml . jinja
@@ -174,7 +174,7 @@ Here's a list of features enabled by this renderer.
- Optionally(enabled by default, *disable* via the `-G` renderer option,
- eg, in the shebang line: ``#!stateconf -G``), generates a
+ e.g., in the shebang line: ``#!stateconf -G``), generates a
``stateconf.set`` goal state(state id named as ``.goal`` by default,
configurable via the master/minion config option, ``stateconf_goal_state``)
that requires all other states in the salt file. Note, the ``.goal``
@@ -186,7 +186,7 @@ Here's a list of features enabled by this renderer.
all states in the Tomcat sls file will be executed before some state in
the webapp sls file.
-- Optionally(enable via the `-o` renderer option, eg, in the shebang line:
+- Optionally(enable via the `-o` renderer option, e.g., in the shebang line:
``#!stateconf -o``), orders the states in a sls file by adding a
``require`` requisite to each state such that every state requires the
state defined just before it. The order of the states here is the order
@@ -202,7 +202,7 @@ Here's a list of features enabled by this renderer.
there are many states defined in a sls file, then it tends to be easier
to see the order they will be executed with this feature.
- You are still allowed to use all the requisites, with a few restricitons.
+ You are still allowed to use all the requisites, with a few restrictions.
You cannot ``require`` or ``watch`` a state defined *after* the current
state. Similarly, in a state, you cannot ``require_in`` or ``watch_in``
a state defined *before* it. Breaking any of the two restrictions above
View
6 doc/ref/renderers/index.rst
@@ -14,7 +14,7 @@ the SLS files can be any structured format that can be dreamed up.
Currently there is support for ``Jinja + YAML``, ``Mako + YAML``,
``Wempy + YAML``, ``Jinja + json`` ``Mako + json`` and ``Wempy + json``. But
renderers can be written to support anything. This means that the Salt states
-could be managed by xml files, html files, puppet files, or any format that
+could be managed by XML files, HTML files, puppet files, or any format that
can be translated into the data structure used by the state system.
Multiple Renderers
@@ -49,7 +49,7 @@ Composing Renderers
-------------------
A renderer can be composed from other renderers by connecting them in a series
of pipes(``|``). In fact, the default ``Jinja + YAML`` renderer is implemented
-by combining a yaml renderer and a jinja renderer. Such renderer configuration
+by combining a YAML renderer and a Jinja renderer. Such renderer configuration
is specified as: ``jinja | yaml``.
Other renderer combinations are possible, here's a few examples:
@@ -63,7 +63,7 @@ Other renderer combinations are possible, here's a few examples:
``jinja | mako | yaml``
This one allows you to use both jinja and mako templating syntax in the
- input and then parse the final rendererd output as YAML.
+ input and then parse the final rendered output as YAML.
And here's a contrived example sls file using the ``jinja | mako | yaml`` renderer:
View
2  doc/ref/returners/index.rst
@@ -59,7 +59,7 @@ A simple returner is implemented here:
'''
Return information to a redis server
'''
- # Get a redis commection
+ # Get a redis connection
serv = redis.Redis(
host='redis-serv.example.com',
port=6379,
View
8 doc/ref/states/index.rst
@@ -91,9 +91,9 @@ SLS Files
The Salt state files are simple sets of data. Since the SLS files are just data
they can be represented in a number of different ways. The default format is
-yaml generated from a jinja template. This allows for the states files to have
+yaml generated from a Jinja template. This allows for the states files to have
all the language constructs of Python and the simplicity of yaml. State files
-can then be complicated jinja templates that translate down to yaml, or just
+can then be complicated Jinja templates that translate down to yaml, or just
plain and simple yaml files!
The State files are constructed data structures in a simple format. The format
@@ -179,9 +179,9 @@ source code:
:blob:`salt/renderers`
-By default SLS files are rendered using jinja as a templating engine, and yaml
+By default SLS files are rendered using Jinja as a templating engine, and yaml
as the serialization format. Since the rendering system can be extended simply
by adding a new renderer to the renderers directory, it is possible that any
structured file could be used to represent the SLS files.
-In the future xml and raw Python will be added, as well as many other formats.
+In the future XML and raw Python will be added, as well as many other formats.
View
6 doc/ref/states/requisites.rst
@@ -4,7 +4,7 @@ Requisites
The Salt requisite system is used to create relationships between states. The
core idea being, that when one state it dependent somehow on another that
-interdependency can be easily defined.
+inter-dependency can be easily defined.
Requisites come in two types. Direct requisites, and requisite_ins. The
relationships are directional, so a requisite statement makes the requiring
@@ -133,8 +133,8 @@ Using ``require_in``
- running
The ``require_in`` statement is particularly useful when assigning a require
-in a sperate sls file. For instance it may be common for httpd to require
-components used to set up php or mod_python, but the http state does not need
+in a separate sls file. For instance it may be common for httpd to require
+components used to set up PHP or mod_python, but the HTTP state does not need
to be aware of the additional components that require it when it is set up:
http.sls
View
2  doc/ref/states/writing.rst
@@ -17,7 +17,7 @@ illustrate:
.. code-block:: yaml
/etc/salt/master: # maps to "name"
- file: # maps to State module filename eg https://github.com/saltstack/salt/blob/develop/salt/states/file.py
+ file: # maps to State module filename e.g. https://github.com/saltstack/salt/blob/develop/salt/states/file.py
- managed # maps to the managed function in the file State module
- user: root # one of many options passed to the manage function
- group: root
View
2  doc/ref/syndic.rst
@@ -19,7 +19,7 @@ Configuring the Syndic
Since the Syndic only needs to be attached to a higher level master the
configuration is very simple. On a master that is running a syndic to connect
to a higher level master the syndic_master option needs to be set in the
-master config file. The syndic_master option contains the hostname or ip
+master config file. The syndic_master option contains the hostname or IP
address of the master server that can control the master that the syndic is
running on.
View
6 doc/ref/topology.rst
@@ -13,7 +13,7 @@ The Salt Master runs 2 network services. First is the ZeroMQ PUB system. This
service by default runs on port ``4505`` and can be configured via the
``publish_port`` option in the master configuration.
-Second is the ZeroMQ REP system. This is a seperate interface used for all
+Second is the ZeroMQ REP system. This is a separate interface used for all
bi-directional communication with minions. By default this system binds to
port ``4506`` and can be configured via the ``ret_port`` option in the master.
@@ -22,8 +22,8 @@ PUB/SUB
The commands sent out via the salt client are broadcast out to the minions via
ZeroMQ PUB/SUB. This is done by allowing the minions to maintain a connection
-back to the Salt Master and then all connecions are informed to download the
-command data at once. The command data is kept extreamly small (usually less
+back to the Salt Master and then all connections are informed to download the
+command data at once. The command data is kept extremely small (usually less
than 1K) so it is not a burden on the network.
Return
View
6 doc/ref/windows-package-manager.rst
@@ -8,7 +8,7 @@ repository similar to what is provided by yum and apt on Linux.
By default, the Windows software repository is found at ``/srv/salt/win/repo``
Each piece of software should have its own directory which contains the
installers and a package definition file. This package definition file is a
-yaml file named ``init.sls``.
+YAML file named ``init.sls``.
The package definition file should look similar to this example for Firefox:
``/srv/salt/win/repo/firefox/init.sls``
@@ -41,7 +41,7 @@ The package definition file should look similar to this example for Firefox:
uninstaller: '%ProgramFiles(x86)%/Mozilla Firefox/uninstall/helper.exe'
uninstall_flags: ' /S'
-Add ``msiexec: True`` if using an msi installer requiring the use of ``msiexec
+Add ``msiexec: True`` if using an MSI installer requiring the use of ``msiexec
/i`` to install and ``msiexec /x`` to uninstall.
``/srv/salt/win/repo/7zip/init.sls``
@@ -121,7 +121,7 @@ Git Hosted Repo
Windows software package definitions can also be hosted in one or more git
repositories. The default repo is one hosted on Github.com by SaltStack, which
includes package definitions for open source software. This repo points to the
-http or ftp locations of the installer files. Anyone is welcome to send a pull
+HTTP or ftp locations of the installer files. Anyone is welcome to send a pull
request to this repo to add new package definitions. Browse the repo
here: `https://github.com/saltstack/salt-winrepo
<https://github.com/saltstack/salt-winrepo>`_ .
View
8 doc/topics/development/package_providers.rst
@@ -61,7 +61,7 @@ This function must also accept ``**kwargs``, in order to receive the
``fromrepo`` and ``repo`` keyword arguments from pkg states. Where supported,
these arguments should be used to find the install/upgrade candidate in the
specified repository. The ``fromrepo`` kwarg takes precedence over ``repo``, so
-if both of those kwargs are present, the repository specifed in ``fromrepo``
+if both of those kwargs are present, the repository specified in ``fromrepo``
should be used. However, if ``repo`` is used instead of ``fromrepo``, it should
still work, to preserve backwards compatibility with older versions of Salt.
@@ -131,7 +131,7 @@ done:
dictionary values will be the path/URI for the package.
-The second return value will be a string with two possbile values:
+The second return value will be a string with two possible values:
``repository`` or ``file``. The :strong:`install` function can use this value
(if necessary) to build the proper command to install the targeted package(s).
@@ -216,7 +216,7 @@ success.
mod_repo
^^^^^^^^
-Modify the local configuration for one or more option for a conifigured repo.
+Modify the local configuration for one or more option for a configured repo.
This is also the way to create new repository configuration on the local
system; if a repo is specified which does not yet exist, it will be created.
@@ -247,7 +247,7 @@ function that requires that technique must still use the ``lowpkg`` version.
list_pkgs
^^^^^^^^^
Returns a dict of packages installed, including the package name and version.
-Can accept a list of packages; if none are spcified, then all installed
+Can accept a list of packages; if none are specified, then all installed
packages will be listed.
.. code-block:: python
View
2  doc/topics/eauth/access_control.rst
@@ -17,7 +17,7 @@ all of the three aforementioned systems. While this adds functionality to the
configuration in 0.10.4, it does not negate the old configuration.
Now specific functions can be opened up to specific minions from specific users
-in the case of external auth and client acls, and for specific minions in the
+in the case of external auth and client ACLs, and for specific minions in the
case of the peer system.
The access controls are manifested using matchers in these configurations:
View
2  doc/topics/event/index.rst
@@ -16,7 +16,7 @@ Listening for Events
The event system is accessed via the event library and can only be accessed
by the same system user that Salt is running as. To listen to events a
SaltEvent object needs to be created and then the get_event function needs to
-be run. The SaltEvent object needs to know the location that the Salt unix
+be run. The SaltEvent object needs to know the location that the Salt Unix
sockets are kept. In the configuration this is the ``sock_dir`` option. The
``sock_dir`` option defaults to "/var/run/salt/master" on most systems.
View
2  doc/topics/git/index.rst
@@ -74,4 +74,4 @@ if there is a security fix they can be made sooner.
The point release is only designated by tagging the commit on the release
branch with release number using the existing convention (version 0.11.1 is
tagged with v0.11.1). From the tag point a new source tarball is generated
-and published to Pypi, and a release announcement is made.
+and published to PyPI, and a release announcement is made.
View
4 doc/topics/index.rst
@@ -90,10 +90,10 @@ versatile as it is practical, suitable for any network.
Open
====
-Salt is developed under the `Apache 2.0 licence`_, and can be used for
+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.
-.. _`Apache 2.0 licence`: http://www.apache.org/licenses/LICENSE-2.0.html
+.. _`Apache 2.0 license`: http://www.apache.org/licenses/LICENSE-2.0.html
View
4 doc/topics/installation/rhel.rst
@@ -9,7 +9,7 @@ Installation
============
Salt and all dependencies have been accepted into the yum
-reposities for EPEL5 and EPEL6. The latest salt version can be found in epel-testing, while an older but more tested version can be found in regular epel.
+repositories for EPEL5 and EPEL6. The latest salt version can be found in epel-testing, while an older but more tested version can be found in regular epel.
Example showing how to install salt from epel-testing:
@@ -17,7 +17,7 @@ Example showing how to install salt from epel-testing:
yum --enablerepo=epel-testing install salt-minion
-On RHEL6, the proper jinja package 'python-jinja2' was moved from EPEL to the
+On RHEL6, the proper Jinja package 'python-jinja2' was moved from EPEL to the
"RHEL Server Optional Channel". Verify this repository is enabled before
installing salt on RHEL6.
View
4 doc/topics/installation/solaris.rst
@@ -12,7 +12,7 @@ starts up successfully on Solaris 10.
Comments and patches for better support on these platforms is very welcome.
-As of version 0.10.4, solaris is well supported under salt, with all of the
+As of version 0.10.4, Solaris is well supported under salt, with all of the
following working well:
1. remote execution
@@ -61,7 +61,7 @@ Once pkgutil is installed you'll need to edit it's config file
- #mirror=http://mirror.opencsw.org/opencsw/testing
+ mirror=http://mirror.opencsw.org/opencsw/unstable
-Ok, time to install salt.
+OK, time to install salt.
.. code-block:: bash
View
6 doc/topics/reactor/index.rst
@@ -46,7 +46,7 @@ with lists of reactor sls formulas (globs can be used for matching):
When an event with a tag of auth is fired the reactor will catch the event and
render the two listed files. The rendered files are standard sls files, so by
-default they are yaml + jinja. The jinja is packed with a few data structures
+default they are yaml + Jinja. The Jinja is packed with a few data structures
similar to state and pillar sls files. The data available is found in the `tag`
and `data` variables. The `tag` variable is just the tag in the fired event
and the `data` variable is the event's data dict. Here is a simple reactor sls:
@@ -59,11 +59,11 @@ and the `data` variable is the event's data dict. Here is a simple reactor sls:
- tgt: mysql1
{% endif %}
-This simple reactor file uses jinja to further refine the reaction to be made.
+This simple reactor file uses Jinja to further refine the reaction to be made.
If the `id` in the event data is mysql1 (if the name of the minion is mysql1) then
the following reaction is defined. The same data structure and compiler used
for the state system is used for the reactor system. The only difference is that the
-data is matched up to the salt command api and the runner system. In this
+data is matched up to the salt command API and the runner system. In this
example a command is published to the mysql1 minion with a function of
state.highstate. Similarly, a runner can be called:
View
4 doc/topics/releases/0.10.0.rst
@@ -18,7 +18,7 @@ Event System
The Salt Master now comes equipped with a new event system. This event system
has replaced some of the back end of the Salt client and offers the beginning of
a system which will make plugging external applications into Salt. The event
-system relies on a local zeromq publish socket and other processes can connect
+system relies on a local ZeroMQ publish socket and other processes can connect
to this socket and listen for events. The new events can be easily managed via
Salt's event library.
@@ -43,7 +43,7 @@ YAML Parsing Updates
--------------------
In the past the YAML parser for sls files would return the incorrect numbers
-when the file mode was set with a preceding 0. The yaml parser used in Salt
+when the file mode was set with a preceding 0. The YAML parser used in Salt
has been modified to no longer convert these number into octal but to keep
them as the correct value so that sls files can be a little cleaner to write.
View
4 doc/topics/releases/0.10.2.rst
@@ -6,7 +6,7 @@ Salt 0.10.2 Release Notes
cleaner ways to access the salt-call capabilities in the API, minion data
caching and the event system has been added to salt minions.
-There have also been updates to the zeromq functions, many more tests
+There have also been updates to the ZeroMQ functions, many more tests
(thanks to sponsors, the code sprint and many contributors) and a swath
of bug fixes.
@@ -99,7 +99,7 @@ OpenBSD.
SQL Modules
^^^^^^^^^^^
-The MySQL and Postgres modules have both received a number of additions thanks
+The MySQL and PostgreSQL modules have both received a number of additions thanks
to the work of Avi Marcus and Roman Imankulov.
ZFS Support on FreeBSD
View
2  doc/topics/releases/0.10.4.rst
@@ -47,7 +47,7 @@ Access Control System
All Salt systems can now be configured to grant access to non-administrative
users in a granular way. The old configuration continues to work. Specific
functions can be opened up to specific minions from specific users in the case
-of external auth and client acls, and for specific minions in the case of the
+of external auth and client ACLs, and for specific minions in the case of the
peer system.
Access controls are configured like this:
View
8 doc/topics/releases/0.10.5.rst
@@ -50,7 +50,7 @@ A new API was added to the Salt Master which allows the master to be managed
via an external API. This new system allows Salt API to easily hook into the
Salt Master and manage configs, modify the state tree, manage the pillar and
more. The main motivation for the wheel system is to enable features needed
-in the upcoming web ui so users can manage the master just as easily as they
+in the upcoming web UI so users can manage the master just as easily as they
manage minions.
The wheel system has also been hooked into the external auth system. This
@@ -64,17 +64,17 @@ Jack Kuan has added a substantial new feature. The render pipes system allows
Salt to treat the render system like unix pipes. This new system enables sls
files to be passed through specific render engines. While the default renderer
is still recommended, different engines can now be more easily merged. So to
-pipe the output of mako used in YAML use this shebang line:
+pipe the output of Mako used in YAML use this shebang line:
#!mako|yaml
Salt Key Overhaul
-----------------
-The Salt Key system was originally developed as only a cli interface, but as
+The Salt Key system was originally developed as only a CLI interface, but as
time went on it was pressed into becoming a clumsy API. This release marks a
complete overhaul of Salt Key. Salt Key has been rewritten to function purely
-from an api and to use the outputter system. The benefit here is that the
+from an API and to use the outputter system. The benefit here is that the
outputter system works much more cleanly with Salt Key now, and the internals
of Salt Key can be used much more cleanly.
View
2  doc/topics/releases/0.11.0.rst
@@ -34,7 +34,7 @@ can respond to events within a salted environment. The reactor system uses sls
files to match events fired on the master with actions, enabling Salt
to react to problems in an infrastructure.
-Your load-balanced group of webservers is under extra load? Spin up a new vm
+Your load-balanced group of webservers is under extra load? Spin up a new VM
and add it to the group. Your fileserver is filling up? Send a notification to
your sysadmin on call. The possibilities are endless!
View
4 doc/topics/releases/0.12.0.rst
@@ -33,13 +33,13 @@ systems. Software on Windows can now be managed in the same way. The SaltStack
team built a package manager that interfaces with the standard Salt pkg module
to allow for installing and removing software on Windows. In addition, a
software package repository has been built on top of the Salt fileserver. A
-small yaml file provides the information necessary for the package manager to
+small YAML file provides the information necessary for the package manager to
install and remove software.
An interesting feature of the new Salt Windows software package repository is
that one or more remote git repositories can supplement the master's local
repository. The repository can point to software on the master's fileserver or
-on an http, https, or ftp server.
+on an HTTP, HTTPS, or ftp server.
New Default Outputter
---------------------
View
6 doc/topics/releases/0.13.0.rst
@@ -2,7 +2,7 @@
Salt 0.13.0 Release Notes
=========================
-The lucky number 13 has turned the corner! From cli notifications when quitting
+The lucky number 13 has turned the corner! From CLI notifications when quitting
a salt command, to substantial improvements on Windows, Salt 0.13.0 has
arrived!
@@ -63,8 +63,8 @@ remote executions to also quit. Now a message is displayed showing what
command can be used to track the execution and what the job id is for the
execution.
-Version Specification in Muliple-Package States
------------------------------------------------
+Version Specification in Multiple-Package States
+------------------------------------------------
Versions can now be specified within multiple-package :mod:`pkg.installed
<salt.states.pkg.installed>` states. An example can be found below:
View
14 doc/topics/releases/0.6.0.rst
@@ -16,15 +16,15 @@ setup and use, the entire application is contained in a single package, and the
master and minion daemons require no running dependencies in the way that Func
requires Certmaster and MCollective requires activeMQ.
-Salt also manages authentication and encryption. Rather than using ssl for
+Salt also manages authentication and encryption. Rather than using SSL for
encryption, salt manages encryption on a payload level, so the data sent across
-the network is encrypted with fast aes encryption, and authentication uses RSA
+the network is encrypted with fast AES encryption, and authentication uses RSA
keys. This means that Salt is fast, secure, and very efficient.
-Messaging in Salt is executed with zeromq, so the message passing interface is
-built into salt and does not require an external MQ server. This also adds
+Messaging in Salt is executed with ZeroMQ, so the message passing interface is
+built into salt and does not require an external ZeroMQ server. This also adds
speed to Salt since there is no additional bloat on the networking layer, and
-zeromq has already proven itself as a very fast networking system.
+ZeroMQ has already proven itself as a very fast networking system.
The remote execution in Salt is "Lazy Execution", in that once the command is
sent the requesting network connection is closed. This makes it easier to
@@ -36,10 +36,10 @@ Salt also allows users to make execution modules in Python. Writers of these
modules should also be pleased to know that they have access to the impressive
information gathered from PuppetLabs' Facter application, making Salt module
more flexible. In the future I hope to also allow Salt to group servers based
-on facter information as well.
+on Facter information as well.
All in all Salt is fast, efficient and clean, can be used from a simple command
-line client or through an api, uses message queue technology to make network
+line client or through an API, uses message queue technology to make network
execution extremely fast, and encryption is handled in a very fast and
efficient manner. Salt is also VERY easy to use and VERY easy to extend.
View
4 doc/topics/releases/0.7.0.rst
@@ -9,8 +9,8 @@ suitable for general use.
0.7.0 Brings the following new features to Salt:
-- Integration with facter data from puppet labs
-- Allow for matching minions from the salt client via facter information
+- Integration with Facter data from puppet labs
+- Allow for matching minions from the salt client via Facter information
- Minion job threading, many jobs can be executed from the master at once
- Preview of master clustering support - Still experimental
- Introduce new minion modules for stats, virtualization, service management and more
View
6 doc/topics/releases/0.8.0.rst
@@ -64,7 +64,7 @@ it to a specific module. The returner modules work like minion modules, so any
returner can be added to the minions.
This means that a custom data returner can be added to communicate the return
-data so anything from MySQL, redis, mongodb and more!
+data so anything from MySQL, Redis, MongoDB and more!
There are 2 simple stock returners in the returners directory:
@@ -93,7 +93,7 @@ In 0.7.0 the minion would block after receiving a command from the master, now
the minion will spawn a thread or multiprocess. By default Python threads are
used because for general use they have proved to be faster, but the minion can
now be configured to use the Python multiprocessing module instead. Using
-multiprocessing will cause executions that are cpu bound or would otherwise
+multiprocessing will cause executions that are CPU bound or would otherwise
exploit the negative aspects of the Python GIL to run faster and more reliably,
but simple calls will still be faster with Python threading.
The configuration option can be found in the minion configuration file:
@@ -104,7 +104,7 @@ Lowered Supported Python to 2.6 -
The requirement for Python 2.7 has been removed to support Python 2.6. I have
received requests to take the minimum Python version back to 2.4, but
-unfortunately this will not be possible, since the zeromq Python bindings do
+unfortunately this will not be possible, since the ZeroMQ Python bindings do
not support Python 2.4.
Salt 0.8.0 is a very major update, it also changes the network protocol slightly
View
4 doc/topics/releases/0.8.7.rst
@@ -4,7 +4,7 @@ Salt 0.8.7 release notes
It has been a month since salt 0.8.0, and it has been a long month! But Salt is
still coming along strong. 0.8.7 has a lot of changes and a lot of updates.
-This update makes Salt’s ZeroMQ back end better, strips facter from the
+This update makes Salt’s ZeroMQ back end better, strips Facter from the
dependencies, and introduces interfaces to handle more capabilities.
Many of the major updates are in the background, but the changes should shine
@@ -24,7 +24,7 @@ The major new features and changes in Salt 0.8.7 are:
* Dynamic state enforcement managers
* Extract the module loader into salt.loader
* Make Job ids more granular
-* Replace facter functionality with the new salt grains interface
+* Replace Facter functionality with the new salt grains interface
* Support for “virtual” salt modules
* Introduce the salt-call command
* Better debugging for minion modules
View
14 doc/topics/releases/0.8.8.rst
@@ -27,7 +27,7 @@ Much of the salt code has been cleaned up and a new cleaner logging system has
been introduced thanks to the efforts of Pedro Algarvio. These additions will
allow for much more flexible logging to be executed by salt, and fixed a great
deal of my poor spelling in the salt docstrings! Pedro Algarvio has also
-cleaned up the api, making it easier to embed salt into another application.
+cleaned up the API, making it easier to embed salt into another application.
The biggest addition to salt found in 0.8.8 is the new state system. The salt
module system has received a new front end which allows salt to be used as a
@@ -49,14 +49,14 @@ Hosts
The system used to define the salt states is based on a data structure, the
data structure used to define the salt states has been made to be as easy to
-use as possible. The data structure is defined by default using a yaml file
-rendered via a jinja template. This means that the state definition language
-supports all of the data structures that yaml supports, and all of the
-programming constructs and logic that jinja supports. If the user does not
-like yaml or jinja the states can be defined in yaml-mako, json-jinja, or
+use as possible. The data structure is defined by default using a YAML file
+rendered via a Jinja template. This means that the state definition language
+supports all of the data structures that YAML supports, and all of the
+programming constructs and logic that Jinja supports. If the user does not
+like YAML or Jinja the states can be defined in yaml-mako, json-jinja, or
json-mako. The system used to render the states is completely dynamic, and any
rendering system can be added to the capabilities of Salt, this means that a
-rendering system that renders xml data in a cheetah template, or whatever you
+rendering system that renders XML data in a cheetah template, or whatever you
can imagine, can be easily added to the capabilities of salt.
The salt state system also supports isolated environments, as well as matching
View
6 doc/topics/releases/0.8.9.rst
@@ -21,7 +21,7 @@ The Salt source can be downloaded from the salt github site:
:download:`salt-0.8.9.tar.gz`
-Or from PiPy:
+Or from PyPI:
http://pypi.python.org/packages/source/s/salt/salt-0.8.9.tar.gz
@@ -51,7 +51,7 @@ Refined Outputters
One problem often complained about in salt was the fact that the output was
so messy. Thanks to help from Jeff Schroeder a cleaner interface for the
-command output for the Salt cli has been made. This new interface makes
+command output for the Salt CLI has been made. This new interface makes
adding new printout formats easy and additions to the capabilities of minion
modules makes it possible to set the printout mode or ``outputter`` for
functions in minion modules.
@@ -151,7 +151,7 @@ New Returners
mongo_return
~~~~~~~~~~~~
-Send the return information to a mongodb server.
+Send the return information to a MongoDB server.
New Runners
```````````
View
6 doc/topics/releases/0.9.0.rst
@@ -6,7 +6,7 @@ Salt 0.9.0 is here. This is an exciting release, 0.9.0 includes the new network
topology features allowing peer salt commands and masters of masters via the
syndic interface.
-0.9.0 also introduces many more modules, improvements to the api and
+0.9.0 also introduces many more modules, improvements to the API and
improvements to the ZeroMQ systems.
Download!
@@ -16,7 +16,7 @@ The Salt source can be downloaded from the salt github site:
:download:`salt-0.9.0.tar.gz`
-Or from PiPy:
+Or from PyPI:
http://pypi.python.org/packages/source/s/salt/salt-0.9.0.tar.gz
@@ -87,7 +87,7 @@ Improved 0MQ Master Workers
The 0MQ worker system has been further refined to be faster and more robust.
This new system has been able to handle a much larger load than the previous
-setup. The new system uses the ipc protocol in 0MQ instead of tcp.
+setup. The new system uses the IPC protocol in 0MQ instead of TCP.
New Modules
-----------
View
2  doc/topics/releases/0.9.2.rst
@@ -19,7 +19,7 @@ The Salt source can be downloaded from the salt github site:
:download:`salt-0.9.2.tar.gz`
-Or from PiPy:
+Or from PyPI:
http://pypi.python.org/packages/source/s/salt/salt-0.9.2.tar.gz
View
8 doc/topics/releases/0.9.3.rst
@@ -18,7 +18,7 @@ The Salt source can be downloaded from the salt github site:
:download:`salt-0.9.3.tar.gz`
-Or from PiPy:
+Or from PyPI:
http://pypi.python.org/packages/source/s/salt/salt-0.9.3.tar.gz
@@ -104,8 +104,8 @@ displays this new capability.
Python State Renderer
`````````````````````
-Until now Salt States could only be declared in yaml or json using jinja or
-mako. A new, very powerful, renderer has been added, making it possible to
+Until now Salt States could only be declared in yaml or json using Jinja or
+Mako. A new, very powerful, renderer has been added, making it possible to
write Salt States in pure Python:
.. code-block:: python
@@ -207,7 +207,7 @@ file.recurse
- source: salt://linux
file.absent
- Make sure that the file is not on the system, recursively delets
+ Make sure that the file is not on the system, recursively deletes
directories, files and symlinks.
.. code-block:: yaml
View
2  doc/topics/releases/0.9.4.rst
@@ -20,7 +20,7 @@ The Salt source can be downloaded from the salt github site:
:download:`salt-0.9.4.tar.gz`
-Or from PiPy:
+Or from PyPI:
http://pypi.python.org/packages/source/s/salt/salt-0.9.4.tar.gz
View
10 doc/topics/releases/0.9.5.rst
@@ -22,7 +22,7 @@ This has proven not only that Salt has great value, but also the
expandability of Salt is as exponential as I originally intended.
0.9.5 has received over 600 additional commits since 0.9.4 with a swath of new
-commiters. The following individuals have contributed to the development of
+committers. The following individuals have contributed to the development of
0.9.5:
* Aaron Bull Schaefer
@@ -276,7 +276,7 @@ More to Come
------------
We are actively seeking inclusion in more distributions. Primarily getting
-Salt into Gentoo, Suse, OpenBSD and preparing Solaris support are all turning
+Salt into Gentoo, SUSE, OpenBSD and preparing Solaris support are all turning
into higher priorities.
Refinement
@@ -366,13 +366,13 @@ Salt can now manage local users on Microsoft Windows Systems
:mod:`yumpkg5 <salt.modules.yumpkg5>`
`````````````````````````````````````
-The yumpkg module introduces in 0.9.4 uses the yum api to interact with the
+The yumpkg module introduces in 0.9.4 uses the yum API to interact with the
yum package manager. Unfortunately, on Red Hat 5 systems salt does not have
-access to the yum api because the yum api is running under Python 2.4 and Salt
+access to the yum API because the yum API is running under Python 2.4 and Salt
needs to run under Python 2.6.
The yumpkg5 module bypasses this issue by shelling out to yum on systems where
-the yum api is not available.
+the yum API is not available.
New States
-----------
View
4 doc/topics/releases/0.9.6.rst
@@ -12,10 +12,10 @@ with Salt, and is required as a dependency.
New Features
============
-http and ftp support in files.managed
+HTTP and ftp support in files.managed
-------------------------------------
-Now under the source option in the file.managed state a http or ftp address
+Now under the source option in the file.managed state a HTTP or ftp address
can be used instead of a file located on the salt master.
Allow Multiple Returners
View
10 doc/topics/releases/0.9.8.rst
@@ -7,8 +7,8 @@ well as a number of precursors to advanced future developments.
This version of Salt adds much more power to the command line, making the
old hard timeout issues a thing of the past and adds keyword argument
-support. These additions are also available in the salt client api, making
-the available api tools much more powerful.
+support. These additions are also available in the salt client API, making
+the available API tools much more powerful.
The new pillar system allows for data to be stored on the master and
assigned to minions in a granular way similar to the state system. It also
@@ -32,7 +32,7 @@ default behavior of grain matching has changed slightly to reflect the rest
of salt and the compound matcher system has been refined.
A number of impressive features with keyword arguments have been added to both
-the cli and to the state system. This makes states much more powerful and
+the CLI and to the state system. This makes states much more powerful and
flexible while maintaining the simple configuration everyone loves.
The new batch size capability allows for executions to be rolled through a
@@ -123,7 +123,7 @@ has just become portable, allowing minions to have a local copy of states
or to manage states without a master entirely.
This is accomplished via the new file client interface in Salt that allows
-for the ``salt://`` uri to be redirected to custom interfaces. This means that
+for the ``salt://`` URI to be redirected to custom interfaces. This means that
there are now two interfaces for the salt file server, calling the master
or looking in a local, minion defined ``file_roots``.
@@ -342,7 +342,7 @@ issues when package installation waits for confirmation.
A :doc:`pkg </ref/modules/all/salt.modules.zypper>` module for OpenSUSE's
zypper was added.
-The :doc:`service </ref/modules/all/salt.modules.upstart>` module on ubuntu
+The :doc:`service </ref/modules/all/salt.modules.upstart>` module on Ubuntu
natively supports upstart.
A new :doc:`debconf </ref/modules/all/salt.modules.debconfmod>` module was
View
2  doc/topics/releases/0.9.9.rst
@@ -280,5 +280,5 @@ runners and commands like salt-key.
Client Tests
------------
-Tests have been added to test the aspects of the client apis and ensure that
+Tests have been added to test the aspects of the client APIs and ensure that
the client calls work, and that they manage passed data, in a desirable way.
View
2  doc/topics/targeting/nodegroups.rst
@@ -8,7 +8,7 @@ Node groups
A predefined group of minions declared in the master configuration file
:conf_master:`nodegroups` setting as a compound target.
-Nodegroups are declared using a compound target specification. The compount
+Nodegroups are declared using a compound target specification. The compound
target documentation can be found here:
:doc:`Compound Matchers <compound>`
View
2  doc/topics/troubleshooting/index.rst
@@ -31,7 +31,7 @@ What Ports do the Master and Minion Need Open?
No ports need to be opened up on each minion. For the master, TCP ports 4505
and 4506 need to be open. If you've put both your Salt master and minion in
-debug mode and don't see an acknowledgement that your minion has connected,
+debug mode and don't see an acknowledgment that your minion has connected,
it could very well be a firewall.
You can check port connectivity from the minion with the nc command:
View
2  doc/topics/troubleshooting/yaml_idiosyncrasies.rst
@@ -229,7 +229,7 @@ Examples:
-List of useable `Unicode characters`_ will help you to identify correct numbers.
+List of usable `Unicode characters`_ will help you to identify correct numbers.
.. _`Unicode characters`: http://en.wikipedia.org/wiki/List_of_Unicode_characters
View
2  doc/topics/tutorials/gitfs.rst
@@ -23,7 +23,7 @@ tree to multiple masters seamless and automated.
Salt's file server also has a concept of environments, when using the gitfs
backend, Salt translates git branches and tags into environments, making
-environment management very simple. Just merging a qa or staging branch up
+environment management very simple. Just merging a QA or staging branch up
to a production branch can be all that is required to make those file changes
available to Salt.
View
6 doc/topics/tutorials/pillar.rst
@@ -4,7 +4,7 @@ Pillar Walkthrough
.. note::
- This walkthrough assumes that the reader has already completed the inital
+ This walkthrough assumes that the reader has already completed the initial
Salt Stack walkthrough:
:doc:`Walkthrough </topics/tutorials/walkthrough>`
@@ -15,7 +15,7 @@ for specific minions. The data generated in pillar is made available to almost
every component of Salt and is used for a number of purposes:
Highly Sensitive Data:
- Information transfered via pillar is guaranteed to only be presented to the
+ Information transferred via pillar is guaranteed to only be presented to the
minions that are targeted, this makes pillar the engine to use in Salt for
managing security information, such as cryptographic keys and passwords.
Minion Configuration:
@@ -92,7 +92,7 @@ More Complex Data
Pillar files are sls files, just like states, but unlike states they do not
need to define `formulas`, the data can be arbitrary, this example for
-instance sets up user data with a uid:
+instance sets up user data with a UID:
`/srv/pillar/users/init.sls`
View
4 doc/topics/tutorials/starting_states.rst
@@ -13,7 +13,7 @@ to contain this data simply. This is often called configuration management.
.. note::
- This is just the begining of using states, make sure to read up on pillar
+ This is just the beginning of using states, make sure to read up on pillar
next:
:doc:`Pillar Walkthrough </topics/tutorials/pillar>`
@@ -312,7 +312,7 @@ renderers.
The ``py`` renderer allows for SLS files to be written in pure Python, allowing
for the utmost level of flexibility and power when preparing SLS data; while the
:doc:`pydsl</ref/renderers/all/salt.renderers.pydsl>` renderer provides a flexible,
-domain-specific languange for authoring SLS data in Python.
+domain-specific language for authoring SLS data in Python.
.. _`Jinja2`: http://jinja.pocoo.org/
.. _`Mako`: http://www.makotemplates.org/
View
4 doc/topics/tutorials/states_pt1.rst
@@ -14,7 +14,7 @@ Apache HTTP server and to ensure the server is running.
Setting up the Salt State Tree
==============================
-States are stored in text files on the master and transfered to the minions on
+States are stored in text files on the master and transferred to the minions on
demand via the master's File Server. The collection of state files make up the
:term:`State Tree`.
@@ -60,7 +60,7 @@ minion matches is defined; for now simply specify all hosts (``*``).
.. admonition:: Targeting minions
The expressions can use any of the targeting mechanisms used by Salt —
- minions can be matched by glob, pcre regular expression, or by :doc:`grains
+ minions can be matched by glob, PCRE regular expression, or by :doc:`grains
</topics/targeting/grains>`. For example::
base:
View
24 doc/topics/tutorials/walkthrough.rst
@@ -96,7 +96,7 @@ greatly increases the command output:
# salt-master -l debug
-The Salt Master needs to bind to 2 tcp network ports on the system, these ports
+The Salt Master needs to bind to 2 TCP network ports on the system, these ports
are 4505 and 4506. For more in depth information on fire walling these ports
the firewall tutorial is available:
@@ -109,7 +109,7 @@ Setting up a Salt Minion
The Salt Minion can operate with or without a Salt Master. This walkthrough
assumes that the minion will be connected to the master, for information on
- how to run a masterless minion please see the masterless quickstart guide:
+ how to run a master-less minion please see the masterless quickstart guide:
:doc:`Masterless Minon Quickstart </topics/tutorials/quickstart>`
@@ -235,7 +235,7 @@ Grains
~~~~~~
Salt uses a system called `Grains` to build up static data about minions. This
-data includes information about the operating system that is running, cpu
+data includes information about the operating system that is running, CPU
architecture and many more. The grains system is used throughout Salt to
deliver platform data to many components and to users.
@@ -258,7 +258,7 @@ Many other targeting systems can be used other than globs, these systems
include:
Regular Expressions
- Target using pcre compliant regular expressions:
+ Target using PCRE compliant regular expressions:
:doc:`Targeting with Regular Expressions</topics/targeting/pcre>`
Grains
@@ -270,12 +270,12 @@ Pillar
:doc:`Targeting with Pillar</topics/targeting/pillar>`
IP
- Target based on ip addr/subnet/range:
+ Target based on IP addr/subnet/range:
:doc:`Targeting with ipcidr</topics/targeting/ipcidr>`
Compound
Create logic to target based on multiple targets:
- :doc:`Targeting with Compond</topics/targeting/compound>`
+ :doc:`Targeting with Compound</topics/targeting/compound>`
Nodegroup
Target with nodegroups:
@@ -283,7 +283,7 @@ Nodegroup
The concepts of targets are used on the command line with salt, but also
function in many other areas as well, including the state system and the
-systems used for acls and user permission restrictions.
+systems used for ACLs and user permission restrictions.
Salt States
===========
@@ -368,7 +368,7 @@ Adding Some Depth
-----------------
Obviously maintaining sls formulas right in the root of the file server will
-not scale out to resonably sized deployments. This is why more depth is
+not scale out to reasonably sized deployments. This is why more depth is
required. Start by making an nginx formula a better way, make a nginx
subdirectory and add an init.sls file:
@@ -388,7 +388,7 @@ A few things are introduced in this sls formula, first is the service statement
which ensures that the nginx service is running, but the nginx service can't be
started unless the package is installed, hence the `require`. The `require`
statement makes sure that the required component is executed before and that
-it results in sucess.
+it results in success.
.. note::
@@ -432,7 +432,7 @@ joe or any other editor that may need to be deployed.
Next Reading
------------
-Two walkthroughs are specificly reommended at this point, first a deeper run
+Two walkthroughs are specifically recommended at this point, first a deeper run
through states:
:doc:`Starting States </topics/tutorials/starting_states>`
@@ -464,7 +464,7 @@ This concludes the initial Salt walkthrough, but there are many more things to
yet learn! These documents will cover important core aspects of Salt:
Pillar
- Paramaters and minion private data (pillar is a core component of states):
+ Parameters and minion private data (pillar is a core component of states):
:doc:`States Tutorial</topics/tutorials/states_pt1>`
:doc:`Pillar</topics/pillar/index>`
@@ -474,7 +474,7 @@ Job Management
A few more tutorials are also available:
-Remote Excution Tutorial
+Remote Execution Tutorial
:doc:`Remote Execution Tutorial</topics/tutorials/modules>`
Standalone Minion
Please sign in to comment.
Something went wrong with that request. Please try again.