Bug 461261

Summary:	Multiple Activation keys prevent config channel deploy
Product:	Red Hat Satellite 5	Reporter:	Nick Strugnell <nstrug>
Component:	Provisioning	Assignee:	Clifford Perry <cperry>
Status:	CLOSED WONTFIX	QA Contact:	Red Hat Satellite QA List <satqe-list>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	511	CC:	casmith, jplans, jsherril, liko, mosvald, xdmoon
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:
Clones:	557581 (view as bug list)		Environment:
Last Closed:	2011-04-15 14:51:55 UTC	Type:	---
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:	462714, 557581

Description Nick Strugnell 2008-09-05 12:13:31 UTC

Description of problem:
We have a kickstart that uses two activation keys. Both activation keys have config channels associated with them. Configuration channel deployment fails.

This is because the first activation key deploys the rhncfg-* RPMs. The second activation key also tries to do the same (even though they are not listed in the package list) but this of course fails, as the packages are already deployed.

This counts as a failed prior action, and therefore configuration channels are not deployed.

Version-Release number of selected component (if applicable):
RHN satellite 5.1.1
client system is RHEL3u7 i386 - may be specific to this release, have not got any other client systems to test on

How reproducible:
Always

Steps to Reproduce:
1. Write two configuration channels
2. Write two activation keys, and associate each key with one channel
3. Add both keys to a kickstart
4. Kickstart a RHEL3.7 system

Actual results:
Config channels are not deployed. In the system view on the satellite, the deploy is listed as failed due to a "failed prior action". Clicking through, we see the failed prior action is the attempt to install the rhncfg-* RPMs which were already installed (by the first activation key.)

Even if we remove the rhncfg-* RPMs from the activation keys, they are transparently re-added.


Expected results:
Activation key should not fail on the fact that RPMs are already deployed.

Additional info:
There is a general issue here that activation keys fail if they try to deploy packages that are already deployed. This is incorrect - status should be judged on end state "are the packages installed after the key has been run?" rather than transient errors.

Comment 6 Martin Osvald 🛹 2010-01-15 16:12:10 UTC

a temporary workaround could be to remove automatically generated activation key from --activatiokey parameter from ks.cfg and leave there only defined key(s) associated with configuration files, e.g.:

=== snip from ks.cfg ===
...
rhnreg_ks --serverUrl=https://satellite.server/XMLRPC --sslCACert=/usr/share/rhn/RHN-ORG-TRUSTED-SSL-CERT --activationkey=1-84e00fdd59162dc725294322d1e74974,1-your_defined_key,1-your_second_defined_key
...
=== snip ===

and change it to:

rhnreg_ks --serverUrl=https://your.satellite.server/XMLRPC --sslCACert=/usr/share/rhn/RHN-ORG-TRUSTED-SSL-CERT --activationkey=1-your_defined_key,1-your_second_defined_key

Comment 7 Justin Sherrill 2010-01-21 20:53:18 UTC

So there are really two issues presented in this bugzilla.  

The first:
When provisioning with two activation keys with config deploy enabled, both keys try to install the rhncfg* packages.  The 2nd one will fail since these packages are already installed, and thus the dependent config deploy will also fail.

The second:
When re-provisioning with an activation key that has config deploy enabled, deployment will not happen because the re-activation key will have it disabled.  Meaning that if you use two keys and one has deploy disabled, deployment will not happen for any of the keys.

Comment 9 Justin Sherrill 2010-01-21 21:15:00 UTC

Went ahead and cloned this bug to https://bugzilla.redhat.com/show_bug.cgi?id=557581 for the second issue.

This bz will only concern the first issue involving two keys with config deploy enabled.

Comment 10 Justin Sherrill 2010-01-21 21:36:18 UTC

I'm not able to reproduce this issue on 5.2 or 5.3.  Again, this is the issue where TWO Keys are used BOTH with config deploy enabled.  

This was tested against a RHEL 5 client with:

yum-rhn-plugin-0.5.3-30.el5
rhnlib-2.2.6-2.el5

If this is reproducible against 5.3, please let me know how :}

And just to be clear, for the 2nd issue that I think most people are concerned with, please see bz 557581.