Hide Forgot
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?
Created redmine issue http://projects.theforeman.org/issues/17603 from this bug
Proposed solution https://github.com/theforeman/foreman_remote_execution/pull/213
Upstream bug assigned to inecas
Moving this bug to POST for triage into Satellite 6 since the upstream issue http://projects.theforeman.org/issues/17603 has been resolved.
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
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.
Created attachment 1250936 [details] verification screenshot
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