doc(user_guide): fix typos (#47425)
This commit is contained in:
parent
f83fa2ac93
commit
5959158612
9 changed files with 12 additions and 12 deletions
|
@ -75,7 +75,7 @@ It is also possible to become a user other than root using
|
||||||
.. note::
|
.. note::
|
||||||
|
|
||||||
Rarely, some users have security rules where they constrain their sudo/pbrun/doas environment to running specific command paths only.
|
Rarely, some users have security rules where they constrain their sudo/pbrun/doas environment to running specific command paths only.
|
||||||
This does not work with ansible's no-bootstrapping philosophy and hundreds of different modules.
|
This does not work with Ansible's no-bootstrapping philosophy and hundreds of different modules.
|
||||||
If doing this, use Ansible from a special account that does not have this constraint.
|
If doing this, use Ansible from a special account that does not have this constraint.
|
||||||
One way of doing this without sharing access to unauthorized users would be gating Ansible with :ref:`ansible_tower`, which
|
One way of doing this without sharing access to unauthorized users would be gating Ansible with :ref:`ansible_tower`, which
|
||||||
can hold on to an SSH credential and let members of certain organizations use it on their behalf without having direct access.
|
can hold on to an SSH credential and let members of certain organizations use it on their behalf without having direct access.
|
||||||
|
|
|
@ -52,7 +52,7 @@ Support
|
||||||
=======
|
=======
|
||||||
|
|
||||||
For more information on how included Ansible modules are supported by Red Hat,
|
For more information on how included Ansible modules are supported by Red Hat,
|
||||||
please refer to the following `knowledgebase article <https://access.redhat.com/articles/3166901>`_ as well as other resources on the `Red Hat Customer Portal. <https://access.redhat.com/>`_
|
please refer to the following `knowledge base article <https://access.redhat.com/articles/3166901>`_ as well as other resources on the `Red Hat Customer Portal. <https://access.redhat.com/>`_
|
||||||
|
|
||||||
.. seealso::
|
.. seealso::
|
||||||
|
|
||||||
|
|
|
@ -15,7 +15,7 @@ By default these should be relative to the config file, some are specifically re
|
||||||
Task paths
|
Task paths
|
||||||
==========
|
==========
|
||||||
|
|
||||||
Here things start getting complicated, there are 2 different scopes to consider, task evalution (paths are all local, like in lookups) and task execution, which is normally on the remote, unless an action plugin is involved.
|
Here things start getting complicated, there are 2 different scopes to consider, task evaluation (paths are all local, like in lookups) and task execution, which is normally on the remote, unless an action plugin is involved.
|
||||||
|
|
||||||
Some tasks that require 'local' resources use action plugins (template and copy are examples of these), in which case the path is also local.
|
Some tasks that require 'local' resources use action plugins (template and copy are examples of these), in which case the path is also local.
|
||||||
|
|
||||||
|
|
|
@ -17,7 +17,7 @@ The documentation covered here is an extension of the documentation that can be
|
||||||
Unsafe or Raw Strings
|
Unsafe or Raw Strings
|
||||||
~~~~~~~~~~~~~~~~~~~~~
|
~~~~~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
Ansible provides an internal data type for declaring variable values as "unsafe". This means that the data held within the variables value should be treated as unsafe preventing unsafe character subsitition and information disclosure.
|
Ansible provides an internal data type for declaring variable values as "unsafe". This means that the data held within the variables value should be treated as unsafe preventing unsafe character substitution and information disclosure.
|
||||||
|
|
||||||
Jinja2 contains functionality for escaping, or telling Jinja2 to not template data by means of functionality such as ``{% raw %} ... {% endraw %}``, however this uses a more comprehensive implementation to ensure that the value is never templated.
|
Jinja2 contains functionality for escaping, or telling Jinja2 to not template data by means of functionality such as ``{% raw %} ... {% endraw %}``, however this uses a more comprehensive implementation to ensure that the value is never templated.
|
||||||
|
|
||||||
|
|
|
@ -6,7 +6,7 @@ Intro to Playbooks
|
||||||
About Playbooks
|
About Playbooks
|
||||||
```````````````
|
```````````````
|
||||||
|
|
||||||
Playbooks are a completely different way to use ansible than in adhoc task execution mode, and are
|
Playbooks are a completely different way to use ansible than in ad-hoc task execution mode, and are
|
||||||
particularly powerful.
|
particularly powerful.
|
||||||
|
|
||||||
Simply put, playbooks are the basis for a really simple configuration management and multi-machine deployment system,
|
Simply put, playbooks are the basis for a really simple configuration management and multi-machine deployment system,
|
||||||
|
|
|
@ -11,7 +11,7 @@ When you execute a playbook, you can filter tasks based on tags in two ways:
|
||||||
- In Ansible configuration settings, with the ``TAGS_RUN`` and ``TAGS_SKIP`` options
|
- In Ansible configuration settings, with the ``TAGS_RUN`` and ``TAGS_SKIP`` options
|
||||||
|
|
||||||
Tags can be applied to *many* structures in Ansible (see "tag inheritance",
|
Tags can be applied to *many* structures in Ansible (see "tag inheritance",
|
||||||
below), but its simplest use is with indivdual tasks. Here is an example
|
below), but its simplest use is with individual tasks. Here is an example
|
||||||
that tags two tasks with different tags::
|
that tags two tasks with different tags::
|
||||||
|
|
||||||
tasks:
|
tasks:
|
||||||
|
@ -86,7 +86,7 @@ such as ``include_role`` and ``include_tasks``.
|
||||||
When you apply ``tags:`` attributes to structures other than tasks,
|
When you apply ``tags:`` attributes to structures other than tasks,
|
||||||
Ansible processes the tag attribute to apply ONLY to the tasks they contain.
|
Ansible processes the tag attribute to apply ONLY to the tasks they contain.
|
||||||
Applying tags anywhere other than tasks is just a convenience so you don't
|
Applying tags anywhere other than tasks is just a convenience so you don't
|
||||||
have to tag tasks indivdually.
|
have to tag tasks individually.
|
||||||
|
|
||||||
This example tags all tasks in the two plays. The first play has all its tasks
|
This example tags all tasks in the two plays. The first play has all its tasks
|
||||||
tagged with 'bar', and the second has all its tasks tagged with 'foo'::
|
tagged with 'bar', and the second has all its tasks tagged with 'foo'::
|
||||||
|
|
|
@ -144,7 +144,7 @@ In addition, the following Ansible Core modules/action-plugins work with Windows
|
||||||
* set_stats
|
* set_stats
|
||||||
* setup
|
* setup
|
||||||
* slurp
|
* slurp
|
||||||
* template (also: win_tempate)
|
* template (also: win_template)
|
||||||
* wait_for_connection
|
* wait_for_connection
|
||||||
|
|
||||||
Can I run Python modules?
|
Can I run Python modules?
|
||||||
|
|
|
@ -409,7 +409,7 @@ connection. Some things to check for this are:
|
||||||
|
|
||||||
HTTP 500 Error
|
HTTP 500 Error
|
||||||
++++++++++++++
|
++++++++++++++
|
||||||
These indicate an error has occured with the WinRM service. Some things
|
These indicate an error has occurred with the WinRM service. Some things
|
||||||
to check for include:
|
to check for include:
|
||||||
|
|
||||||
* Verify that the number of current open shells has not exceeded either
|
* Verify that the number of current open shells has not exceeded either
|
||||||
|
|
|
@ -273,7 +273,7 @@ rules apply:
|
||||||
* A double quote preceded by a backslash ``\`` is interpreted as just a double
|
* A double quote preceded by a backslash ``\`` is interpreted as just a double
|
||||||
quote ``"`` and not as an argument delimiter.
|
quote ``"`` and not as an argument delimiter.
|
||||||
|
|
||||||
* Backslashes are interpreted literally unless it immediately preceeds double
|
* Backslashes are interpreted literally unless it immediately precedes double
|
||||||
quotes; for example ``\`` == ``\`` and ``\"`` == ``"``
|
quotes; for example ``\`` == ``\`` and ``\"`` == ``"``
|
||||||
|
|
||||||
* If an even number of backslashes is followed by a double quote, one
|
* If an even number of backslashes is followed by a double quote, one
|
||||||
|
@ -294,7 +294,7 @@ With those rules in mind, here are some examples of quoting::
|
||||||
argv[3] = C:\path\with space
|
argv[3] = C:\path\with space
|
||||||
argv[4] = double "quoted"
|
argv[4] = double "quoted"
|
||||||
|
|
||||||
- win_command: '"C:\Program Files\Program\program.exe" "escaped \\\" backslash" unqouted-end-backslash\'
|
- win_command: '"C:\Program Files\Program\program.exe" "escaped \\\" backslash" unquoted-end-backslash\'
|
||||||
|
|
||||||
argv[0] = C:\Program Files\Program\program.exe
|
argv[0] = C:\Program Files\Program\program.exe
|
||||||
argv[1] = escaped \" backslash
|
argv[1] = escaped \" backslash
|
||||||
|
@ -412,7 +412,7 @@ Here are some examples on how to write Windows paths::
|
||||||
|
|
||||||
Legacy key=value Style
|
Legacy key=value Style
|
||||||
----------------------
|
----------------------
|
||||||
The legacy ``key=value`` syntax is used on the command line for adhoc commands,
|
The legacy ``key=value`` syntax is used on the command line for ad-hoc commands,
|
||||||
or inside playbooks. The use of this style is discouraged within playbooks
|
or inside playbooks. The use of this style is discouraged within playbooks
|
||||||
because backslash characters need to be escaped, making playbooks harder to read.
|
because backslash characters need to be escaped, making playbooks harder to read.
|
||||||
The legacy syntax depends on the specific implementation in Ansible, and quoting
|
The legacy syntax depends on the specific implementation in Ansible, and quoting
|
||||||
|
|
Loading…
Reference in a new issue