* 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).
..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.
..note::
@ -64,40 +61,36 @@ Managed Node Requirements
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
: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::
Ansible's "raw" module (for executing commands in a quick and dirty
way) and the script module don't even need that. So technically, you can use
Ansible to install python-simplejson using the raw module, which
then allows you to use everything else. (That's jumping ahead
though.)
..note::
* If you have SELinux enabled on remote nodes, you will also want to install
libselinux-python on them before using any copy/file/template related functions in Ansible. You
can use the :ref:`yum` or :ref`dnf` module in Ansible to install this package on remote systems
that do not have it.
If you have SELinux enabled on remote nodes, you will also want to install
libselinux-python on them before using any copy/file/template related functions in
Ansible. You can of course still use the yum module in Ansible to install this package on
remote systems that do not have it.
* By default, Ansible uses the python interpreter located at :file:`/usr/bin/python` to run its
modules. However, some Linux distributions may only have a Python 3 interpreter installed to
:file:`/usr/bin/python3` by default. On those systems, you may see an error like::
..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
such as RHEL 6. However, some Linux distributions (Gentoo, Arch) may not have a
Python 2.X interpreter installed by default. On those systems, you should install one, and set
the ``ansible_python_interpreter`` variable in inventory (see :ref:`inventory`) to point at your 2.X Python. Distributions
like Red Hat Enterprise Linux, CentOS, Fedora, and Ubuntu all have a 2.X interpreter installed
by default and this does not apply to those distributions. This is also true of nearly all
Unix systems.
* Ansible's "raw" module (for executing commands in a quick and dirty way) and the script module
don't even need Python installed. So technically, you can use Ansible to install a compatible
version of Python using the :ref:`raw` module, which then allows you to use everything else.
For example, if you need to bootstrap Python 2 onto a RHEL-based system, you can install it
via
..code-block:: shell
If you need to bootstrap these remote systems by installing Python 2.X,
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.
ansible myhost --sudo -m raw -a "yum install -y python2"
.._installing_the_control_machine:
@ -204,8 +197,9 @@ To install the newest version, you may need to unmask the ansible package prior
..note::
If you have Python 3 as a default Python slot on your Gentoo nodes (default setting), then you
must set ``ansible_python_interpreter = /usr/bin/python2`` in your group or inventory variables.
The current default Python slot on Gentoo is version 3.4. Ansible needs Python-3.5 or higher so
you will need to `:ref:`bootstrap <managed_node_requirements>` a compatible version onto the
machines.
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.
..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.
On the controller side
----------------------
..note:: Technology preview features provide early access to upcoming product innovations,
enabling you to test functionality and provide feedback during the development process.
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.
By default commands are 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.
The shell type of the target system. You should not use this setting unless you have set the
:ref:`ansible_shell_executable` to a non-Bourne (sh) compatible shell. By default commands are
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
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`
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
be named something like :program:`python2.6`.
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.
..versionadded:: 2.1
.._ansible_shell_executable:
ansible_shell_executable
This sets the shell the ansible controller will use on the target machine,
overrides ``executable`` in :file:`ansible.cfg` which defaults to
Toshio Kuratomi
7 years ago