Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.

Bug 1033334

Summary: [RFE] Allow easy registration with SAM/Satellite through subscription manager
Product: Red Hat Enterprise Linux 7 Reporter: Matt Reid <mreid>
Component: subscription-managerAssignee: candlepin-bugs
Status: CLOSED WONTFIX QA Contact: John Sefler <jsefler>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 7.0CC: alikins, bkearney, dgoodwin, khowell
Target Milestone: rcKeywords: FutureFeature
Target Release: 7.1   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2018-02-22 15:46:59 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:
Bug Depends On:    
Bug Blocks: 1121117    

Description Matt Reid 2013-11-21 21:27:18 UTC
Description of problem:
I'd love to see us streamline registration with an on premise server. If I point subscription manager to SAM, we know where the rpm we need is located and how to access it, can't we take a minute to install it, drop the cert in place, let it edit the relevant conf files, and then try to register with SAM? Instead of failing and making them manually pull over the cert, install it, and re-launch subman GUI or re-run registration through the CLI (assuming they don't have to look up how to get the cert/why it won't connect)?

I think all we have to do is:
* recognize that they're trying to register with something they don't have a certificate for yet
* pull this over: http://sam_server_hostname/pub/candlepin-cert-consumer.noarch.rpm
* install the rpm
* refresh the data the reg dialog is looking at, so it matches the updated conf file
* and continue with the registration, which should now work, instead of fail like it would currently (without manually installing the rpm)

Would that be possible?

Still seems awkward to me that we don't have any support for doing this through the GUI or CLI without knowing that you have to do it and how to do it. It's probably fair that this will be automated in many environments once they hit sufficient scale to want to use those products, but it doesn't feel like we should completely depend on them doing so to have a decent experience.

If they're trying to register through the CLI, it would be even easier wouldn't it? We just have to catch that case, run the command from our docs (# rpm -ivh http://sam.example.com/pub/candlepin-cert-consumer.noarch.rpm) and then continue registration/or kick it off again with the same options they ran it with the first time (could we save the switches or pull from bash history or something?).

Comment 1 Devan Goodwin 2014-01-21 13:21:32 UTC
*** Bug 857269 has been marked as a duplicate of this bug. ***

Comment 2 Devan Goodwin 2014-01-21 13:40:41 UTC
*** Bug 857271 has been marked as a duplicate of this bug. ***

Comment 4 Bryan Kearney 2014-07-30 19:21:49 UTC
Acking 7.1

Comment 7 Adrian Likins 2015-05-06 18:01:18 UTC
I would consider this a subset of "autodiscovery/autoconfiguration". 

The main gap is discovering where to ask for the information, and how to verify it can be trusted. 

I would like to add some support for auto discovering the sat6 server via DNS serv records, amahi/bonjour, or even just a predictable hostname ("sat6server" in local name resolving domain). 

That get's you pointing at the host and url, now you need to be able to trust it.

A few potential:

1) As part of sat6 sync/manifests, provide some form of Red Hat signed version of this info (via an RPM seems straightforward.). Then we ship a gpg pub used by yum/rpm that can verify the rpm as being provided by us. It doesn't id it as being from precisely from that sat6 server, but it's much closer.

2) bootstrap trust chain from tpm of some sort

Both of those involve a ton of trust/crypto/process however.

Comment 8 Kevin Howell 2018-02-22 15:46:59 UTC
bootstrap.py implements the spirit of this request.