Bug 2275964
Summary: | The content source of a host is always set to nil or blank when CNAME of the satellite is used for registration purposes | ||
---|---|---|---|
Product: | Red Hat Satellite | Reporter: | Sayan Das <saydas> |
Component: | Hosts - Content | Assignee: | satellite6-bugs <satellite6-bugs> |
Status: | CLOSED MIGRATED | QA Contact: | Satellite QE Team <sat-qe-bz-list> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 6.14.2 | CC: | ahumbe, gmukhrai, jlenz, peter.vreman, rlavi |
Target Milestone: | Unspecified | Keywords: | MigratedToJIRA, Regression, Triaged |
Target Release: | Unused | ||
Hardware: | x86_64 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | If docs needed, set a value | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2024-06-06 17:28:50 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
2024-04-18 18:26:38 UTC
CC'ing, Peter ( the end-user ) Gourav ( the case owner ) Jeremy ( Developer and possibly someone who can give more clarification ) For me, I never kept the name different than URl in my internal smart-proxy , and that could be due to the installer option i used. Perhaps Peter had used one or two more extra options than myself. And hence the difference. but for peter, The internal smart-proxy has name set to CNAME and URL is using OS FQDN of the satellite. When he changes the URL and uses the CNAME there as well, That does the trick for him [ as well as my own testing ]. Now the question is, How valid this entire scenario is ? And is it the right way to integrate CNAME in satellite and use it? If not and if someone wants to use the CNAME for every possible action without changing the OS hostname\FQDN, what is the right approach here ? -- Sayan There is no CNAME needed to reproduce, it On the client use the IP address in /etc/rhsm/rhsm.conf [Server] hostname = <ip-address-of-sat6> I enabeled debug logging, but now see that it even a Warning (which is pretty hidden between the many red-herring warnigns about 'Scoped search' and other view related warnings) ~~~ 2024-04-19T09:23:08 [W|app|9fd73270] Host clientA.example.com registered through unknown proxy 10.x.x.x ~~~ On the client this is not visible that the Satellite is having an issue with the used proxy/Capsule: ~~~ $ sudo /usr/sbin/subscription-manager register --org=Hilti --activationkey=$(sudo facter foreman_activationkey) --force Unregistering from: 10.x.x.x:443/rhsm The system with UUID bdeb2bbc-577c-434e-8d8e-4d72a4aa254e has been unregistered All local data removed The system has been registered with ID: 35b19a18-4040-4f03-b10c-1e9b18cfc3b4 The registered system name is: clientA ~~~ I expect here that the rhsm call is then failing the registration when the proxy is unknown. Then at least the error is known to the user that the rhsm.conf is using an invalid value. And if it is allowed to have on a proxy differnt addresses then the proxy can have next to its primary name also other allowed aliases/CNAME/ipaddreses in a list so that the Satellite can map it to a valid content_source Then codewise, it's happening correctly i.e. https://github.com/Katello/katello/blob/master/app/controllers/katello/api/rhsm/candlepin_proxies_controller.rb#L273-L277 is where We identify the parent host\source using HTTP_X_FORWARDED_HOST header or Setting[:foreman_url] in the absence of HTTP_X_FORWARDED_HOST header. def get_parent_host(headers) hostnames = headers["HTTP_X_FORWARDED_HOST"] host = hostnames.split(/[,,:]/)[0].strip if hostnames host || URI.parse(Setting[:foreman_url]).host end Then get_parent_host is later used in https://github.com/Katello/katello/blob/master/app/controllers/katello/api/rhsm/candlepin_proxies_controller.rb#L475-L493 for setting registered_through capsule and then the content source. So when the smart-proxy URL does not matches the get_parent_host output, The waring is logged and content_source is set as null https://github.com/Katello/katello/blob/master/app/controllers/katello/api/rhsm/candlepin_proxies_controller.rb#L491 Rails.logger.warn "Host %s registered through unknown proxy %s" % [host.name, content_source_hostname] if content_source_id.nil? host.content_facet.update_attribute(:content_source_id, content_source_id) foreman=# \d+ katello_content_facets Table "public.katello_content_facets" Column | Type | Collation | Nullable | Default | Storage | Stats target | Description --------------------------------------+------------------------+-----------+----------+----------------------------------------------------+----------+--------------+------------- id | integer | | not null | nextval('katello_content_facets_id_seq'::regclass) | plain | | host_id | integer | | not null | | plain | | uuid | character varying(255) | | | | extended | | kickstart_repository_id | integer | | | | plain | | content_source_id | integer | | | | plain | | --- From what I see content_source_id is nullable and hence a null value gets updated `host.content_facet.update_attribute` happens. If the request is to ensure that does not happen and logs a proper error during the same, Then +1 from my end about it as well. This BZ has been automatically migrated to the issues.redhat.com Red Hat Issue Tracker. All future work related to this report will be managed there. Due to differences in account names between systems, some fields were not replicated. Be sure to add yourself to Jira issue's "Watchers" field to continue receiving updates and add others to the "Need Info From" field to continue requesting information. To find the migrated issue, look in the "Links" section for a direct link to the new issue location. The issue key will have an icon of 2 footprints next to it, and begin with "SAT-" followed by an integer. You can also find this issue by visiting https://issues.redhat.com/issues/?jql= and searching the "Bugzilla Bug" field for this BZ's number, e.g. a search like: "Bugzilla Bug" = 1234567 In the event you have trouble locating or viewing this issue, you can file an issue by sending mail to rh-issues. You can also visit https://access.redhat.com/articles/7032570 for general account information. |