Prepackaged configurations

Havoc Pennington hp at redhat.com
Sat May 22 18:43:52 UTC 2004


Hi,

Something that's missing in the OS is an "out of the box" experience
for the different ways one might use the operating system.
 
For example, if you want an X terminal server and some X terminal
clients, then you have to read a fair bit of docs and modify all the
relevant config files, which may be in a number of formats. Other use
cases that require custom setup might include router/firewall,
clustering, locked-down desktop, or whatever.

In an ideal world, someone could maintain the canonical best practice
setup for say a locked-down desktop lab, and everyone else just
clicks/types "install me a locked down desktop lab system," applies any
site-local tweaks, and that's it.

I'm calling this a canned or prepackaged configuration.

This would be useful because:

 - developers could encode the recommended best practices
   in these canned configurations
 - QA and testers could then easily install and test the 
   OS for each canned use case
 - docs authors could easily get things working for 
   each use case
 - users and admins would have a nice "out of the box" 
   experience getting things going very quickly, and 
   avoiding a lot of custom engineering that tends to 
   break on upgrade
 - allows developers to coordinate the whole network
   environment; e.g. the canned config for LDAP/Kerberos 
   server should automatically work with all the client
   installs, same for print server etc.
 - we probably need different defaults for desktop and server
   in some cases, e.g. for how hardware is handled

Some of the things that _might_ change across canned configurations:

 - the package set (the only thing we can change now, via 
   the Workstation or Server split in the comps file for example)
 - specific parts of a config file, e.g. enabling xdmcp in gdm
 - default settings in gconf (e.g. each canned config might 
   add a new config source in /etc/gconf/2/path)
 - contents of /etc/skel
 - optimum partitioning scheme
 - first boot screens, e.g. asking for site-specific info to 
   go into the configuration
 - kernel boot options

Some baseline considerations for how to approach this problem:

 - we should approach it consistently, such that there's one place 
   to browse a list of available configurations, a general pattern 
   followed for how they are implemented, and so forth

 - 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)

 - 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.

 - 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

 - 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

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

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

Some possible approaches:

 A. documentation. We just write down how to build each 
    configuration, possibly providing an example kickstart file.
    Put these documents in a common location with a standard
    naming scheme, etc.

    Downsides: doesn't provide the automation, so no "out of the box"
    experience; doesn't clearly make one developer/maintainer 
    responsible for whether the config works and what it's like.

    Upside: relatively easy

 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

 C. kickstart profiles. Introduce something like "%profile 
    x-terminal-client" that can go in a kickstart file. 
    Could implement an XML description of each profile, 
    support something like:
$ kickstart-profile --list
vnc-terminal          Remote Desktop Terminal       VNC based thin client terminal...
x-terminal            X Terminal                    X based thing client terminal...
....
    
    This is somewhat nicer than just providing a collection of 
    kickstart files.
   
 D. config profiles usable by the installer. Same as above, but
    offer them in the installer rather than just package sets
    in the installer. 

 E. dynamic "alternatives" system for configurations. Direction 
    suggested by Owen, haven't sorted out how this would work 
    precisely, perhaps symlink-based.

 F. write a simple library for redirecting config file lookup 
    depending on a global "what this system is for" setting. 
    e.g. you might have gdm.conf.normal and gdm.conf.xterminalclient
    and gdm would use a simple library that keys off of 
    /etc/sysconfig/system-profile to locate the right config file?

 G. meta-packages. e.g. have a package x-terminal-client that depends
    on some set of other packages, provides certain config files, 
    etc.
   
    The obvious problem is that the gdm package provides 
    gdm.conf, so how does a meta-package install a different 
    gdm.conf. If every important daemon/feature supported a 
    conf.d with override files in it, that might answer the 
    question, but sadly that isn't the norm.

 H. Some sort of RPM changes. Presumably we could make RPM smart
    about this problem in some way. I don't have concrete ideas.

Obviously, this is far from fully thought-out at this point, I'm just
trying to start the thread. It looks pretty likely to me that our
solution will be a pragmatic compromise that isn't quite ideal. But
which compromise is the best one?

Havoc


 









More information about the fedora-devel-list mailing list