Bug 2018540

FYI, this is also happening in Satellite 6.10.4:

  TASK [project-receptor.satellite_receptor_installer : Identify Satellite source type] ***
  fatal: [satellite.example.local]: FAILED! => {"changed": false,
    "connection": "close",
    "content": "Insights services authentication failed\n",
    "content_length": "40",
    "content_type": "text/plain",
    "date": "Tue, 19 Apr 2022 14:21:01 GMT",
    "elapsed": 0,
    "msg": "Status code was 401 and not [200]: HTTP Error 401: Unauthorized",
    "redirected": false,
    "server": "openresty",
    "set_cookie": "b3e2e456866f84f3604b36899c8be8b3=9d71d2c6ed07194f0210382d9230ce93; path=/; HttpOnly; Secure; SameSite=None",
    "status": 401,
    "url": "https://cert.cloud.redhat.com/api/sources/v2.0/source_types?name=satellite",
    "x_content_type_options": "nosniff",
    "x_frame_options": "SAMEORIGIN",
    "x_rh_edge_cache_status": "Miss from child, Miss from parent",
    "x_rh_edge_reference_id": "0.442b3417.1650378061.8294a2fa",
    "x_rh_edge_request_id": "8294a2fa",
    "x_rh_insights_request_id": "e25bdcde0fae486cb7c5aedf9186bbdb"}

With the lack of customer support cases attached to this case, I have to wonder if my and Rudnei Bertol, Junior's problem is some mis-configuration.  I know for me, my satellite started out registered to the Customer Portal using my Red Hat employee credentials and using a Red Hat employee subscription.  Needing to closer model what a customer sees & does, I've since re-registered it under a different account number that contains its own "Red Hat Satellite Infrastructure Subscription", and am also using a manifest from that non-employee account number.

So maybe something is `stuck` trying to use the old employee credentials trying to get into the non-employee account, thus causing the HTTP 401 error?  How can this be troubleshot, please?

I just wanted to post some information here that might help others.

My Satellite 6.11, which had started out ~3 years ago as Satellite 6.8 and had been upgraded since then, apparently had some issue unique to it that was causing the:

  "output": "fatal: [satellite.localdomain]: FAILED! : {\"changed\": false, \"connection\": \"close\", \"content\": \"Insights services authentication failed\\n\", \"content_length\": \"40\", \"content_type\": \"text/plain\", \"date\": \"Fri, 10 Mar 2023 17:04:16 GMT\", \"elapsed\": 0, \"msg\": \"Status code was 401 and not [200]: HTTP Error 401: Unauthorized\", \"redirected\": false, \"server\": \"openresty\", \"set_cookie\": \"b3e2e456866f84f3604b36899c8be8b3=585449718aa85314c0d2740eab3c54a8; path=/; HttpOnly; Secure; SameSite=None\", \"status\": 401, \"strict_transport_security\": \"max-age=31536000; includeSubDomains\", \"url\": \"https://cert.cloud.redhat.com/api/sources/v3.1/sources?filter[source_ref]=2bcf47c8-1587-4a83-83c3-1e11cb685b1e\", \"x_content_type_options\": \"nosniff\", \"x_frame_options\": \"SAMEORIGIN\", \"x_rh_edge_cache_status\": \"Miss from child, Miss from parent\", \"x_rh_edge_reference_id\": \"0.442b3417.1678467856.527269e0\", \"x_rh_edge_request_id\": \"527269e0\", \"x_rh_insights_request_id\": \"85bcc1f7fd794283a4e18897f3830d98\"}\n",

...error when trying to configure the cloud connector.  Although I would get the above error and the job would fail, it is interesting to note that my satellite *did* show up as an available source:

  https://console.redhat.com/settings/sources?sort_by[]=created_at:desc&limit=50&offset=0&category=Red%20Hat

...after about 40 minutes.  (I learned from members of the consoledot-sources team that console.redhat.com makes "Available" new sources  at 15 and 45 minutes after each hour.  Until then, the newly created source is seen as "In progress".)

I suspect the 401 problem stemmed from -- long ago and since deleted -- having a 2nd organization using a manifest from Red Hat's internal staging environment, which my satellite could not reach due to being outside of Red Hat's network.  (I've not been able to confirm that suspicion.)

Although I now had a console.redhat.com Red Hat source, it only partially worked.  I could see my satellite receiving playbooks from it, but remediations never quite got successfully applied to my hosts.  Due to time constraints, I did not pursue that problem.


Instead, I wanted to confirm that the problem was something unique to my satellite.  So, I built a new Satellite 6.11 server last week and tried its Configure Cloud Connector -- the configuration worked fine; no 401 errors at all.  This morning I went the extra step of using it to apply an errata to one of that satellite's content hosts, and again it was successful.

So at this point, I consider my problem not worth pursuing anymore.

Based on the available feedback, and the original bug targeting receptor based Cloud Connector that was replaced in Satellite 6.11 I am opting to close this bug. If you continue to have this problem with Satellite 6.11+ please re-open with new details.