How-to info needed for multiple instances of RH OS's and multipleunique versions {to be kickstarted}

Steden Klaus Klaus.Steden at thomson.net
Sun Jul 1 06:04:43 UTC 2007


I did pretty much that using templates written as Perl include files that were sourced by a CGI that a modified Anaconda called using cmdline boot parameters. I wrote this up on the Fedora Wiki.

You should be able to bundle all your network installers on a single USB key or CD using a separate subdir for each flavour although I had to add some tools to older installers to make them work with my script.

Hth,
Klaus


----- Original Message -----
From: kickstart-list-bounces at redhat.com <kickstart-list-bounces at redhat.com>
To: kickstart-list at redhat.com <kickstart-list at redhat.com>
Sent: Sat Jun 30 22:45:00 2007
Subject: How-to info needed for multiple instances of RH OS's and multipleunique versions {to be kickstarted}

Hi.  I'm a new member of the list, recently joined about a week ago.  I could really use some help regarding kickstart.
 
I have one physical system running FC6.  It is set up as my kickstart/NFS/DNS/DHCP server.  I've a second physical
system, a PC with the VMware Workstation installed and running.  I use it to boot/build 'play' virtual machines from the
FC6 kickstart server.
 
I've taken the /root/anaconda-ks.cfg file from the same FC6 system and am using it, along with all the other normal
kickstart steps, to tailor a network-based build of FC6.  I do basically understand how to do that, and can successfully
build a Virtual Machine (under VMware Workstation v6.0 on a separate computer) with FC6.  Great.  Now I am cook'n.
 
Next, I established many new directory names, unique for each OS, established them each/all basically the same as for
FC6, into that same FC6 kickstart server.  The list follows for each of the OS's I'm working with.
 
 
RHEL WS3u0 x32
RHEL WS3u1 x32
RHEL WS3u2 x32
RHEL WS3u3 x32
RHEL WS3u4 x32
RHEL WS3u5 x32
RHEL WS3u6 x32
RHEL WS3u7 x32
RHEL WS3u8 x32
RHEL WS3u9 x32 {And conceivably back to the 2.1 versions, too}
 
 
RHEL WS3u0 x64
RHEL WS3u1 x64
RHEL WS3u2 x64
RHEL WS3u3 x64
RHEL WS3u4 x64
RHEL WS3u5 x64
RHEL WS3u6 x64
RHEL WS3u7 x64
RHEL WS3u8 x64
RHEL WS3u9 x64 {And conceivably back to the 2.1 versions, too}
 
 
RHEL WS4u0 x32
RHEL WS4u1 x32
RHEL WS4u2 x32
RHEL WS4u3 x32
RHEL WS4u4 x32
RHEL WS4u5 x32
 
RHEL WS4u0 x64
RHEL WS4u1 x64
RHEL WS4u2 x64
RHEL WS4u3 x64
RHEL WS4u4 x64
RHEL WS4u5 x64
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
 
 
RHEL ES3u0 x32
RHEL ES3u1 x32
RHEL ES3u2 x32
RHEL ES3u3 x32
RHEL ES3u4 x32
RHEL ES3u5 x32
RHEL ES3u6 x32
RHEL ES3u7 x32
RHEL ES3u8 x32
RHEL ES3u9 x32 {And conceivably back to the 2.1 versions}
 
 
RHEL ES3u0 x64
RHEL ES3u1 x64
RHEL ES3u2 x64
RHEL ES3u3 x64
RHEL ES3u4 x64
RHEL ES3u5 x64
RHEL ES3u6 x64
RHEL ES3u7 x64
RHEL ES3u8 x64
RHEL ES3u9 x64 {And conceivably back to the 2.1 versions}
 
 
RHEL ES4u0 x32
RHEL ES4u1 x32
RHEL ES4u2 x32
RHEL ES4u3 x32
RHEL ES4u4 x32
RHEL ES4u5 x32
 
RHEL ES4u0 x64
RHEL ES4u1 x64
RHEL ES4u2 x64
RHEL ES4u3 x64
RHEL ES4u4 x64
RHEL ES4u5 x64
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
 
 
RHEL AS3u0 x32
RHEL AS3u1 x32
RHEL AS3u2 x32
RHEL AS3u3 x32
RHEL AS3u4 x32
RHEL AS3u5 x32
RHEL AS3u6 x32
RHEL AS3u7 x32
RHEL AS3u8 x32
RHEL AS3u9 x32 {And conceivably back to the 2.1 versions}
 
 
RHEL AS3u0 x64
RHEL AS3u1 x64
RHEL AS3u2 x64
RHEL AS3u3 x64
RHEL AS3u4 x64
RHEL AS3u5 x64
RHEL AS3u6 x64
RHEL AS3u7 x64
RHEL AS3u8 x64
RHEL AS3u9 x64 {And conceivably back to the 2.1 versions}
 
 
 
RHEL AS4u0 x32
RHEL AS4u1 x32
RHEL AS4u2 x32
RHEL AS4u3 x32
RHEL AS4u4 x32
RHEL AS4u5 x32
 
RHEL AS4u0 x64
RHEL AS4u1 x64
RHEL AS4u2 x64
RHEL AS4u3 x64
RHEL AS4u4 x64
RHEL AS4u5 x64
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
 
 
RHEL AS5u0 x32
RHEL AS5u0 x64
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
 
 
FC1 x32
FC2 x32
FC3 x32
FC4 x32
FC5 x32
FC6 x32
 
 
FC1 x64
FC2 x64
FC3 x64
FC4 x64
FC5 x64
FC6 x64
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
 
 
Fedora 7 x32
 
Fedora 7 x64
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
 
 
These are all for the Intel architecture, as that is all I have available. I'd do other architectures too (zSeries, Itanium
and S/390) if someone wishes to loan me the equipment for the next year or so. <smile>
 
 
My question is this:
How do I dynamically build OS-specific kickstart anaconda-ks.cfg files for EACH of them without having to waste
tons of hours manually installing each one simply to get that one file out of it???  I would have thought the kickstart
GUI would have had something to allow the operator to 'select' which OS from the multitudes possible, that it would
now be looking at.  If such a capability exists, I'm unable to find it.
 
I seek to devote more of my time to developing/polishing the post-installation area(s) than basic OS building.
 
I have the disk resources to support hosting all the native files for each of the OS's I've listed above.  Additionally,
I've the disk resources to support hosting each of the OS's as they get built, to include snapshots and checkpoints,
within VMware virtual machines.  I have all the ISO's for each them as well. I have a 64 bit Intel system for virtual
building of OS's. I have a task which requires testing various capabilities against each of these OSs, and uniquely
against each of the various update/releases, thus this is why I'm approaching kickstart from such a broad perspective.
I'm simply unsure on how to properly go about it.
 
So, how do I manage kickstart building for any OS I wish to pick, and have the resultant anaconda-ks.cfg file work
correctly for the chosen OS, when I'm building tons of machines 'virtually'?  Do the kickstart tools in existence today
facilitate this (it doesn't seem like they do)?  If not, what manual method is needed?  Is there a resource or two on
the net that would facilitate what I'm seeking to learn?
 
Thank you very much in advance for your help.

R,
-Joe Wulf, CISSP, USN(RET)

 





More information about the Kickstart-list mailing list