On Tue, Jan 20, 2015 at 11:13 AM, Ashley M. Kirchner <ashley@xxxxxxxxxx> 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@xxxxxxxxx
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
