Michael, thank you very much for the feedback. Those PDF's I'll surely take a look at. The /root/anaconda-ks.cfg does seem to pick up some of the unique qualities of the HW installed on. But, seems to loose specifics, such as anything in %post. Also, the adding of a user doesn't seem to have an equivalent during the install or post sections. I'm coming at this still pretty new to kickstart. So I wish to be clear that I'm voicing concerns and frustrations.... not throwing stones. Doing things the kickstart way certainly has been entertaining, to say the least. So far I've been blessed by having the luxury of doing things at a sedate pace, in a lab environment. The learning curve to get kickstart going and viable in a production environment, at the pace mission systems NEED to be pushed out the door would have taken a lot longer, at least for me. I'll keep learning and hopefully contributing some in return. One thing that is still very difficult for me to 'get' is how to manipulate the firstboot 'stuff'. I've been developing a very robust secure hardened version of linux. I have several places where reboots exist, yet have not found good info in any of the KS docs I've looked at that describes how to build a system, and manipulate firstboot to meet my needs. Maybe that isn't a kickstart 'thing' either. Don't know yet. R, -Joe Wulf, CISSP, USN(RET) Senior IA Engineer ProSync Technology Group, LLC www.prosync.com -----Original Message----- From: kickstart-list-bounces@xxxxxxxxxx [mailto:kickstart-list-bounces@xxxxxxxxxx] On Behalf Of Michael DeHaan Sent: Wednesday, August 22, 2007 10:44 To: Discussion list about Kickstart Subject: Re: Installing minimal number of packages Joe_Wulf wrote: > > I would have liked to have seen or found a 'users manual' for kickstart. > http://www.redhat.com/docs/manuals/enterprise/RHEL-5-manual/Installation_Guide-en -US/index.html http://www.redhat.com/docs/manuals/enterprise/RHEL-5-manual/Installation_Guide-en -US/s1-kickstart2-options.html and "yum install system-config-kickstart" > - When I build a system with KS, why does the /root/anaconda-ks.cfg file > NOT reflect exactly what the source ks.cfg looked like? > Anaconda records all of it's choices, including choices made interactively in the installer. The anaconda.ks file can be used to reproduce the install choices, including questions not posed in the original kickstart. Perhaps you could give a concrete example of something showing up that you did not expect and was not what you wanted? > - I want to build many systems from many versions of the RedHat OS's. Why > doesn't the kickstart configuration NATURALLY understand each OS I've > copied into my ks server and build ks-cfg files that work natively with > that version of the OS. > Each version of the OS has new features that cannot be expressed in previous versions. An example is the "repo" functionality that was added for RHEL 5 / FC 6. This functionality is very powerful but was not available in EL 4. Ergo, if you request to use it in your kickstart, that should be an error, else you won't be able to install packages from external repos that you may have mentioned in the packages section. Keeping seperate kickstarts for seperate OS's is desired behavior, because they are seperate OS's and therefore require different answer files. If you want something to manage those configurations, look at something like http://cobbler.et.redhat.com, use RHN, or write your templating system, however simple or complex you'd like it to be. --Michael _______________________________________________ Kickstart-list mailing list Kickstart-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/kickstart-list _______________________________________________ Kickstart-list mailing list Kickstart-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/kickstart-list
