General idea
""""""""""""
I'd like to have a tool that can manage kickstart files. It should be simple,
straightforward and versatile. Every possible kickstart file that already
exists should be able to be constructed (by moving pieces into seperate
scriptlets that afterwards can be reused).

This eventually will lead to contributed scriptlets that others can depend
and improve upon.


Configuration levels
""""""""""""""""""""
We require different configuration levels.

	System dependent (lxpmgt001)
		interface
		ip-address(es)
		hostname
		mac-address(es)
		profile = reverse-proxy ibm-x345

	Profile and OS dependent (reverse-proxy, web-server)
		package-set

	Hardware dependent (dell-lattitude, ibm-x345)
		modules (+order)
		lvm-configuration

	OS dependent (rhel4as, rhel3as)
		dist

Other configuration options are:

	boot-options
	profile

It might be useful (for consultants that work at various comlpanies)
to group these files by customer as well so you do not have to have
different seperated installations for basic testing from a laptop.

I'm currently envisioning a setup where the basedir could simply be
moved to point to different custom profiles and scriptlets.


How to use it
"""""""""""""
A few command-line tools should help out in creating kickstart files.

	footprint lxpmgt001

would create a kickstartfile called ks-lxpmgt001.cfg in the webserver
documentroot with all the specified scriptlets using the various
configuration options.

There will be a CGI script that automatically (based on the mac-address)
generates the required kickstart-file on demand (as well as make a backup
of this file for future reference).

Eventually, it would also configure the local DHCP and TFTP server and PXE
configuration. Or use the LDAP backend (or a relational database) to get
the required configuration options.

	footprint-cfg lxpmgt001


Scriptlets
""""""""""
Small pieces of python code (os dependent or os independent) that can hook
into anaconda (or are self-sufficient) and make use of the standardized
configuration options to perform a specific task.

We would have 2 kind of scriptlets, internal and external. The internal
scriptlets perform tasks on the generated kickstart file, the external
scriptlets add pieces of code to %pre or %post sections and are performed
before or after installation.

Internal scriptlets can always be rewritten to perform the same
functionality as external scriptlets. But they are often less complex
(as they only use kickstart functionality).

External scriptlets can act upon differences and offer much more
flexibility.

Scriptlets that I think would be handy:

	Internal:
		LVM configuration

	External:
		Remote logging
		Better debugging
		Skinning interface
		Complex partitioning
		Complex network setup
		Software installation and configuration

The aim is not to %include these files in the kickstart file because
we want to be able to diff the timestamped versions as well as trace
problems back to the selfsufficient kickstart file.


Functionality
"""""""""""""
Footprint would also perform specific tasks (or have tools to help you
do these). Things that would be exteremly useful:

	Adding kernel modules to initrd
	Maintaining custom initrd
	Writing pxelinux config (boot-options)
	Writing boot floppy images or ISO files
	Write out a DHCP/DNS configuration
	Communicate with remote console systems
	Create a timestamped version of the requested kickstart


System configuration
""""""""""""""""""""
Although I would like a good solution for system configuration. Footprint
will not go beyond basic and simple configuration (to the point that the
system is minimal and secure). It's possible that I will integrate something
with Footprint at some point, but it should work independently as well.


Future
""""""
The following items are on the back of my mind for the future, but I'd like
to not focus on these during the first implementation, even though I consider
some of these are very important.

	LDAP backend support
	SQL backend support
	Web-based (or GUI) frontend
	Support for other operating systems
		Windows (unattended)
		FreeBSD
		Solaris Jumpstart
		YaST

Help and forethought about any of these are welcome to limit the risk of
doing a redesign too soon.


References
""""""""""
"Enhancing Kickstart" by Brian Boyd (Sys Admin Sep/Oct 2005)
ftp://ftp.mfi.com/pub/sysadmin/2005/0510.zip
http://www.rocksclusters.org/
http://xml2hostconf.sourceforge.net/
http://reductivelabs.com/projects/puppet/
http://www.instalinux.com/
http://blog.nominet.org.uk/
http://geek.j2solutions.net/stuff/autokickrhel4.py
http://www.networkcomputing.com/channels/storageandservers/showArticle.jhtml;?articleID=194300555

---
Please send me improvements to this document.