Bug 1180273
Summary: | [RFE] rhn-migrate-classic-to-rhsm should allow the user to migrate a system without requiring credentials on RHN Classic | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 6 | Reporter: | Rich Jerrido <rjerrido> |
Component: | subscription-manager | Assignee: | Alex Wood <awood> |
Status: | CLOSED ERRATA | QA Contact: | John Sefler <jsefler> |
Severity: | unspecified | Docs Contact: | Mark Flitter <mflitter> |
Priority: | unspecified | ||
Version: | 6.7 | CC: | awood, dgoodwin, dlah, rjerrido, skallesh, wpoteat |
Target Milestone: | rc | Keywords: | FutureFeature |
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Enhancement | |
Doc Text: |
subscription-manager supports migrating without RHN Classic credentials
New '--keep' option for 'rhn-migrate-classic-to-rhsm'
The rhn-migrate-classic-to-rhsm tool no longer requires RHN Classic credentials if the new '--keep' option is used. This functionality can help simplify automated migration.
|
Story Points: | --- |
Clone Of: | Environment: | ||
Last Closed: | 2015-07-22 06:52:45 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: | 1125249 |
Description
Rich Jerrido
2015-01-08 18:10:16 UTC
Rich, Right now the user does have to enter their RHN credentials regardless because the script needs to know the channels a system is registered too. That channel listing is what we use to determine which product certificates to install for subscription-manager to use. Is there is a way to do that without the need for credentials? The script also verifies that the user is an org admin (see bug 1086367). I do not know enough about RHN classic to know if deleting a system requires org admin capability. Also I'd like to note that the sat5to6 script (which uses almost all of the same code as rhn-migrate-classic-to-rhsm) does have a --registration-state option where users can choose "purge" to delete the system from the Sat 5 instance, "unentitle" to unentitle it, and "keep" to just leave it alone. So to summarize: - we can add the option to leave a system profile behind - we can possibly remove the need for the user to be an org admin (pending confirmation; I sit near the RHN Classic developers so I can talk with them) - we somehow need to get the channel listing for the system. I can talk with the Classic guys about this as well, but if you have ideas on how to get the channel listing without providing credentials, that would be good too. (In reply to Alex Wood from comment #2) > - we can add the option to leave a system profile behind > - we can possibly remove the need for the user to be an org admin (pending > confirmation; I sit near the RHN Classic developers so I can talk with them) > - we somehow need to get the channel listing for the system. I can talk > with the Classic guys about this as well, but if you have ideas on how to > get the channel listing without providing credentials, that would be good > too. Via the yum API would be my first guess since any client supported for migration to RHSM/SAM/Satellite 6 has yum (and the yum-rhn-plugin). As additional background, as part of Satellite 6 deployment, there is a desire for the end user to migrate systems from Satellite 5 (or RHN Classic) to Satellite 6. sat5to6 (from its manual): "assumes that the command hammer import content-host has run successfully on the Satellite v.6 installation, that a content-host for the client where sat5to6 is to be executed has been created, and that the result-ing RPM has been built and installed on the Satellite v.5 host that the client is subscribed to" For many users, who are Ok with how their Satellite 5 instances looked, the transition tooling (to include sat5to6) work perfectly. However, there is a sizable subset of users who won't use the transition tooling, because * They are a RHN Classic user, so they don't have a Satellite 5 instance to migrate from * They see Satellite 6 as 'new architecture', and as such, want to build/model it differently. However, they'd still need to migrate the clients. It is for these users that this RFE was raised. In the past, the user would leverage the bootstrap.sh we shipped in Satellite 5. I would like to leverage rhn-migrate-classic-to-rhsm as part of the bootstrap process/script documented in https://bugzilla.redhat.com/show_bug.cgi?id=1154373. To get there I have to take a RHEL system of unknown origin, get product certs on it, and then get it registered on Satellite 6. Without a switch to skip the profile deletion, I have to prompt the user midway in this process, which is less than ideal. Rich, Just talked with the classic guys and I will get to work on this ASAP. Rich, Quick question for you. What should the migration script do with the system id file if a user selects the "--leave-profile" option (which I have renamed to "--registration-state=keep" to be consistent with the sat5to6 tool)? If we leave the system id in place on the system, the user will see a warning that informs them they are registered to both RHSM and RHN Classic. That warning is printed out by subscription-manager itself, so it's not something I can remove easily. We can either just leave the warning or we can rename the system id file with a ".save" or ".bak" extension. Which would you prefer? rename the system id file with .save or .bak. --registration-state=keep IMHO means 'do not delete the profile on Classic/Sat5'. I'd like to keep the system id file on disk in the event that something abnormal happens (and the user needs to fall back to using Classic/Sat5). But we have to make it .save or .bak. Otherwise, the message printed via subscription-manager tells the user that some intervention is required, when in fact, it is not. commit 5df7aaaa69a22b9e3f771971f1aa4e58657c8377 Author: Alex Wood <awood> Date: Fri Mar 20 16:35:02 2015 -0400 1180273: Allow migration without requiring RHN credentials If we don't attempt to remove the system from RHN after migration, we don't need to have the user's RHN credentials. Providing this option allows users to run the migration script without having to provide credentials interactively or insecurely on the command-line. [root@jsefler-os6 ~]# rpm -q subscription-manager-migration subscription-manager-migration-1.14.5-1.el6.x86_64 The initial implementation of this feature shows the new option to be... [root@jsefler-os6 ~]# rhn-migrate-classic-to-rhsm --help | grep -A2 registration-state --registration-state=keep,purge state to leave system in on legacy server (default is 'purge') That ^ syntax for this feature seems like overkill for a boolean operation. I suggest we simply the option to... --keep-classic will remain registered to the channel-based legacy server (default is to unregister) We also need an entry in the man page for rhn-migrate-classic-to-rhsm that explains the system will remain registered when specifying this option and will effectively be double registered. This will lead to an interoperability warning message when running subscription-manager that states... WARNING This system has already been registered with Red Hat using RHN Classic. Your system is being registered again using Red Hat Subscription Management. Red Hat recommends that customers only register once. To learn how to unregister from either service please consult this Knowledge Base Article: https://access.redhat.com/kb/docs/DOC-45563 Finally, the bash-completion code needs to be updated to account for this new command line option. Moving back to NEW/FailedQA Reminder for Alex... If the user supplies the new "--keep-classic/--registration-state=keep" option AND the "--legacy-user/--legacy-password" options, then either... 1. abort the process stating that classic credentials are not required when passing the "--keep-classic/--registration-state=keep" option. or 2. ignore the "--legacy-user/--legacy-password" credentials and prompt for the destination credentials. Currently in subscription-manager-migration-1.14.5-1.el6 I am getting a failure for this scenario because there are no credentials to authenticate to the destination entitlement server... [root@jsefler-os6 ~]# rhn-migrate-classic-to-rhsm --legacy-user=qa --legacy-password=REDACTED --registration-state=keep Unable to connect to certificate server: Invalid credentials.. See /var/log/rhsm/rhsm.log for more details. [root@jsefler-os6 ~]# tail -f /var/log/rhsm/rhsm.log 2015-04-20 16:51:44,992 [DEBUG] rhn-migrate-classic-to-rhsm:19144 @connection.py:494 - Making request: GET /subscription/users/None/owners 2015-04-20 16:51:45,279 [DEBUG] rhn-migrate-classic-to-rhsm:19144 @connection.py:521 - Response: status=401 2015-04-20 16:51:45,280 [ERROR] rhn-migrate-classic-to-rhsm:19144 @migrate.py:270 - Invalid credentials. Traceback (most recent call last): File "/usr/share/rhsm/subscription_manager/migrate/migrate.py", line 268, in get_org owner_list = self.cp.getOwnerList(username) File "/usr/lib64/python2.6/site-packages/rhsm/connection.py", line 974, in getOwnerList return self.conn.request_get(method) File "/usr/lib64/python2.6/site-packages/rhsm/connection.py", line 602, in request_get return self._request("GET", method) File "/usr/lib64/python2.6/site-packages/rhsm/connection.py", line 530, in _request self.validateResponse(result, request_type, handler) File "/usr/lib64/python2.6/site-packages/rhsm/connection.py", line 572, in validateResponse raise RestlibException(response['status'], error_msg) RestlibException: Invalid credentials. master commit 6eded942a7d184ef7ed92bbd94225120ee2f2f20 [root@dhcp35-236 product]# subscription-manager version server type: RHN Classic and Red Hat Subscription Management subscription management server: 0.9.26.8-1 subscription management rules: 5.12 subscription-manager: 1.14.6-1.el6 python-rhsm: 1.14.2-1.el6 When user doesnot supply legacy user and password with --keep option,doesnot ask for legacy user and legacy password [root@dhcp35-236 product]# rhn-migrate-classic-to-rhsm --keep Destination username: qa Destination password: Retrieving existing legacy subscription information... +-----------------------------------------------------+ System is currently subscribed to these legacy channels: +-----------------------------------------------------+ rhel-x86_64-server-6 +-----------------------------------------------------+ Installing product certificates for these legacy channels: +-----------------------------------------------------+ rhel-x86_64-server-6 Product certificates installed successfully to /etc/pki/product. Attempting to register system to destination server... WARNING This system has already been registered with Red Hat using RHN Classic. Your system is being registered again using Red Hat Subscription Management. Red Hat recommends that customers only register once. To learn how to unregister from either service please consult this Knowledge Base Article: https://access.redhat.com/kb/docs/DOC-45563 The system has been registered with ID: a3e3fa79-9cb6-4fd8-b430-76053b1b4ff7 Installed Product Current Status: Product Name: Red Hat Enterprise Linux Server Status: Subscribed System 'dhcp35-236.lab.eng.blr.redhat.com' successfully registered. [root@dhcp35-236 product]# subscription-manager identity server type: RHN Classic and Red Hat Subscription Management system identity: a3e3fa79-9cb6-4fd8-b430-76053b1b4ff7 name: dhcp35-236.lab.eng.blr.redhat.com org name: Quality Assurance org ID: 711497 When you use legacy user and legacy password along with --keep option [root@dhcp35-236 product]# rhn-migrate-classic-to-rhsm --legacy-user=qa --legacy-password ****** --keep Destination username: qa Destination password: Retrieving existing legacy subscription information... +-----------------------------------------------------+ System is currently subscribed to these legacy channels: +-----------------------------------------------------+ rhel-x86_64-server-6 +-----------------------------------------------------+ Installing product certificates for these legacy channels: +-----------------------------------------------------+ rhel-x86_64-server-6 Product certificates installed successfully to /etc/pki/product. Attempting to register system to destination server... WARNING This system has already been registered with Red Hat using RHN Classic. Your system is being registered again using Red Hat Subscription Management. Red Hat recommends that customers only register once. To learn how to unregister from either service please consult this Knowledge Base Article: https://access.redhat.com/kb/docs/DOC-45563 The system has been registered with ID: e0e726ca-d0d2-4b1f-bdd6-35325001645e Installed Product Current Status: Product Name: Red Hat Enterprise Linux Server Status: Subscribed System 'dhcp35-236.lab.eng.blr.redhat.com' successfully registered. [root@dhcp35-236 product]# subscription-manager identity server type: RHN Classic and Red Hat Subscription Management system identity: e0e726ca-d0d2-4b1f-bdd6-35325001645e name: dhcp35-236.lab.eng.blr.redhat.com org name: Quality Assurance org ID: 711497 Man page for rhn-migrate-classic-to-rhsm has been updated with --keep option <snip> --keep Leaves the system profile on the legacy system. Normally the system profile on the legacy system is deleted. commit 6eded942a7d184ef7ed92bbd94225120ee2f2f20 Author: Alex Wood <awood> Date: Wed Apr 22 11:43:05 2015 -0400 1180273: Migrate from RHN Classic without credentials This commit builds on a previous effort to allow users to migrate from RHN Classic without a password. In this commit, the option for leaving a profile on RHN Classic (it is the deletion of a profile that requires a password) has been switched to a flag rather than an option as it was previously. Additionally this commit fixes an issue where users were not being required to provide credentials to the destination when leaving a profile on RHN Classic. Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHBA-2015-1345.html |