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 -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
