* Update the documentation to list Python 3 as official
* Add some reference targets for inventory variables so we can link to docs
* Add a platform FAQ section
Populate it with
* virtualenv info (previously on the python3 support page)
* BSD (Link to the working with BSD page)
* Solaris (Document how to work around the non-POSIX shell on some
Solaris hosts)
Fixes#21594
* Fix some refs in the release_and_maintenance document
* Fix unindent error in module template
Fix for the module/plugin template unintentionally unindented inside of
a raw block, leading to errors like:
ERROR: docs/docsite/rst/modules/redshift_facts_module.rst:289:0: Explicit markup ends without a blank line; unexpected unindent.
* Make wording for Solaris troubleshooting better.
(cherry picked from commit a08459a814)
Currently Ansible can be run from any machine with Python 2 (versions 2.6 or 2.7) or Python 3 (versions 3.5 and higher) installed (Windows isn't supported for the control machine).
Currently Ansible can be run from any machine with Python 2 (versions 2.6 or 2.7) or Python 3 (versions 3.5 and higher) installed (Windows isn't supported for the control machine).
..note::
Ansible 2.2 introduces a tech preview of support for Python 3 (versions 3.5 and higher). For more information, see `Python 3 Support <http://docs.ansible.com/ansible/python_3_support.html>`_.
This includes Red Hat, Debian, CentOS, OS X, any of the BSDs, and so on.
This includes Red Hat, Debian, CentOS, OS X, any of the BSDs, and so on.
..note::
..note::
@ -64,40 +61,36 @@ Managed Node Requirements
On the managed nodes, you need a way to communicate, which is normally ssh. By
On the managed nodes, you need a way to communicate, which is normally ssh. By
default this uses sftp. If that's not available, you can switch to scp in
default this uses sftp. If that's not available, you can switch to scp in
:file:`ansible.cfg`. You also need Python 2.6 or later.
:file:`ansible.cfg`. You also need Python 2 (version 2.6 or later) or Python 3 (version 3.5 or
later).
..note::
..note::
Ansible's "raw" module (for executing commands in a quick and dirty
* If you have SELinux enabled on remote nodes, you will also want to install
way) and the script module don't even need that. So technically, you can use
libselinux-python on them before using any copy/file/template related functions in Ansible. You
Ansible to install python-simplejson using the raw module, which
can use the :ref:`yum` or :ref`dnf` module in Ansible to install this package on remote systems
then allows you to use everything else. (That's jumping ahead
that do not have it.
though.)
..note::
If you have SELinux enabled on remote nodes, you will also want to install
* By default, Ansible uses the python interpreter located at :file:`/usr/bin/python` to run its
libselinux-python on them before using any copy/file/template related functions in
modules. However, some Linux distributions may only have a Python 3 interpreter installed to
Ansible. You can of course still use the yum module in Ansible to install this package on
:file:`/usr/bin/python3` by default. On those systems, you may see an error like::
remote systems that do not have it.
..note::
"module_stdout": "/bin/sh: /usr/bin/python: No such file or directory\r\n"
Ansible 2.2 introduces a tech preview of support for Python 3. For more information, see `Python 3 Support <http://docs.ansible.com/ansible/python_3_support.html>`_.
you can either set the :ref:`ansible_python_interpreter` inventory variable (see
:ref:`inventory`) to point at your interpreter or you can install a Python 2 interpreter for
modules to use. You will still need to set :ref:`ansible_python_interpreter` if the Python
2 interpreter is not installed to :command:`/usr/bin/python`.
By default, Ansible uses Python 2 in order to maintain compatibility with older distributions
* Ansible's "raw" module (for executing commands in a quick and dirty way) and the script module
such as RHEL 6. However, some Linux distributions (Gentoo, Arch) may not have a
don't even need Python installed. So technically, you can use Ansible to install a compatible
Python 2.X interpreter installed by default. On those systems, you should install one, and set
version of Python using the :ref:`raw` module, which then allows you to use everything else.
the ``ansible_python_interpreter`` variable in inventory (see :ref:`inventory`) to point at your 2.X Python. Distributions
For example, if you need to bootstrap Python 2 onto a RHEL-based system, you can install it
like Red Hat Enterprise Linux, CentOS, Fedora, and Ubuntu all have a 2.X interpreter installed
via
by default and this does not apply to those distributions. This is also true of nearly all
Unix systems.
..code-block:: shell
If you need to bootstrap these remote systems by installing Python 2.X,
ansible myhost --sudo -m raw -a "yum install -y python2"
using the 'raw' module will be able to do it remotely. For example,
``ansible myhost --sudo -m raw -a "yum install -y python2 python-simplejson"``
would install Python 2.X and the simplejson module needed to run ansible and its modules.
.._installing_the_control_machine:
.._installing_the_control_machine:
@ -204,8 +197,9 @@ To install the newest version, you may need to unmask the ansible package prior
..note::
..note::
If you have Python 3 as a default Python slot on your Gentoo nodes (default setting), then you
The current default Python slot on Gentoo is version 3.4. Ansible needs Python-3.5 or higher so
must set ``ansible_python_interpreter = /usr/bin/python2`` in your group or inventory variables.
you will need to `:ref:`bootstrap <managed_node_requirements>` a compatible version onto the
machines.
Latest Releases Via pkg (FreeBSD)
Latest Releases Via pkg (FreeBSD)
+++++++++++++++++++++++++++++++++
+++++++++++++++++++++++++++++++++
@ -254,11 +248,6 @@ The AUR has a PKGBUILD for pulling directly from Github called `ansible-git <htt
Also see the `Ansible <https://wiki.archlinux.org/index.php/Ansible>`_ page on the ArchWiki.
Also see the `Ansible <https://wiki.archlinux.org/index.php/Ansible>`_ page on the ArchWiki.
..note::
If you have Python 3 as a default Python slot on your Arch nodes (default setting), then you
must set ``ansible_python_interpreter = /usr/bin/python2`` in your group or inventory variables.
Ansible 2.2, 2.3, and 2.4 feature a tech preview of Python 3 support. This topic discusses how you can test to make sure your modules and playbooks work with Python 3.
Ansible 2.5 and above have support for Python 3. Previous to 2.5, the Python 3 support was
considered a tech preview. This topic discusses how to setup your controller and managed machines
to use Python 3.
..note:: Ansible supports Python version 3.5 and above only.
..note:: Ansible supports Python version 3.5 and above only.
On the controller side
----------------------
..note:: Technology preview features provide early access to upcoming product innovations,
The easiest way to run :command:`/usr/bin/ansible` under Python 3 is to install it with the Python3
enabling you to test functionality and provide feedback during the development process.
version of pip. This will make the default :command:`/usr/bin/ansible` run with Python3:
Please be aware that tech preview features may not be functionally complete and are not
intended for production use. To report a Python 3 bug, please see `Community Information & Contributing <http://docs.ansible.com/ansible/community.html#i-d-like-to-report-a-bug>`_.
Testing Python 3 with commands and playbooks
--------------------------------------------
* Run Ansible 2.2+ - See :ref:`from_source`
* To test Python 3 on the controller, run your ansible command via
The shell type of the target system. You should not use this setting unless you have set the ``ansible_shell_executable`` to a non-Bourne (sh) compatible shell.
The shell type of the target system. You should not use this setting unless you have set the
By default commands are formatted using ``sh``-style syntax.
:ref:`ansible_shell_executable` to a non-Bourne (sh) compatible shell. By default commands are
Setting this to ``csh`` or ``fish`` will cause commands executed on target systems to follow those shell's syntax instead.
formatted using ``sh``-style syntax. Setting this to ``csh`` or ``fish`` will cause commands
executed on target systems to follow those shell's syntax instead.
.._ansible_python_interpreter:
ansible_python_interpreter
ansible_python_interpreter
The target host python path. This is useful for systems with more
The target host python path. This is useful for systems with more
than one Python or not located at :command:`/usr/bin/python` such as \*BSD, or where :command:`/usr/bin/python`
than one Python or not located at :command:`/usr/bin/python` such as \*BSD, or where :command:`/usr/bin/python`
is not a 2.X series Python. We do not use the :command:`/usr/bin/env` mechanism as that requires the remote user's
is not a 2.X series Python. We do not use the :command:`/usr/bin/env` mechanism as that requires the remote user's
path to be set right and also assumes the :program:`python` executable is named python, where the executable might
path to be set right and also assumes the :program:`python` executable is named python, where the executable might
be named something like :program:`python2.6`.
be named something like :program:`python2.6`.
ansible_*_interpreter
ansible_*_interpreter
Works for anything such as ruby or perl and works just like ``ansible_python_interpreter``.
Works for anything such as ruby or perl and works just like :ref:`ansible_python_interpreter`.
This replaces shebang of modules which will run on that host.
This replaces shebang of modules which will run on that host.
..versionadded:: 2.1
..versionadded:: 2.1
.._ansible_shell_executable:
ansible_shell_executable
ansible_shell_executable
This sets the shell the ansible controller will use on the target machine,
This sets the shell the ansible controller will use on the target machine,
overrides ``executable`` in :file:`ansible.cfg` which defaults to
overrides ``executable`` in :file:`ansible.cfg` which defaults to
Toshio Kuratomi
7 years ago