@ -157,7 +157,7 @@ To learn more about Jinja2, you can optionally see the `Jinja2 docs <http://jinj
If there are discovered variables about the system, called 'facts', these variables bubble up back into the
If there are discovered variables about the system, called 'facts', these variables bubble up back into the
playbook, and can be used on each system just like explicitly set variables. Ansible provides several
playbook, and can be used on each system just like explicitly set variables. Ansible provides several
of these, prefixed with 'ansible', and are documented under 'setup' in the module documentation. Additionally,
of these, prefixed with 'ansible', which are documented under 'setup' in the module documentation. Additionally,
facts can be gathered by ohai and facter if they are installed. Facter variables are prefixed with ``facter_`` and Ohai variables are prefixed with ``ohai_``. These add extra dependencies and are only there for ease of users
facts can be gathered by ohai and facter if they are installed. Facter variables are prefixed with ``facter_`` and Ohai variables are prefixed with ``ohai_``. These add extra dependencies and are only there for ease of users
porting over from those other configuration systems.
porting over from those other configuration systems.
@ -188,7 +188,7 @@ The goal of each task is to execute a module, with very specific arguments.
Variables, as mentioned above, can be used in arguments to modules.
Variables, as mentioned above, can be used in arguments to modules.
Modules are 'idempotent', meaning if you run them
Modules are 'idempotent', meaning if you run them
again, they will make the changes they are told to make to bring the
again, they will make only the changes they must in order to bring the
system to the desired state. This makes it very safe to rerun
system to the desired state. This makes it very safe to rerun
the same playbook multiple times. They won't change things
the same playbook multiple times. They won't change things
unless they have to change things.
unless they have to change things.
@ -225,7 +225,7 @@ them work just like you would expect. Simple::
command: /sbin/setenforce 0
command: /sbin/setenforce 0
The command and shell module care about return codes, so if you have a command
The command and shell module care about return codes, so if you have a command
who's successful exit code is not zero, you may wish to do this::
whose successful exit code is not zero, you may wish to do this::
tasks:
tasks:
- name: run this command and ignore the result
- name: run this command and ignore the result
@ -370,7 +370,7 @@ Variables passed in can then be used in the included files. You can reference t
{{ user }}
{{ user }}
(In addition to the explicitly passedin parameters, all variables from
(In addition to the explicitly passed-in parameters, all variables from
the vars section are also available for use here as well.)
the vars section are also available for use here as well.)
Starting in 1.0, variables can also be passed to include files using an alternative syntax,
Starting in 1.0, variables can also be passed to include files using an alternative syntax,
@ -554,7 +554,7 @@ Let's run a playbook using a parallelism level of 10::
Tips and Tricks
Tips and Tricks
```````````````
```````````````
Look at the bottom of the playbook execution for a summary of the nodes that were executed
Look at the bottom of the playbook execution for a summary of the nodes that were targeted
and how they performed. General failures and fatal "unreachable" communication attempts are
and how they performed. General failures and fatal "unreachable" communication attempts are
Even if you didn't define them yourself, Ansible provides a few variables for you, automatically.
Even if you didn't define them yourself, Ansible provides a few variables for you automatically.
The most important of these are 'hostvars', 'group_names', and 'groups'. Users should not use
The most important of these are 'hostvars', 'group_names', and 'groups'. Users should not use
these names themselves as they are reserved. 'environment' is also reserved.
these names themselves as they are reserved. 'environment' is also reserved.
@ -437,7 +437,7 @@ As a reminder, the various YAML files contain just keys and values::
somethingelse: 42
somethingelse: 42
How does this work? If the operating system was 'CentOS', the first file Ansible would try to import
How does this work? If the operating system was 'CentOS', the first file Ansible would try to import
would be 'vars/CentOS.yml', followed up by '/vars/os_defaults.yml' if that file
would be 'vars/CentOS.yml', followed by '/vars/os_defaults.yml' if that file
did not exist. If no files in the list were found, an error would be raised.
did not exist. If no files in the list were found, an error would be raised.
On Debian, it would instead first look towards 'vars/Debian.yml' instead of 'vars/CentOS.yml', before
On Debian, it would instead first look towards 'vars/Debian.yml' instead of 'vars/CentOS.yml', before
falling back on 'vars/os_defaults.yml'. Pretty simple.
falling back on 'vars/os_defaults.yml'. Pretty simple.
@ -614,7 +614,7 @@ Negative numbers are not supported. This works as follows::
.. versionadded: 1.1
.. versionadded: 1.1
``with_password`` and associated lookup macro generate a random plaintext password and store it in
``with_password`` and associated lookup macro generate a random plaintext password and store it in
a file at a given filepath. Support for crypted save modes (as with vars_prompt) are pending. If the
a file at a given filepath. Support for crypted save modes (as with vars_prompt) is pending. If the
file exists previously, it will retrieve its contents, behaving just like with_file. Usage of variables like "{{ inventory_hostname }}" in the filepath can be used to set
file exists previously, it will retrieve its contents, behaving just like with_file. Usage of variables like "{{ inventory_hostname }}" in the filepath can be used to set
up random passwords per host (what simplifies password management in 'host_vars' variables).
up random passwords per host (what simplifies password management in 'host_vars' variables).
@ -1093,7 +1093,7 @@ If using local_action, you can do this::
arg1: 1234
arg1: 1234
arg2: 'asdf'
arg2: 'asdf'
Which of course means, though more verbose, this is also technically legal syntax::
Which of course means that, though more verbose, this is also legal syntax::
- If the repository is added, C(apt-get update) is invoked.
- If the repository is added, C(apt-get update) is invoked.
- This module works on Debian and Ubuntu only and requires C(apt-add-repository) be available on the destination server. To ensure this package is available use the M(apt) module and install the C(python-software-properties) package (or C(software-properties-common) in Ubuntu 13.04 or newer) before using this module.
- This module works on Debian and Ubuntu only and requires C(add-apt-repository) be available on the destination server. To ensure this package is available use the M(apt) module and install the C(python-software-properties) package (or C(software-properties-common) in Ubuntu 13.04 or newer) before using this module.
- This module cannot be used on Debian Squeeze (Version 6) as there is no C(add-apt-repository) in C(python-software-properties)
- This module cannot be used on Debian Squeeze (Version 6) as there is no C(add-apt-repository) in C(python-software-properties)
- A bug in C(apt-add-repository) always adds C(deb) and C(deb-src) types for repositories (see the issue on Launchpad U(https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/987264)), if a repo doesn't have source information (eg MongoDB repo from 10gen) the system will fail while updating repositories.
- A bug in C(add-apt-repository) always adds C(deb) and C(deb-src) types for repositories (see the issue on Launchpad U(https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/987264)), if a repo doesn't have source information (eg MongoDB repo from 10gen) the system will fail while updating repositories.