Bug 1402432

Summary: Prefer fqdn instead of IP when tracking if remote execution is enabled for the host
Product: Red Hat Satellite Reporter: Michal Dekan <mdekan>
Component: Remote ExecutionAssignee: Ivan Necas <inecas>
Status: CLOSED ERRATA QA Contact: jcallaha
Severity: high Docs Contact:
Priority: high    
Version: 6.2.4CC: bbuckingham, bkearney, brubisch, inecas, jcallaha, kelly.brown1, ktordeur, mlele, peter.vreman, rjerrido, xdmoon, zhunting
Target Milestone: UnspecifiedKeywords: PrioBumpGSS, Triaged
Target Release: Unused   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: tfm-rubygem-foreman_remote_execution-0.3.0.14-1 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
: 1417083 (view as bug list) Environment:
Last Closed: 2017-03-06 08:35:19 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:
Bug Depends On:    
Bug Blocks: 1417083    
Attachments:
Description Flags
verification screenshot none

Description Michal Dekan 2016-12-07 14:40:45 UTC 
Description of problem:

Customer has nodes within RAC cluster where IP addresses are changing quite often. This might result in jobs to be executed on the different host

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

Satellite 6.2.4

$ egrep 'remote|tfm-rubygem-katello' installed_packages 
tfm-rubygem-smart_proxy_remote_execution_ssh_core-0.1.2-1.el7sat.noarch
rubygem-smart_proxy_remote_execution_ssh-0.1.2-2.el7sat.noarch
tfm-rubygem-hammer_cli_foreman_remote_execution-0.0.5.3-1.el7sat.noarch
tfm-rubygem-foreman_remote_execution-0.3.0.12-1.el7sat.noarch
tfm-rubygem-katello-3.0.0.82-1.el7sat.noarch

How reproducible:

100%

Steps to Reproduce:

Taken from the case:

On my test system I have eth0 and eth1:

# facter
ipaddress => 10.12.213.48
ipaddress_eth0 => 10.12.213.48
ipaddress_eth1 => 10.12.212.180

So now, if I supply a puppet report of facts, the Satellite now knows my IP of my RE interface (eth0) and the other interface.
If I bring down eth0 now, and send a new puppet report the Satellite will report the IP as blank for the RE interface and the RE Job will fail to connect via SSH.
If we sent a new puppet report (puppet agent -tv), the Satellite will receive the new 'ipaddress' fact which has changed to the IP of eth1. Now when we attempt a job, even though that interface is NOT checked for RE, the job will succeed..

Actual results:

Network interface with RE NOT enabled successfully executes the jobs. 

Expected results:

Job should not be marked as successfully if new changed interface with IP was not marked for RE.

Additional info:

Can we use fqdn instead of ip address as a source of remote execution activation?
Comment 2 Ivan Necas 2016-12-07 15:18:41 UTC 
Created redmine issue http://projects.theforeman.org/issues/17603 from this bug
Comment 3 Ivan Necas 2016-12-07 17:41:38 UTC 
Proposed solution https://github.com/theforeman/foreman_remote_execution/pull/213
Comment 4 Bryan Kearney 2016-12-07 19:03:20 UTC 
Upstream bug assigned to inecas
Comment 5 Bryan Kearney 2016-12-07 19:03:23 UTC 
Upstream bug assigned to inecas
Comment 8 Satellite Program 2017-01-24 21:04:08 UTC 
Moving this bug to POST for triage into Satellite 6 since the upstream issue http://projects.theforeman.org/issues/17603 has been resolved.
Comment 9 Ivan Necas 2017-02-06 17:04:03 UTC 
Steps to verify:

1. set ip address on host primary interface to other value
2. run the execution job against the host

Expected result:

Primarily, the host fqdn should be used for addressing the host

To switch to the original behavior (which might be useful, when DNS present in the infrastructure), set 'remote_execution_connect_by_ip' to true in Remote Execution settings
Comment 12 jcallaha 2017-02-16 19:43:56 UTC 
Verified in Satellite 6.2.8 Snap 2.

Steps:
1. Enable remote execution on a remote host.
2. Change the ipaddress of the host's interface(s)
3. Run a job against the host.

Result:
The job completed successfully, as expected.

Negative test steps:
1. Use the host setup above
2. Navigate to Administer -> Settings
3. Click on the RemoteExecution tab
4. Change "remote_execution_connect_by_ip" to "true"
5. Run a job against the host

Result:
The job failed, as expected.
Errno::ETIMEDOUT Connection timed out - connect(2) for "10.19.34.1" port 22

See attached image to see the first job succeed and the second job fail.
Comment 13 jcallaha 2017-02-16 19:44:41 UTC 
Created attachment 1250936 [details]
verification screenshot
Comment 15 errata-xmlrpc 2017-03-06 08:35:19 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2017:0447