[CentOS] Kickstarting several *different* setups

Tue Jan 20 18:43:03 UTC 2015
Ashley M. Kirchner <ashley at pcraft.com>

Gotcha. Thanks all! You guys gave me the answers I needed to know and hear.
For the immediate futre I will likely go with multiple pxeboot options
which then picks the specific kickstart file. It's easy for me to put a
label on the server that says 'web' or 'mail' etc. Then just pick the same
from the menu.

Eventually I'll delve deeper into custom and automated setups.

On Tue, Jan 20, 2015 at 10:35 AM, Les Mikesell <lesmikesell at gmail.com>
wrote:

> On Tue, Jan 20, 2015 at 11:13 AM, Ashley M. Kirchner <ashley at pcraft.com>
> wrote:
> > Tom: Thanks for the suggestion. I'll look into those tools.
> >
> > Mark: Yes, they are using pxeboot. Right now when they boot up, the pxe
> > config offers two options, 32- and 64bit. Are you suggesting I create
> > multiple entries that one selects based on what the machine is going to
> be?
> > Is there a way to have this done automatically so I don't have to
> > physically have to do that for each machine, but rather turn the thing on
> > and have it determine what needs to get installed on that particular
> > machine?
> >
> > Les: I was hoping for some way to have it all automated so if for some
> > reason I'm not in the building, I can instruct someone else to reboot,
> pick
> > the kickstart option in the pxeboot menu (be it a web, mail, db, or user
> > server) and a few minutes later have a working machine without them
> needing
> > to do anything else afterwards. Mirroring the data files from backup is a
> > single step that can be done by any monkey, it's the configuration, or
> the
> > manual selecting of a script to run, something they can easily screw up,
> > that's I want to avoid.
>
> There's always a tradeoff in hiding what is being done between
> simplifying things and making it completely impossible for anyone else
> to understand it or fix it if it breaks when you aren't there.  I like
> a little balance between the extremes.  Like making the scripts that
> do the work visible, but including some sanity checking so it won't
> run on the wrong machine - or anything else that you can guess ahead
> of time someone might do wrong with it.   But you could embed the same
> thing in a cgi kickstart URL if there is some way it can deduce the
> right file to deliver or make your db restore process add/configure
> any missing packages needed at that point.
>
> --
>    Les Mikesell
>      lesmikesell at gmail.com
> _______________________________________________
> CentOS mailing list
> CentOS at centos.org
> http://lists.centos.org/mailman/listinfo/centos
>
>