Re: distribution customization
--- Bill Nottingham <notting(a)redhat.com> 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.