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
