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

[Michael DeHaan]

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 at redhat.com 
> [mailto:kickstart-list-bounces at redhat.com] *On Behalf Of *Joe_Wulf
> *Sent:* Saturday, June 30, 2007 10:45 PM
> *To:* kickstart-list at redhat.com
> *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 at redhat.com
> https://www.redhat.com/mailman/listinfo/kickstart-list