distribution customization

[Bill Nottingham <notting redhat com>]

One of the features we're working on for Fedora Core 7 is a
framework to customize the distribution [1] without necessarily
modifying the package set; this is needed as we're intending
to target multiple 'spins' [2] of Fedora.

Right now, what *currently* can be customized is:

- anaconda splash screens and artwork (via product.img)
- anaconda install classes (via product.img)
- default package set (via comps.xml)
- default groups selected in said package set (via installclasses)
- repository selection (via installclass)

What we *want* to be able to customize is:

- default set of services to start
  rPath has sent a patch for chkconfig that allows for this; it works
  by writing override files for any service you want to change,
  and then running chkconfig.
- sysctl settings
  Allow for different sets of defaults depending on app/workload.
  Server/desktop/router/etc.
  A simple implementation would just be to allow for /etc/sysctl.d/,
  and lay down files there, although there are integration issues
  there (see below.)

So, there are three issues that need solved:

1) What other parameters do we want modifiable?

I'm open to ideas.

The one that hits me is 'anything that can be specified in kickstart';
reasonably, anything done there (well, excluding %post) should be able
to be 1) made a default 2) made required.

Potential implementations of this:

 a) Ship a kickstart file in the spin that's used by default.
 
    Pros: Easily expandable to do anything we want, through the use
          of %post
	  Allows for future expansion and automatic support of
	  any new anaconda features.
    Cons: If we want the concept of 'setting defaults' that the
          user of the spin can change, will need some reinterpretation
	  of how kickstart is used inside of anaconda. Unless I've
	  missed something.
 
 b) Embed this information in the install class
 
    Pros: Doesn't use kickstart
          Allows you change anaconda's UI, add/remove screens, etc.
    Cons: Deeply ties you to anaconda versions. More likely to break


 c) ???

2) How do we package these modifications?

 a) A package containing whatever files are used to customize that
    pungi/whatever uses when building the image.

    Pros: Easy to drop whatever customizations onto the filesystem
    Cons: Well, either you have packages that Aren't Fedora in the spins,
          or you make someone go through and review them.

 b) Just a product.img, generated either as part of the spin, or
    passed to the tool to be put in the spin
    
    Pros: Easy to customize anaconda bits this way - infrastructure
          is already there.
    Cons: Awful for dropping any needed files on the filesystem. Unless
          you use kickstart %post, which is a dirty dirty hack.
 
 c) ????
 
Of course, you could argue that all this default setting, etc. belongs
as part of a centralized configuration management and provisioning tool,
such as cfengine or puppet. Not sure we really want to go down that
road, though.

Bill