cmueller/ansible
1
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

More doc updates regarding ansible_shell_executable

Browse source
This commit is contained in:
Toshio Kuratomi 2016-03-18 09:16:21 -07:00
parent 8bdf0d4746
commit 60c943997b
2 changed files with 15 additions and 14 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

2
docsite/rst/intro_inventory.rst
View file

@ -267,7 +267,7 @@ ansible_shell_executable
overrides ``executable`` in :file:`ansible.cfg` which defaults to
:command:`/bin/sh`. You should really only change it if is not possible
to use :command:`/bin/sh` (i.e. :command:`/bin/sh` is not installed on the target
machine.).
machine or cannot be run from sudo.).
Examples from a host file::

27
lib/ansible/plugins/connection/__init__.py
View file

@ -173,7 +173,7 @@ class ConnectionBase(with_metaclass(ABCMeta, object)):
When a command is executed, it goes through multiple commands to get
there. It looks approximately like this::
[LocalShell] ConnectionCommand [UsersLoginShell (*)] DEFAULT_EXECUTABLE [(BecomeCommand DEFAULT_EXECUTABLE)] Command
[LocalShell] ConnectionCommand [UsersLoginShell (*)] ANSIBLE_SHELL_EXECUTABLE [(BecomeCommand ANSIBLE_SHELL_EXECUTABLE)] Command
:LocalShell: Is optional. It is run locally to invoke the
``Connection Command``. In most instances, the
``ConnectionCommand`` can be invoked directly instead. The ssh
@ -198,24 +198,25 @@ class ConnectionBase(with_metaclass(ABCMeta, object)):
to inform ansible of differences in how the ``UsersLoginShell``
handles things like quoting if a shell has different semantics
than the Bourne shell.
:DEFAULT_EXECUTABLE: This is the shell accessible via
``ansible.constants.DEFAULT_EXECUTABLE``. We explicitly invoke
this shell so that we have predictable quoting rules at this
point. The ``DEFAULT_EXECUTABLE`` is only settable by the user
because some sudo setups may only allow invoking a specific Bourne
shell. (For instance, ``/bin/bash`` may be allowed but
``/bin/sh``, our default, may not). We invoke this twice, once
after the ``ConnectionCommand`` and once after the
:ANSIBLE_SHELL_EXECUTABLE: This is the shell set via the inventory var
``ansible_shell_executable`` or via
``constants.DEFAULT_EXECUTABLE`` if the inventory var is not set.
We explicitly invoke this shell so that we have predictable
quoting rules at this point. ``ANSIBLE_SHELL_EXECUTABLE`` is only
settable by the user because some sudo setups may only allow
invoking a specific shell. (For instance, ``/bin/bash`` may be
allowed but ``/bin/sh``, our default, may not). We invoke this
twice, once after the ``ConnectionCommand`` and once after the
``BecomeCommand``. After the ConnectionCommand, this is run by
the ``UsersLoginShell``. After the ``BecomeCommand`` we specify
that the ``DEFAULT_EXECUTABLE`` is being invoked directly.
:BecomeComand DEFAULTEXECUTABLE: Is the command that performs
that the ``ANSIBLE_SHELL_EXECUTABLE`` is being invoked directly.
:BecomeComand ANSIBLE_SHELL_EXECUTABLE: Is the command that performs
privilege escalation. Setting this up is performed by the action
plugin prior to running ``exec_command``. So we just get passed
:param:`cmd` which has the BecomeCommand already added.
(Examples: sudo, su) If we have a BecomeCommand then we will
invoke a DEFAULT_EXECUTABLE shell inside of it so that we have
a consistent view of quoting.
invoke a ANSIBLE_SHELL_EXECUTABLE shell inside of it so that we
have a consistent view of quoting.
:Command: Is the command we're actually trying to run remotely.
(Examples: mkdir -p $HOME/.ansible, python $HOME/.ansible/tmp-script-file)
"""