Description of problem:
Time to time we in support hit a case where one Satellite steps into toes of another Satellite due to wrong FQDN resolution - often a cloned Satellite talks to production Satellite instead of itself.

This can cause various issues like 04042817 where cloned Satellite removed many random CVs (so katello repositories were almost empty), but katello remove orphans talked to production Satellite to align their pulp to be also almost empty.

These issues happen rarely (say once per year per my experience), but they are hard to identify and with potential very harmful effect (many CVs returned 404 as pulp data were gone here).

Shall we have some protection or at least detection against that?

Possible ideas:

• enforce an entry in /etc/hosts resolving hostname to own IP address - this would mimic DNS and would cause more harm than any gain for most of customers (who will be responsible for maintaining this record?)
• Satellite clone should detect FQDN is not resolved to its own IP, and warn (or halt the clone? that would be too abrupt)
• have a warning in documentation to Sat clone about this?
• some other idea..?
   

How reproducible:
100%
 

Is this issue a regression from an earlier version:
no
 

Steps to Reproduce:

One potential scenario:
1. Clone a Satellite to a new system with same FQDN that is resolved to the IP address of the first Satellite

2. From the cloned Satellite, remove some CVs

3. Wait for Sunday's katello orphan cleanup

4. Try if clients can access CVs from the main Satellite (those CVs we deleted from the backup/testing one).

Actual behavior:
[Describe the issue in detail, including what is happening and where]

Expected behavior:
[Describe what should be happening instead]

Business Impact / Additional info: