Assorted doc bugs

Refs #9051
Refs #13407
Refs #21475
Refs #14876
Refs #27005

doc/index.rst

@@ -62,6 +62,15 @@ Masterless Quickstart:
 A list of all tutorials can be found here:
     :doc:`All Salt tutorials <topics/tutorials/index>`
 
+Demo Environments
+=================
+
+You can download one of the following `Vagrant <http://vagrantup.com>`_
+projects to quickly set up a Salt demo environment:
+
+- https://github.com/UtahDave/salt-vagrant-demo
+- https://github.com/UtahDave/salt-vagrant-lxc
+
 Salt in depth
 =============
 

doc/ref/cli/index.rst

@@ -231,6 +231,14 @@ You may change the arguments separator using the ``--args-separator`` option:
 
     salt --args-separator=:: '*' some.fun,test.echo params with , comma :: foo
 
+CLI Completion
+==============
+
+Shell completion scripts for the Salt CLI are available in the ``pkg`` Salt
+`source directory`_.
+
+.. _source directory: https://github.com/saltstack/salt/tree/develop/pkg
+
 salt-call
 =========
 .. toctree::

doc/ref/modules/all/index.rst

@@ -92,6 +92,7 @@ Full list of builtin execution modules
     freebsdpkg
     freebsdports
     freebsdservice
+    fsutils
     gem
     genesis
     gentoo_service

doc/ref/modules/all/salt.modules.fsutils.rst

@@ -0,0 +1,6 @@
+====================
+salt.modules.fsutils
+====================
+
+.. automodule:: salt.modules.fsutils
+    :members:

doc/topics/pillar/index.rst

@@ -321,28 +321,6 @@ locally. This is done with the ``saltutil.refresh_pillar`` function.
 This function triggers the minion to asynchronously refresh the pillar and will
 always return ``None``.
 
-.. _targeting-pillar:
-
-Targeting with Pillar
-=====================
-
-Pillar data can be used when targeting minions. This allows for ultimate
-control and flexibility when targeting minions.
-
-.. code-block:: bash
-
-    salt -I 'somekey:specialvalue' test.ping
-
-Like with :doc:`Grains <../targeting/grains>`, it is possible to use globbing
-as well as match nested values in Pillar, by adding colons for each level that
-is being traversed. The below example would match minions with a pillar named
-``foo``, which is a dict containing a key ``bar``, with a value beginning with
-``baz``:
-
-.. code-block:: bash
-
-    salt -I 'foo:bar:baz*' test.ping
-
 
 Set Pillar Data at the Command Line
 ===================================

doc/topics/ssh/roster.rst

@@ -23,14 +23,14 @@ How Rosters Work
 ================
 
 The roster system compiles a data structure internally referred to as
-`targets`. The `targets` is a list of target systems and attributes about how
+``targets``. The ``targets`` is a list of target systems and attributes about how
 to connect to said systems. The only requirement for a roster module in Salt
-is to return the `targets` data structure.
+is to return the ``targets`` data structure.
 
 Targets Data
 ------------
 
-The information which can be stored in a roster `target` is the following:
+The information which can be stored in a roster ``target`` is the following:
 
 .. code-block:: yaml
 

doc/topics/targeting/grains.rst

@@ -206,15 +206,15 @@ defining custom grains, there is an order of precedence which should be kept in
 mind when defining them. The order of evaluation is as follows:
 
 1. Core grains.
-2. Custom grain modules in ``_grains`` directory, synced to minions.
-3. Custom grains in ``/etc/salt/grains``.
-4. Custom grains in ``/etc/salt/minion``.
+2. Custom grains in ``/etc/salt/grains``.
+3. Custom grains in ``/etc/salt/minion``.
+4. Custom grain modules in ``_grains`` directory, synced to minions.
 
 Each successive evaluation overrides the previous ones, so any grains defined
 by custom grains modules synced to minions that have the same name as a core
 grain will override that core grain. Similarly, grains from
-``/etc/salt/grains`` override both core grains and custom grain modules, and
-grains in ``/etc/salt/minion`` will override *any* grains of the same name.
+``/etc/salt/minion`` override both core grains and custom grain modules, and
+grains in ``_grains`` will override *any* grains of the same name.
 
 
 Examples of Grains

doc/topics/targeting/index.rst

@@ -28,8 +28,9 @@ There are many ways to target individual minions or groups of minions in Salt:
 
     globbing
     grains
+    pillar
     ipcidr
     compound
     nodegroups
     batch
-    range
+    range

doc/topics/targeting/pillar.rst

@@ -0,0 +1,22 @@
+.. _targeting-pillar:
+
+=====================
+Targeting with Pillar
+=====================
+
+Pillar data can be used when targeting minions. This allows for ultimate
+control and flexibility when targeting minions.
+
+.. code-block:: bash
+
+    salt -I 'somekey:specialvalue' test.ping
+
+Like with :ref:`Grains <targeting-grains>`, it is possible to use globbing
+as well as match nested values in Pillar, by adding colons for each level that
+is being traversed. The below example would match minions with a pillar named
+``foo``, which is a dict containing a key ``bar``, with a value beginning with
+``baz``:
+
+.. code-block:: bash
+
+    salt -I 'foo:bar:baz*' test.ping

doc/topics/tutorials/states_pt3.rst

@@ -47,11 +47,11 @@ Here's a more complex example:
 .. code-blocK:: jinja
 
     # Comments in yaml start with a hash symbol.
-    # Since jinja rendering occurs before yaml parsing, if you want to include jinja 
+    # Since jinja rendering occurs before yaml parsing, if you want to include jinja
     # in the comments you may need to escape them using 'jinja' comments to prevent
     # jinja from trying to render something which is not well-defined jinja.
     # e.g.
-    # {# iterate over the Three Stooges using a {% for %}..{% endfor %} loop 
+    # {# iterate over the Three Stooges using a {% for %}..{% endfor %} loop
     # with the iterator variable {{ usr }} becoming the state ID. #}
     {% for usr in 'moe','larry','curly' %}
     {{ usr }}:
@@ -81,6 +81,43 @@ in the template context. The `grains` can be used from within sls modules:
         - name: apache2
         {% endif %}
 
+Using Environment Variables in SLS modules
+==========================================
+
+You can use ``salt['environ.get']('VARNAME')`` to use an environment
+variable in a Salt state.
+
+.. code-block:: bash
+
+   MYENVVAR="world" salt-call state.template test.sls
+
+.. code-block:: yaml
+
+   Create a file with contents from an environment variable:
+  file.managed:
+    - name: /tmp/hello
+    - contents: {{ salt['environ.get']('MYENVVAR') }}
+
+Error checking:
+
+.. code-block:: yaml
+
+   {% set myenvvar = salt['environ.get']('MYENVVAR') %}
+   {% if myenvvar %}
+
+   Create a file with contents from an environment variable:
+     file.managed:
+       - name: /tmp/hello
+       - contents: {{ salt['environ.get']('MYENVVAR') }}
+
+   {% else %}
+
+   Fail - no environment passed in:
+     test:
+       A. fail_without_changes
+
+   {% endif %}
+
 Calling Salt modules from templates
 ===================================
 

salt/states/user.py

@@ -233,7 +233,8 @@ def present(name,
 
     password
         A password hash to set for the user. This field is only supported on
-        Linux, FreeBSD, NetBSD, OpenBSD, and Solaris.
+        Linux, FreeBSD, NetBSD, OpenBSD, and Solaris. If the ``empty_password``
+        argument is set to ``True`` then ``password`` is ignored.
 
     .. versionchanged:: 0.16.0
        BSD support added.