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
