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

Michael DeHaan <mdehaan@xxxxxxxxxx> · Mon, 02 Jul 2007 12:04:36 -0400

Shabazian, Chip wrote:
Well, first of all, you can dispense with the WS/ES/AS redundancy. 
+1.
The only difference between them is what gets installed in package 
groups and the redhat-release rpm.  For testing binary compatibility, 
you can simply test any of the WS/ES/AS versions.  In fact, depending 
on your kickstart, it's possible you get the exact same build from 
each one (I do using our kickstart).

I would probably just take my kickstart file, replace the install 
source with something unique such as INSTALL_SOURCE_HERE, then do a 
"for `ls /dir/of/your/install/trees`" loop using perl or sed to change 
the INSTALL_SOURCE_HERE to the proper directory name and create 
kickstart files for each release.  You could then simply use 
ks=method:/path_to_kickstarts/release.cfg.

It may be a bit simplistic, but it's quick and should work just fine.  
Any issues you run into can be fixed in the specific release kickstart 
file.

Although Cobbler is an excellent tool (and I highly recommend it for 
anyone setting up a build infrastructure), it sounds like more setup 
than you need for this project.

Managing an large set of distros and then assigning kickstarts to them 
is kind of what I designed it for :).  

Regardless of the size of your setup, it still should be faster than 
making changes to /tftpboot and the kickstart files once set up -- and 
even that should only take a few minutes -- no scripting required.

Back on the kickstart topic, it turns out that kickstarts for 
RHEL3/4/FC5 for base installs are reasonably the same, with the exception
of the ability to specify yum repositories in the kickstart which is new 
in FC6/RHEL5, and the install key logic that is new in RHEL5.    Cobbler 
uses Cheetah for this,
so you can template out those specific parts based on what distro you 
are running.

cobbler distro add --name=d1 --ksmeta="type=rhel4"
cobbler distro add --name=d2 --ksmeta="type=rhel5"

In the kickstart file

.. blah ...
#if $type == "rhel5"
  key --skip
#end
.. blah ...

cobbler profile add --name=p1 --distro=d1 --kickstart=/path/to/same/ks.cfg
cobbler profile add --name=p2 --distro=d2 --kickstart=/path/to/same/ks.cfg

You can feed whatever variables you need into --ksmeta that you would want.

Chip

------------------------------------------------------------------------
*From:* kickstart-list-bounces@xxxxxxxxxx 
[mailto:kickstart-list-bounces@xxxxxxxxxx] *On Behalf Of *Joe_Wulf
*Sent:* Saturday, June 30, 2007 10:45 PM
*To:* kickstart-list@xxxxxxxxxx
*Subject:* How-to info needed for multiple instances of RH OS's and 
multiple unique 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)

------------------------------------------------------------------------

_______________________________________________
Kickstart-list mailing list
Kickstart-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/kickstart-list