Bug 677950 - When registering with activation key, system is first put to its default channel and only then changed to the channel from the key
Summary: When registering with activation key, system is first put to its default chan...
Keywords:
Status: CLOSED DEFERRED
Alias: None
Product: Red Hat Satellite 5
Classification: Red Hat
Component: Registration
Version: 540
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Michael Mráka
QA Contact: Red Hat Satellite QA List
URL:
Whiteboard:
Depends On:
Blocks: 462714
TreeView+ depends on / blocked
 
Reported: 2011-02-16 11:02 UTC by Jan Pazdziora
Modified: 2014-07-04 13:24 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-07-04 13:24:57 UTC
Target Upstream Version:


Attachments (Terms of Use)

Description Jan Pazdziora 2011-02-16 11:02:32 UTC
Description of problem:

When registering with rhnreg_ks and --activationkey and the key has base channel set to something else than RHN Satellite default, the history for the system after registration shows that the system was subscribed and then unsubscribed from its "default" channel, and only then changed to the base channel from the key.

Version-Release number of selected component (if applicable):

Satellite 5.4.x

# rpm -qf /usr/sbin/rhnreg_ks
rhn-setup-0.4.20-33.el5_5.2

How reproducible:

Deterministic.

Steps to Reproduce:
1. Have Satellite with rhel-i386-server-5 and rhel-i386-client-5 channels.
2. Have client machine with server installed:
# rpm -q redhat-release
redhat-release-5Server-5.5.0.2
3. Create activation key on the Satellite and define Red Hat Enterprise Linux Desktop (rhel-i386-client-5) as its base channel.
4. Run rhnreg_ks with the activation key.
5. Get sid of the client machine (grep ID- /etc/sysconfig/rhn/systemid)
6. Go to https://FQDN/network/systems/details/history/history.pxt?sid=SID
  
Actual results:

System Event 	(n/a) 	Subscription via Token 	02/16/11 5:44:33 AM EST
System Event 	(n/a) 	subscribed to channel rhel-i386-client-5 	02/16/11 5:44:33 AM EST
System Event 	(n/a) 	unsubscribed from channel rhel-i386-server-5 	02/16/11 5:44:33 AM EST
System Event 	(n/a) 	added system entitlement 	02/16/11 5:44:33 AM EST
System Event 	(n/a) 	subscribed to channel rhel-i386-server-5 	02/16/11 5:44:33 AM EST 

Expected results:

System Event 	(n/a) 	Subscription via Token 	02/16/11 5:44:33 AM EST
System Event 	(n/a) 	subscribed to channel rhel-i386-client-5 	02/16/11 5:44:33 AM EST
System Event 	(n/a) 	added system entitlement 	02/16/11 5:44:33 AM EST

Additional info:

The system should not be subscribed to its default channel and unsubscribed immediatelly, that seems strange.

What is more strange is that if you specify versionOverride=5Client, you will get

System Event 	(n/a) 	Subscription via Token 	02/16/11 5:57:27 AM EST
System Event 	(n/a) 	subscribed to channel rhel-i386-client-5 	02/16/11 5:57:27 AM EST
System Event 	(n/a) 	unsubscribed from channel rhel-i386-client-5 	02/16/11 5:57:27 AM EST
System Event 	(n/a) 	added system entitlement 	02/16/11 5:57:26 AM EST
System Event 	(n/a) 	subscribed to channel rhel-i386-client-5 	02/16/11 5:57:26 AM EST

So it's not only about the channels being different -- the thing first subscribes to the default channel and then changes it, without taking into account that the channel information is in fact correct.

If the default channel cannot be found, for example because you specify versionOverride=5XX, the registration passes just fine and there are no steps subscribing and unsubscribing to and from that default channel:

System Event 	(n/a) 	Subscription via Token 	02/16/11 5:48:29 AM EST
System Event 	(n/a) 	subscribed to channel rhel-i386-client-5 	02/16/11 5:48:29 AM EST
System Event 	(n/a) 	added system entitlement 	02/16/11 5:48:29 AM EST 

That's why I believe that that subscribe/unsubscribe step is not needed at all.


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