Bug 461261 - Multiple Activation keys prevent config channel deploy
Multiple Activation keys prevent config channel deploy
Product: Red Hat Satellite 5
Classification: Red Hat
Component: Provisioning (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Clifford Perry
Red Hat Satellite QA List
Depends On:
Blocks: 462714 557581
  Show dependency treegraph
Reported: 2008-09-05 08:13 EDT by Nick Strugnell
Modified: 2011-04-15 10:51 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 557581 (view as bug list)
Last Closed: 2011-04-15 10:51:55 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Nick Strugnell 2008-09-05 08:13:31 EDT
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:

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 11:12:10 EST
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 15:53:18 EST
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 16:15:00 EST
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 16:36:18 EST
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:


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.

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