ansible/docsite/rst/faq.rst

377 lines
16 KiB
ReStructuredText
Raw Normal View History

2013-04-14 23:31:47 +00:00
Frequently Asked Questions
==========================
Here are some commonly-asked questions and their answers.
.. _set_environment:
2013-10-04 17:27:19 +00:00
How can I set the PATH or any other environment variable for a task or entire playbook?
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
2015-08-19 23:28:50 +00:00
Setting environment variables can be done with the `environment` keyword. It can be used at task or play level::
environment:
PATH: "{{ ansible_env.PATH }}:/thingy/bin"
SOME: value
.. note:: starting in 2.0.1 the setup task from gather_facts also inherits the environment directive from the play, you might need to use the `|default` filter to avoid errors if setting this at play level.
2013-04-14 23:31:47 +00:00
How do I handle different machines needing different user accounts or ports to log in with?
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Setting inventory variables in the inventory file is the easiest way.
.. include:: ../rst_common/ansible_ssh_changes_note.rst
2013-04-14 23:31:47 +00:00
For instance, suppose these hosts have different usernames and ports::
[webservers]
asdf.example.com ansible_port=5000 ansible_user=alice
jkl.example.com ansible_port=5001 ansible_user=bob
2013-04-14 23:31:47 +00:00
You can also dictate the connection type to be used, if you want::
[testcluster]
localhost ansible_connection=local
/path/to/chroot1 ansible_connection=chroot
foo.example.com
bar.example.com
You may also wish to keep these in group variables instead, or file them in a group_vars/<groupname> file.
2013-04-14 23:31:47 +00:00
See the rest of the documentation for more information about how to organize variables.
2013-10-04 17:27:19 +00:00
.. _use_ssh:
2013-04-14 23:31:47 +00:00
How do I get ansible to reuse connections, enable Kerberized SSH, or have Ansible pay attention to my local SSH config file?
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
2013-07-20 16:44:15 +00:00
Switch your default connection type in the configuration file to 'ssh', or use '-c ssh' to use
Native OpenSSH for connections instead of the python paramiko library. In Ansible 1.2.1 and later, 'ssh' will be used
by default if OpenSSH is new enough to support ControlPersist as an option.
2013-04-14 23:31:47 +00:00
Paramiko is great for starting out, but the OpenSSH type offers many advanced options. You will want to run Ansible
from a machine new enough to support ControlPersist, if you are using this connection type. You can still manage
older clients. If you are using RHEL 6, CentOS 6, SLES 10 or SLES 11 the version of OpenSSH is still a bit old, so
consider managing from a Fedora or openSUSE client even though you are managing older nodes, or just use paramiko.
2013-04-14 23:31:47 +00:00
We keep paramiko as the default as if you are first installing Ansible on an EL box, it offers a better experience
for new users.
Squashed commit of the following: commit 9921bb9d2002e136c030ff337c14f8b7eab0fc72 Author: Abhijit Menon-Sen <ams@2ndQuadrant.com> Date: Mon Aug 10 20:19:44 2015 +0530 Document --ssh-extra-args command-line option commit 8b25595e7b1cc3658803d0821fbf498c18ee608a Author: Abhijit Menon-Sen <ams@2ndQuadrant.com> Date: Thu Aug 13 13:24:57 2015 +0530 Don't disable GSSAPI/Pubkey authentication when using --ask-pass This commit is based on a bug report and PR by kolbyjack (#6846) which was subsequently closed and rebased as #11690. The original problem was: «The password on the delegated host is different from the one I provided on the command line, so it had to use the pubkey, and the main host doesn't have a pubkey on it yet, so it had to use the password.» (This commit is revised and included here because #11690 would conflict with the changes in #11908 otherwise.) Closes #11690 commit 119d0323892c65e8169ae57e42bbe8e3517551a3 Author: Abhijit Menon-Sen <ams@2ndQuadrant.com> Date: Thu Aug 13 11:16:42 2015 +0530 Be more explicit about why SSH arguments are added This adds vvvvv log messages that spell out in detail where each SSH command-line argument is obtained from. Unfortunately, we can't be sure if, say, self._play_context.remote_user is obtained from ANSIBLE_REMOTE_USER in the environment, remote_user in ansible.cfg, -u on the command line, or an ansible_ssh_user setting in the inventory or on a task or play. In some cases, e.g. timeout, we can't even be sure if it was set by the user or just a default. Nevertheless, on the theory that at five v's you can use all the hints available, I've mentioned the possible sources in the log messages. Note that this caveat applies only to the arguments that ssh.py adds by itself. In the case of ssh_args and ssh_extra_args, we know where they are from, and say so, though we can't say WHERE in the inventory they may be set (e.g. in host_vars or group_vars etc.). commit b605c285baf505f75f0b7d73cb76b00d4723d02e Author: Abhijit Menon-Sen <ams@2ndQuadrant.com> Date: Tue Aug 11 15:19:43 2015 +0530 Add a FAQ entry about ansible_ssh_extra_args commit 49f8edd035cd28dd1cf8945f44ec3d55212910bd Author: Abhijit Menon-Sen <ams@2ndQuadrant.com> Date: Mon Aug 10 20:48:50 2015 +0530 Allow ansible_ssh_args to be set as an inventory variable Before this change, ssh_args could be set only in the [ssh_connection] section of ansible.cfg, and was applied to all hosts. Now it's possible to set ansible_ssh_args as an inventory variable (directly, or through group_vars or host_vars) to selectively override the global setting. Note that the default ControlPath settings are applied only if ssh_args is not set, and this is true of ansible_ssh_args as well. So if you want to override ssh_args but continue to set ControlPath, you'll need to repeat the appropriate options when setting ansible_ssh_args. (If you only need to add options to the default ssh_args, you may be able to use the ansible_ssh_extra_args inventory variable instead.) commit 37c1a5b6794cee29a7809ad056a86365a2c0f886 Author: Abhijit Menon-Sen <ams@2ndQuadrant.com> Date: Mon Aug 10 19:42:30 2015 +0530 Allow overriding ansible_ssh_extra_args on the command-line This patch makes it possible to do: ansible somehost -m setup \ --ssh-extra-args '-o ProxyCommand="ssh -W %h:%p -q user@bouncer.example.com"' This overrides the inventory setting, if any, of ansible_ssh_extra_args. Based on a patch originally by @Richard2ndQuadrant. commit b023ace8a8a7ce6800e29129a27ebe8bf6bd38e0 Author: Abhijit Menon-Sen <ams@2ndQuadrant.com> Date: Mon Aug 10 19:06:19 2015 +0530 Add an ansible_ssh_extra_args inventory variable This can be used to configure a per-host or per-group ProxyCommand to connect to hosts through a jumphost, e.g.: inventory: [gatewayed] foo ansible_ssh_host=192.0.2.1 group_vars/gatewayed.yml: ansible_ssh_extra_args: '-o ProxyCommand="ssh -W %h:%p -q bounceuser@gateway.example.com"' Note that this variable is used in addition to any ssh_args configured in the [ssh_connection] section of ansible.cfg (so you don't need to repeat the ControlPath settings in ansible_ssh_extra_args).
2015-09-03 15:26:56 +00:00
.. _use_ssh_jump_hosts:
How do I configure a jump host to access servers that I have no direct access to?
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
With Ansible 2, you can set a `ProxyCommand` in the
`ansible_ssh_common_args` inventory variable. Any arguments specified in
this variable are added to the sftp/scp/ssh command line when connecting
to the relevant host(s). Consider the following inventory group::
Squashed commit of the following: commit 9921bb9d2002e136c030ff337c14f8b7eab0fc72 Author: Abhijit Menon-Sen <ams@2ndQuadrant.com> Date: Mon Aug 10 20:19:44 2015 +0530 Document --ssh-extra-args command-line option commit 8b25595e7b1cc3658803d0821fbf498c18ee608a Author: Abhijit Menon-Sen <ams@2ndQuadrant.com> Date: Thu Aug 13 13:24:57 2015 +0530 Don't disable GSSAPI/Pubkey authentication when using --ask-pass This commit is based on a bug report and PR by kolbyjack (#6846) which was subsequently closed and rebased as #11690. The original problem was: «The password on the delegated host is different from the one I provided on the command line, so it had to use the pubkey, and the main host doesn't have a pubkey on it yet, so it had to use the password.» (This commit is revised and included here because #11690 would conflict with the changes in #11908 otherwise.) Closes #11690 commit 119d0323892c65e8169ae57e42bbe8e3517551a3 Author: Abhijit Menon-Sen <ams@2ndQuadrant.com> Date: Thu Aug 13 11:16:42 2015 +0530 Be more explicit about why SSH arguments are added This adds vvvvv log messages that spell out in detail where each SSH command-line argument is obtained from. Unfortunately, we can't be sure if, say, self._play_context.remote_user is obtained from ANSIBLE_REMOTE_USER in the environment, remote_user in ansible.cfg, -u on the command line, or an ansible_ssh_user setting in the inventory or on a task or play. In some cases, e.g. timeout, we can't even be sure if it was set by the user or just a default. Nevertheless, on the theory that at five v's you can use all the hints available, I've mentioned the possible sources in the log messages. Note that this caveat applies only to the arguments that ssh.py adds by itself. In the case of ssh_args and ssh_extra_args, we know where they are from, and say so, though we can't say WHERE in the inventory they may be set (e.g. in host_vars or group_vars etc.). commit b605c285baf505f75f0b7d73cb76b00d4723d02e Author: Abhijit Menon-Sen <ams@2ndQuadrant.com> Date: Tue Aug 11 15:19:43 2015 +0530 Add a FAQ entry about ansible_ssh_extra_args commit 49f8edd035cd28dd1cf8945f44ec3d55212910bd Author: Abhijit Menon-Sen <ams@2ndQuadrant.com> Date: Mon Aug 10 20:48:50 2015 +0530 Allow ansible_ssh_args to be set as an inventory variable Before this change, ssh_args could be set only in the [ssh_connection] section of ansible.cfg, and was applied to all hosts. Now it's possible to set ansible_ssh_args as an inventory variable (directly, or through group_vars or host_vars) to selectively override the global setting. Note that the default ControlPath settings are applied only if ssh_args is not set, and this is true of ansible_ssh_args as well. So if you want to override ssh_args but continue to set ControlPath, you'll need to repeat the appropriate options when setting ansible_ssh_args. (If you only need to add options to the default ssh_args, you may be able to use the ansible_ssh_extra_args inventory variable instead.) commit 37c1a5b6794cee29a7809ad056a86365a2c0f886 Author: Abhijit Menon-Sen <ams@2ndQuadrant.com> Date: Mon Aug 10 19:42:30 2015 +0530 Allow overriding ansible_ssh_extra_args on the command-line This patch makes it possible to do: ansible somehost -m setup \ --ssh-extra-args '-o ProxyCommand="ssh -W %h:%p -q user@bouncer.example.com"' This overrides the inventory setting, if any, of ansible_ssh_extra_args. Based on a patch originally by @Richard2ndQuadrant. commit b023ace8a8a7ce6800e29129a27ebe8bf6bd38e0 Author: Abhijit Menon-Sen <ams@2ndQuadrant.com> Date: Mon Aug 10 19:06:19 2015 +0530 Add an ansible_ssh_extra_args inventory variable This can be used to configure a per-host or per-group ProxyCommand to connect to hosts through a jumphost, e.g.: inventory: [gatewayed] foo ansible_ssh_host=192.0.2.1 group_vars/gatewayed.yml: ansible_ssh_extra_args: '-o ProxyCommand="ssh -W %h:%p -q bounceuser@gateway.example.com"' Note that this variable is used in addition to any ssh_args configured in the [ssh_connection] section of ansible.cfg (so you don't need to repeat the ControlPath settings in ansible_ssh_extra_args).
2015-09-03 15:26:56 +00:00
[gatewayed]
foo ansible_host=192.0.2.1
bar ansible_host=192.0.2.2
Squashed commit of the following: commit 9921bb9d2002e136c030ff337c14f8b7eab0fc72 Author: Abhijit Menon-Sen <ams@2ndQuadrant.com> Date: Mon Aug 10 20:19:44 2015 +0530 Document --ssh-extra-args command-line option commit 8b25595e7b1cc3658803d0821fbf498c18ee608a Author: Abhijit Menon-Sen <ams@2ndQuadrant.com> Date: Thu Aug 13 13:24:57 2015 +0530 Don't disable GSSAPI/Pubkey authentication when using --ask-pass This commit is based on a bug report and PR by kolbyjack (#6846) which was subsequently closed and rebased as #11690. The original problem was: «The password on the delegated host is different from the one I provided on the command line, so it had to use the pubkey, and the main host doesn't have a pubkey on it yet, so it had to use the password.» (This commit is revised and included here because #11690 would conflict with the changes in #11908 otherwise.) Closes #11690 commit 119d0323892c65e8169ae57e42bbe8e3517551a3 Author: Abhijit Menon-Sen <ams@2ndQuadrant.com> Date: Thu Aug 13 11:16:42 2015 +0530 Be more explicit about why SSH arguments are added This adds vvvvv log messages that spell out in detail where each SSH command-line argument is obtained from. Unfortunately, we can't be sure if, say, self._play_context.remote_user is obtained from ANSIBLE_REMOTE_USER in the environment, remote_user in ansible.cfg, -u on the command line, or an ansible_ssh_user setting in the inventory or on a task or play. In some cases, e.g. timeout, we can't even be sure if it was set by the user or just a default. Nevertheless, on the theory that at five v's you can use all the hints available, I've mentioned the possible sources in the log messages. Note that this caveat applies only to the arguments that ssh.py adds by itself. In the case of ssh_args and ssh_extra_args, we know where they are from, and say so, though we can't say WHERE in the inventory they may be set (e.g. in host_vars or group_vars etc.). commit b605c285baf505f75f0b7d73cb76b00d4723d02e Author: Abhijit Menon-Sen <ams@2ndQuadrant.com> Date: Tue Aug 11 15:19:43 2015 +0530 Add a FAQ entry about ansible_ssh_extra_args commit 49f8edd035cd28dd1cf8945f44ec3d55212910bd Author: Abhijit Menon-Sen <ams@2ndQuadrant.com> Date: Mon Aug 10 20:48:50 2015 +0530 Allow ansible_ssh_args to be set as an inventory variable Before this change, ssh_args could be set only in the [ssh_connection] section of ansible.cfg, and was applied to all hosts. Now it's possible to set ansible_ssh_args as an inventory variable (directly, or through group_vars or host_vars) to selectively override the global setting. Note that the default ControlPath settings are applied only if ssh_args is not set, and this is true of ansible_ssh_args as well. So if you want to override ssh_args but continue to set ControlPath, you'll need to repeat the appropriate options when setting ansible_ssh_args. (If you only need to add options to the default ssh_args, you may be able to use the ansible_ssh_extra_args inventory variable instead.) commit 37c1a5b6794cee29a7809ad056a86365a2c0f886 Author: Abhijit Menon-Sen <ams@2ndQuadrant.com> Date: Mon Aug 10 19:42:30 2015 +0530 Allow overriding ansible_ssh_extra_args on the command-line This patch makes it possible to do: ansible somehost -m setup \ --ssh-extra-args '-o ProxyCommand="ssh -W %h:%p -q user@bouncer.example.com"' This overrides the inventory setting, if any, of ansible_ssh_extra_args. Based on a patch originally by @Richard2ndQuadrant. commit b023ace8a8a7ce6800e29129a27ebe8bf6bd38e0 Author: Abhijit Menon-Sen <ams@2ndQuadrant.com> Date: Mon Aug 10 19:06:19 2015 +0530 Add an ansible_ssh_extra_args inventory variable This can be used to configure a per-host or per-group ProxyCommand to connect to hosts through a jumphost, e.g.: inventory: [gatewayed] foo ansible_ssh_host=192.0.2.1 group_vars/gatewayed.yml: ansible_ssh_extra_args: '-o ProxyCommand="ssh -W %h:%p -q bounceuser@gateway.example.com"' Note that this variable is used in addition to any ssh_args configured in the [ssh_connection] section of ansible.cfg (so you don't need to repeat the ControlPath settings in ansible_ssh_extra_args).
2015-09-03 15:26:56 +00:00
You can create `group_vars/gatewayed.yml` with the following contents::
Squashed commit of the following: commit 9921bb9d2002e136c030ff337c14f8b7eab0fc72 Author: Abhijit Menon-Sen <ams@2ndQuadrant.com> Date: Mon Aug 10 20:19:44 2015 +0530 Document --ssh-extra-args command-line option commit 8b25595e7b1cc3658803d0821fbf498c18ee608a Author: Abhijit Menon-Sen <ams@2ndQuadrant.com> Date: Thu Aug 13 13:24:57 2015 +0530 Don't disable GSSAPI/Pubkey authentication when using --ask-pass This commit is based on a bug report and PR by kolbyjack (#6846) which was subsequently closed and rebased as #11690. The original problem was: «The password on the delegated host is different from the one I provided on the command line, so it had to use the pubkey, and the main host doesn't have a pubkey on it yet, so it had to use the password.» (This commit is revised and included here because #11690 would conflict with the changes in #11908 otherwise.) Closes #11690 commit 119d0323892c65e8169ae57e42bbe8e3517551a3 Author: Abhijit Menon-Sen <ams@2ndQuadrant.com> Date: Thu Aug 13 11:16:42 2015 +0530 Be more explicit about why SSH arguments are added This adds vvvvv log messages that spell out in detail where each SSH command-line argument is obtained from. Unfortunately, we can't be sure if, say, self._play_context.remote_user is obtained from ANSIBLE_REMOTE_USER in the environment, remote_user in ansible.cfg, -u on the command line, or an ansible_ssh_user setting in the inventory or on a task or play. In some cases, e.g. timeout, we can't even be sure if it was set by the user or just a default. Nevertheless, on the theory that at five v's you can use all the hints available, I've mentioned the possible sources in the log messages. Note that this caveat applies only to the arguments that ssh.py adds by itself. In the case of ssh_args and ssh_extra_args, we know where they are from, and say so, though we can't say WHERE in the inventory they may be set (e.g. in host_vars or group_vars etc.). commit b605c285baf505f75f0b7d73cb76b00d4723d02e Author: Abhijit Menon-Sen <ams@2ndQuadrant.com> Date: Tue Aug 11 15:19:43 2015 +0530 Add a FAQ entry about ansible_ssh_extra_args commit 49f8edd035cd28dd1cf8945f44ec3d55212910bd Author: Abhijit Menon-Sen <ams@2ndQuadrant.com> Date: Mon Aug 10 20:48:50 2015 +0530 Allow ansible_ssh_args to be set as an inventory variable Before this change, ssh_args could be set only in the [ssh_connection] section of ansible.cfg, and was applied to all hosts. Now it's possible to set ansible_ssh_args as an inventory variable (directly, or through group_vars or host_vars) to selectively override the global setting. Note that the default ControlPath settings are applied only if ssh_args is not set, and this is true of ansible_ssh_args as well. So if you want to override ssh_args but continue to set ControlPath, you'll need to repeat the appropriate options when setting ansible_ssh_args. (If you only need to add options to the default ssh_args, you may be able to use the ansible_ssh_extra_args inventory variable instead.) commit 37c1a5b6794cee29a7809ad056a86365a2c0f886 Author: Abhijit Menon-Sen <ams@2ndQuadrant.com> Date: Mon Aug 10 19:42:30 2015 +0530 Allow overriding ansible_ssh_extra_args on the command-line This patch makes it possible to do: ansible somehost -m setup \ --ssh-extra-args '-o ProxyCommand="ssh -W %h:%p -q user@bouncer.example.com"' This overrides the inventory setting, if any, of ansible_ssh_extra_args. Based on a patch originally by @Richard2ndQuadrant. commit b023ace8a8a7ce6800e29129a27ebe8bf6bd38e0 Author: Abhijit Menon-Sen <ams@2ndQuadrant.com> Date: Mon Aug 10 19:06:19 2015 +0530 Add an ansible_ssh_extra_args inventory variable This can be used to configure a per-host or per-group ProxyCommand to connect to hosts through a jumphost, e.g.: inventory: [gatewayed] foo ansible_ssh_host=192.0.2.1 group_vars/gatewayed.yml: ansible_ssh_extra_args: '-o ProxyCommand="ssh -W %h:%p -q bounceuser@gateway.example.com"' Note that this variable is used in addition to any ssh_args configured in the [ssh_connection] section of ansible.cfg (so you don't need to repeat the ControlPath settings in ansible_ssh_extra_args).
2015-09-03 15:26:56 +00:00
ansible_ssh_common_args: '-o ProxyCommand="ssh -W %h:%p -q user@gateway.example.com"'
Squashed commit of the following: commit 9921bb9d2002e136c030ff337c14f8b7eab0fc72 Author: Abhijit Menon-Sen <ams@2ndQuadrant.com> Date: Mon Aug 10 20:19:44 2015 +0530 Document --ssh-extra-args command-line option commit 8b25595e7b1cc3658803d0821fbf498c18ee608a Author: Abhijit Menon-Sen <ams@2ndQuadrant.com> Date: Thu Aug 13 13:24:57 2015 +0530 Don't disable GSSAPI/Pubkey authentication when using --ask-pass This commit is based on a bug report and PR by kolbyjack (#6846) which was subsequently closed and rebased as #11690. The original problem was: «The password on the delegated host is different from the one I provided on the command line, so it had to use the pubkey, and the main host doesn't have a pubkey on it yet, so it had to use the password.» (This commit is revised and included here because #11690 would conflict with the changes in #11908 otherwise.) Closes #11690 commit 119d0323892c65e8169ae57e42bbe8e3517551a3 Author: Abhijit Menon-Sen <ams@2ndQuadrant.com> Date: Thu Aug 13 11:16:42 2015 +0530 Be more explicit about why SSH arguments are added This adds vvvvv log messages that spell out in detail where each SSH command-line argument is obtained from. Unfortunately, we can't be sure if, say, self._play_context.remote_user is obtained from ANSIBLE_REMOTE_USER in the environment, remote_user in ansible.cfg, -u on the command line, or an ansible_ssh_user setting in the inventory or on a task or play. In some cases, e.g. timeout, we can't even be sure if it was set by the user or just a default. Nevertheless, on the theory that at five v's you can use all the hints available, I've mentioned the possible sources in the log messages. Note that this caveat applies only to the arguments that ssh.py adds by itself. In the case of ssh_args and ssh_extra_args, we know where they are from, and say so, though we can't say WHERE in the inventory they may be set (e.g. in host_vars or group_vars etc.). commit b605c285baf505f75f0b7d73cb76b00d4723d02e Author: Abhijit Menon-Sen <ams@2ndQuadrant.com> Date: Tue Aug 11 15:19:43 2015 +0530 Add a FAQ entry about ansible_ssh_extra_args commit 49f8edd035cd28dd1cf8945f44ec3d55212910bd Author: Abhijit Menon-Sen <ams@2ndQuadrant.com> Date: Mon Aug 10 20:48:50 2015 +0530 Allow ansible_ssh_args to be set as an inventory variable Before this change, ssh_args could be set only in the [ssh_connection] section of ansible.cfg, and was applied to all hosts. Now it's possible to set ansible_ssh_args as an inventory variable (directly, or through group_vars or host_vars) to selectively override the global setting. Note that the default ControlPath settings are applied only if ssh_args is not set, and this is true of ansible_ssh_args as well. So if you want to override ssh_args but continue to set ControlPath, you'll need to repeat the appropriate options when setting ansible_ssh_args. (If you only need to add options to the default ssh_args, you may be able to use the ansible_ssh_extra_args inventory variable instead.) commit 37c1a5b6794cee29a7809ad056a86365a2c0f886 Author: Abhijit Menon-Sen <ams@2ndQuadrant.com> Date: Mon Aug 10 19:42:30 2015 +0530 Allow overriding ansible_ssh_extra_args on the command-line This patch makes it possible to do: ansible somehost -m setup \ --ssh-extra-args '-o ProxyCommand="ssh -W %h:%p -q user@bouncer.example.com"' This overrides the inventory setting, if any, of ansible_ssh_extra_args. Based on a patch originally by @Richard2ndQuadrant. commit b023ace8a8a7ce6800e29129a27ebe8bf6bd38e0 Author: Abhijit Menon-Sen <ams@2ndQuadrant.com> Date: Mon Aug 10 19:06:19 2015 +0530 Add an ansible_ssh_extra_args inventory variable This can be used to configure a per-host or per-group ProxyCommand to connect to hosts through a jumphost, e.g.: inventory: [gatewayed] foo ansible_ssh_host=192.0.2.1 group_vars/gatewayed.yml: ansible_ssh_extra_args: '-o ProxyCommand="ssh -W %h:%p -q bounceuser@gateway.example.com"' Note that this variable is used in addition to any ssh_args configured in the [ssh_connection] section of ansible.cfg (so you don't need to repeat the ControlPath settings in ansible_ssh_extra_args).
2015-09-03 15:26:56 +00:00
Ansible will append these arguments to the command line when trying to
connect to any hosts in the group `gatewayed`. (These arguments are used
in addition to any `ssh_args` from `ansible.cfg`, so you do not need to
repeat global `ControlPersist` settings in `ansible_ssh_common_args`.)
Squashed commit of the following: commit 9921bb9d2002e136c030ff337c14f8b7eab0fc72 Author: Abhijit Menon-Sen <ams@2ndQuadrant.com> Date: Mon Aug 10 20:19:44 2015 +0530 Document --ssh-extra-args command-line option commit 8b25595e7b1cc3658803d0821fbf498c18ee608a Author: Abhijit Menon-Sen <ams@2ndQuadrant.com> Date: Thu Aug 13 13:24:57 2015 +0530 Don't disable GSSAPI/Pubkey authentication when using --ask-pass This commit is based on a bug report and PR by kolbyjack (#6846) which was subsequently closed and rebased as #11690. The original problem was: «The password on the delegated host is different from the one I provided on the command line, so it had to use the pubkey, and the main host doesn't have a pubkey on it yet, so it had to use the password.» (This commit is revised and included here because #11690 would conflict with the changes in #11908 otherwise.) Closes #11690 commit 119d0323892c65e8169ae57e42bbe8e3517551a3 Author: Abhijit Menon-Sen <ams@2ndQuadrant.com> Date: Thu Aug 13 11:16:42 2015 +0530 Be more explicit about why SSH arguments are added This adds vvvvv log messages that spell out in detail where each SSH command-line argument is obtained from. Unfortunately, we can't be sure if, say, self._play_context.remote_user is obtained from ANSIBLE_REMOTE_USER in the environment, remote_user in ansible.cfg, -u on the command line, or an ansible_ssh_user setting in the inventory or on a task or play. In some cases, e.g. timeout, we can't even be sure if it was set by the user or just a default. Nevertheless, on the theory that at five v's you can use all the hints available, I've mentioned the possible sources in the log messages. Note that this caveat applies only to the arguments that ssh.py adds by itself. In the case of ssh_args and ssh_extra_args, we know where they are from, and say so, though we can't say WHERE in the inventory they may be set (e.g. in host_vars or group_vars etc.). commit b605c285baf505f75f0b7d73cb76b00d4723d02e Author: Abhijit Menon-Sen <ams@2ndQuadrant.com> Date: Tue Aug 11 15:19:43 2015 +0530 Add a FAQ entry about ansible_ssh_extra_args commit 49f8edd035cd28dd1cf8945f44ec3d55212910bd Author: Abhijit Menon-Sen <ams@2ndQuadrant.com> Date: Mon Aug 10 20:48:50 2015 +0530 Allow ansible_ssh_args to be set as an inventory variable Before this change, ssh_args could be set only in the [ssh_connection] section of ansible.cfg, and was applied to all hosts. Now it's possible to set ansible_ssh_args as an inventory variable (directly, or through group_vars or host_vars) to selectively override the global setting. Note that the default ControlPath settings are applied only if ssh_args is not set, and this is true of ansible_ssh_args as well. So if you want to override ssh_args but continue to set ControlPath, you'll need to repeat the appropriate options when setting ansible_ssh_args. (If you only need to add options to the default ssh_args, you may be able to use the ansible_ssh_extra_args inventory variable instead.) commit 37c1a5b6794cee29a7809ad056a86365a2c0f886 Author: Abhijit Menon-Sen <ams@2ndQuadrant.com> Date: Mon Aug 10 19:42:30 2015 +0530 Allow overriding ansible_ssh_extra_args on the command-line This patch makes it possible to do: ansible somehost -m setup \ --ssh-extra-args '-o ProxyCommand="ssh -W %h:%p -q user@bouncer.example.com"' This overrides the inventory setting, if any, of ansible_ssh_extra_args. Based on a patch originally by @Richard2ndQuadrant. commit b023ace8a8a7ce6800e29129a27ebe8bf6bd38e0 Author: Abhijit Menon-Sen <ams@2ndQuadrant.com> Date: Mon Aug 10 19:06:19 2015 +0530 Add an ansible_ssh_extra_args inventory variable This can be used to configure a per-host or per-group ProxyCommand to connect to hosts through a jumphost, e.g.: inventory: [gatewayed] foo ansible_ssh_host=192.0.2.1 group_vars/gatewayed.yml: ansible_ssh_extra_args: '-o ProxyCommand="ssh -W %h:%p -q bounceuser@gateway.example.com"' Note that this variable is used in addition to any ssh_args configured in the [ssh_connection] section of ansible.cfg (so you don't need to repeat the ControlPath settings in ansible_ssh_extra_args).
2015-09-03 15:26:56 +00:00
Note that `ssh -W` is available only with OpenSSH 5.4 or later. With
older versions, it's necessary to execute `nc %h:%p` or some equivalent
command on the bastion host.
With earlier versions of Ansible, it was necessary to configure a
suitable `ProxyCommand` for one or more hosts in `~/.ssh/config`,
or globally by setting `ssh_args` in `ansible.cfg`.
2013-10-04 17:27:19 +00:00
.. _ec2_cloud_performance:
2013-04-14 23:31:47 +00:00
How do I speed up management inside EC2?
++++++++++++++++++++++++++++++++++++++++
Don't try to manage a fleet of EC2 machines from your laptop. Connect to a management node inside EC2 first
and run Ansible from there.
2013-10-04 17:27:19 +00:00
.. _python_interpreters:
2013-04-14 23:31:47 +00:00
How do I handle python pathing not having a Python 2.X in /usr/bin/python on a remote machine?
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
While you can write ansible modules in any language, most ansible modules are written in Python, and some of these
are important core ones.
By default Ansible assumes it can find a /usr/bin/python on your remote system that is a 2.X version of Python, specifically
2.4 or higher.
Setting of an inventory variable 'ansible_python_interpreter' on any host will allow Ansible to auto-replace the interpreter
used when executing python modules. Thus, you can point to any python you want on the system if /usr/bin/python on your
system does not point to a Python 2.X interpreter.
Some Linux operating systems, such as Arch, may only have Python 3 installed by default. This is not sufficient and you will
get syntax errors trying to run modules with Python 3. Python 3 is essentially not the same
language as Python 2. Ansible modules currently need to support older Pythons for users that still have Enterprise Linux 5 deployed, so they are not yet ported to run under Python 3.0. This is not a problem though as you can just install Python 2 also on a managed host.
Python 3.0 support will likely be addressed at a later point in time when usage becomes more mainstream.
Do not replace the shebang lines of your python modules. Ansible will do this for you automatically at deploy time.
2013-10-04 17:27:19 +00:00
.. _use_roles:
2013-04-14 23:31:47 +00:00
What is the best way to make content reusable/redistributable?
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
If you have not done so already, read all about "Roles" in the playbooks documentation. This helps you make playbook content
self-contained, and works well with things like git submodules for sharing content with others.
2013-04-14 23:31:47 +00:00
If some of these plugin types look strange to you, see the API documentation for more details about ways Ansible can be extended.
2013-10-04 17:27:19 +00:00
.. _configuration_file:
2013-04-14 23:31:47 +00:00
Where does the configuration file live and what can I configure in it?
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
2013-12-21 07:06:38 +00:00
See :doc:`intro_configuration`.
2013-04-14 23:31:47 +00:00
2013-10-04 17:27:19 +00:00
.. _who_would_ever_want_to_disable_cowsay_but_ok_here_is_how:
2013-04-14 23:31:47 +00:00
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
that you would like to work in a professional cow-free environment, you can either uninstall cowsay, or set an environment variable::
export ANSIBLE_NOCOWS=1
2013-10-04 17:27:19 +00:00
.. _browse_facts:
2013-04-14 23:31:47 +00:00
How do I see a list of all of the ansible\_ variables?
++++++++++++++++++++++++++++++++++++++++++++++++++++++
Ansible by default gathers "facts" about the machines under management, and these facts can be accessed in Playbooks and in templates. To see a list of all of the facts that are available about a machine, you can run the "setup" module as an ad-hoc action::
ansible -m setup hostname
This will print out a dictionary of all of the facts that are available for that particular host. You might want to pipe the output to a pager.
.. _browse_inventory_vars:
How do I see all the inventory vars defined for my host?
++++++++++++++++++++++++++++++++++++++++++++++++++++++++
You can see the resulting vars you define in inventory running the following command::
ansible -m debug -a "var=hostvars['hostname']" localhost
2013-04-14 23:31:47 +00:00
2013-10-04 17:27:19 +00:00
.. _host_loops:
2013-04-14 23:31:47 +00:00
How do I loop over a list of hosts in a group, inside of a template?
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
A pretty common pattern is to iterate over a list of hosts inside of a host group, perhaps to populate a template configuration
2016-02-26 21:43:22 +00:00
file with a list of servers. To do this, you can just access the "$groups" dictionary in your template, like this:
.. code-block:: jinja
2013-04-14 23:31:47 +00:00
{% for host in groups['db_servers'] %}
{{ host }}
{% endfor %}
If you need to access facts about these hosts, for instance, the IP address of each hostname, you need to make sure that the facts have been populated. For example, make sure you have a play that talks to db_servers::
- hosts: db_servers
tasks:
2016-02-26 21:43:22 +00:00
- debug: msg="doesn't matter what you do, just that they were talked to previously."
2013-04-14 23:31:47 +00:00
Then you can use the facts inside your template, like this::
{% for host in groups['db_servers'] %}
{{ hostvars[host]['ansible_eth0']['ipv4']['address'] }}
{% endfor %}
2014-01-02 22:37:48 +00:00
.. _programatic_access_to_a_variable:
2014-03-15 14:36:42 +00:00
How do I access a variable name programmatically?
+++++++++++++++++++++++++++++++++++++++++++++++++
An example may come up where we need to get the ipv4 address of an arbitrary interface, where the interface to be used may be supplied
via a role parameter or other input. Variable names can be built by adding strings together, like so::
{{ hostvars[inventory_hostname]['ansible_' + which_interface]['ipv4']['address'] }}
2014-03-15 14:36:42 +00:00
The trick about going through hostvars is necessary because it's a dictionary of the entire namespace of variables. 'inventory_hostname'
is a magic variable that indicates the current host you are looping over in the host loop.
2014-01-02 22:37:48 +00:00
.. _first_host_in_a_group:
How do I access a variable of the first host in a group?
++++++++++++++++++++++++++++++++++++++++++++++++++++++++
What happens if we want the ip address of the first webserver in the webservers group? Well, we can do that too. Note that if we
are using dynamic inventory, which host is the 'first' may not be consistent, so you wouldn't want to do this unless your inventory
2014-01-29 04:41:39 +00:00
was static and predictable. (If you are using :doc:`tower`, it will use database order, so this isn't a problem even if you are using cloud
based inventory scripts).
Anyway, here's the trick::
{{ hostvars[groups['webservers'][0]]['ansible_eth0']['ipv4']['address'] }}
Notice how we're pulling out the hostname of the first machine of the webservers group. If you are doing this in a template, you
could use the Jinja2 '#set' directive to simplify this, or in a playbook, you could also use set_fact::
- set_fact: headnode={{ groups[['webservers'][0]] }}
- debug: msg={{ hostvars[headnode].ansible_eth0.ipv4.address }}
Notice how we interchanged the bracket syntax for dots -- that can be done anywhere.
2013-10-04 17:27:19 +00:00
.. _file_recursion:
2013-04-14 23:31:47 +00:00
How do I copy files recursively onto a target host?
+++++++++++++++++++++++++++++++++++++++++++++++++++
The "copy" module has a recursive parameter, though if you want to do something more efficient for a large number of files, take a look at the "synchronize" module instead, which wraps rsync. See the module index for info on both of these modules.
2013-04-14 23:31:47 +00:00
2013-10-04 17:27:19 +00:00
.. _shell_env:
2013-04-14 23:31:47 +00:00
How do I access shell environment variables?
++++++++++++++++++++++++++++++++++++++++++++
If you just need to access existing variables, use the 'env' lookup plugin. For example, to access the value of the HOME
environment variable on management machine::
---
# ...
vars:
local_home: "{{ lookup('env','HOME') }}"
If you need to set environment variables, see the Advanced Playbooks section about environments.
2013-10-04 17:27:19 +00:00
Ansible 1.4 will also make remote environment variables available via facts in the 'ansible_env' variable::
{{ ansible_env.SOME_VARIABLE }}
.. _user_passwords:
How do I generate crypted passwords for the user module?
++++++++++++++++++++++++++++++++++++++++++++++++++++++++
The mkpasswd utility that is available on most Linux systems is a great option::
mkpasswd --method=sha-512
If this utility is not installed on your system (e.g. you are using OS X) then you can still easily
generate these passwords using Python. First, ensure that the `Passlib <https://code.google.com/p/passlib/>`_
password hashing library is installed.
pip install passlib
Once the library is ready, SHA512 password values can then be generated as follows::
python -c "from passlib.hash import sha512_crypt; import getpass; print sha512_crypt.encrypt(getpass.getpass())"
Use the integrated :ref:`hash_filters` to generate a hashed version of a password.
2016-09-23 18:46:18 +00:00
You shouldn't put plaintext passwords in your playbook or host_vars; instead, use :doc:`playbooks_vault` to encrypt sensitive data.
2013-10-04 17:27:19 +00:00
.. _commercial_support:
2016-11-19 09:04:59 +00:00
Can I get training on Ansible?
++++++++++++++++++++++++++++++
2013-04-14 23:31:47 +00:00
2016-11-19 09:04:59 +00:00
Yes! See our `services page <http://www.ansible.com/consulting>`_ for information on our services and training offerings. Email `info@ansible.com <mailto:info@ansible.com>`_ for further details.
We also offer free web-based training classes on a regular basis. See our `webinar page <http://www.ansible.com/webinars-training>`_ for more info on upcoming webinars.
2013-04-14 23:31:47 +00:00
2013-10-04 17:27:19 +00:00
.. _web_interface:
Is there a web interface / REST API / etc?
++++++++++++++++++++++++++++++++++++++++++
Yes! Ansible, Inc makes a great product that makes Ansible even more powerful
and easy to use. See :doc:`tower`.
2013-10-04 17:27:19 +00:00
.. _docs_contributions:
2013-04-14 23:31:47 +00:00
How do I submit a change to the documentation?
++++++++++++++++++++++++++++++++++++++++++++++
Great question! Documentation for Ansible is kept in the main project git repository, and complete instructions for contributing can be found in the docs README `viewable on GitHub <https://github.com/ansible/ansible/blob/devel/docsite/README.md>`_. Thanks!
2013-04-14 23:31:47 +00:00
.. _keep_secret_data:
How do I keep secret data in my playbook?
+++++++++++++++++++++++++++++++++++++++++
2014-03-30 23:45:55 +00:00
If you would like to keep secret data in your Ansible content and still share it publicly or keep things in source control, see :doc:`playbooks_vault`.
In Ansible 1.8 and later, if you have a task that you don't want to show the results or command given to it when using -v (verbose) mode, the following task or playbook attribute can be useful::
- name: secret task
shell: /usr/bin/do_something --value={{ secret_value }}
no_log: True
This can be used to keep verbose output but hide sensitive information from others who would otherwise like to be able to see the output.
The no_log attribute can also apply to an entire play::
- hosts: all
no_log: True
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
no_log attribute does not prevent data from being shown when debugging Ansible itself via
the ANSIBLE_DEBUG environment variable.
2016-03-01 17:43:52 +00:00
.. _when_to_use_brackets:
.. _dynamic_variables:
.. _interpolate_variables:
2016-04-19 15:24:51 +00:00
When should I use {{ }}? Also, how to interpolate variables or dynamic variable names
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
2016-03-01 17:43:52 +00:00
A steadfast rule is 'always use {{ }} except when `when:`'.
Conditionals are always run through Jinja2 as to resolve the expression,
so `when:`, `failed_when:` and `changed_when:` are always templated and you should avoid adding `{{}}`.
In most other cases you should always use the brackets, even if previouslly you could use variables without specifying (like `with_` clauses),
as this made it hard to distinguish between an undefined variable and a string.
Another rule is 'moustaches don't stack'. We often see this::
{{ somevar_{{other_var}} }}
2016-03-01 17:43:52 +00:00
The above DOES NOT WORK, if you need to use a dynamic variable use the hostvars or vars dictionary as appropriate::
{{ hostvars[inventory_hostname]['somevar_' + other_var] }}
.. _i_dont_see_my_question:
2013-04-14 23:31:47 +00:00
I don't see my question here
++++++++++++++++++++++++++++
Please see the section below for a link to IRC and the Google Group, where you can ask your question there.
2013-04-14 23:31:47 +00:00
.. seealso::
:doc:`index`
The documentation index
:doc:`playbooks`
An introduction to playbooks
:doc:`playbooks_best_practices`
Best practices advice
`User Mailing List <http://groups.google.com/group/ansible-project>`_
Have a question? Stop by the google group!
`irc.freenode.net <http://irc.freenode.net>`_
#ansible IRC chat channel
2013-04-14 23:31:47 +00:00