Bug 630938

Summary: Erroneous Config File Deployment During Kickstart
Product: [Community] Spacewalk Reporter: Andy Speagle <andy.speagle>
Component: ServerAssignee: Jan Pazdziora (Red Hat) <jpazdziora>
Status: CLOSED DUPLICATE QA Contact: Red Hat Satellite QA List <satqe-list>
Severity: medium Docs Contact:
Priority: low    
Version: 1.0CC: jpazdziora
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-09-23 13:01:15 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: 723481    

Description Andy Speagle 2010-09-07 12:39:59 UTC
Description of problem:
When kickstarting new RHEL 5.5 servers, all configuration files available via configuration channels configured for use in related activation keys are being deployed upon registration of the OS during kickstart.

I have validated that the related activation keys are NOT configured to deploy all config files upon activation, yet it happens regardless.

Version-Release number of selected component (if applicable):
This is seemingly new as of v1.0 ... this was not an issue with v0.8.

How reproducible:
Every time.

Steps to Reproduce:
1.  Create kickstart profile and select activation key.
2.  Ensure activation key is not set to deploy all config files upon activation.
3.  Kickstart server and note unwanted configuration files.
  
Actual results:
In my case, I have certain files related to network configuration that should only be deployed based on logic in the post-install script.  However, by monitoring the installation process, I can see that these files are being deployed as soon as the system is registered... before my non-chroot post-install script runs.

Expected results:
Logic within my post-install script only pulls the offending files in the correct hardware scenario.

Additional info:

Comment 1 Jan Pazdziora (Red Hat) 2010-10-27 08:32:01 UTC
Mass-aligning under space12, so that we don't lose track of this bugzilla. This however does not mean that we plan (will be able to) address this bug in Spacewalk 1.2.

Comment 2 Jan Pazdziora (Red Hat) 2010-11-19 16:04:41 UTC
Mass-moving to space13.

Comment 3 Miroslav Suchý 2011-04-11 07:33:16 UTC
We did not have time for this one during Spacewalk 1.4 time frame. Mass moving to Spacewalk 1.5.

Comment 4 Miroslav Suchý 2011-04-11 07:37:06 UTC
We did not have time for this one during Spacewalk 1.4 time frame. Mass moving to Spacewalk 1.5.

Comment 5 Jan Pazdziora (Red Hat) 2011-07-20 11:51:26 UTC
Aligning under space16.

Comment 6 Jan Pazdziora (Red Hat) 2011-09-23 13:01:15 UTC

*** This bug has been marked as a duplicate of bug 600527 ***