Clarify the document about the order of matryoshka shells
(nesting shells)
This commit is contained in:
parent
6265d6fd2a
commit
ab693579a9
1 changed files with 20 additions and 15 deletions
|
@ -173,8 +173,8 @@ class ConnectionBase(with_metaclass(ABCMeta, object)):
|
||||||
When a command is executed, it goes through multiple commands to get
|
When a command is executed, it goes through multiple commands to get
|
||||||
there. It looks approximately like this::
|
there. It looks approximately like this::
|
||||||
|
|
||||||
HardCodedShell ConnectionCommand UsersLoginShell DEFAULT_EXECUTABLE BecomeCommand DEFAULT_EXECUTABLE Command
|
[LocalShell] ConnectionCommand [UsersLoginShell (*)] DEFAULT_EXECUTABLE [(BecomeCommand DEFAULT_EXECUTABLE)] Command
|
||||||
:HardCodedShell: Is optional. It is run locally to invoke the
|
:LocalShell: Is optional. It is run locally to invoke the
|
||||||
``Connection Command``. In most instances, the
|
``Connection Command``. In most instances, the
|
||||||
``ConnectionCommand`` can be invoked directly instead. The ssh
|
``ConnectionCommand`` can be invoked directly instead. The ssh
|
||||||
connection plugin which can have values that need expanding
|
connection plugin which can have values that need expanding
|
||||||
|
@ -187,15 +187,17 @@ class ConnectionBase(with_metaclass(ABCMeta, object)):
|
||||||
``ansible_ssh_host`` and so forth are fed to this piece of the
|
``ansible_ssh_host`` and so forth are fed to this piece of the
|
||||||
command to connect to the correct host (Examples ``ssh``,
|
command to connect to the correct host (Examples ``ssh``,
|
||||||
``chroot``)
|
``chroot``)
|
||||||
:UsersLoginShell: This is the shell that the ``ansible_ssh_user`` has
|
:UsersLoginShell: This shell may or may not be created depending on
|
||||||
configured as their login shell. In traditional UNIX parlance,
|
the ConnectionCommand used by the connection plugin. This is the
|
||||||
this is the last field of a user's ``/etc/passwd`` entry We do not
|
shell that the ``ansible_ssh_user`` has configured as their login
|
||||||
specifically try to run the ``UsersLoginShell`` when we connect.
|
shell. In traditional UNIX parlance, this is the last field of
|
||||||
Instead it is implicit in the actions that the
|
a user's ``/etc/passwd`` entry We do not specifically try to run
|
||||||
``ConnectionCommand`` takes when it connects to a remote machine.
|
the ``UsersLoginShell`` when we connect. Instead it is implicit
|
||||||
``ansible_shell_type`` may be set to inform ansible of differences
|
in the actions that the ``ConnectionCommand`` takes when it
|
||||||
in how the ``UsersLoginShell`` handles things like quoting if a
|
connects to a remote machine. ``ansible_shell_type`` may be set
|
||||||
shell has different semantics than the Bourne shell.
|
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
|
:DEFAULT_EXECUTABLE: This is the shell accessible via
|
||||||
``ansible.constants.DEFAULT_EXECUTABLE``. We explicitly invoke
|
``ansible.constants.DEFAULT_EXECUTABLE``. We explicitly invoke
|
||||||
this shell so that we have predictable quoting rules at this
|
this shell so that we have predictable quoting rules at this
|
||||||
|
@ -207,10 +209,13 @@ class ConnectionBase(with_metaclass(ABCMeta, object)):
|
||||||
``BecomeCommand``. After the ConnectionCommand, this is run by
|
``BecomeCommand``. After the ConnectionCommand, this is run by
|
||||||
the ``UsersLoginShell``. After the ``BecomeCommand`` we specify
|
the ``UsersLoginShell``. After the ``BecomeCommand`` we specify
|
||||||
that the ``DEFAULT_EXECUTABLE`` is being invoked directly.
|
that the ``DEFAULT_EXECUTABLE`` is being invoked directly.
|
||||||
:BecomeComand: Is the command that performs privilege escalation.
|
:BecomeComand DEFAULTEXECUTABLE: Is the command that performs
|
||||||
Setting this up is performed by the action plugin prior to running
|
privilege escalation. Setting this up is performed by the action
|
||||||
``exec_command``. So we just get passed :param:`cmd` which has the
|
plugin prior to running ``exec_command``. So we just get passed
|
||||||
BecomeCommand already added. (Examples: sudo, su)
|
: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.
|
||||||
:Command: Is the command we're actually trying to run remotely.
|
:Command: Is the command we're actually trying to run remotely.
|
||||||
(Examples: mkdir -p $HOME/.ansible, python $HOME/.ansible/tmp-script-file)
|
(Examples: mkdir -p $HOME/.ansible, python $HOME/.ansible/tmp-script-file)
|
||||||
"""
|
"""
|
||||||
|
|
Loading…
Reference in a new issue