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 <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> 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 > [email protected] <mailto:[email protected]> > https://fedorahosted.org/mailman/listinfo/cobbler > > > ------------------------------------------------------------------------ > > _______________________________________________ > cobbler mailing list > [email protected] > https://fedorahosted.org/mailman/listinfo/cobbler > _______________________________________________ cobbler mailing list [email protected] https://fedorahosted.org/mailman/listinfo/cobbler
