Prepackaged configurations

[Matthew Miller]

On Sat, May 22, 2004 at 02:43:52PM -0400, Havoc Pennington wrote:
[selectively quoted throughout]
> I'm calling this a canned or prepackaged configuration.

I'd really like to see this.


>  - the package set (the only thing we can change now, via 
>    the Workstation or Server split in the comps file for example)

Actually, more than that can be changed in the install classes -- default
partitioning scheme, for example.


>  - default settings in gconf (e.g. each canned config might 
>    add a new config source in /etc/gconf/2/path)

This could be simply which packages get installed, right?

>  - contents of /etc/skel

And this already _is_ that. But unfortunately it can lead to confusion, if
some of the relevant packages are installed before some user accounts are
created and after others....


>  - kernel boot options

And this'd be easy to do in anaconda too. I think probably pretty easily
through just the installclasses files....


>  - ideally, it's dynamic instead of only install-time, i.e. 
>    you can change a machine from config A to config B post-install.
>    Easier for some things than others (e.g. partitioning scheme 
>    impossible to change post-install, config files perhaps easier,
>    package set relatively simple)

Apt for RPM has a nice script in contrib that can add or remove package
groups (as definied in the comps file). So if the config types could be
definied as sets of packages, that'd be really handy.


>  - ideally, third parties can provide their own canned 
>    configurations maintained separately from the main OS.
>    You can imagine whole open source projects that basically 
>    just maintain a configuration.

I'd like that. :)

> 
>  - ideally, these configurations can be in the installer in the 
>    same list as Workstation vs. Server choice; it would be strange
>    to choose between Workstation and Server then later choose 
>    between canned configurations

Definitely. If it's not there (and I think it should be), the
workstation/server/personal desktop choice should also be removed.

>  - ideally, local or site-specific tweaks can be kept separate from 
>    and "override" the canned settings, so that on upgrade you 
>    inherit new updates to the canned config

This can already be done with install classes already --
<https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=66634>. It could maybe
be made even simpler, and perhaps the comps file extended to be able to
include other files (and maybe have overrides).

In fact, maybe the comps file should be entirely subsumed into the install
classes -- they're already very tightly linked anyway.

>  - Jeremy does not want to maintain this stuff in the installer

Yes, that's fair -- the installer is insane enough already. 

But luckily, the installer has most of what's needed already done. With some
basic improvements to comps/installclasses handling, all of the long-term
maintenance could go elsewhere.


>  - selecting a given canned config has to be possible via kickstart

Definitely. Leveraging the existing install classes would work nicely for
that, too.



>  B. kickstart files. We provide a kickstart file for each 
>     configuration, probably there's a package naming convention
>     like kickstart-x-terminal-client, and a convention for 
>     where the kickstart file is installed. 
> 
>     Downsides: user has to install the OS, set up a kickstart server
>     or make a boot disk, learn about kickstart, etc.; kickstart files
>     contain incidental noise such as partitioning and so forth that 
>     will usually be unrelated to the canned config
> 
>     Upside: does not affect the installer, and again relatively 
>     easy

These sample kickstart files could be on the install disk by default, and
syslinux entries created for them....


>  D. config profiles usable by the installer. Same as above, but
>     offer them in the installer rather than just package sets
>     in the installer. 

I think this is The Way. There's already a lot more than package sets that
installclasses can do. You can even hook up a post-install script.


-- 
Matthew Miller           mattdm at mattdm.org        <http://www.mattdm.org/>
Boston University Linux      ------>                <http://linux.bu.edu/>