You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
However when running a playbook that is present inside the EE, against a target, then it fails to authenticate. Adding the debug flag indicates that the runner in fact doesn’t add any mount options when executing podman, that would handle any SSH keys.
I have been trying to get my head around the intent of the code, but it's really hard to match the docs to the code and trying to guess what is intentional and what is dead code or code waiting(?) to be moved over to ansible-navigator.
Anyways, i think i have found two issues?
Both runner.py and _base.py defines the handle_command_wrap function. However, the version in runner.py#L415 explicitly sets BaseExecutionMode.NONE as the execution mode, when calling wrap_args_for_containerization, regardless of the self.execution_mode being set earlier based on the actual execution mode defined through the CLI options.
In Refactoring and purging playbook and ad-hoc commands #689, the wrap_args_for_containerization function in _base.py got refactored, and quite a substantial part of this functions logic got wrapped in the following if statement:
# For run() and run_async() API value of base execution_mode is 'BaseExecutionMode.NONE'
# and the container volume mounts are handled separately using 'container_volume_mounts'
# hence ignore additional mount here
ifexecution_mode!=BaseExecutionMode.NONE:
effectively ensuring that none of that code will ever(?) be executed, as the execution mode is enforced to be NONE as per finding 1 above. Specifically it skips the call to the _handle_automounts function, which seems to be responsible for trying to handle SSH credentials.
Besides this, isn't it kind of defeating the purpose of the container isolation, when using --ipc=host? I assume this is primarily to allow access to the ssh-agent socket?
The text was updated successfully, but these errors were encountered:
The runner docs seems to indicate that when run using an EE, then it should mount in the SSH agent and/or the host users ~/.ssh (as long as it is not symlinked). Ref: Using Runner with Execution Environments — Ansible Runner Documentation 1
However when running a playbook that is present inside the EE, against a target, then it fails to authenticate. Adding the debug flag indicates that the runner in fact doesn’t add any mount options when executing podman, that would handle any SSH keys.
I have been trying to get my head around the intent of the code, but it's really hard to match the docs to the code and trying to guess what is intentional and what is dead code or code waiting(?) to be moved over to ansible-navigator.
Anyways, i think i have found two issues?
Both runner.py and _base.py defines the
handle_command_wrap
function. However, the version in runner.py#L415 explicitly setsBaseExecutionMode.NONE
as the execution mode, when callingwrap_args_for_containerization
, regardless of theself.execution_mode
being set earlier based on the actual execution mode defined through the CLI options.In Refactoring and purging playbook and ad-hoc commands #689, the
wrap_args_for_containerization
function in _base.py got refactored, and quite a substantial part of this functions logic got wrapped in the following if statement:ansible-runner/src/ansible_runner/config/_base.py
Lines 516 to 519 in 1bad459
effectively ensuring that none of that code will ever(?) be executed, as the execution mode is enforced to be
NONE
as per finding 1 above. Specifically it skips the call to the_handle_automounts
function, which seems to be responsible for trying to handle SSH credentials.Besides this, isn't it kind of defeating the purpose of the container isolation, when using
--ipc=host
? I assume this is primarily to allow access to thessh-agent
socket?The text was updated successfully, but these errors were encountered: