mirror of
https://github.com/ansible-collections/community.general.git
synced 2024-09-14 20:13:21 +02:00
fix some docsite's rst syntax error.
This commit is contained in:
parent
fce9f4f679
commit
e6466339e5
5 changed files with 5 additions and 5 deletions
|
@ -134,7 +134,7 @@ with a "{", YAML will think it is a dictionary, so you must quote it, like so::
|
|||
|
||||
foo: "{{ variable }}"
|
||||
|
||||
The same applies for strings that start or contain any YAML special characters `` [] {} : > | `` .
|
||||
The same applies for strings that start or contain any YAML special characters ``[] {} : > |`` .
|
||||
|
||||
Boolean conversion is helpful, but this can be a problem when you want a literal `yes` or other boolean values as a string.
|
||||
In these cases just use quotes::
|
||||
|
|
|
@ -404,7 +404,7 @@ This is a boolean that turns on more verbose logging. If a module uses
|
|||
:py:meth:`AnsibleModule.debug` rather than :py:meth:`AnsibleModule.log` then
|
||||
the messages are only logged if this is True. This also turns on logging of
|
||||
external commands that the module executes. This can be changed via
|
||||
the``debug`` setting in :file:`ansible.cfg` or the environment variable
|
||||
the ``debug`` setting in :file:`ansible.cfg` or the environment variable
|
||||
:envvar:`ANSIBLE_DEBUG`. If, for some reason, a module must access this, it
|
||||
should do so by instantiating an :class:`AnsibleModule` and accessing
|
||||
:attr:`AnsibleModule._debug`.
|
||||
|
|
|
@ -130,7 +130,7 @@ Below you see an example how it can be used in combination with Ansible's block
|
|||
CLOUDSTACK_PROJECT: web-app
|
||||
CLOUDSTACK_ZONE: sf-1
|
||||
|
||||
.. Note:: You are still able overwrite the environment variables using the module arguments, e.g.``zone: sf-2``
|
||||
.. Note:: You are still able overwrite the environment variables using the module arguments, e.g. ``zone: sf-2``
|
||||
|
||||
.. Note:: Unlike ``CLOUDSTACK_REGION`` these additional environment variables are ingored in the CLI ``cs``.
|
||||
|
||||
|
|
|
@ -136,7 +136,7 @@ If you use Boto profiles to manage multiple AWS accounts, you can pass ``--profi
|
|||
You can then run ``ec2.py --profile prod`` to get the inventory for the prod account, although this option is not supported by ``ansible-playbook``.
|
||||
You can also use the ``AWS_PROFILE`` variable - for example: ``AWS_PROFILE=prod ansible-playbook -i ec2.py myplaybook.yml``
|
||||
|
||||
Since each region requires its own API call, if you are only using a small set of regions, you can edit the``ec2.ini`` file and comment out the regions you are not using.
|
||||
Since each region requires its own API call, if you are only using a small set of regions, you can edit the ``ec2.ini`` file and comment out the regions you are not using.
|
||||
|
||||
There are other config options in ``ec2.ini``, including cache control and destination variables. By default, the ``ec2.ini`` file is configured for **all Amazon cloud services**, but you can comment out any features that aren't applicable. For example, if you don't have ``RDS`` or ``elasticache``, you can set them to ``False`` ::
|
||||
|
||||
|
|
|
@ -176,7 +176,7 @@ Attention for the older style variables (``ansible_ssh_*``): ansible_ssh_passwor
|
|||
|
||||
Although Ansible is mostly an SSH-oriented system, Windows management will not happen over SSH (`yet <http://blogs.msdn.com/b/powershell/archive/2015/06/03/looking-forward-microsoft-support-for-secure-shell-ssh.aspx>`).
|
||||
|
||||
If you have installed the ``kerberos`` module and ``ansible_user`` contains ``@`` (e.g. ``username@realm``), Ansible will first attempt Kerberos authentication. *This method uses the principal you are authenticated to Kerberos with on the control machine and not ``ansible_user``*. If that fails, either because you are not signed into Kerberos on the control machine or because the corresponding domain account on the remote host is not available, then Ansible will fall back to "plain" username/password authentication.
|
||||
If you have installed the ``kerberos`` module and ``ansible_user`` contains ``@`` (e.g. ``username@realm``), Ansible will first attempt Kerberos authentication. *This method uses the principal you are authenticated to Kerberos with on the control machine and not* ``ansible_user``. If that fails, either because you are not signed into Kerberos on the control machine or because the corresponding domain account on the remote host is not available, then Ansible will fall back to "plain" username/password authentication.
|
||||
|
||||
When using your playbook, don't forget to specify --ask-vault-pass to provide the password to unlock the file.
|
||||
|
||||
|
|
Loading…
Reference in a new issue