mirror of
https://github.com/ansible-collections/community.general.git
synced 2024-09-14 20:13:21 +02:00
Update places we mention env vars to use :envvar: (#28887)
This commit is contained in:
parent
a7d5492ea3
commit
933298505a
10 changed files with 24 additions and 20 deletions
|
@ -167,7 +167,7 @@ the most popular are
|
||||||
To be able to view the arguments as passed by Ansible to the module follow
|
To be able to view the arguments as passed by Ansible to the module follow
|
||||||
these steps.
|
these steps.
|
||||||
|
|
||||||
- Prefix the Ansible command with ``ANSIBLE_KEEP_REMOTE_FILES=1`` to get Ansible to keep the exec files on the server
|
- Prefix the Ansible command with :envvar:`ANSIBLE_KEEP_REMOTE_FILES=1` to get Ansible to keep the exec files on the server
|
||||||
- Log onto the Windows server using the same user Ansible executed the module as
|
- Log onto the Windows server using the same user Ansible executed the module as
|
||||||
- Navigate to ``%TEMP%\..``, there should be a folder starting with ``ansible-tmp-``
|
- Navigate to ``%TEMP%\..``, there should be a folder starting with ``ansible-tmp-``
|
||||||
- Inside this folder open up the powershell script for the module
|
- Inside this folder open up the powershell script for the module
|
||||||
|
|
|
@ -149,7 +149,7 @@ How do I disable cowsay?
|
||||||
++++++++++++++++++++++++
|
++++++++++++++++++++++++
|
||||||
|
|
||||||
If cowsay is installed, Ansible takes it upon itself to make your day happier when running playbooks. If you decide
|
If cowsay is installed, Ansible takes it upon itself to make your day happier when running playbooks. If you decide
|
||||||
that you would like to work in a professional cow-free environment, you can either uninstall cowsay, or set an environment variable:
|
that you would like to work in a professional cow-free environment, you can either uninstall cowsay, or set the :envvar:`ANSIBLE_NOCOWS` environment variable:
|
||||||
|
|
||||||
.. code-block:: shell-session
|
.. code-block:: shell-session
|
||||||
|
|
||||||
|
@ -350,7 +350,7 @@ The no_log attribute can also apply to an entire play::
|
||||||
Though this will make the play somewhat difficult to debug. It's recommended that this
|
Though this will make the play somewhat difficult to debug. It's recommended that this
|
||||||
be applied to single tasks only, once a playbook is completed. Note that the use of the
|
be applied to single tasks only, once a playbook is completed. Note that the use of the
|
||||||
no_log attribute does not prevent data from being shown when debugging Ansible itself via
|
no_log attribute does not prevent data from being shown when debugging Ansible itself via
|
||||||
the ANSIBLE_DEBUG environment variable.
|
the :envvar:`ANSIBLE_DEBUG` environment variable.
|
||||||
|
|
||||||
|
|
||||||
.. _when_to_use_brackets:
|
.. _when_to_use_brackets:
|
||||||
|
|
|
@ -41,7 +41,7 @@ Use the ``ansible-galaxy`` command to download roles from the `Galaxy website <h
|
||||||
roles_path
|
roles_path
|
||||||
==========
|
==========
|
||||||
|
|
||||||
Be aware that by default Ansible downloads roles to the path specified by the environment variable *ANSIBLE_ROLES_PATH*. This can be set to a series of
|
Be aware that by default Ansible downloads roles to the path specified by the environment variable :envvar:`ANSIBLE_ROLES_PATH`. This can be set to a series of
|
||||||
directories (i.e. */etc/ansible/roles:~/.ansible/roles*), in which case the first writable path will be used. When Ansible is first installed it defaults
|
directories (i.e. */etc/ansible/roles:~/.ansible/roles*), in which case the first writable path will be used. When Ansible is first installed it defaults
|
||||||
to */etc/ansible/roles*, which requires *root* privileges.
|
to */etc/ansible/roles*, which requires *root* privileges.
|
||||||
|
|
||||||
|
|
|
@ -526,7 +526,7 @@ is a directory with multiple sources (static and dynamic)::
|
||||||
|
|
||||||
inventory_ignore_extensions = ~, .orig, .bak, .ini, .cfg, .retry, .pyc, .pyo
|
inventory_ignore_extensions = ~, .orig, .bak, .ini, .cfg, .retry, .pyc, .pyo
|
||||||
|
|
||||||
This option can be overridden by setting ``ANSIBLE_INVENTORY_IGNORE``
|
This option can be overridden by setting :envvar:`ANSIBLE_INVENTORY_IGNORE`
|
||||||
environment variable.
|
environment variable.
|
||||||
|
|
||||||
.. _jinja2_extensions:
|
.. _jinja2_extensions:
|
||||||
|
@ -786,7 +786,7 @@ restrict_facts_namespace
|
||||||
.. versionadded:: 2.4
|
.. versionadded:: 2.4
|
||||||
|
|
||||||
This allows restricting facts in their own namespace (under ansible_facts) instead of pushing them into the main.
|
This allows restricting facts in their own namespace (under ansible_facts) instead of pushing them into the main.
|
||||||
False by default. Can also be set via the environment variable `ANSIBLE_RESTRICT_FACTS`. Using `ansible_system` as an example:
|
False by default. Can also be set via the environment variable :envvar:`ANSIBLE_RESTRICT_FACTS`. Using `ansible_system` as an example:
|
||||||
|
|
||||||
When False::
|
When False::
|
||||||
|
|
||||||
|
|
|
@ -348,7 +348,7 @@ In an inventory directory, executable files will be treated as dynamic inventory
|
||||||
|
|
||||||
~, .orig, .bak, .ini, .cfg, .retry, .pyc, .pyo
|
~, .orig, .bak, .ini, .cfg, .retry, .pyc, .pyo
|
||||||
|
|
||||||
You can replace this list with your own selection by configuring an ``inventory_ignore_extensions`` list in ansible.cfg, or setting the ANSIBLE_INVENTORY_IGNORE environment variable. The value in either case should be a comma-separated list of patterns, as shown above.
|
You can replace this list with your own selection by configuring an ``inventory_ignore_extensions`` list in ansible.cfg, or setting the :envvar:`ANSIBLE_INVENTORY_IGNORE` environment variable. The value in either case should be a comma-separated list of patterns, as shown above.
|
||||||
|
|
||||||
Any ``group_vars`` and ``host_vars`` subdirectories in an inventory directory will be interpreted as expected, making inventory directories a powerful way to organize different sets of configurations.
|
Any ``group_vars`` and ``host_vars`` subdirectories in an inventory directory will be interpreted as expected, making inventory directories a powerful way to organize different sets of configurations.
|
||||||
|
|
||||||
|
|
|
@ -135,7 +135,7 @@ If you understand the implications and wish to disable this behavior, you can do
|
||||||
[defaults]
|
[defaults]
|
||||||
host_key_checking = False
|
host_key_checking = False
|
||||||
|
|
||||||
Alternatively this can be set by an environment variable:
|
Alternatively this can be set by the :envvar:`ANSIBLE_HOST_KEY_CHECKING` environment variable:
|
||||||
|
|
||||||
.. code-block:: bash
|
.. code-block:: bash
|
||||||
|
|
||||||
|
|
|
@ -140,11 +140,15 @@ Networking Environment Variables
|
||||||
|
|
||||||
The following environment variables are available to Ansible networking modules:
|
The following environment variables are available to Ansible networking modules:
|
||||||
|
|
||||||
username ANSIBLE_NET_USERNAME
|
username :envvar:`ANSIBLE_NET_USERNAME`
|
||||||
password ANSIBLE_NET_PASSWORD
|
|
||||||
ssh_keyfile ANSIBLE_NET_SSH_KEYFILE
|
password :envvar:`ANSIBLE_NET_PASSWORD`
|
||||||
authorize ANSIBLE_NET_AUTHORIZE
|
|
||||||
auth_pass ANSIBLE_NET_AUTH_PASS
|
ssh_keyfile :envvar:`ANSIBLE_NET_SSH_KEYFILE`
|
||||||
|
|
||||||
|
authorize :envvar:`ANSIBLE_NET_AUTHORIZE`
|
||||||
|
|
||||||
|
auth_pass :envvar:`ANSIBLE_NET_AUTH_PASS`
|
||||||
|
|
||||||
Variables are evaulated in the following order, listed from lowest to highest priority:
|
Variables are evaulated in the following order, listed from lowest to highest priority:
|
||||||
|
|
||||||
|
|
|
@ -51,7 +51,7 @@ Enabling Networking logging and how to read the logfile
|
||||||
|
|
||||||
Ansible 2.3 features improved logging to help diagnose and troubleshoot issues regarding Ansible Networking modules.
|
Ansible 2.3 features improved logging to help diagnose and troubleshoot issues regarding Ansible Networking modules.
|
||||||
|
|
||||||
Because logging is very verbose it is disabled by default. It can be enabled via the ``ANSIBLE_LOG_PATH`` and ``ANISBLE_DEBUG`` options::
|
Because logging is very verbose it is disabled by default. It can be enabled via the :envvar:`ANSIBLE_LOG_PATH` and :envvar:`ANISBLE_DEBUG` options::
|
||||||
|
|
||||||
# Specify the location for the log file
|
# Specify the location for the log file
|
||||||
export ANSIBLE_LOG_PATH=~/ansible.log
|
export ANSIBLE_LOG_PATH=~/ansible.log
|
||||||
|
@ -143,7 +143,7 @@ Category "Unable to open shell"
|
||||||
|
|
||||||
**Platforms:** Any
|
**Platforms:** Any
|
||||||
|
|
||||||
The ``unable to open shell`` message is new in Ansible 2.3. This message means that the ``ansible-connection`` daemon has not been able to successfully talk to the remote network device. This generally means that there is an authentication issue. It is a "catch all" message, meaning you need to enable ``ANSIBLE_LOG_PATH`` to find the underlying issues.
|
The ``unable to open shell`` message is new in Ansible 2.3. This message means that the ``ansible-connection`` daemon has not been able to successfully talk to the remote network device. This generally means that there is an authentication issue. It is a "catch all" message, meaning you need to enable :ref:`log_path` to find the underlying issues.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
@ -222,7 +222,7 @@ For example:
|
||||||
|
|
||||||
Suggestions to resolve:
|
Suggestions to resolve:
|
||||||
|
|
||||||
If you are specifying credentials via ``password:`` (either directly or via ``provider:``) or the environment variable ``ANSIBLE_NET_PASSWORD`` it is possible that ``paramiko`` (the Python SSH library that Ansible uses) is using ssh keys, and therefore the credentials you are specifying are being ignored. To find out if this is the case, disable "look for keys". This can be done like this:
|
If you are specifying credentials via ``password:`` (either directly or via ``provider:``) or the environment variable :envvar:`ANSIBLE_NET_PASSWORD` it is possible that ``paramiko`` (the Python SSH library that Ansible uses) is using ssh keys, and therefore the credentials you are specifying are being ignored. To find out if this is the case, disable "look for keys". This can be done like this:
|
||||||
|
|
||||||
.. code-block:: yaml
|
.. code-block:: yaml
|
||||||
|
|
||||||
|
@ -490,7 +490,7 @@ Add ``authorize: yes`` to the task. For example:
|
||||||
authorize: yes
|
authorize: yes
|
||||||
register: result
|
register: result
|
||||||
|
|
||||||
If the user requires a password to go into privileged mode, this can be specified with ``auth_pass``; if ``auth_pass`` isn't set, the environment variable ``ANSIBLE_NET_AUTHORIZE`` will be used instead.
|
If the user requires a password to go into privileged mode, this can be specified with ``auth_pass``; if ``auth_pass`` isn't set, the environment variable :envvar:`ANSIBLE_NET_AUTHORIZE` will be used instead.
|
||||||
|
|
||||||
|
|
||||||
Add `authorize: yes` to the task. For example:
|
Add `authorize: yes` to the task. For example:
|
||||||
|
@ -527,7 +527,7 @@ Add `authorize: yes` to the task. For example:
|
||||||
This occurs when Ansible wasn't able to connect to the remote device and obtain a shell with the timeout.
|
This occurs when Ansible wasn't able to connect to the remote device and obtain a shell with the timeout.
|
||||||
|
|
||||||
|
|
||||||
This information is available when ``ANSIBLE_LOG_PATH`` is set see (FIXMELINKTOSECTION):
|
This information is available when :ref:`DEFAULT_LOG_PATH` is set see (FIXMELINKTOSECTION):
|
||||||
|
|
||||||
.. code-block:: yaml
|
.. code-block:: yaml
|
||||||
|
|
||||||
|
|
|
@ -62,7 +62,7 @@ If you wish to change the port Ansible will use for the accelerated connection,
|
||||||
# default port is 5099
|
# default port is 5099
|
||||||
accelerate_port: 10000
|
accelerate_port: 10000
|
||||||
|
|
||||||
The `accelerate_port` option can also be specified in the environment variable ACCELERATE_PORT, or in your `ansible.cfg` configuration::
|
The `accelerate_port` option can also be specified in the environment variable :envvar:`ACCELERATE_PORT`, or in your `ansible.cfg` configuration::
|
||||||
|
|
||||||
[accelerate]
|
[accelerate]
|
||||||
accelerate_port = 5099
|
accelerate_port = 5099
|
||||||
|
|
|
@ -95,7 +95,7 @@ uses key=value escaping which has not changed. The other option is to check for
|
||||||
* templating (variables in playbooks and template lookups) has improved with regard to keeping the original instead of turning everything into a string.
|
* templating (variables in playbooks and template lookups) has improved with regard to keeping the original instead of turning everything into a string.
|
||||||
If you need the old behavior, quote the value to pass it around as a string.
|
If you need the old behavior, quote the value to pass it around as a string.
|
||||||
* Empty variables and variables set to null in yaml are no longer converted to empty strings. They will retain the value of `None`.
|
* Empty variables and variables set to null in yaml are no longer converted to empty strings. They will retain the value of `None`.
|
||||||
You can override the `null_representation` setting to an empty string in your config file by setting the `ANSIBLE_NULL_REPRESENTATION` environment variable.
|
You can override the `null_representation` setting to an empty string in your config file by setting the :envvar:`ANSIBLE_NULL_REPRESENTATION` environment variable.
|
||||||
* Extras callbacks must be whitelisted in ansible.cfg. Copying is no longer necessary but whitelisting in ansible.cfg must be completed.
|
* Extras callbacks must be whitelisted in ansible.cfg. Copying is no longer necessary but whitelisting in ansible.cfg must be completed.
|
||||||
* dnf module has been rewritten. Some minor changes in behavior may be observed.
|
* dnf module has been rewritten. Some minor changes in behavior may be observed.
|
||||||
* win_updates has been rewritten and works as expected now.
|
* win_updates has been rewritten and works as expected now.
|
||||||
|
|
Loading…
Reference in a new issue