1. Proposed title of this feature request

Kickstart option to prevent creating anaconda-ks.cfg

2. Customer info:

Eric Sisolak - 457414

3. What is the nature and description of the request?

Deployed systems write out a kickstart file to /root/anaconda-ks.cfg that can be used to kickstart similarly configured systems.  This is a handy way to generate a kickstart file if you need one.  However, in many cases you don't, especially if you already used one to deploy the system in the firstplace.  In these scenarios it is best to remove the file since it contains potentially sensitive info (such as root's password or hash).  Previously it could be removed during %post (as noted here: https://access.redhat.com/solutions/504253), however in RHEL 7 it is created after %post making it more difficult to cleanup.

I would like a kickstart option that would be able to disable the creation of this kickstart file.  This could be used to override the default of creating /root/anaconda-ks.cfg and later cleanup would not be needed.  Or even have the default for kickstarted installs to be disabled since obviously a kickstart exists.

Adding the option to the interactive installer might also be useful,

4. Why does the customer need this? (List the business requirements here)

Customer creates several kickstarted machines, does not want /root/anaconda-ks.cfg generated that includes potentially sensitive info. Wants this process to have the option for automation during the kickstart/install stage.


5. How would the customer like to achieve this? (List the functional requirements here) Include the packages in distribution in future release.

I assume this would be an addition to the GUI install, or a change to when the anaconda-ks.cfg file is generated (as it is right now generated after %post).


6. For each functional requirement listed, specify how Red Hat and the customer can test to confirm the requirement is successfully implemented.

Easy to test, just kickstart an install.


7. Is there already an existing RFE upstream or in Red Hat Bugzilla?
 No 


8. Does the customer have any specific time-line dependencies and which release would they like to target (i.e. RHEL5, RHEL6)?

 Future release of RHEL 7. 


9. Sales is not involved.


10. List any affected packages or components.

None


11. Would the customer be able to assist in testing this functionality if implemented?

Yes