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.
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
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.
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.
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.