Resolving some doc errors.
This commit is contained in:
Michael DeHaan
parent
71ddb80524
commit
4a0e06dc80
8 changed files with 32 additions and 37 deletions
|
|
@ -431,8 +431,6 @@ the program. Stop by the mailing list to inquire about requirements.
|
|||
|
||||
:doc:`modules`
|
||||
Learn about available modules
|
||||
:doc:`contrib`
|
||||
User contributed playbooks, modules, and articles
|
||||
`Github modules directory <https://github.com/ansible/ansible/tree/devel/library>`_
|
||||
Browse source of core modules
|
||||
`Mailing List <http://groups.google.com/group/ansible-project>`_
|
||||
|
|
|
|||
|
|
@ -28,7 +28,7 @@ An Introduction
|
|||
intro_installation
|
||||
intro_getting_started
|
||||
intro_inventory
|
||||
intro_inventory_dynamic
|
||||
intro_dynamic_inventory
|
||||
intro_patterns
|
||||
intro_adhoc
|
||||
modules
|
||||
|
|
|
|||
|
|
@ -111,7 +111,7 @@ Also note that host key checking in paramiko mode is reasonably slow, therefore
|
|||
|
||||
.. seealso::
|
||||
|
||||
:doc:`examples`
|
||||
:doc:`intro_ad_hoc`
|
||||
Examples of basic commands
|
||||
:doc:`playbooks`
|
||||
Learning ansible's configuration management language
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
.. _patterns:
|
||||
.. _inventory:
|
||||
|
||||
Inventory
|
||||
=========
|
||||
|
|
@ -172,27 +172,27 @@ List of Behavioral Inventory Parameters
|
|||
As aluded to above, setting the following variables controls how ansible interacts with remote hosts. Some we have already
|
||||
mentioned::
|
||||
|
||||
ansible_ssh_host
|
||||
The name of the host to connect to, if different from the alias you wish to give to it.
|
||||
ansible_ssh_port
|
||||
The ssh port number, if not 22
|
||||
ansible_ssh_user
|
||||
The default ssh user name to use.
|
||||
ansible_ssh_pass
|
||||
The ssh password to use (this is insecure, we strongly recommend using --ask-pass or SSH keys)
|
||||
ansible_connection
|
||||
Connection type of the host. Candidates are local, ssh or paramiko. The default is paramiko before Ansible 1.2, and 'smart' afterwards which detects whether usage of 'ssh' would be feasible based on whether ControlPersist is supported.
|
||||
ansible_ssh_private_key_file
|
||||
Private key file used by ssh. Useful if using multiple keys and you don't want to use SSH agent.
|
||||
ansible_python_interpreter
|
||||
The target host python path. This is userful for systems with more
|
||||
than one Python or not located at "/usr/bin/python" such as \*BSD, or where /usr/bin/python
|
||||
is not a 2.X series Python. We do not use the "/usr/bin/env" mechanism as that requires the remote user's
|
||||
path to be set right and also assumes the "python" executable is named python, where the executable might
|
||||
be named something like "python26".
|
||||
ansible\_\*\_interpreter
|
||||
Works for anything such as ruby or perl and works just like ansible_python_interpreter.
|
||||
This replaces shebang of modules which will run on that host.
|
||||
ansible_ssh_host
|
||||
The name of the host to connect to, if different from the alias you wish to give to it.
|
||||
ansible_ssh_port
|
||||
The ssh port number, if not 22
|
||||
ansible_ssh_user
|
||||
The default ssh user name to use.
|
||||
ansible_ssh_pass
|
||||
The ssh password to use (this is insecure, we strongly recommend using --ask-pass or SSH keys)
|
||||
ansible_connection
|
||||
Connection type of the host. Candidates are local, ssh or paramiko. The default is paramiko before Ansible 1.2, and 'smart' afterwards which detects whether usage of 'ssh' would be feasible based on whether ControlPersist is supported.
|
||||
ansible_ssh_private_key_file
|
||||
Private key file used by ssh. Useful if using multiple keys and you don't want to use SSH agent.
|
||||
ansible_python_interpreter
|
||||
The target host python path. This is userful for systems with more
|
||||
than one Python or not located at "/usr/bin/python" such as \*BSD, or where /usr/bin/python
|
||||
is not a 2.X series Python. We do not use the "/usr/bin/env" mechanism as that requires the remote user's
|
||||
path to be set right and also assumes the "python" executable is named python, where the executable might
|
||||
be named something like "python26".
|
||||
ansible\_\*\_interpreter
|
||||
Works for anything such as ruby or perl and works just like ansible_python_interpreter.
|
||||
This replaces shebang of modules which will run on that host.
|
||||
|
||||
Examples from a host file::
|
||||
|
||||
|
|
|
|||
|
|
@ -63,13 +63,11 @@ See :doc:`moduledev`.
|
|||
|
||||
.. seealso::
|
||||
|
||||
:doc:`contrib`
|
||||
User contributed playbooks, modules, and articles
|
||||
:doc:`examples`
|
||||
:doc:`intro_adhoc`
|
||||
Examples of using modules in /usr/bin/ansible
|
||||
:doc:`playbooks`
|
||||
Examples of using modules with /usr/bin/ansible-playbook
|
||||
:doc:`moduledev`
|
||||
:doc:`developing_modules`
|
||||
How to write your own modules
|
||||
:doc:`api`
|
||||
Examples of using modules with the Python API
|
||||
|
|
|
|||
|
|
@ -325,13 +325,13 @@ can do this::
|
|||
|
||||
:doc:`YAMLSyntax`
|
||||
Learn about YAML syntax
|
||||
:doc:`bestpractices`
|
||||
:doc:`playbooks_bestpractices`
|
||||
Various tips about managing playbooks in the real world
|
||||
:doc:`modules`
|
||||
Learn about available modules
|
||||
:doc:`moduledev`
|
||||
:doc:`developing_modules`
|
||||
Learn how to extend Ansible by writing your own modules
|
||||
:doc:`patterns`
|
||||
:doc:`intro_patterns`
|
||||
Learn about how to select hosts
|
||||
`Github examples directory <https://github.com/ansible/ansible/tree/devel/examples/playbooks>`_
|
||||
Complete playbook files from the github project source
|
||||
|
|
|
|||
|
|
@ -85,8 +85,7 @@ If a required variable has not been set, you can skip or fail using Jinja2's
|
|||
This is especially useful in combination with the conditional import of vars
|
||||
files (see below).
|
||||
|
||||
.. note :: When combining `when` with `with_items`, be aware that the `when` statement is processed separately for each item.
|
||||
This is by design::
|
||||
Note that when combining `when` with `with_items` (see :doc:`playbook_loops`), be aware that the `when` statement is processed separately for each item. This is by design::
|
||||
|
||||
tasks:
|
||||
- command: echo {{ item }}
|
||||
|
|
|
|||
|
|
@ -63,7 +63,7 @@ contain all of my wordpress tasks in a single wordpress.yml file, and use it lik
|
|||
- include: wordpress.yml user=alice
|
||||
- include: wordpress.yml user=bob
|
||||
|
||||
Variables passed in can then be used in the included files. We've already covered them a bit in :doc:`intro_variales`.
|
||||
Variables passed in can then be used in the included files. We've already covered them a bit in :doc:`intro_variables`.
|
||||
You can reference them like this::
|
||||
|
||||
{{ user }}
|
||||
|
|
@ -318,7 +318,7 @@ The resulting order of execution would be as follows::
|
|||
Learn about YAML syntax
|
||||
:doc:`playbooks`
|
||||
Review the basic Playbook language features
|
||||
:doc:`bestpractices`
|
||||
:doc:`playbooks_best_practices`
|
||||
Various tips about managing playbooks in the real world
|
||||
:doc:`modules`
|
||||
Learn about available modules
|
||||
|
|
|
|||
Loading…
Reference in a new issue