Like many medium to large installations, we have some process in
place to "roll" (i.e. install and configure) machines in an
automatic or semi-automatic process. Currently we use a combination
of kickstart and "clustering" scripts to do this. The biggest
problem we face going forward is organizing and maintaining
this kickstart system across multiple versions. For security
and auditing purposes, we would like to have some mechanism in
place that only installs minimal packages on each machine, with
different packages--based on cluster or "profile"--placed on
specific machines.
To this end we are trying to build a "Differential" kickstart process
that uses the name of a machine (handed off via DHCP or DNS) to
determine what software to install.
I have this working as a very, very ugly "post install" script, but
I think I have found a way to do this a lot cleaner by making
certain modifications to the Anaconda python scripts, and
a modification to genhdlist.
In addition, I have a few questions (and a complaint) about Anaconda.
What I have in mind is to modify genhdlist to take an (optional) argument
of a file name containing the list of RPMS to get the headers from,
rather than building the list from the Redhat/RPMS directory, and
writing the headers to a file called <profile_name>.hdl, rather than
hdlist.
Then modify the Anaconda code slightly to read a profile configuration
file (if it exists, otherwise continue as normal) that maps machine
name to profile name, which will be a "comps" file (basically containing
only base) and an hdlist file containing the headers.
I've already had a fellow sysadmin who knows C really well look over
genhdlist, and other than some nasty comments about the lack of
comments in the code, and general coding style, he seems to
think this will be a trivial add.
I've been thinking about this for a while, and looking at the Anaconda
source code a bit, mostly with the RH7 and now I'm looking at
the stuff in wolverine where there is now "hdlist2".
However, in what is unfortunately seems to be typical Open Source
fashion, there is almost no documentation on what genhdlist does,
the format of hdlist, or almost any of the internals of
Anaconda.
Which means that now that I know what hdlist actually contains, it
has been split into hdlist and hdlist2, and I have no documentation
on what goes in each.
On the anaconda side it seems slightly more complicated, but still
fairly easy to modify it to point to different "comps" files and
"hdlist" files.
I can find 3 files that seem to directly read the hdlist file, and
the comps file, and they are the same set of files, so what I am
considering doing is adding a method to comps.py that returns
a path to which configuration (comps file and hdlist) to use.
I have a couple questions tho'. What exactly *is* hdlist2 and what
is the relationship between hdlist and hdlist2.
Second, is there a possiblity of getting the programmers involved
in the production of the anaconda/kickstart system to document
what they are doing? Inline comments, beyond the stage of
"mmmm... linear search" (which besides being an incorrect use
of elipisis is utterly useless) would be fairly helpful in
understanding what is going on there.
Finally, some unrelated questions:
When will reiserfs be supported in the kickstart process, and when
will LVM be supported? We need both of these for an upcoming rollout,
and I would rather *NOT* have to deal with System Imager for this,
as if we start using it, it will wind up replacing kickstart as
our means of rolling new boxes, and cause me lots of grief.
As a trivial question (while I'm asking) is there an easy way to
get rid of the redhat logo screen on startup? All of our machines
run headless with console redirected to serial, and it is kindof
annoying to have the garbage that this splash screen throws up
scroll across the screen.
Comments?
--
Share and Enjoy.
_______________________________________________
Redhat-devel-list mailing list
[EMAIL PROTECTED]
https://listman.redhat.com/mailman/listinfo/redhat-devel-list
