Bug 504049 - Reprovisioning ignores kickstart's associated activation keys
Summary: Reprovisioning ignores kickstart's associated activation keys
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Satellite 5
Classification: Red Hat
Component: Provisioning
Version: 530
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Justin Sherrill
QA Contact: Dave Parker
URL:
Whiteboard:
Depends On:
Blocks: 457075
TreeView+ depends on / blocked
 
Reported: 2009-06-03 23:07 UTC by Justin Sherrill
Modified: 2009-09-10 19:26 UTC (History)
2 users (show)

Fixed In Version: sat530
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-09-10 19:26:11 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Justin Sherrill 2009-06-03 23:07:51 UTC
If you create a kickstart file and associate one or more activation keys they will not be used if you reprovision a machine using that kickstart.

The reason is that we associate the keys to the cobbler profile but at provisioning time set the key in the system record to the system's reactivation token. 

So when the kickstart is rendered for the system it just uses that reactivation key and not any of the profile's activation keys. 



We have to do 2 things:

1.  When scheduling a kickstart, set the system record's key to include both the reactivation token and the kickstart's keys.
2.  When modifying a kickstart's activation key selections, you have to modify any associated system records to include the new key and remove any old ones. fun :/

Comment 1 Justin Sherrill 2009-06-05 19:26:09 UTC
e79579a


So there are 4 places where things have changed.

1.  Clicking the "Create cobbler system record" (this ties a profile with a system)
2.  Deleting an activation key that is associated to a kickstart profile (That has been associated to a system)
3.  renaming an activation key that  is associated to a kickstart profile (That has been associated to a system)
4.  adding or removing an activation key from a kickstart profile that is associated to a system

doing all of these should result in the "redhat mgmt key" within the cobbler profile or system record objects being updated correctly.

Comment 2 Steve Salevan 2009-07-06 20:38:46 UTC
FAILS_QA on 7/2 build.

Created an activation key which would register a machine to a cloned base channel and associated it to a kickstart.  Scheduled kickstart, and after kickstart completion, this key was ignored and the machine was registered to the normal, non-cloned channel.

Comment 3 Justin Sherrill 2009-07-08 16:01:50 UTC
So I wasn't able to reproduce the error.  I created an activation key with a custom base channel, assigned it to a kickstart, then re-provisioned a machine with it.  

After it registered, it was registered to a different base channel.

Comment 4 Dave Parker 2009-07-21 23:35:30 UTC
I kickstarted a box to a normal base channel, then created a clone of that base channel and associated it with a new activation key -- which I in turn associated with a kickstart profile (the same one I initially kickstarted the box with).  Subsequent to kickstart the machine appears to be registered to the cloned base channel.

Comment 5 Preethi Thomas 2009-08-04 18:03:51 UTC
Release Pending
test1182.test.redhat.com

Comment 6 Brandon Perkins 2009-09-10 19:26:11 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHEA-2009-1434.html


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