--- Bill Nottingham <notting@xxxxxxxxxx> wrote: > One of the features we're working on for Fedora Core 7 is a > framework to customize the distribution [1] without necessarily > modifying the package set; this is needed as we're intending > to target multiple 'spins' [2] of Fedora. FYI here is the current outline (not much different from what I've said on livecd-list for ages) for a project I am working on. Preface: its still deep in proof of concept stages- ------------------------------------------ viros/vsys system image generator outline ------------------------------------------ (not required to run as root) 1) generate (and maybe regress test) a custom livecd/derivative-distro vsys generate liveiso --strain=fz7 customstrain.iso (takes a few hours, progress meter, non-interactive, maybe eventually a gui to manage flags/options) 2) test/play your new system image vsys virtualize customstrain.iso (purely a wrapper to abstract away qemu options) What this is doing is create a 'strain' (aka 'spin'/'recipe'/'system configuration') of a livecd. In this case it pulls the recipe/config from /usr/share/viros/strains/fz7.vml, which is an xml config file describing exactly what needs to be known to create this particular spin/strain/livecd. Basically the input for how to do a fedora core 6 automated install (grub boot line, kickstart, arbitrary extra data/script payload, etc...). Then, to create a new, modified 'strain', you either copy and modify the vml file, or use builtin 'features/traits', i.e. vsys generate liveiso --strain=fz7 \ --addfeature adduser:user=sysuser,password=notobvious --addfeature gdmautologin:user=sysuser --addfeature adddefaultstartpage:user=sysuser,page="http://example.com"; The features/traits would be a standard format (rpm/tgz/makeself/whatever) and live in /usr/share/viros/traits/ To reiterate, one benefit of my design using qemu instead of DavidZ's root based pilgrim, is that all install actions (including hundreds of %pre/%post scripts) are run in a user protected environment. Another benefit, is that this can abstract away the distribution. I.e. I fully intend to support debian/ubunto/centos (and later PPC versions of stuff using qemu-ppc). I.e. I hope to have default strain configurations that can say generate the latest version of knoppix with all debian updates applied. Also, I have it working so that everything is always done to a hidden vnc window, so it can just churn away on some headless server generating images, and even doing automated regression tests on those images by booting them under qemu. One final aspect is that I also have designed it with modular backends in mind. I.e. 'generate a livecd using the unionfs method', 'generate a livecd using the devicemapper snapshot method', 'generate a livecd using the kadischi bindmounting method', 'generate a livecd using the jdogalt rebootless installable method', 'generate a tgz that can be remotely push installed to server you have root ssh access'. Anyway, as I've been saying for years, I hope to get it demoable any day now, and that other people find it as useful as I imagine it to be :) Maybe DavidZ has some better plans for pilgrim, perhaps integrating with this virtmanager I haven't played with yet... -dmc/jdog ____________________________________________________________________________________ Have a burning question? Go to www.Answers.yahoo.com and get answers from real people who know.
