As an EC2 user, I would like to set up a RHUI as an alternate content source
Typically, if I set up a new Pulp instance I can set up a local content source to help populate it quickly. However, if I am using EC2, I can't use my region's local RHUI to help populate my Pulp.
The content source config allows for most of what I need: the CA, client cert and client key. However, RHUI in EC2 requires additional metadata from the cloud-init magic IP in the HTTP header to allow the request through. These settings are specific to an instance, but do not generally change once the instance is created.
If there was a way to specify additional HTTP headers in the content request, it would be let Pulp users set up RHUI as an alternate content source. A very basic way to do this would be to allow setting arbitrary HTTP headers in the conf file.
I can supply an ec2 machine that's already set up and show how to populate the headers.
#5 Updated by cduryee over 4 years ago
As a Pulp user, I would like to use a RHUI which has the Amazon authentication plugin enabled as an alternate content source.
The existing ACS config supports most of the required values, but two additional HTTP headers (X-RHUI-ID and X-RHUI-SIGNATURE) have to be presented in order to obtain content from the RHUI. The values of these two headers are strings that do not change once an instance is created.
#8 Updated by cduryee over 4 years ago
ah, I was just being lazy with my typing :) acs = alternate content source
There are probably a number of ways to solve the problem of getting the content out of a RHUI, but one idea would be to allow setting the two X-RHUI headers via https://docs.pulpproject.org/user-guide/content-sources.html. I believe if two additional settings were exposed to set values for the two headers and then the header values were passed through to nectar, that would work. I think it would operate similarly to how basic auth is set up.
#9 Updated by bmbouter over 4 years ago
OK that is a good plan. The last bit of detail I'm looking for are the actual names of those two options. Then one of us can write out the deliverables as checklist items. I can help w/ that once the setting names are decided.
Thanks for all the input you've given. This story is really shaping up.
#15 Updated by firstname.lastname@example.org over 4 years ago
I don't think that adding RHUI specific options to the alternate content source descriptor is appropriate. These are just HTTP headers and should be supported generically. Instead, let's add support for a headers option. This is a list option (like paths) but has the form of <header>=<value>.
headers: X-RHUI-ID=1234 \ X-RHUI-SIGNATURE=AF1902B9C8DAF1902B9C8D