[PLUG] A _Red Hat_ upgrade question

[Paul Heinlein]

On 30 Aug 2002, Karl M. Hegbloom wrote:

> How much information does that "kickstart" file contain?  Does it
> know how you've configured those installed packages, your
> networking, etc, or does it merely contain the list of packages to
> install?

It includes

* supported languages and default language
* keyboard and mouse hardware info
* X configuration info (video hardware, default resolution/depth)
* network info (dhcp or static addr/dns/gateway/netmask)
* md5 version of your root password
* firewall/iptables info: disabled, low, medium, high
* authorization configuration (nis? ldap? shadow? md5?)
* timezone
* which bootloader (lilo? grub?) and where it's installed
* local disk partitioning
* package listing

The idea is that, given this kickstart file, you could re-install Red 
Hat to the exact same state if the need arose.

In general, the kickstart facility is one of the things I really like 
about Red Hat. At work I keep two unaltered trees for, say, Red Hat 
7.3 on an nfs fileserver:

* linux/7.3   -- the original 7.3 installation tree
* updates/7.3 -- all the patches, updates

Then I have a tree for locally built rpms

* local/7.3

I've written a Perl script that copies the original installation tree 
into a parallel <version>-current directory, i.e.,:

* linux/7.3-current

The script then scans that tree, making note of all the rpms 
(including those specific to athlon, i686, and i585 architectures). 
Then the script scans the updates directory and, when it finds an 
updated package in updates/7.3, it moves the new package into 
7.3-current and deletes the previous one.

I haven't yet written into the script similar functionality for
scanning my local rpms for updates, so I still have to do that by 
hand. :-(

In any event, the 7.3-current tree ends up with all the latest updates 
plus all my latest local packages (cfengine, xfce, aterm) plus a 
couple third-party packages (java, the ICA client).

Red Hat has a plain text file that allows you to create/edit named 
package groups that you see at installation time, so I have a couple 
groups, one containing non-standard packages that we install on 
desktop machines and one for infrastructure servers.

Once the updates are in place and the package-list file ("comps") is
edited, my perl script uses Red Hat's anaconda tools to regenerate the
installation images -- so any new installation from the 7.3-current
tree is fully patched and includes local and third-party packages.

--Paul Heinlein <heinlein at attbi.com>