Ansible cfg где находится

Конфигурационный файл#

Настройки Ansible можно менять в конфигурационном файле.

Конфигурационный файл Ansible может храниться в разных местах (файлы перечислены в порядке уменьшения приоритета):

ANSIBLE_CONFIG (переменная окружения)
ansible.cfg (в текущем каталоге)
~/.ansible.cfg (в домашнем каталоге пользователя)
/etc/ansible/ansible.cfg

Ansible ищет файл конфигурации в указанном порядке и использует первый найденный (конфигурация из разных файлов не совмещается).

В конфигурационном файле можно менять множество параметров. Полный список параметров и их описание можно найти в документации.

В текущем каталоге должен быть инвентарный файл myhosts.ini:

[cisco_routers] 192.168.100.1 192.168.100.2 192.168.100.3

В текущем каталоге надо создать такой конфигурационный файл ansible.cfg:

[defaults] inventory = ./myhosts.ini remote_user = cisco ask_pass = True

Настройки в конфигурационном файле:

[defaults] — эта секция конфигурации описывает общие параметры по умолчанию
inventory = ./myhosts — параметр inventory позволяет указать местоположение инвентарного файла. Если настроить этот параметр, не придется указывать, где находится файл, при каждом запуске Ansible
remote_user = cisco — от имени какого пользователя будет подключаться Ansible
ask_pass = True — этот параметр аналогичен опции –ask-pass в командной строке. Если он выставлен в конфигурации Ansible, то уже не нужно указывать его в командной строке.

Теперь вызов ad-hoc команды будет выглядеть так:

$ ansible 192.168.100.1 -m ios_command -a "commands='sh ip int br'"

gathering#

По умолчанию Ansible собирает факты об устройствах.

Факты — это информация о хостах, к которым подключается Ansible. Эти факты можно использовать в playbook и шаблонах как переменные.

Сбором фактов, по умолчанию, занимается модуль setup.

Но для сетевого оборудования модуль setup не подходит, поэтому сбор фактов надо отключить. Это можно сделать в конфигурационном файле Ansible или в playbook.

Для сетевого оборудования нужно использовать отдельные модули для сбора фактов (если они есть). Это рассматривается в разделе ios_facts.

Отключение сбора фактов в конфигурационном файле:

gathering = explicit

host_key_checking#

Параметр host_key_checking отвечает за проверку ключей при подключении по SSH. Если указать в конфигурационном файле host_key_checking=False , проверка будет отключена.

Это полезно, когда с управляющего хоста Ansible надо подключиться к большому количеству устройств первый раз.

Другие параметры конфигурационного файла можно посмотреть в документации. Пример конфигурационного файла в репозитории Ansible.

Ansible: hosts и ansible.cfg. Lesson 1

Ansible с чего начать? Первые уроки: hosts и ansible.cfg

Уважаемые читатели, в данной статье разберем основы при работе с Ansible. Материал будет интересен в первую очередь новичкам. Для начала рекомендуем также прочитать данные 2 статьи:

Установка Ansible на Debian
Установка и настройка SSH для авторизации без пароля

* Здесь мы не будем затрагивать вопрос установки, и настройки SSH соединения с серверами (об этом есть материал выше).

1. Ansible — что это и для чего? Разбираем основы
Если вы только установили Ansible, необходимо перейти в его каталог и проверить содержимое:

Ansible — это система управления конфигурациями, написанная на Python. Более простым языком: это универсальный инструмент позволяющий выполнять некий структурированный список команд (написанный на языке YML, в виде скрипта) на нескольких серверах.
Если у вас несколько серверов 5. 100, то при попытке даже простого обновления пакетов, вы потеряете уйму времени на подключение к каждому из этих серверов по отдельности. Ansible дает универсальное средство решить данную проблему, как? читаем дальше!

2. Настройка файла hosts под наши сервера
Прежде всего нам надо настроить список наших серверов, на которые мы будем отправлять наши данные. Для этого заходим в файл hosts:

Содержимое файла hosts будем примерно таким:

Допустим у нас есть сервера c IP 192.168.0.10 и 192.168.0.20 (локальный). Добавим наши сервера в файл выше и укажем данные для подключения к ним (пояснения прямо в коде):

Пример заполнения выше, с данными пользователя, не совсем корректный. Лучше использовать SSH. О том как его настроить, ссылка на статью в самом начале. Смотрим где у нас находится ключ SSH:

Вносим эти данные в наш файл hosts:

Можно попробывать подключиться к серверу. Есть один момент, при подключении первый раз к серверу он спросит отпечаток: «Are you sure you want to continue connecting (yes/no)». После подтверждения, он больше не спрашивает. Но если вы подключаетесь первый раз к 100 серверам, то придеться отвечать по каждому. Простая команда для примера:

Чтобы отменить проверку отпечатка на каждый сервер и не прописывать файл сервера, заполняем файл ansible.cfg. Обычно эти значения уже есть в шаблоне, надо только их раскомментировать:

Повторяем команду выше, но уже сокращенный вариант:

3. Создаем файл inventory или hosts

Допустим у вас много серверов: сервера баз, сервера приложений, сервера итогового проекта PROD. Тогда это можно записать в файл hosts в разных вариантах:

Тем самым, вот так просто вы можем составлять группы, а в созданные группы еще группы. Это удобно, главное не переборщить.

Теперь объединим данные для авторизации для серверов debi:

Или в виде графа:

4. Выносим общие переменные из файла hosts
В пункте 3 мы вынесли общие переменные с данными пользователя в отдельный блок. Но на практике, такие данные более професионально выносить в отдельный файл. Это мы сейчас и сделаем:

Проверям что у нас в каталоге Ansible:

Создаем директорию group_vars и переходим в неё:

Создаем файл с нашим именем группы серверов debi_servers:

Сохраняем. В файле hosts эти строчки полностью стираете:

Стал чистый файл hosts который содержит только сервера и группы серверов. Все данные с vars теперь в отдельном файле, расположенном в директории group_vars. Так и должно быть, это более профессиональное написание.

На этом статья заканчивается, продолжение читаем в следующих статьях!

Источник: http://linuxsql.ru

Can’t find the config file in “/etc/ansible/” on Mac OS X

At any rate, from what I’m reading there should be a config file in /etc/ansible/ , but the content of that directory is just:

$ ls -a /etc/ansible/ . .. .hosts.swp hosts roles

It doesn’t look like there’s an environment variable defined either:

$ echo $ANSIBLE_CONFIG # blank line

Ansible works as far as I can tell (without a local ansible.cfg , and there’s nothing in the ansible folder in the user dir), but I’m confounded. Can someone please explain what I’m not getting here?

53.3k 20 20 gold badges 163 163 silver badges 212 212 bronze badges
asked Sep 19, 2015 at 17:11
469 2 2 gold badges 5 5 silver badges 14 14 bronze badges

4 Answers 4

From what I know the Ansible config file ( ansible.cfg ) might be located here for user-level configuration settings:

~/.ansible.cfg

As well as the system-wide config located here; where you state you can’t find any such file:

 /etc/ansible/ansible.cfg

If somehow you have multiple users on your system, perhaps there is a ~/.ansible.cfg floating in one of their user directories you have forgotten about?

You state you might have installed it using pip , but checking the Homebrew formula for Ansible, it was only recently bumped from version 1.9.2 to 1.9.3 on September 4th. So perhaps you installed it via Homebrew?

And your main concern seems to be whether the ansible.cfg is necessary:

Ansible works as far as I can tell (without a local ansible.cfg , and there’s nothing in the ansible folder in the user dir), but I’m confounded.

Can someone please explain what I’m not getting here?

Yes, it should work fine without a configuration. For most pieces of software all a config file does is override the core system defaults. So if ansible.cfg is missing, Ansible would still work but only be using the core system defaults. As explained in Ansible’s official documentation:

Certain settings in Ansible are adjustable via a configuration file. The stock configuration should be sufficient for most users, but there may be reasons you would want to change them.

Changes can be made and used in a configuration file which will be processed in the following order:

* ANSIBLE_CONFIG (an environment variable) * ansible.cfg (in the current directory) * .ansible.cfg (in the home directory) * /etc/ansible/ansible.cfg

Ansible Configuration Settings

Ansible supports several sources for configuring its behavior, including an ini file named ansible.cfg , environment variables, command-line options, playbook keywords, and variables. See Controlling how Ansible behaves: precedence rules for details on the relative precedence of each source.

The ansible-config utility allows users to see all the configuration settings available, their defaults, how to set them and where their current value comes from. See ansible-config for more information.

The configuration file

Changes can be made and used in a configuration file which will be searched for in the following order:

ANSIBLE_CONFIG (environment variable if set)
ansible.cfg (in the current directory)
~/.ansible.cfg (in the home directory)
/etc/ansible/ansible.cfg

Ansible will process the above list and use the first file found, all others are ignored.

The configuration file is one variant of an INI format. Both the hash sign ( # ) and semicolon ( ; ) are allowed as comment markers when the comment starts the line. However, if the comment is inline with regular values, only the semicolon is allowed to introduce the comment. For instance:

# some basic default values. inventory = /etc/ansible/hosts ; This points to the file that lists your hosts

Generating a sample ansible.cfg file

You can generate a fully commented-out example ansible.cfg file, for example:

$ ansible-config init --disabled > ansible.cfg

You can also have a more complete file that includes existing plugins:

$ ansible-config init --disabled -t all > ansible.cfg

You can use these as starting points to create your own ansible.cfg file.

Avoiding security risks with ansible.cfg in the current directory

If Ansible were to load ansible.cfg from a world-writable current working directory, it would create a serious security risk. Another user could place their own config file there, designed to make Ansible run malicious code both locally and remotely, possibly with elevated privileges. For this reason, Ansible will not automatically load a config file from the current working directory if the directory is world-writable.

If you depend on using Ansible with a config file in the current working directory, the best way to avoid this problem is to restrict access to your Ansible directories to particular user(s) and/or group(s). If your Ansible directories live on a filesystem which has to emulate Unix permissions, like Vagrant or Windows Subsystem for Linux (WSL), you may, at first, not know how you can fix this as chmod , chown , and chgrp might not work there. In most of those cases, the correct fix is to modify the mount options of the filesystem so the files and directories are readable and writable by the users and groups running Ansible but closed to others. For more details on the correct settings, see:

for Vagrant, the Vagrant documentation covers synced folder permissions.
for WSL, the WSL docs and this Microsoft blog post cover mount options.

If you absolutely depend on storing your Ansible config in a world-writable current working directory, you can explicitly specify the config file via the ANSIBLE_CONFIG environment variable. Please take appropriate steps to mitigate the security concerns above before doing so.

Relative paths for configuration

You can specify a relative path for many configuration options. In most of those cases the path used will be relative to the ansible.cfg file used for the current execution. If you need a path relative to your current working directory (CWD) you can use the > macro to specify it. We do not recommend this approach, as using your CWD as the root of relative paths can be a security risk. For example: cd /tmp; secureinfo=./newrootpassword ansible-playbook ~/safestuff/change_root_pwd.yml .

Common Options

This is a copy of the options available from our release, your local install might have extra options due to additional plugins, you can use the command line utility mentioned above ( ansible-config ) to browse through those.

ACTION_WARNINGS

Description :

By default Ansible will issue a warning when received from a task action (module or action plugin) These warnings can be silenced by adjusting this setting to False.

AGNOSTIC_BECOME_PROMPT

Description :

Display an agnostic become prompt instead of displaying a prompt containing the command line supplied become method

ANSIBLE_CONNECTION_PATH

Description :

Specify where to look for the ansible-connection script. This location will be checked before searching $PATH. If null, ansible will start with the same directory as the ansible script.

ANSIBLE_COW_ACCEPTLIST

Description :

Accept list of cowsay templates that are ‘safe’ to use, set to empty list if you want to enable all installed templates.

[‘bud-frogs’, ‘bunny’, ‘cheese’, ‘daemon’, ‘default’, ‘dragon’, ‘elephant-in-snake’, ‘elephant’, ‘eyes’, ‘hellokitty’, ‘kitty’, ‘luke-koala’, ‘meow’, ‘milk’, ‘moofasa’, ‘moose’, ‘ren’, ‘sheep’, ‘small’, ‘stegosaurus’, ‘stimpy’, ‘supermilker’, ‘three-eyes’, ‘turkey’, ‘turtle’, ‘tux’, ‘udder’, ‘vader-koala’, ‘vader’, ‘www’]

cowsay_enabled_stencils :Version Added: 2.11

ANSIBLE_COW_PATH

Description :

Specify a custom cowsay path or swap in your cowsay implementation of choice

ANSIBLE_COW_SELECTION

Description :

This allows you to chose a specific cowsay stencil for the banners or use ‘random’ to cycle through them.

ANSIBLE_FORCE_COLOR

Description :

This option forces color mode even when running without a TTY or the “nocolor” setting is True.

ANSIBLE_HOME

Description :

The default root path for Ansible config files on the controller.

ANSIBLE_NOCOLOR

Description :

This setting allows suppressing colorizing output, which is used to give a better indication of failure and status information.

Variable : ANSIBLE_NOCOLOR
Variable : NO_COLOR Version Added : 2.11

ANSIBLE_NOCOWS

Description :

If you have cowsay installed but want to avoid the ‘cows’ (why. ), use this.

ANSIBLE_PIPELINING

Description :

This is a global option, each connection plugin can override either by having more specific options or not supporting pipelining at all. Pipelining, if supported by the connection plugin, reduces the number of network operations required to execute a module on the remote server, by executing many Ansible modules without actual file transfer. It can result in a very significant performance improvement when enabled. However this conflicts with privilege escalation (become). For example, when using ‘sudo:’ operations you must first disable ‘requiretty’ in /etc/sudoers on all managed hosts, which is why it is disabled by default. This setting will be disabled if ANSIBLE_KEEP_REMOTE_FILES is enabled.

Section : [connection] Key : pipelining
Section : [defaults] Key : pipelining

ANY_ERRORS_FATAL

Description :

Sets the default value for the any_errors_fatal keyword, if True, Task failures will be considered fatal errors.

BECOME_ALLOW_SAME_USER

Description :

This setting controls if become is skipped when remote user and become user are the same. I.E root sudo to root. If executable, it will be run and the resulting stdout will be used as the password.

BECOME_PASSWORD_FILE

Description :

The password file to use for the become plugin. –become-password-file. If executable, it will be run and the resulting stdout will be used as the password.

BECOME_PLUGIN_PATH

Description :

Colon separated paths in which Ansible will search for Become Plugins.

CACHE_PLUGIN

Description :

Chooses which cache plugin to use, the default ‘memory’ is ephemeral.

CACHE_PLUGIN_CONNECTION

Description :

Defines connection or path information for the cache plugin

CACHE_PLUGIN_PREFIX

Description :

Prefix to use for cache plugin files/tables

CACHE_PLUGIN_TIMEOUT

Description :

Expiration timeout for the cache plugin data

CALLBACKS_ENABLED

Description :

List of enabled callbacks, not all callbacks need enabling, but many of those shipped with Ansible do as we don’t want them activated by default.

callbacks_enabled :Version Added: 2.11

COLLECTIONS_ON_ANSIBLE_VERSION_MISMATCH

Description :

When a collection is loaded that does not support the running Ansible version (with the collection metadata key requires_ansible ).

error : issue a ‘fatal’ error and stop the play
warning : issue a warning but continue
ignore : just continue silently

COLLECTIONS_PATHS

Description :

Colon separated paths in which Ansible will search for collections content. Collections must be in nested subdirectories, not directly in these directories. For example, if COLLECTIONS_PATHS includes ‘>’ , and you want to add my.collection to that directory, it must be saved as ‘ ~ «/collections/ansible_collections/my/collection» >>’ .

Section : [defaults] Key : collections_paths
Section : [defaults] Key : collections_path Version Added : 2.10

Variable : ANSIBLE_COLLECTIONS_PATH Version Added : 2.10
Variable : ANSIBLE_COLLECTIONS_PATHS

COLLECTIONS_SCAN_SYS_PATH

Description :

A boolean to enable or disable scanning the sys.path for installed collections

COLOR_CHANGED

Description :

Defines the color to use on ‘Changed’ task status

black
bright gray
blue
white
green
bright blue
cyan
bright green
red
bright cyan
purple
bright red
yellow
bright purple
dark gray
bright yellow
magenta
bright magenta
normal

COLOR_CONSOLE_PROMPT

Description :

Defines the default color to use for ansible-console

black
bright gray
blue
white
green
bright blue
cyan
bright green
red
bright cyan
purple
bright red
yellow
bright purple
dark gray
bright yellow
magenta
bright magenta
normal

COLOR_DEBUG

Description :

Defines the color to use when emitting debug messages

black
bright gray
blue
white
green
bright blue
cyan
bright green
red
bright cyan
purple
bright red
yellow
bright purple
dark gray
bright yellow
magenta
bright magenta
normal

COLOR_DEPRECATE

Description :

Defines the color to use when emitting deprecation messages

black
bright gray
blue
white
green
bright blue
cyan
bright green
red
bright cyan
purple
bright red
yellow
bright purple
dark gray
bright yellow
magenta
bright magenta
normal

COLOR_DIFF_ADD

Description :

Defines the color to use when showing added lines in diffs

black
bright gray
blue
white
green
bright blue
cyan
bright green
red
bright cyan
purple
bright red
yellow
bright purple
dark gray
bright yellow
magenta
bright magenta
normal

COLOR_DIFF_LINES

Description :

Defines the color to use when showing diffs

black
bright gray
blue
white
green
bright blue
cyan
bright green
red
bright cyan
purple
bright red
yellow
bright purple
dark gray
bright yellow
magenta
bright magenta
normal

COLOR_DIFF_REMOVE

Description :

Defines the color to use when showing removed lines in diffs

black
bright gray
blue
white
green
bright blue
cyan
bright green
red
bright cyan
purple
bright red
yellow
bright purple
dark gray
bright yellow
magenta
bright magenta
normal

COLOR_ERROR

Description :

Defines the color to use when emitting error messages

black
bright gray
blue
white
green
bright blue
cyan
bright green
red
bright cyan
purple
bright red
yellow
bright purple
dark gray
bright yellow
magenta
bright magenta
normal

COLOR_HIGHLIGHT

Description :

Defines the color to use for highlighting

black
bright gray
blue
white
green
bright blue
cyan
bright green
red
bright cyan
purple
bright red
yellow
bright purple
dark gray
bright yellow
magenta
bright magenta
normal

COLOR_OK

Description :

Defines the color to use when showing ‘OK’ task status

black
bright gray
blue
white
green
bright blue
cyan
bright green
red
bright cyan
purple
bright red
yellow
bright purple
dark gray
bright yellow
magenta
bright magenta
normal

COLOR_SKIP

Description :

Defines the color to use when showing ‘Skipped’ task status

black
bright gray
blue
white
green
bright blue
cyan
bright green
red
bright cyan
purple
bright red
yellow
bright purple
dark gray
bright yellow
magenta
bright magenta
normal

COLOR_UNREACHABLE

Description :

Defines the color to use on ‘Unreachable’ status

black
bright gray
blue
white
green
bright blue
cyan
bright green
red
bright cyan
purple
bright red
yellow
bright purple
dark gray
bright yellow
magenta
bright magenta
normal

COLOR_VERBOSE

Description :

Defines the color to use when emitting verbose messages. i.e those that show with ‘-v’s.

black
bright gray
blue
white
green
bright blue
cyan
bright green
red
bright cyan
purple
bright red
yellow
bright purple
dark gray
bright yellow
magenta
bright magenta
normal

COLOR_WARN

Description :

Defines the color to use when emitting warning messages

black
bright gray
blue
white
green
bright blue
cyan
bright green
red
bright cyan
purple
bright red
yellow
bright purple
dark gray
bright yellow
magenta
bright magenta
normal

CONNECTION_FACTS_MODULES

Description :

Which modules to run during a play’s fact gathering stage based on connection

CONNECTION_PASSWORD_FILE

Description :

The password file to use for the connection plugin. –connection-password-file.

COVERAGE_REMOTE_OUTPUT

Description :

Sets the output directory on the remote host to generate coverage reports to. Currently only used for remote coverage on PowerShell modules. This is for internal use only.

COVERAGE_REMOTE_PATHS

Description :

A list of paths for files on the Ansible controller to run coverage for when executing on the remote host. Only files that match the path glob will have its coverage collected. Multiple path globs can be specified and are separated by : . Currently only used for remote coverage on PowerShell modules. This is for internal use only.

DEFAULT_ACTION_PLUGIN_PATH

Description :

Colon separated paths in which Ansible will search for Action Plugins.

DEFAULT_ALLOW_UNSAFE_LOOKUPS

Description :

When enabled, this option allows lookup plugins (whether used in variables as > or as a loop as with_foo) to return data that is not marked ‘unsafe’. By default, such data is marked as unsafe to prevent the templating engine from evaluating any jinja2 templating language, as this could represent a security risk. This option is provided to allow for backward compatibility, however users should first consider adding allow_unsafe=True to any lookups which may be expected to contain data which may be run through the templating engine late

DEFAULT_ASK_PASS

Description :

This controls whether an Ansible playbook should prompt for a login password. If using SSH keys for authentication, you probably do not need to change this setting.

DEFAULT_ASK_VAULT_PASS

Description :

This controls whether an Ansible playbook should prompt for a vault password.

DEFAULT_BECOME

Description :

Toggles the use of privilege escalation, allowing you to ‘become’ another user after login.

DEFAULT_BECOME_ASK_PASS

Description :

Toggle to prompt for privilege escalation password.

DEFAULT_BECOME_EXE

Description :

executable to use for privilege escalation, otherwise Ansible will depend on PATH

DEFAULT_BECOME_FLAGS

Description :

Flags to pass to the privilege escalation executable.

DEFAULT_BECOME_METHOD

Description :

Privilege escalation method to use when become is enabled.

DEFAULT_BECOME_USER

Description :

The user your login/remote user ‘becomes’ when using privilege escalation, most systems will use ‘root’ when no user is specified.

DEFAULT_CACHE_PLUGIN_PATH

Description :

Colon separated paths in which Ansible will search for Cache Plugins.

DEFAULT_CALLBACK_PLUGIN_PATH

Description :

Colon separated paths in which Ansible will search for Callback Plugins.

DEFAULT_CLICONF_PLUGIN_PATH

Description :

Colon separated paths in which Ansible will search for Cliconf Plugins.

DEFAULT_CONNECTION_PLUGIN_PATH

Description :

Colon separated paths in which Ansible will search for Connection Plugins.

DEFAULT_DEBUG

Description :

Toggles debug output in Ansible. This is very verbose and can hinder multiprocessing. Debug output can also include secret information despite no_log settings being enabled, which means debug mode should not be used in production.

DEFAULT_EXECUTABLE

Description :

This indicates the command to use to spawn a shell under for Ansible’s execution needs on a target. Users may need to change this in rare instances when shell usage is constrained, but in most cases it may be left as is.

DEFAULT_FACT_PATH

Description :

This option allows you to globally configure a custom path for ‘local_facts’ for the implied ansible_collections.ansible.builtin.setup_module task when using fact gathering. If not set, it will fallback to the default from the ansible.builtin.setup module: /etc/ansible/facts.d . This does not affect user defined tasks that use the ansible.builtin.setup module. The real action being created by the implicit task is currently ansible.legacy.gather_facts module, which then calls the configured fact modules, by default this will be ansible.builtin.setup for POSIX systems but other platforms might have different defaults.

the module_defaults keyword is a more generic version and can apply to all calls to the M(ansible.builtin.gather_facts) or M(ansible.builtin.setup) actions

DEFAULT_FILTER_PLUGIN_PATH

Description :

Colon separated paths in which Ansible will search for Jinja2 Filter Plugins.

DEFAULT_FORCE_HANDLERS

Description :

This option controls if notified handlers run on a host even if a failure occurs on that host. When false, the handlers will not run if a failure has occurred on a host. This can also be set per play or on the command line. See Handlers and Failure for more details.

DEFAULT_FORKS

Description :

Maximum number of forks Ansible will use to execute tasks on target hosts.

DEFAULT_GATHER_SUBSET

Description :

Set the gather_subset option for the ansible_collections.ansible.builtin.setup_module task in the implicit fact gathering. See the module documentation for specifics. It does not apply to user defined ansible.builtin.setup tasks.

the module_defaults keyword is a more generic version and can apply to all calls to the M(ansible.builtin.gather_facts) or M(ansible.builtin.setup) actions

DEFAULT_GATHER_TIMEOUT

Description :

Set the timeout in seconds for the implicit fact gathering, see the module documentation for specifics. It does not apply to user defined ansible_collections.ansible.builtin.setup_module tasks.

the module_defaults keyword is a more generic version and can apply to all calls to the M(ansible.builtin.gather_facts) or M(ansible.builtin.setup) actions

DEFAULT_GATHERING

Description :

This setting controls the default policy of fact gathering (facts discovered about remote systems). This option can be useful for those wishing to save fact gathering time. Both ‘smart’ and ‘explicit’ will use the cache plugin.

implicit : the cache plugin will be ignored and facts will be gathered per play unless ‘gather_facts: False’ is set.
explicit : facts will not be gathered unless directly requested in the play.
smart : each new host that has no facts discovered will be scanned, but if the same host is addressed in multiple plays it will not be contacted again in the run.

DEFAULT_HASH_BEHAVIOUR

Description :

This setting controls how duplicate definitions of dictionary variables (aka hash, map, associative array) are handled in Ansible. This does not affect variables whose values are scalars (integers, strings) or arrays. WARNING, changing this setting is not recommended as this is fragile and makes your content (plays, roles, collections) non portable, leading to continual confusion and misuse. Don’t change this setting unless you think you have an absolute need for it. We recommend avoiding reusing variable names and relying on the combine filter and vars and varnames lookups to create merged versions of the individual variables. In our experience this is rarely really needed and a sign that too much complexity has been introduced into the data structures and plays. For some uses you can also look into custom vars_plugins to merge on input, even substituting the default host_group_vars that is in charge of parsing the host_vars/ and group_vars/ directories. Most users of this setting are only interested in inventory scope, but the setting itself affects all sources and makes debugging even harder. All playbooks and roles in the official examples repos assume the default for this setting. Changing the setting to merge applies across variable sources, but many sources will internally still overwrite the variables. For example include_vars will dedupe variables internally before updating Ansible, with ‘last defined’ overwriting previous definitions in same file. The Ansible project recommends you avoid «merge« for new projects. It is the intention of the Ansible developers to eventually deprecate and remove this setting, but it is being kept as some users do heavily rely on it. New projects should avoid ‘merge’.

replace : Any variable that is defined more than once is overwritten using the order from variable precedence rules (highest wins).
merge : Any dictionary variable will be recursively merged with new definitions across the different variable definition sources.

DEFAULT_HOST_LIST

Description :

Comma separated list of Ansible inventory sources

DEFAULT_HTTPAPI_PLUGIN_PATH

Description :

Colon separated paths in which Ansible will search for HttpApi Plugins.

DEFAULT_INTERNAL_POLL_INTERVAL

Description :

This sets the interval (in seconds) of Ansible internal processes polling each other. Lower values improve performance with large playbooks at the expense of extra CPU load. Higher values are more suitable for Ansible usage in automation scenarios, when UI responsiveness is not required but CPU usage might be a concern. The default corresponds to the value hardcoded in Ansible

DEFAULT_INVENTORY_PLUGIN_PATH

Description :

Colon separated paths in which Ansible will search for Inventory Plugins.

DEFAULT_JINJA2_EXTENSIONS

Description :

This is a developer-specific feature that allows enabling additional Jinja2 extensions. See the Jinja2 documentation for details. If you do not know what these do, you probably don’t need to change this setting 🙂

DEFAULT_JINJA2_NATIVE

Description :

This option preserves variable types during template operations.

DEFAULT_KEEP_REMOTE_FILES

Description :

Enables/disables the cleaning up of the temporary files Ansible used to execute the tasks on the remote. If this option is enabled it will disable ANSIBLE_PIPELINING .

DEFAULT_LIBVIRT_LXC_NOSECLABEL

Description :

This setting causes libvirt to connect to lxc containers by passing –noseclabel to virsh. This is necessary when running on systems which do not have SELinux.

DEFAULT_LOAD_CALLBACK_PLUGINS

Description :

Controls whether callback plugins are loaded when running /usr/bin/ansible. This may be used to log activity from the command line, send notifications, and so on. Callback plugins are always loaded for ansible-playbook .

DEFAULT_LOCAL_TMP

Description :

Temporary directory for Ansible to use on the controller.

DEFAULT_LOG_FILTER

Description :

List of logger names to filter out of the log file

DEFAULT_LOG_PATH

Description :

File to which Ansible will log on the controller. When empty logging is disabled.

DEFAULT_LOOKUP_PLUGIN_PATH

Description :

Colon separated paths in which Ansible will search for Lookup Plugins.

DEFAULT_MANAGED_STR

Description :

Sets the macro for the ‘ansible_managed’ variable available for ansible_collections.ansible.builtin.template_module and ansible_collections.ansible.windows.win_template_module . This is only relevant for those two modules.

DEFAULT_MODULE_ARGS

Description :

This sets the default arguments to pass to the ansible adhoc binary if no -a is specified.

DEFAULT_MODULE_COMPRESSION

Description :

Compression scheme to use when transferring Python modules to the target.

DEFAULT_MODULE_NAME

Description :

Module to use with the ansible AdHoc command, if none is specified via -m .

DEFAULT_MODULE_PATH

Description :

Colon separated paths in which Ansible will search for Modules.

DEFAULT_MODULE_UTILS_PATH

Description :

Colon separated paths in which Ansible will search for Module utils files, which are shared by modules.

DEFAULT_NETCONF_PLUGIN_PATH

Description :

Colon separated paths in which Ansible will search for Netconf Plugins.

DEFAULT_NO_LOG

Description :

Toggle Ansible’s display and logging of task details, mainly used to avoid security disclosures.

DEFAULT_NO_TARGET_SYSLOG

Description :

Toggle Ansible logging to syslog on the target when it executes tasks. On Windows hosts this will disable a newer style PowerShell modules from writing to the event log.

ansible_no_target_syslog :Version Added: 2.10

DEFAULT_NULL_REPRESENTATION

Description :

What templating should return as a ‘null’ value. When not set it will let Jinja2 decide.

DEFAULT_POLL_INTERVAL

Description :

For asynchronous tasks in Ansible (covered in Asynchronous Actions and Polling), this is how often to check back on the status of those tasks when an explicit poll interval is not supplied. The default is a reasonably moderate 15 seconds which is a tradeoff between checking in frequently and providing a quick turnaround when something may have completed.

DEFAULT_PRIVATE_KEY_FILE

Description :

Option for connections using a certificate or key file to authenticate, rather than an agent or passwords, you can set the default value here to avoid re-specifying –private-key with every invocation.

DEFAULT_PRIVATE_ROLE_VARS

Description :

Makes role variables inaccessible from other roles. This was introduced as a way to reset role variables to default values if a role is used more than once in a playbook.

DEFAULT_REMOTE_PORT

Description :

Port to use in remote connections, when blank it will use the connection plugin default.

DEFAULT_REMOTE_USER

Description :

Sets the login user for the target machines When blank it uses the connection plugin’s default, normally the user currently executing Ansible.

DEFAULT_ROLES_PATH

Description :

Colon separated paths in which Ansible will search for Roles.

DEFAULT_SELINUX_SPECIAL_FS

Description :

Some filesystems do not support safe operations and/or return inconsistent errors, this setting makes Ansible ‘tolerate’ those in the list w/o causing fatal errors. Data corruption may occur and writes are not always verified when a filesystem is in the list.

fuse, nfs, vboxsf, ramfs, 9p, vfat

DEFAULT_STDOUT_CALLBACK

Description :

Set the main callback used to display Ansible output. You can only have one at a time. You can have many other callbacks, but just one can be in charge of stdout. See Callback plugins for a list of available options.

DEFAULT_STRATEGY

Description :

Set the default strategy used for plays.

DEFAULT_STRATEGY_PLUGIN_PATH

Description :

Colon separated paths in which Ansible will search for Strategy Plugins.

DEFAULT_SU

Description :

Toggle the use of “su” for tasks.

DEFAULT_SYSLOG_FACILITY

Description :

Syslog facility to use when Ansible logs to the remote target

DEFAULT_TERMINAL_PLUGIN_PATH

Description :

Colon separated paths in which Ansible will search for Terminal Plugins.

DEFAULT_TEST_PLUGIN_PATH

Description :

Colon separated paths in which Ansible will search for Jinja2 Test Plugins.

DEFAULT_TIMEOUT

Description :

This is the default timeout for connection plugins to use.

DEFAULT_TRANSPORT

Description :

Default connection plugin to use, the ‘smart’ option will toggle between ‘ssh’ and ‘paramiko’ depending on controller OS and ssh versions

DEFAULT_UNDEFINED_VAR_BEHAVIOR

Description :

When True, this causes ansible templating to fail steps that reference variable names that are likely typoed. Otherwise, any ‘>’ that contains undefined variables will be rendered in a template or ansible action line exactly as written.

DEFAULT_VARS_PLUGIN_PATH

Description :

Colon separated paths in which Ansible will search for Vars Plugins.

DEFAULT_VAULT_ENCRYPT_IDENTITY

Description :

The vault_id to use for encrypting by default. If multiple vault_ids are provided, this specifies which to use for encryption. The –encrypt-vault-id cli option overrides the configured value.

DEFAULT_VAULT_ID_MATCH

Description :

If true, decrypting vaults with a vault id will only try the password from the matching vault-id

DEFAULT_VAULT_IDENTITY

Description :

The label to use for the default vault id label in cases where a vault id label is not provided

DEFAULT_VAULT_IDENTITY_LIST

Description :

A list of vault-ids to use by default. Equivalent to multiple –vault-id args. Vault-ids are tried in order.

DEFAULT_VAULT_PASSWORD_FILE

Description :

The vault password file to use. Equivalent to –vault-password-file or –vault-id If executable, it will be run and the resulting stdout will be used as the password.

DEFAULT_VERBOSITY

Description :

Sets the default verbosity, equivalent to the number of -v passed in the command line.

DEPRECATION_WARNINGS

Description :

Toggle to control the showing of deprecation warnings

DEVEL_WARNING

Description :

Toggle to control showing warnings related to running devel

DIFF_ALWAYS

Description :

Configuration toggle to tell modules to show differences when in ‘changed’ status, equivalent to —diff .

DIFF_CONTEXT

Description :

How many lines of context to show when displaying the differences between files.

DISPLAY_ARGS_TO_STDOUT

Description :

Normally ansible-playbook will print a header for each task that is run. These headers will contain the name: field from the task if you specified one. If you didn’t then ansible-playbook uses the task’s action to help you tell which task is presently running. Sometimes you run many of the same action and so you want more information about the task to differentiate it from others of the same action. If you set this variable to True in the config then ansible-playbook will also include the task’s arguments in the header. This setting defaults to False because there is a chance that you have sensitive values in your parameters and you do not want those to be printed. If you set this to True you should be sure that you have secured your environment’s stdout (no one can shoulder surf your screen and you aren’t saving stdout to an insecure file) or made sure that all of your playbooks explicitly added the no_log: True parameter to tasks which have sensitive values See How do I keep secret data in my playbook? for more information.

DISPLAY_SKIPPED_HOSTS

Description :

Toggle to control displaying skipped task/host entries in a task in the default callback

DOC_FRAGMENT_PLUGIN_PATH

Description :

Colon separated paths in which Ansible will search for Documentation Fragments Plugins.

DOCSITE_ROOT_URL

Description :

Root docsite URL used to generate docs URLs in warning/error text; must be an absolute URL with valid scheme and trailing slash.

DUPLICATE_YAML_DICT_KEY

Description :

By default Ansible will issue a warning when a duplicate dict key is encountered in YAML. These warnings can be silenced by adjusting this setting to False.

error : issue a ‘fatal’ error and stop the play
warn : issue a warning but continue
ignore : just continue silently

EDITOR

editor :Version Added: 2.15

Variable : ANSIBLE_EDITOR Version Added : 2.15
Variable : EDITOR

ENABLE_TASK_DEBUGGER

Description :

Whether or not to enable the task debugger, this previously was done as a strategy plugin. Now all strategy plugins can inherit this behavior. The debugger defaults to activating when a task is failed on unreachable. Use the debugger keyword for more flexibility.

ERROR_ON_MISSING_HANDLER

Description :

Toggle to allow missing handlers to become a warning instead of an error when notifying.

FACTS_MODULES

Description :

Which modules to run during a play’s fact gathering stage, using the default of ‘smart’ will try to figure it out based on connection type. If adding your own modules but you still want to use the default Ansible facts, you will want to include ‘setup’ or corresponding network module to the list (if you add ‘smart’, Ansible will also figure it out). This does not affect explicit calls to the ‘setup’ module, but does always affect the ‘gather_facts’ action (implicit or explicit).

GALAXY_CACHE_DIR

Description :

The directory that stores cached responses from a Galaxy server. This is only used by the ansible-galaxy collection install and download commands. Cache files inside this dir will be ignored if they are world writable.

GALAXY_COLLECTION_SKELETON

Description :

Collection skeleton directory to use as a template for the init action in ansible-galaxy collection , same as —collection-skeleton .

GALAXY_COLLECTION_SKELETON_IGNORE

Description :

patterns of files to ignore inside a Galaxy collection skeleton directory

GALAXY_DISABLE_GPG_VERIFY

Description :

Disable GPG signature verification during collection installation.

GALAXY_DISPLAY_PROGRESS

Description :

Some steps in ansible-galaxy display a progress wheel which can cause issues on certain displays or when outputting the stdout to a file. This config option controls whether the display wheel is shown or not. The default is to show the display wheel if stdout has a tty.

GALAXY_GPG_KEYRING

Description :

Configure the keyring used for GPG signature verification during collection installation and verification.

GALAXY_IGNORE_CERTS

Description :

If set to yes, ansible-galaxy will not validate TLS certificates. This can be useful for testing against a server with a self-signed certificate.

GALAXY_IGNORE_INVALID_SIGNATURE_STATUS_CODES

Description :

A list of GPG status codes to ignore during GPG signature verification. See L(https://github.com/gpg/gnupg/blob/master/doc/DETAILS#general-status-codes) for status code descriptions. If fewer signatures successfully verify the collection than GALAXY_REQUIRED_VALID_SIGNATURE_COUNT , signature verification will fail even if all error codes are ignored.

EXPSIG
EXPKEYSIG
REVKEYSIG
BADSIG
ERRSIG
NO_PUBKEY
MISSING_PASSPHRASE
BAD_PASSPHRASE
NODATA
UNEXPECTED
ERROR
FAILURE
BADARMOR
KEYEXPIRED
KEYREVOKED
NO_SECKEY

GALAXY_REQUIRED_VALID_SIGNATURE_COUNT

Description :

The number of signatures that must be successful during GPG signature verification while installing or verifying collections. This should be a positive integer or all to indicate all signatures must successfully validate the collection. Prepend + to the value to fail if no valid signatures are found for the collection.

GALAXY_ROLE_SKELETON

Description :

Role skeleton directory to use as a template for the init action in ansible-galaxy / ansible-galaxy role , same as —role-skeleton .

GALAXY_ROLE_SKELETON_IGNORE

Description :

patterns of files to ignore inside a Galaxy role or collection skeleton directory

GALAXY_SERVER

Description :

URL to prepend when roles don’t specify the full URI, assume they are referencing this server as the source.

GALAXY_SERVER_LIST

Description :

A list of Galaxy servers to use when installing a collection. The value corresponds to the config ini header [galaxy_server.>] which defines the server details. See Configuring the ansible-galaxy client for more details on how to define a Galaxy server. The order of servers in this list is used to as the order in which a collection is resolved. Setting this config option will ignore the GALAXY_SERVER config option.

GALAXY_TOKEN_PATH

Description :

Local path to galaxy access token file

HOST_KEY_CHECKING

Description :

Set this to “False” if you want to avoid host key checking by the underlying tools Ansible uses to connect to the host

HOST_PATTERN_MISMATCH

Description :

This setting changes the behaviour of mismatched host patterns, it allows you to force a fatal error, a warning or just ignore it

error : issue a ‘fatal’ error and stop the play
warning : issue a warning but continue
ignore : just continue silently

INJECT_FACTS_AS_VARS

Description :

Facts are available inside the ansible_facts variable, this setting also pushes them as their own vars in the main namespace. Unlike inside the ansible_facts dictionary, these will have an ansible_ prefix.

INTERPRETER_PYTHON

Description :

Path to the Python interpreter to be used for module execution on remote targets, or an automatic discovery mode. Supported discovery modes are auto (the default), auto_silent , auto_legacy , and auto_legacy_silent . All discovery modes employ a lookup table to use the included system Python (on distributions known to include one), falling back to a fixed ordered list of well-known Python interpreter locations if a platform-specific default is not available. The fallback behavior will issue a warning that the interpreter should be set explicitly (since interpreters installed later may change which one is used). This warning behavior can be disabled by setting auto_silent or auto_legacy_silent . The value of auto_legacy provides all the same behavior, but for backwards-compatibility with older Ansible releases that always defaulted to /usr/bin/python , will use that interpreter if present.

INTERPRETER_PYTHON_FALLBACK

[‘python3.11’, ‘python3.10’, ‘python3.9’, ‘python3.8’, ‘python3.7’, ‘python3.6’, ‘python3.5’, ‘/usr/bin/python3’, ‘/usr/libexec/platform-python’, ‘python2.7’, ‘/usr/bin/python’, ‘python’]

INVALID_TASK_ATTRIBUTE_FAILED

Description :

If ‘false’, invalid attributes for a task will result in warnings instead of errors

INVENTORY_ANY_UNPARSED_IS_FAILED

Description :

If ‘true’, it is a fatal error when any given inventory source cannot be successfully parsed by any available inventory plugin; otherwise, this situation only attracts a warning.

INVENTORY_CACHE_ENABLED

Description :

Toggle to turn on inventory caching. This setting has been moved to the individual inventory plugins as a plugin option Inventory plugins . The existing configuration settings are still accepted with the inventory plugin adding additional options from inventory configuration. This message will be removed in 2.16.

INVENTORY_CACHE_PLUGIN

Description :

The plugin for caching inventory. This setting has been moved to the individual inventory plugins as a plugin option Inventory plugins . The existing configuration settings are still accepted with the inventory plugin adding additional options from inventory and fact cache configuration. This message will be removed in 2.16.

INVENTORY_CACHE_PLUGIN_CONNECTION

Description :

The inventory cache connection. This setting has been moved to the individual inventory plugins as a plugin option Inventory plugins . The existing configuration settings are still accepted with the inventory plugin adding additional options from inventory and fact cache configuration. This message will be removed in 2.16.

INVENTORY_CACHE_PLUGIN_PREFIX

Description :

The table prefix for the cache plugin. This setting has been moved to the individual inventory plugins as a plugin option Inventory plugins . The existing configuration settings are still accepted with the inventory plugin adding additional options from inventory and fact cache configuration. This message will be removed in 2.16.

INVENTORY_CACHE_TIMEOUT

Description :

Expiration timeout for the inventory cache plugin data. This setting has been moved to the individual inventory plugins as a plugin option Inventory plugins . The existing configuration settings are still accepted with the inventory plugin adding additional options from inventory and fact cache configuration. This message will be removed in 2.16.

INVENTORY_ENABLED

Description :

List of enabled inventory plugins, it also determines the order in which they are used.

[‘host_list’, ‘script’, ‘auto’, ‘yaml’, ‘ini’, ‘toml’]

INVENTORY_EXPORT

Description :

Controls if ansible-inventory will accurately reflect Ansible’s view into inventory or its optimized for exporting.

INVENTORY_IGNORE_EXTS

Description :

List of extensions to ignore when using a directory as an inventory source

Section : [defaults] Key : inventory_ignore_extensions
Section : [inventory] Key : ignore_extensions

INVENTORY_IGNORE_PATTERNS

Description :

List of patterns to ignore when using a directory as an inventory source

Section : [defaults] Key : inventory_ignore_patterns
Section : [inventory] Key : ignore_patterns

INVENTORY_UNPARSED_IS_FAILED

Description :

If ‘true’ it is a fatal error if every single potential inventory source fails to parse, otherwise this situation will only attract a warning.

INVENTORY_UNPARSED_WARNING

Description :

By default Ansible will issue a warning when no inventory was loaded and notes that it will use an implicit localhost-only inventory. These warnings can be silenced by adjusting this setting to False.

JINJA2_NATIVE_WARNING

Description :

Toggle to control showing warnings related to running a Jinja version older than required for jinja2_native

ANSIBLE_JINJA2_NATIVE_WARNING :Deprecated in: 2.17 :Deprecated detail: This option is no longer used in the Ansible Core code base.

LOCALHOST_WARNING

Description :

By default Ansible will issue a warning when there are no hosts in the inventory. These warnings can be silenced by adjusting this setting to False.

MAX_FILE_SIZE_FOR_DIFF

Description :

Maximum size of files to be considered for diff display

MODULE_IGNORE_EXTS

Description :

List of extensions to ignore when looking for modules to load This is for rejecting script and binary module fallback extensions

MODULE_STRICT_UTF8_RESPONSE

Description :

Enables whether module responses are evaluated for containing non UTF-8 data Disabling this may result in unexpected behavior Only ansible-core should evaluate this configuration

NETCONF_SSH_CONFIG

Description :

This variable is used to enable bastion/jump host with netconf connection. If set to True the bastion/jump host ssh settings should be present in ~/.ssh/config file, alternatively it can be set to custom ssh configuration file path to read the bastion/jump host settings.

NETWORK_GROUP_MODULES

[‘eos’, ‘nxos’, ‘ios’, ‘iosxr’, ‘junos’, ‘enos’, ‘ce’, ‘vyos’, ‘sros’, ‘dellos9’, ‘dellos10’, ‘dellos6’, ‘asa’, ‘aruba’, ‘aireos’, ‘bigip’, ‘ironware’, ‘onyx’, ‘netconf’, ‘exos’, ‘voss’, ‘slxos’]

OLD_PLUGIN_CACHE_CLEARING

Description :

Previously Ansible would only clear some of the plugin loading caches when loading new roles, this led to some behaviours in which a plugin loaded in previous plays would be unexpectedly ‘sticky’. This setting allows to return to that behaviour.

PAGER

pager :Version Added: 2.15

Variable : ANSIBLE_PAGER Version Added : 2.15
Variable : PAGER

PARAMIKO_HOST_KEY_AUTO_ADD

PARAMIKO_LOOK_FOR_KEYS

PERSISTENT_COMMAND_TIMEOUT

Description :

This controls the amount of time to wait for response from remote device before timing out persistent connection.

PERSISTENT_CONNECT_RETRY_TIMEOUT

Description :

This controls the retry timeout for persistent connection to connect to the local domain socket.

PERSISTENT_CONNECT_TIMEOUT

Description :

This controls how long the persistent connection will remain idle before it is destroyed.

PERSISTENT_CONTROL_PATH_DIR

Description :

Path to socket to be used by the connection persistence system.

PLAYBOOK_DIR

Description :

A number of non-playbook CLIs have a —playbook-dir argument; this sets the default value for it.

PLAYBOOK_VARS_ROOT

Description :

This sets which playbook dirs will be used as a root to process vars plugins, which includes finding host_vars/group_vars

top : follows the traditional behavior of using the top playbook in the chain to find the root directory.
bottom : follows the 2.4.0 behavior of using the current playbook to find the root directory.
all : examines from the first parent to the current playbook.

PLUGIN_FILTERS_CFG

Description :

A path to configuration for filtering which plugins installed on the system are allowed to be used. See Rejecting modules for details of the filter file’s format. The default is /etc/ansible/plugin_filters.yml

PYTHON_MODULE_RLIMIT_NOFILE

Description :

Attempts to set RLIMIT_NOFILE soft limit to the specified value when executing Python modules (can speed up subprocess usage on Python 2.x. See https://bugs.python.org/issue11284). The value will be limited by the existing hard limit. Default value of 0 does not attempt to adjust existing system-defined limits.

RETRY_FILES_ENABLED

Description :

This controls whether a failed Ansible playbook should create a .retry file.

RETRY_FILES_SAVE_PATH

Description :

This sets the path in which Ansible will save .retry files when a playbook fails and retry files are enabled. This file will be overwritten after each run with the list of failed hosts from all plays.

RUN_VARS_PLUGINS

Description :

This setting can be used to optimize vars_plugin usage depending on user’s inventory size and play selection.

demand : will run vars_plugins relative to inventory sources anytime vars are ‘demanded’ by tasks.
start : will run vars_plugins relative to inventory sources after importing that inventory source.

SHOW_CUSTOM_STATS

Description :

This adds the custom stats set via the set_stats plugin to the default output

STRING_CONVERSION_ACTION

Description :

Action to take when a module parameter value is converted to a string (this does not affect variables). For string parameters, values such as ‘1.00’, “[‘a’, ‘b’,]”, and ‘yes’, ‘y’, etc. will be converted by the YAML parser unless fully quoted. Valid options are ‘error’, ‘warn’, and ‘ignore’. Since 2.8, this option defaults to ‘warn’ but will change to ‘error’ in 2.12.

STRING_TYPE_FILTERS

Description :

This list of filters avoids ‘type conversion’ when templating variables Useful when you want to avoid conversion into lists or dictionaries for JSON strings, for example.

[‘string’, ‘to_json’, ‘to_nice_json’, ‘to_yaml’, ‘to_nice_yaml’, ‘ppretty’, ‘json’]

SYSTEM_WARNINGS

Description :

Allows disabling of warnings related to potential issues on the system running ansible itself (not on the managed hosts) These may include warnings about 3rd party packages or other conditions that should be resolved if possible.

TAGS_RUN

Description :

default list of tags to run in your plays, Skip Tags has precedence.

TAGS_SKIP

Description :

default list of tags to skip in your plays, has precedence over Run Tags

TASK_DEBUGGER_IGNORE_ERRORS

Description :

This option defines whether the task debugger will be invoked on a failed task when ignore_errors=True is specified. True specifies that the debugger will honor ignore_errors, False will not honor ignore_errors.

TASK_TIMEOUT

Description :

Set the maximum time (in seconds) that a task can run for. If set to 0 (the default) there is no timeout.

TRANSFORM_INVALID_GROUP_CHARS

Description :

Make ansible transform invalid characters in group names supplied by inventory sources.

always : it will replace any invalid characters with ‘_’ (underscore) and warn the user
never : it will allow for the group name but warn about the issue
ignore : it does the same as ‘never’, without issuing a warning
silently : it does the same as ‘always’, without issuing a warning

USE_PERSISTENT_CONNECTIONS

Description :

Toggles the use of persistence for connections.

VALIDATE_ACTION_GROUP_METADATA

Description :

A toggle to disable validating a collection’s ‘metadata’ entry for a module_defaults action group. Metadata containing unexpected fields or value types will produce a warning when this is True.

VARIABLE_PLUGINS_ENABLED

Description :

Accept list for variable plugins that require it.

VARIABLE_PRECEDENCE

Description :

Allows to change the group variable precedence merge order.

[‘all_inventory’, ‘groups_inventory’, ‘all_plugins_inventory’, ‘all_plugins_play’, ‘groups_plugins_inventory’, ‘groups_plugins_play’]

VAULT_ENCRYPT_SALT

Description :

The salt to use for the vault encryption. If it is not provided, a random salt will be used.

VERBOSE_TO_STDERR

Description :

Force ‘verbose’ option to use stderr instead of stdout

WIN_ASYNC_STARTUP_TIMEOUT

Description :

For asynchronous tasks in Ansible (covered in Asynchronous Actions and Polling), this is how long, in seconds, to wait for the task spawned by Ansible to connect back to the named pipe used on Windows systems. The default is 5 seconds. This can be too low on slower systems, or systems under heavy load. This is not the total time an async command can run for, but is a separate timeout to wait for an async command to start. The task will only start to be timed against its async_timeout once it has connected to the pipe, so the overall maximum duration the task can take will be extended by the amount specified here.

WORKER_SHUTDOWN_POLL_COUNT

Description :

The maximum number of times to check Task Queue Manager worker processes to verify they have exited cleanly. After this limit is reached any worker processes still running will be terminated. This is for internal use only.

WORKER_SHUTDOWN_POLL_DELAY

Description :

The number of seconds to sleep between polling loops when checking Task Queue Manager worker processes to verify they have exited cleanly. This is for internal use only.

YAML_FILENAME_EXTENSIONS

Description :

Check all of these extensions when looking for ‘variable’ files which should be YAML or JSON or vaulted versions of these. This affects vars_files, include_vars, inventory and vars plugins among others.

Environment Variables

Other environment variables to configure plugins in collections can be found in Index of all Collection Environment Variables .

Override the default ansible config file

The default root path for Ansible config files on the controller.

Specify where to look for the ansible-connection script. This location will be checked before searching $PATH.If null, ansible will start with the same directory as the ansible script.

This allows you to chose a specific cowsay stencil for the banners or use ‘random’ to cycle through them.

Accept list of cowsay templates that are ‘safe’ to use, set to empty list if you want to enable all installed templates.

This option forces color mode even when running without a TTY or the “nocolor” setting is True.

This setting allows suppressing colorizing output, which is used to give a better indication of failure and status information.

If you have cowsay installed but want to avoid the ‘cows’ (why. ), use this.

Specify a custom cowsay path or swap in your cowsay implementation of choice

This is a global option, each connection plugin can override either by having more specific options or not supporting pipelining at all.Pipelining, if supported by the connection plugin, reduces the number of network operations required to execute a module on the remote server, by executing many Ansible modules without actual file transfer.It can result in a very significant performance improvement when enabled.However this conflicts with privilege escalation (become). For example, when using ‘sudo:’ operations you must first disable ‘requiretty’ in /etc/sudoers on all managed hosts, which is why it is disabled by default.This setting will be disabled if ANSIBLE_KEEP_REMOTE_FILES is enabled.

Sets the default value for the any_errors_fatal keyword, if True, Task failures will be considered fatal errors.

This setting controls if become is skipped when remote user and become user are the same. I.E root sudo to root.If executable, it will be run and the resulting stdout will be used as the password.

The password file to use for the become plugin. –become-password-file.If executable, it will be run and the resulting stdout will be used as the password.

Display an agnostic become prompt instead of displaying a prompt containing the command line supplied become method

Chooses which cache plugin to use, the default ‘memory’ is ephemeral.

Defines connection or path information for the cache plugin

Prefix to use for cache plugin files/tables

Expiration timeout for the cache plugin data

A boolean to enable or disable scanning the sys.path for installed collections

When a collection is loaded that does not support the running Ansible version (with the collection metadata key requires_ansible ).

Defines the color to use on ‘Changed’ task status

Defines the default color to use for ansible-console

Defines the color to use when emitting debug messages

Defines the color to use when emitting deprecation messages

Defines the color to use when showing added lines in diffs

Defines the color to use when showing diffs

Defines the color to use when showing removed lines in diffs

Defines the color to use when emitting error messages

Defines the color to use for highlighting

Defines the color to use when showing ‘OK’ task status

Defines the color to use when showing ‘Skipped’ task status

Defines the color to use on ‘Unreachable’ status

Defines the color to use when emitting verbose messages. i.e those that show with ‘-v’s.

Defines the color to use when emitting warning messages

The password file to use for the connection plugin. –connection-password-file.

Sets the output directory on the remote host to generate coverage reports to.Currently only used for remote coverage on PowerShell modules.This is for internal use only.

A list of paths for files on the Ansible controller to run coverage for when executing on the remote host.Only files that match the path glob will have its coverage collected.Multiple path globs can be specified and are separated by : .Currently only used for remote coverage on PowerShell modules.This is for internal use only.

By default Ansible will issue a warning when received from a task action (module or action plugin)These warnings can be silenced by adjusting this setting to False.

By default Ansible will issue a warning when there are no hosts in the inventory.These warnings can be silenced by adjusting this setting to False.

By default Ansible will issue a warning when no inventory was loaded and notes that it will use an implicit localhost-only inventory.These warnings can be silenced by adjusting this setting to False.

Colon separated paths in which Ansible will search for Documentation Fragments Plugins.

Colon separated paths in which Ansible will search for Action Plugins.

This controls whether an Ansible playbook should prompt for a login password. If using SSH keys for authentication, you probably do not need to change this setting.

This controls whether an Ansible playbook should prompt for a vault password.

Toggles the use of privilege escalation, allowing you to ‘become’ another user after login.

Toggle to prompt for privilege escalation password.

Privilege escalation method to use when become is enabled.

executable to use for privilege escalation, otherwise Ansible will depend on PATH

Flags to pass to the privilege escalation executable.

Colon separated paths in which Ansible will search for Become Plugins.

The user your login/remote user ‘becomes’ when using privilege escalation, most systems will use ‘root’ when no user is specified.

Colon separated paths in which Ansible will search for Cache Plugins.

Colon separated paths in which Ansible will search for Callback Plugins.

List of enabled callbacks, not all callbacks need enabling, but many of those shipped with Ansible do as we don’t want them activated by default.

Colon separated paths in which Ansible will search for Cliconf Plugins.

Colon separated paths in which Ansible will search for Connection Plugins.

This option allows you to globally configure a custom path for ‘local_facts’ for the implied ansible_collections.ansible.builtin.setup_module task when using fact gathering.If not set, it will fallback to the default from the ansible.builtin.setup module: /etc/ansible/facts.d .This does not affect user defined tasks that use the ansible.builtin.setup module.The real action being created by the implicit task is currently ansible.legacy.gather_facts module, which then calls the configured fact modules, by default this will be ansible.builtin.setup for POSIX systems but other platforms might have different defaults.

Colon separated paths in which Ansible will search for Jinja2 Filter Plugins.

This option controls if notified handlers run on a host even if a failure occurs on that host.When false, the handlers will not run if a failure has occurred on a host.This can also be set per play or on the command line. See Handlers and Failure for more details.

Maximum number of forks Ansible will use to execute tasks on target hosts.

This setting controls the default policy of fact gathering (facts discovered about remote systems).This option can be useful for those wishing to save fact gathering time. Both ‘smart’ and ‘explicit’ will use the cache plugin.

Set the gather_subset option for the ansible_collections.ansible.builtin.setup_module task in the implicit fact gathering. See the module documentation for specifics.It does not apply to user defined ansible.builtin.setup tasks.

Set the timeout in seconds for the implicit fact gathering, see the module documentation for specifics.It does not apply to user defined ansible_collections.ansible.builtin.setup_module tasks.

This setting controls how duplicate definitions of dictionary variables (aka hash, map, associative array) are handled in Ansible.This does not affect variables whose values are scalars (integers, strings) or arrays.**WARNING**, changing this setting is not recommended as this is fragile and makes your content (plays, roles, collections) non portable, leading to continual confusion and misuse. Don’t change this setting unless you think you have an absolute need for it.We recommend avoiding reusing variable names and relying on the combine filter and vars and varnames lookups to create merged versions of the individual variables. In our experience this is rarely really needed and a sign that too much complexity has been introduced into the data structures and plays.For some uses you can also look into custom vars_plugins to merge on input, even substituting the default host_group_vars that is in charge of parsing the host_vars/ and group_vars/ directories. Most users of this setting are only interested in inventory scope, but the setting itself affects all sources and makes debugging even harder.All playbooks and roles in the official examples repos assume the default for this setting.Changing the setting to merge applies across variable sources, but many sources will internally still overwrite the variables. For example include_vars will dedupe variables internally before updating Ansible, with ‘last defined’ overwriting previous definitions in same file.The Ansible project recommends you avoid «merge« for new projects.**It is the intention of the Ansible developers to eventually deprecate and remove this setting, but it is being kept as some users do heavily rely on it. New projects should **avoid ‘merge’.

Comma separated list of Ansible inventory sources

Colon separated paths in which Ansible will search for HttpApi Plugins.

Colon separated paths in which Ansible will search for Inventory Plugins.

This is a developer-specific feature that allows enabling additional Jinja2 extensions.See the Jinja2 documentation for details. If you do not know what these do, you probably don’t need to change this setting 🙂

This option preserves variable types during template operations.

Enables/disables the cleaning up of the temporary files Ansible used to execute the tasks on the remote.If this option is enabled it will disable ANSIBLE_PIPELINING .