On Mon, Oct 17, 2011 at 10:51 PM, Garrett Holmstrom
<[log in to unmask]> wrote:
> On 2011-10-17 14:45, ~Stack~ wrote:
>>
>> On 10/14/2011 08:00 PM, Nico Kadel-Garcia wrote:
>>>
>>> On Thu, Oct 13, 2011 at 7:51 PM, ~Stack~<[log in to unmask]>  wrote:
>>>>
>>>> I am attempting to build a group of systems that boot off of PXE and
>>>> auto-install with a kickstart file. I previously used a bundled package
>>>> that for certain reasons is no longer applicable to the new system. So I
>>>> am learning a lot about what happened behind the scenes of the bundled
>>>> package.
>>>>
>>>> This particular stumbling block is: I have a mixed environment of 32bit
>>>> and 64bit machines. I would like for the kickstart menu to auto-pick
>>>> 32bit or 64bit. Is this possible?
>>>
>>> Yes, but it's really *sneaky*. You have to build an OS image, usually
>>> a tarball. %pre scripting sets up your fileysstems, you don't actually
>>> install *anything* with the normal install procedures, and you can run
>>> %post or %post --nochroot scripts to implant details of the hardware
>>> and especially network configuration.
>>>
>>> I did this on over 10,000 Linux servers in one month, along with tools
>>> that played 3-card monty to bundle thee relevant configuration files
>>> from old systems to new system. It  was the *fastest* OS installer
>>> I've ever seen, in industry or personal use.
>>>
>>
>> Would it be possible for you to give a few more details on how you did
>> this? I think I understand what you are saying but I am a ways off from
>> doing it. If I understand, the %pre setups up the environment, detects
>> the hardware, and then modifies the installer for the proper ARCH. Right?
>>
>> I am having numerous PXE issues crop up and while I am solving most of
>> them just by searching the net, a few still elude me.
>>
>> I do appreciate all the help I am getting.
>
> It sounds more like what my current workplace does when setting up systems
> for QA:  create an image of a minimal system, then PXE-boot a minimal OS
> that fetches the appropriate image and writes it to the disk instead of
> installing the system package-by-package as usual.
>
> I would like to learn about how to do this with anaconda, so please respond
> to me or the list as well, Nico.

It's mostly scripting done with '%pre', and you can have multiple
'%pre' scripts executed in order, which is an undocumented but
extremely effective way to assemble testable parts of the tool chain.
You basically get all the tools you have in the "linux rescue"
environment, and that's actually an effective environment to pre-test
the configuration scripts in.

A "%post --nochroot" is invaluable for grabbing /etc/resolv.conf from
the installation environment and copying it to the OS image, and
another one can copy in the /tmp/ks.cfg to /mnt/sysimage/root/ks.cfg
if you use kickstart files. The anaconda generated
/root/anaconda-ks.cfg is a misleading little fantasy, like a cookbook
with only the index. It rewrites all the original configurations, and
leaves out *all* the scripts that were in the ks.cfg!

A "%post" script, or multiple independent %post scripts, can set up
other configurations as needed on a host by host basis. Installing
EPEL tools such as Nagios plugins and NRPE, or RPMforge tools such as
Perl modules, or ripping NetworkManager and the burdensome smartkey
daemons out by their dragging and kicking little feet is easily done
here without manipulating your base kickstart image.