Bug 2033312

Having clients figure out who they should be accessing for Red Hat Subscription and Content purposes by themselves looks like it could be resolved with DNS-based service discovery.

Example:

1. Add a SRV record for "_rhsm" pointing to the Satellite or Capsule hostname. This needs to be done manually by the DNS administrator, or automatically by Satellite to all zones it manages.

2. Modify subscription-manager to have it always query a "_rhsm.<local domain>" record from the local DNS server before it tries the value from /etc/rhsm/rhsm.conf. Or perhaps teach subscription-manager to interpret a "hostname = _rhsm" directive in /etc/rhsm/rhsm.conf as "try to discover from DNS and fallback to subscription.rhsm.redhat.com".

3. Ship RHEL in such a way that subscription-manager will by default try to discover its Satellite server from DNS unless told otherwise -- say, by passing the --no-discovery option or by forcing a server with --server=<satellite hostname>.

4. If not #2 and #3, then have the "Global registration" template perform those lookups to determine the hostname to talk to for RHSM and content purposes.

For clients that want to create the RPM once and reuse it many times without a need to visit Satellite UI or hit Satellite API directly, the global registration can still be used. The main difference is that instead of installing the RPM and running subscription-manager, they only run a single curl command that they created once. For this to work, they need to create the registration command with the following customization (considering Satellite 6.10)

1. Enter the register host form
2. pick the desired activation key (or select the desired host group)
3. switch to Advanced tab, as a Token life time, check "unlimited"
4. generate the command, now you have a command that can be used forever, the registration will happen under the user that generated the command, the command looks similar to this

curl -sS  'https://sat6-10.example.com/register?activation_keys=library&location_id=2&organization_id=1&update_packages=false' -H 'Authorization: Bearer eyJhbGciOiJIUzI1NiJ9.eyJ1c2VyX2lkIjo0LCJpYXQiOjE2Mzk3NTAxMTksImp0aSI6ImU5MGZhMjY0YmNjMWQzNjNhOTIyMzljYzc0ODAwNmNkZDMxMGM3NzBhMDZmYThhMDUzZDEyZDFmYzU5NjU0MDUiLCJzY29wZSI6InJlZ2lzdHJhdGlvbiNnbG9iYWwgcmVnaXN0cmF0aW9uI2hvc3QifQ.WX2JOe6YW0MznxAp3_Z7Fci6HtjFDs8UFWull3P7au4' | bash

If the command is too long and you prefer to use username/password instead of the long JWT (the bearer token), you can modify the command like this

(it will prompt for password)
curl -sS  'https://sat6-10.example.com/register?activation_keys=library&location_id=2&organization_id=1&update_packages=false' -u admin | bash

(password set as part of the command)
curl -sS  'https://sat6-10.example.com/register?activation_keys=library&location_id=2&organization_id=1&update_packages=false' -u admin:changeme | bash

You probably don't want to share such password to users, so the recommendation is to create a personal access token for that user and use that instead of a password, e.g.

curl -sS  'https://sat6-10.example.com/register?activation_keys=library&location_id=2&organization_id=1&update_packages=false' -u admin:6fAE4yqfYmu3h6zcm-jidg | bash

Note that you can tweak even more things, such as the activation_key name, location, organization etc. The key is, such command is universal and can be used to register unlimited amount of machines.

Please let us know, whether that resolves the concern. If not, please specify in what aspects, this is different comparint to the rpm + subscription-manager method. If it does resolve it, we should cover this aspect in our documentation.

I am a customer that stumbled on this looking for a different RFE.  We use rpm + activation key.  It's been that way because 1) There's no provisioning going on from satellite; all image builds, 2) Works completely free of any user creation, ssh keys.  2b) Security feels better if there were no ssh keys involved, and instead it was all kerberos rhim/freeipa.  3) Ease of use; easy scripting, easy copy and pasting.  Reading through the documentation now, it's 22 steps to setup.  3b) When I first read this process, I said heck no, and opened a support case to verify the manual process wasn't going away, which came back with the answer that it is not.  4) The business desire is to leave existing automation and workflow alone.  4b) Lack of understanding of the benefits of switching and the perceived effort to switch.

I'm not saying the change is bad, unwarranted or even negative; I am sharing the user experience.  I am glad to see this now, and well before release of 7.  I need to stop what we were working right now, regroup and get this taken care of and then update all the provisioning and registration automation.

I will be testing Marek's suggestion above, and suggest a refined version be on the support site or in the documentation.

Secondly, I'd like to affirm Pablo's suggestions.  The SRV record is an excellent option for us.  Perhaps that's what should be turned into an RFE.

Thanks George, this is very useful feedback indeed. I totally understand that changing something that works must have some good reason. The reasons I see
1) stronger authentication, digitally signed JWT that is able to expire vs the name of the activation key. This may not be relevant in your case if AK name can't be easily guessed, also it seems you don't want to setup the expiration.
2) you can further customize the steps that should happen during the registration, e.g. installing additional packages or anything really, through tweaking the host init template. The old method does not provide this in any way.

I totally agree with the documentation will be necessary, I'll try to put together some draft soon. I'd be happy if you let us know whether it worked in your case. Once we have some documentation draft, I'll share that here too.

Pablo's request is interesting, however it doesn't solve one thing. User still needs to get the global registration script from somewhere and that somewhere is the actual Satellite (or Capsule). The SRV record would be great for subscription-manager, but that's just one of the steps in the new registration. We'd have to chain curl with dig or something that can get us the URL from SRV record. It may be more interesting for the old way of registration, however the AK would still have to be specified. Anyway, I'd say it's definitely worth opening RFE for subscription-manager.

Summary:
Removing manual registration is among the big changes coming up for users of satellite.  I've tried to demonstrate possible user thoughts and questions.  I am suggesting existing documentation is lacking and that resources be directed for enhanced documentation of what will become a critical and key function of satellite.

Details:
I've tried it tonight, and I appreciate the enhanced functionality.  I see the use case.

For the docs (this is not a support request), it'd be nice to have clarity on what register hosts actually does.  Is it _just_ doing A) Writing the api request and B) building you a token.  In other words, the end user can customize the call the register api endpoint, however they like, and here's a token for <USER> that will last <HOURS>.  It looks like there is always one and only one template that registration is calling.  This comment is after reading the upstream nightly docs.

Questions on this topic I wish were addressed in the docs:
-- Can I edit the get request for the capsule?  That is, real-hostname is the capsule server, but cname.$datacenter.host is the url used by configuration management.  End users should also make sure their cert is SAN cert with the cname in the cert.
--- My hope is use of the capsule (even if cname) will set the location of the host being registered to the same location as the capsule
-- How to have a registration template that's good for any OS version, like any rhel8
-- Can used the in the get request activation key be edited?
--- In a more generic sense, can the get request be edited or is there more than authentication/certs in the token?
6.10 api and hammer docs don't seem clear on this.  Upstream docs show all parameters as optional.
-- How do I see which tokens are still active?  When will they expire?

Additional:
-- We need better exit results.  A curl command has a lot of exit codes, but do not give feedback on if registration was successful, and if it wasn't what happened.

Good points for the docs, I'll try to answer some of the questions here so you don't have to wait for the official docs.

> Can I edit the get request for the capsule?  That is, real-hostname is the capsule server, but cname.$datacenter.host is the url used by configuration management.  End users should also make sure their cert is SAN cert with the cname in the cert.

You could edit the hostname, but in the default setup you'd encoutner problems with SSL certificate mismatch. You'd have to use the --insecure (insecure checkbox) option for the curl and I'm not sure whether all subsequent requests would use such name. I'd consider this unsupported (and untested) and would be seen as an RFE

> My hope is use of the capsule (even if cname) will set the location of the host being registered to the same location as the capsule

The problem with this is, Capsule can belong to multiple locations, which one should be picked? That's why the form has explicit selectors for organization and location (which defaults to the current context). The host ends up created in the org and loc that's selected.

> How to have a registration template that's good for any OS version, like any rhel8

The default host init template should always support all supported OSes. If you add any customization, make a clone, edit that and change the setting so the new clone would be used instead of the default one. If the customization is applicable only for e.g. RHEL 8, same syntax as in other templates can be used, e.g.

<%- if rhel_compatible && os_major >= 8 -%>
 ...
<%- else -%>
 ...
<%- end -%>

more can be found in the Templates DSL documentation that's part of the Satellite.

> Can used the in the get request activation key be edited?

Yes, that get parameters of the requests are not used in the digital signature, therefore can be freely modified. All referenced resources are still subject of the authorization for the user account that created the JWT.

> How do I see which tokens are still active?  When will they expire?

There's no way to list the tokens, they are not stored. If they have valid signature and the expiration date (digitally signed) is still in future, it's trusted. Each user has a secret stored in the DB, that is used to perform the digital signature. There is a way to reset all secrets making all existing tokens invalid, regardless of their expiration time. However that's the only way to expire the token before it's original expiration date.

> We need better exit results.  A curl command has a lot of exit codes, but do not give feedback on if registration was successful, and if it wasn't what happened.

Could you please add more details about this? The Satellite should indicate the result in the Build status, because the whole registration ends with "call home" request. For the top most wrapping curl that user executes, curl should follow the standard behavior, meaning 0 = success.

> cname.$datacenter.host...
>> unsupported (and untested) and would be seen as an RFE ...
> location of the host being registered to the same location as the capsule ...
>> problem with this is, Capsule can belong to multiple locations ...
Great points.  For those who may find this topic, here's what I have working and testing in prod now for global registration templates (GRT).  In my situation, there's one capsule per location.  There's lots of room to scale vertically, and even horizontally, so I don't see the situation changing.  Like the load balanced setup guide, I have subject alternative names on my certs for the CNAME capsule.$LOCATION.host (one san cert per capsule, not one bit one).  My rhel8 testing, the GRT is ok with the CNAME.  I am exploring using service account/pass or personal access tokens instead of JWT (a business problem, not technical).  That was good info from this BZ.

> Which tokens are active ...
>> There's no way to list the tokens ...
I am following BZ 1920184 about token tracking as well.

>> There is a way to reset all secrets making all existing tokens invalid ...
All the secrets?  If it's just the tokens (not globally all secrets), can that be documented here please?  That, combined with the suggestion in the other BZ would help security & compliance feel better.

> Ansible instead of curl...
I think this distracts this BZ, and I need to do more diligence on what the team requesting this is /really/ asking.  If needed, it will be addressed elsewhere.

Other issue I have with the new registration template is that it is requesting the OrgID, as before we were using the Org NAME
It's causing some trouble to explain sysadmins that they need to change the name to ID to do the same thing.

Knowing that Org Name is a primary key/label so it is protected against targeting something that could be duplicated.

(Same goes for the Location btw)
Last time I checked, the registration.erb was only using Org ID to fetch the Org Name afterwards :(

Based upon feedback during auto-closure, leaving this bugzilla as it will need to be addressed prior to removing previous registration methods.

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.