Bug 2203239

Summary: The ssh-user and password inputs per job is not being honored for Ansible based Remote Executions
Product: Red Hat Satellite Reporter: Sayan Das <saydas>
Component: Ansible - Configuration ManagementAssignee: satellite6-bugs <satellite6-bugs>
Status: CLOSED DUPLICATE QA Contact: Satellite QE Team <sat-qe-bz-list>
Severity: medium Docs Contact:
Priority: medium    
Version: 6.13.0CC: ahumbe, aruzicka, nalfassi
Target Milestone: UnspecifiedKeywords: Triaged
Target Release: Unused   
Hardware: All   
OS: All   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2023-05-23 08:44:26 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Sayan Das 2023-05-11 15:35:51 UTC
Description of problem:

When I am using hammer to create a job or using GUI to create a job and trying to specify SSH user \ Effective User and passwords, 

The job will be successful for 'Run Command - Script Default' template as it honors the SSH user inputs 

The job will fail for 'Run Command - Ansible Default' template, as SSH user inputs are not accepted and Ansible tries to SSH to the host via root user only

Version-Release number of selected component (if applicable):

Satellite 6.13.0

How reproducible:

Always

Steps to Reproduce:
1. Install a Satellite 6.13

2. Register a client system ( say name client.example.com )

3. Follow https://access.redhat.com/solutions/2650071 to setup REX based on Non-ROOT users

4. Try to Run two jobs on the client.example.com system using hammer or Satellite UI while specifying Effective User\SSH User and their passwords on the Job invocation page itself.

hammer job-invocation create --job-template 'Run Command - Ansible Default' --inputs 'command=uptime' --search-query "name = client.example.com" --organization RedHat --location GSS --ssh-user rexuser --password password --effective-user root --effective-user-password redhat


hammer job-invocation create --job-template 'Run Command - Script Default' --inputs 'command=uptime' --search-query "name = client.example.com" --organization RedHat --location GSS --ssh-user rexuser --password password --effective-user root --effective-user-password redhat


Actual results:

Job started by the first hammer command will fail
Job started by the second hammer command will be successful. 

If we take a look at the Failed Job from the Monitor --> Jobs page, It will show that 

SSH User: rexuser

Run Command - Ansible Default effective user  : root

But then if we actually check the dynflow console of the task, I see 

        ansible_user: root
        ansible_become_method: sudo
        ansible_port: 22
        ansible_host: client.example.com
        ansible_ssh_port: 22
        ansible_ssh_user: root
        ansible_roles_check_mode: false
        remote_execution_ssh_user: root
        remote_execution_effective_user_method: sudo

So for some reason, The ansible based jobs are not honoring the inputs. 


Expected results:

Ansible-based jobs should honor the per-job inputs properly. 


Additional info:

The same can be easily reproduced from Sat WebUI

Comment 1 Adam Ruzicka 2023-05-15 08:41:38 UTC
This seems to be ansible specific?

Comment 2 Sayan Das 2023-05-15 08:45:56 UTC
Yes true.. But I selected Remote Execution as It's about not using the inputs about that ssh_user\password that we pass during Job Invokation. I am fine with either as long as the right team helps to fix the issue.

I noticed you already switched the component to Ansible, so we should be good here.

Comment 3 Sayan Das 2023-05-18 08:35:45 UTC
Related BZ

2153727 – Ansible Command ignores advance field
https://bugzilla.redhat.com/show_bug.cgi?id=2153727


And both the Bugs perhaps affects 6.11 - 6.13

Comment 5 Sayan Das 2023-05-23 08:44:26 UTC
Closing this BZ as a duplicate of https://bugzilla.redhat.com/show_bug.cgi?id=2153727

*** This bug has been marked as a duplicate of bug 2153727 ***