Bug 2108402

Summary: The API https://<capsule-fqdn>:443/redhat_access/r/insights/v1/branch_info returns 404
Product: Red Hat Satellite Reporter: huanhuan <huali>
Component: InstallationAssignee: satellite6-bugs <satellite6-bugs>
Status: CLOSED DUPLICATE QA Contact: Satellite QE Team <sat-qe-bz-list>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 6.11.0CC: ahumbe, apatel, ehelms
Target Milestone: UnspecifiedKeywords: Triaged
Target Release: Unused   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2023-07-31 13:29:41 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 huanhuan 2022-07-19 02:16:30 UTC
Description of problem:
With satellite 6.11, the client registered to the capsule server is using "443" as default for RHSM API. However when I run "insights-client", I found the API "https://<capsule-fqdn>:443/redhat_access/r/insights/v1/branch_info" return 404. So we can not get the satellite server information on the client now. It works with 8443.

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

How reproducible:
every time

Steps to Reproduce:
1. deploy a satellite capsule 6.11.0
2. register a host to the capsule
3. run "insights-client"
4. check the "branch_info" file in the generated insights-archive

Actual results:
it is "{'remote_branch': -1, 'remote_leaf': -1}"


Expected results:
it should contain the right satellite version info like:
{"product": {"major_version": "6", "type": "Satellite", "minor_version": "11"}, "labels": [{"namespace": "satellite", "value": "Default Location", "key": "location"}, {"namespace": "satellite", "value": "Default Location", "key": "location"}, {"namespace": "satellite", "value": "all client hosts", "key": "hostgroup"}, {"namespace": "satellite", "value": "Capsule Client", "key": "hostgroup"}, {"namespace": "satellite", "value": "all client hosts/Capsule Client", "key": "hostgroup"}, {"namespace": "satellite", "value": "Default Organization", "key": "organization"}, {"namespace": "satellite", "value": "stage", "key": "lifecycle_environment"}, {"namespace": "satellite", "value": "view1", "key": "content_view"}, {"namespace": "satellite", "value": "key1", "key": "activation_key"}, {"namespace": "satellite", "value": "aec4ad37-1c17-4f5d-bd04-485f52601301", "key": "satellite_instance_id"}, {"namespace": "satellite", "value": "1", "key": "organization_id"}], "display_name": "Default Organization", "hostname": "huali-sat68.vm.gsslab.pek2.redhat.com", "remote_branch": "731be4c5-d3ea-4b7d-85c4-7724c28f9e8c", "organization_id": 1, "satellite_instance_id": "aec4ad37-1c17-4f5d-bd04-485f52601301", "remote_leaf": "9363c647-9319-49d7-9233-16660d67803e"}

Additional info:

Comment 1 Brad Buckingham 2022-07-21 14:19:12 UTC
Is this a regression from Satellite 6.10?

Comment 2 huanhuan 2022-07-22 01:04:43 UTC
Hi Brad,

I think it isn't. Because port "443" is supported in satellite 6.11. It is mentioned in the release note https://access.redhat.com/documentation/en-us/red_hat_satellite/6.11/html-single/release_notes/index#assembly_introducing-red-hat-satellite_sat6-release-notes:

New default port for communication with Red Hat Subscription Management (RHSM) API on Capsule servers
With this release, Capsule Servers accept communication for the RHSM API on port 443 by default. The formerly used port 8443 is now deprecated and remains open only for existing content hosts that do not get an automatic configuration update.

Before the capsule server use "8443" for the RHSM API. And it works well. So if it is an old client registered to satellite capsule, it still uses "8443" and the API works well. However, a new client registered to satellite capsule uses "443" now, and the API doesn't work, it returns "404".

Comment 4 Eric Helms 2023-07-31 13:29:41 UTC

*** This bug has been marked as a duplicate of bug 2110222 ***