Bug 1442261

Description of problem:

When using bootstrap.py to register a client host to a capsule, there is still some unknown ties to the main satellite server that's not obvious. The problem does not exist if the process is being done manually without bootstrap.py (i.e.: install katello-ca-consumer, sub-mgr register and etc).

This becomes an issue when doing remote execution, because of the unknown ties to the main satellite server, the ssh initiation always seem to be from the server rather than the capsule, even if remote_execution_global_proxy & remote_execution_fallback_proxy set accordingly.


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

- katello-client-bootstrap-1.2.2-1.el7sat.noarch
- 6.2.8 and yum update to the latest as of now

How reproducible:

- Always

Steps to Reproduce:

1. Server: sat6, Capsule: sat6c; Ensure rex plugin enabled on both server & capsule; Location: location1, location2; 

2. Assign sat6 to location1 only; Assign sat6c to location2 only;

3. Manage Locations->location1->capsules: selected only with sat6; Manage Locations->location2->capsules: selected only with sat6c

4. Infrastructure->Capsules: edit to ensure sat6 with only location1 selected; Infrastructure->Capsules: edit to ensure sat6c with only location2 selected;

5. Administer->RemoteExecution: set remote_execution_global_proxy false; set remote_execution_fallback_proxy true.

6. Create the needed environment, content view, subnet, domain, operating system info and activation key and etc, so to create a host group to use with bootstrap.py. Ensure host group's location is only selected for location2. Ensure host group's content source, puppet ca/master are all pointed to the sat6c capsule.

7. For subnet, one subnet for both locations and server and capsule. Ensure Remote Execution tab under the subnet with emtpy/no selected items. With the remote_execution params setting on step 5, this forces the ssh connection to be from the capsule the system is connected to.

8. bootstrap a host to the capsule server with rex enabled, e.g.:

- ./bootstrap.py -l admin -s sat6c.domain.com -o Example -L "location2" -g "dev/rhel-6Server-x86_64" -a act-dev-os-rhel-6Server --rex --rex-user root

9. Sign the cert to move the bootstrap process along.

10. Now run a command on the system that just got bootstraped, using Commands->Run Command - SSH Default with excute now. It would fail because it's kicking off from sat6 instead of sat6c, which the system doesn't have sat6 server's pub key but only sat6c's.

11. This shows that there is some sorta ties with the sat6 server on the content host when bootstrap from the bootstrap.py. This can be verified by going Manage Locations-> location2->Capsules pane, you can see that sat6 server is under the All items pane but shows up red and complaining about "you cannot remove smart proxies that are used by hosts or inherited".

12. If you don't use bootstrap.py and manually register the host to the sat6c capsule and all that, there is no ties to the sat6 server and no issue of such.


Actual results:

- Remote execution failed, ssh initiated from sat6 server instead of sat6c capsule.
- Some sorta ties back to the sat6 server when using bootstrap.py

Expected results:

- Remote execution succeed, ssh initiated from sat6c capsule.
- No ties back to the sat6 server when using bootstrap.py to register to the sat6c capsule.

Additional info: