RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1033334 - [RFE] Allow easy registration with SAM/Satellite through subscription manager
Summary: [RFE] Allow easy registration with SAM/Satellite through subscription manager
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: subscription-manager
Version: 7.0
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: 7.1
Assignee: candlepin-bugs
QA Contact: John Sefler
URL:
Whiteboard:
: 857269 857271 (view as bug list)
Depends On:
Blocks: rhsm-rhel72
TreeView+ depends on / blocked
 
Reported: 2013-11-21 21:27 UTC by Matt Reid
Modified: 2018-02-22 15:46 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-02-22 15:46:59 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

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.


Note You need to log in before you can comment on or make changes to this bug.