Kickstart and roles

[David Lutterkort]

On Thu, 2006-04-13 at 22:47 -0500, Mike McGrath wrote:
> So I've been kicking around this idea for a while and wanted to see
> what others thought.  Who knows maybe someone will be interested in
> helping.

More than interested. That's actually right down the road me and some
others have been thinking lately.

> This may already exist so if it does please let me know but I would
> like to setup a bunch of kickstart scripts for server and workstation
> roles using only official Fedora software.  For example, lets say
> someone wants a xen workstation.  We could setup a kickstart script
> with everything they need, only the minimals and at the end, yum
> update, configure what we can and on reboot, that user has a working
> xen machine.

We are working on a tool to simplify the very basics of keeping track of
provisioning setup, both for bare-metal and domU provisioing. Our focus
so far has been on the mechanics of keeping kernel/initrd/ks.cfg on a
central server and using PXE boot (for bare-metal) and a separate script
(for domU) to start the provisioning. It's just a tad early to inflict
this on the world, but we'll make a prototype available in the next week
or two. For domU's, the idea is that it should be easy to publish
special-purpose kickstart files and use them with the tool.

> Perhaps a better example, lets say somene needs an email server that
> supports SMTP, imaps and webmail.  We could create a kickstart script
> that installs and configures as much of it as possible in a way that
> we deem secure.  All the user would have to do is fill out a fiew
> variables at the top of the ks script (like domain or something). 
> Anaconda would ask for things like partitions and network.  When the
> machine reboots, they have a working email server.

I think kickstart is not the right tool for that purpose; for something
like webmail, you also need to make sure that the machine stays in a
specific state, update various aspects of the machine (not just
packages, but also configs), make it easy to adapt the upstream version
of the setup to local needs while still being able to consume upstream
updates etc. 

As a separate project, I've been looking into using a config management
tool (puppet [1]) to create 'system recipes', i.e. recommended
configurations for a specific purpose like webmail or a mail server. The
tutorial [2] describes how that would work for one example, and we've
been working on a prototype for distributing these recipes based on a
distributed source control system, mercurial in the prototype [3]. 

> I have a hunch
> there's a market out there for it, and if every ks script came with
> clear "What to do next" instructions we might be able to save some
> chatter on the lists and open Fedora up to many more users out there
> who want to do more with Fedora but just don't know how.

Even better if the 'What to do next' instructions would describe the
configuration of the machine in a way that can be used by the
appropriate tools with minimal human intervention - that's kinda the
idea behind system recipes.

I would love to hear your thoughts on this; and if you have the time, a
helping hand is always welcome,
David

[1] http://reductivelabs.com/projects/puppet
[2] http://people.redhat.com/dlutter/puppet-app.html
[3] http://people.redhat.com/alikins/prm/prm.README