A base class for connections to contain common code.
Terminate the connection
Read-only property holding whether the connection to the remote host is active or closed.
Run a command on the remote host.
Parameters: |
|
---|---|
Returns: | a tuple of (return code, stdout, stderr) The return code is an int while stdout and stderr are both byte strings. |
When a command is executed, it goes through multiple commands to get there. It looks approximately like this:
[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 connection plugin which can have values that need expanding locally specified via ssh_args is the sole known exception to this. Shell metacharacters in the command itself should be processed on the remote machine, not on the local machine so no shell is needed on the local machine. (Example, /bin/sh) |
---|---|
ConnectionCommand: | |
This is the command that connects us to the remote machine to run the rest of the command. ansible_ssh_user, ansible_ssh_host and so forth are fed to this piece of the command to connect to the correct host (Examples ssh, chroot) | |
UsersLoginShell: | |
This shell may or may not be created depending on the ConnectionCommand used by the connection plugin. This is the shell that the ansible_ssh_user has configured as their login shell. In traditional UNIX parlance, this is the last field of a user’s /etc/passwd entry We do not specifically try to run the UsersLoginShell when we connect. Instead it is implicit in the actions that the ConnectionCommand takes when it connects to a remote machine. ansible_shell_type may be set to inform ansible of differences in how the UsersLoginShell handles things like quoting if a shell has different semantics than the Bourne shell. | |
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 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 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) |
Fetch a file from remote to local
Transfer a file from local to remote
An optional method, which can be used to set connection plugin parameters from variables set on the host (or groups to which the host belongs)
Any connection plugin using this should first initialize its attributes in an overridden def __init__(self):, and then use host.get_vars() to find variables which may be used to set those attributes in this method.
String used to identify this Connection class from other classes