Kickstart and roles

[seth vidal]

On Tue, 2006-04-18 at 15:23 -0700, David Lutterkort wrote:
> 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]. 
> 

What we did at duke was to take snippets of kickstarts and assemble them
in whatever order per-profile using glump:
http://linux.duke.edu/projects/mini/glump/

It sounds like puppet is taking that a step further by allowing the
conversation to go both ways.

It's kind a shame puppet isn't in python - it would make it easier to
integrate some of the pkg handling mechanisms of yum with it if it were.

-sv