@ -96,7 +96,7 @@ documentation. The `remote_user` is just the name of the user account::
- hosts: webservers
- hosts: webservers
remote_user: root
remote_user: root
..Note::
..note::
The `remote_user` parameter was formerly called just `user`. It was renamed in Ansible 1.4 to make it more distinguishable from the `user` module (used to create users on remote systems).
The `remote_user` parameter was formerly called just `user`. It was renamed in Ansible 1.4 to make it more distinguishable from the `user` module (used to create users on remote systems).
@ -110,7 +110,7 @@ Remote users can also be defined per task::
ping:
ping:
remote_user: yourname
remote_user: yourname
..Note::
..note::
The `remote_user` parameter for tasks was added in 1.4.
The `remote_user` parameter for tasks was added in 1.4.
@ -110,7 +110,7 @@ it's more than that -- you can also read variables about other hosts. We'll sho
Jinja2 Filters
Jinja2 Filters
``````````````
``````````````
.. note: These are infrequently utilized features. Use them if they fit a use case you have, but this is optional knowledge.
..note:: These are infrequently utilized features. Use them if they fit a use case you have, but this is optional knowledge.
Filters in Jinja2 are a way of transforming template expressions from one kind of data into another. Jinja2
Filters in Jinja2 are a way of transforming template expressions from one kind of data into another. Jinja2
ships with many of these as documented on the official Jinja2 template documentation.
ships with many of these as documented on the official Jinja2 template documentation.
@ -737,7 +737,7 @@ or in a file as above.
Conditional Imports
Conditional Imports
```````````````````
```````````````````
.. note: this behavior is infrequently used in Ansible. You may wish to skip this section. The 'group_by' module as described in the module documentation is a better way to achieve this behavior in most cases.
..note:: This behavior is infrequently used in Ansible. You may wish to skip this section. The 'group_by' module as described in the module documentation is a better way to achieve this behavior in most cases.
Sometimes you will want to do certain things differently in a playbook based on certain criteria.
Sometimes you will want to do certain things differently in a playbook based on certain criteria.
Having one playbook that works on multiple platforms and OS versions is a good example.
Having one playbook that works on multiple platforms and OS versions is a good example.