Andrew Brown wrote:
We're open to suggestions on how the interface should look for
this.
Right now, to elaborate on what Michael described, we'll have a
"cloner" distro installed. This will be generated from an actual
distro, but modified to be a live environment with scripts to save off
or load the hard drive over nfs. Hence the "cobbler distro
make-cloner command.
Specifically, this command could use the utilities in the livecd-tools
package to create an iso or a pxeboot kernel/initrd that's purpose
will be to save and load images. This is what I'm currently looking
into, any suggestions on this step are welcome.
The next step is to associate profiles with a cloner distro. You'd
create a profile for each image you want to save; profiles that are
assigned to a cloner distro represent one image (but that image could
go to several systems). Systems that are assigned to the same
"cloner" profile are intended to have the same image on them (or at
least have the ability to reload the image from time to time). In my
use case, we'd equate profiles with projects, so we could save off an
image related to a project and load another onto a particular machine
as needed.
And the final step is to associate a system with a "cloner" profile.
When a system is assigned to a cloner profile and set to netboot
enabled, its pxeboot file will point to the cloner distro kernel and
initrd. Additionally, kernel parameters will be passed to it to tell
it to save or load, and where it should save/load to/from (nfs path),
and the image name. The computer boots, goes through the imaging
process, and reboots back to the local hard drive when finished.
I thought this was relatively simple (compared to some of our initial
ideas at least), and I like it since it follows the model for distro
-> profile -> system pretty well. This business of a cloner distro
was chosen (over just including a pre-made kernel/initrd with the
package like xcat does) for portability and compatability with all
environments and arcitetures.
I also agree that usability wise this is going to be rather simple.
That's the point of cobbler, in automating what's going on behind the
scenes and making more manual technologies and processes very consumable
and fast. Rather than hear that the implementation "sounds
complicated" (it really isn't -- we have thought this out a good bit), I
was more interested in hearing what folks thought of the feature and syntax.
The theory behind this feature is to be able to take a snapshot of a
customized system. Kickstarts are usually preferred, but in some
environments it is desirable to be able to save a machine's current
state off to an image. Then perhaps something experimental can be
tried, and the original image restored afterwards. This is somewhat
common situation in our lab. The second useful situation is where we
need to set up a machine in a very specific way: customize packages,
configs, files, and such, and then need to duplicate this to many
other machines. The customizations aren't always easy to compress
down into a kickstart, and especially when the hardware is identical,
imaging them is often easier and faster. I know a lot of you probably
don't need convincing that this is a useful feature, I just thought
I'd share some of the more useful cases that I've come across for this
kind of feature.
Right, images are a completely different workflow from kickstart based
systems. There are several use cases here -- restoring backups of
existing images, cloning existing systems that got into a state in a way
that is not reproducable, Windows cloning, and even finding ways to
support other operating systems that Cobbler doesn't support as long as
we understand the filesystem. This is really the largest missing
component of cobbler and a great add.
To me, it seems this is one of the most generic ways we've seen how to
solve the problem thus far -- and that's much better than solving it for
just one OS (Windows specific code -- ack), or doing something hackish
at the filesystem level that is more in the config management layer.
If someone wants to use config management systems or backup systems,
nothing is stopping from doing that on top of Cobbler -- in fact, that
can be a good thing. This is about dealing with /filesystem/ images.
And as always, it's not required that you use it if the use case doesn't
make sense for you. I can see this being /highly/ useful in academic
type environments, where the division in IT between Linux and Windows
systems does not exist ... and not just at university levels, but also
in K-12 lab situations and other places where the administrator doesn't
have the time to learn DHCP, DNS, image cloning tools, kickstart, and so
on, ad nauseum. The other use case is for a heavily customized OS
image, which do exist in certain niche applications. That is less of a
target but still something we should cover in other to completely cover
the provisioning use cases.
For folks that can do kickstart like solutions, absolutely, do those!
They are much more sustaintable and easy to manage -- in particular, the
updates problem goes away, and the storage requirements are much smaller.
-Andrew
On Wed, Jul 30, 2008 at 12:02 PM, Michael DeHaan <mdehaan(a)redhat.com
<mailto:mdehaan@redhat.com>> wrote:
I've been talking with Andrew Brown from NCSU, and we have some
ideas on
how to implement a cobbler imaging solution utilizing livecd's and
partimage. He's going to be taking a crack at implementing this
for a
future cobbler release. I've included basic details here so others
could see what we are thinking and weigh in. The use case is for the
Virtual Compute Lab (
http://vcl.ncsu.edu/) though this should be
extensible to any other place that needs to clone images and might
have
mixed Linux/other deployments. Naturally, if you can do
kickstart (or
preseed, or autoyast, or ...), it's always preferable to do kickstart
(or equivalents) -- maintaining security updates on images and so
forth
and dealing with hardware differences is an additional layer of
complexity.
This is somewhat based around some capabilities of IBM's xcat, though
we're going to rework it to make it work idiomatically in cobbler
where
there is much less setup involved.
The following instructions assume pxe_just_once is turned on in
/etc/cobbler/settings and the systems PXE first in BIOS order. That
makes some things simpler as the live images can simply reboot
when done.
The idea/syntax is as follows:
# from a base of the imported RHEL5 distro, use livecd-tools to
create a
livecd and convert it to a PXE-able image.
# this livecd image will contain a post script that uses partimage to
export partitions to a configured NFS share (in cobbler)
# and/or load the image based on kernel arguments configured via flags
below.
cobbler distro make-cloner --name=RHEL5-cloner --distro=RHEL5
# here we make a profile for what is being cloned. For example,
"RHEL5-image-myclassproject37", this name will be used
# by the NFS share, and because it is parented by a cloner image, it
will have special symantics in terms of what kernel
# arguments get fed to it, such that our special live image (or
modified
initrd, TBD) knows what to do.
cobbler profile add --name=RHEL5-image-projectX --distro=RHEL5-cloner
# now we assign a system via PXE boot to be cloned. Note that we are
assigning it to a live image not to be installed, but to
# be netbooted and then cloned.
cobbler system edit --name=foo --profile=RHEL5-image-projectX
--save-clone [--netboot-enabled=1]
# to clone the image, we assign another system to the cloner profile,
like so, and reboot it once finished
cobbler system edit --name=bar --profile=RHEL5-image-projectX
--load-clone [--netboot-enabled=1]
This should cover all partition types supported by partimage but
not the
"weird stuff".
This also seems to imply that we would have a settting in
/etc/cobbler/settings to configure the address info of the NFS
server to save things to.
Comments? Questions?
--Michael
_______________________________________________
cobbler mailing list
cobbler(a)lists.fedorahosted.org <mailto:cobbler@lists.fedorahosted.org>
https://fedorahosted.org/mailman/listinfo/cobbler
------------------------------------------------------------------------
_______________________________________________
cobbler mailing list
cobbler(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/cobbler