Refresh the use of 'note' to make it consistent.

pull/1256/head
Tim Bielawa 12 years ago
parent d47a833a8d
commit fb5d2d10db

@ -148,9 +148,11 @@ Which could be executed just like this::
ansible webserver -m setup ansible webserver -m setup
ansible webserver -m template -a "src=/tmp/motd.j2 dest=/etc/motd" ansible webserver -m template -a "src=/tmp/motd.j2 dest=/etc/motd"
Note that the name 'webserver' came from cobbler, as did the variables for the config file. You can still .. note::
pass in your own variables like normal in Ansible, but variables from the external inventory script will The name 'webserver' came from cobbler, as did the variables for
override any that have the same name. the config file. You can still pass in your own variables like
normal in Ansible, but variables from the external inventory script
will override any that have the same name.
So, with the template above (motd.j2), this would result in the following data being written to /etc/motd for system 'foo':: So, with the template above (motd.j2), this would result in the following data being written to /etc/motd for system 'foo'::

@ -141,9 +141,11 @@ be processed through the shell, so variables like "$HOME" and
operations like "<", ">", "|", and "&" will not work. As such, all operations like "<", ">", "|", and "&" will not work. As such, all
paths to commands must be fully qualified. paths to commands must be fully qualified.
NOTE:: If you want to run a command through the shell (say you are using .. note::
'<', '>', '|', etc), you actually want the 'shell' module instead. If you want to run a command through the shell (say you are using
The 'command' module is much more secure as it's not affected by the user's environment. '<', '>', '|', etc), you actually want the 'shell' module instead.
The 'command' module is much more secure as it's not affected by
the user's environment.
Example action from Ansible :doc:`playbooks`:: Example action from Ansible :doc:`playbooks`::
@ -730,11 +732,12 @@ but runs the command through the user's configured shell on the remote node.
The given command will be executed on all selected nodes. The given command will be executed on all selected nodes.
NOTE:: If you want to execute a command securely and predicably, it may .. note::
be better to use the 'command' module instead. Best practices If you want to execute a command securely and predicably, it may be
when writing playbooks will follow the trend of using 'command' better to use the 'command' module instead. Best practices when
unless 'shell' is explicitly required. When running ad-hoc commands, writing playbooks will follow the trend of using 'command' unless
use your best judgement. 'shell' is explicitly required. When running ad-hoc commands, use
your best judgement.
Example action from a playbook:: Example action from a playbook::

@ -95,12 +95,18 @@ If you need to specify a password to sudo, run `ansible-playbook` with ``--ask-s
If you run a sudo playbook and the playbook seems to hang, it's probably stuck at the sudo prompt. If you run a sudo playbook and the playbook seems to hang, it's probably stuck at the sudo prompt.
Just `Control-C` to kill it and run it again with `-K`. Just `Control-C` to kill it and run it again with `-K`.
NOTE: When using `sudo_user` to a user other than root, the module arguments are briefly written into .. important::
a random tempfile in /tmp. These are deleted immediately after the command is executed. This only
occurs when sudoing from a user like 'bob' to 'timmy', not when going from 'bob' to 'root', or When using `sudo_user` to a user other than root, the module
logging in directly as 'bob' or 'root'. If this concerns you that this data is briefly readable arguments are briefly written into a random tempfile in /tmp.
(not writeable), avoid transferring uncrypted passwords with `sudo_user` set. In other cases, '/tmp' is not used and These are deleted immediately after the command is executed. This
this does not come into play. Ansible also takes care to not log password parameters. only occurs when sudoing from a user like 'bob' to 'timmy', not
when going from 'bob' to 'root', or logging in directly as 'bob' or
'root'. If this concerns you that this data is briefly readable
(not writeable), avoid transferring uncrypted passwords with
`sudo_user` set. In other cases, '/tmp' is not used and this does
not come into play. Ansible also takes care to not log password
parameters.
Vars section Vars section
++++++++++++ ++++++++++++
@ -318,12 +324,15 @@ of a play::
You can mix in includes along with your regular non-included tasks and handlers. You can mix in includes along with your regular non-included tasks and handlers.
NOTE:: you can not conditionally path the location to an include file, like you can .. note::
with 'vars_files'. If you find yourself needing to do this, consider how you can
restructure your playbook to be more class/role oriented. This is to say you cannot You can not conditionally path the location to an include file,
use a 'fact' to decide what include file to use. All hosts contained within the play like you can with 'vars_files'. If you find yourself needing to do
are going to get the same tasks. ('only_if' provides some ability for hosts to conditionally this, consider how you can restructure your playbook to be more
skip tasks). class/role oriented. This is to say you cannot use a 'fact' to
decide what include file to use. All hosts contained within the
play are going to get the same tasks. ('only_if' provides some
ability for hosts to conditionally skip tasks).
Executing A Playbook Executing A Playbook
```````````````````` ````````````````````

@ -83,8 +83,10 @@ assigned to another node, it's easy to do so within a template or even an action
${hostvars.hostname.factname} ${hostvars.hostname.factname}
NOTE: No database or other complex system is required to exchange data between hosts. The hosts that you .. note::
want to reference data from must be included in either the current play or any previous play. No database or other complex system is required to exchange data
between hosts. The hosts that you want to reference data from must
be included in either the current play or any previous play.
Additionally, *group_names* is a list (array) of all the groups the current host is in. This can be used in templates using Jinja2 syntax to make template source files that vary based on the group membership (or role) of the host:: Additionally, *group_names* is a list (array) of all the groups the current host is in. This can be used in templates using Jinja2 syntax to make template source files that vary based on the group membership (or role) of the host::
@ -140,7 +142,9 @@ The contents of each variables file is a simple YAML dictionary, like this::
somevar: somevalue somevar: somevalue
password: magic password: magic
NOTE: It's also possible to keep per-host and per-group variables in very similar files, this is covered in :ref:`patterns`. .. note::
It's also possible to keep per-host and per-group variables in very
similar files, this is covered in :ref:`patterns`.
Prompting For Sensitive Data Prompting For Sensitive Data
```````````````````````````` ````````````````````````````
@ -256,8 +260,9 @@ but it is easily handled with a minimum of syntax in an Ansible Playbook::
- name: make sure apache is running - name: make sure apache is running
action: service name=$apache state=running action: service name=$apache state=running
Note that a variable (`$facter_operatingsystem`) is being interpolated into the list of .. note::
filenames being defined for vars_files. The variable (`$facter_operatingsystem`) is being interpolated into
the list of filenames being defined for vars_files.
As a reminder, the various YAML files contain just keys and values:: As a reminder, the various YAML files contain just keys and values::

Loading…
Cancel
Save