I would love to use kickstart but my peers are directing me to use images. The perception is that images would deploy faster than kickstart. Has anyone on this list done any performance measurements of images verses kickstart or just kickstart performance. For example there is an old paper documenting system imager installing 1000 nodes in 15 minutes. I do not have the hardware yet to test performance but I may be forced to use this method unless I can get numbers to back up my decision.
http://wiki.systemimager.org/index.php/BitTorrent#Benchmark -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael DeHaan Sent: Tuesday, September 30, 2008 3:00 PM To: cobbler mailing list Subject: Re: More details on system imaging -- livecd based proposal [EMAIL PROTECTED] wrote: > Hi Andrew, > > I'm very interested in using this functionality to deploy a large > number of systems for a datacenter project that I am working on. I do > have some ideas for functionality in case you might be interested. > > 1. Since uploading images is mostly a rare event would it make sense > to just use some other tool, e.g. one of the partimage based CDs (e.g. > clonezilla) to upload the images via ssh/sshfs/ftp/smb. This will > avoid the need to use an insecure nfs that allows root access and > avoids the need to store SSH keys. > Interesting, though I'm not sure SSH is a good route because of the nature of key management. Anonymous FTP uploads would probably be fine. Another problem with that approach at the moment is that (A) it requires setup of udpcast, and (B) clonezilla is not packaged for Fedora/EPEL. So, if there is interest in these tools, ideally interested parties should look toward getting them packaged in Fedora, and then we can work on showing instructions on how to get those up in running with Cobbler. udpcast is actually packaged, but not all of it, and the images still have to be built to support particular hardware. This is non-trivial. The live image approach is nice is that it benefits from the wide variety of hardware support already supported by the Fedora Live CDs. Either way, I think we're looking for (as with other cobbler things) a way to not only get a solid environment up and running, but also one that doesn't produce a lot of trial and error. udpcast concerns me with this. > 2. Maybe use ftp/ssh/sshfs/http to download the images. This would > also avoid the use of NFS. Then you get into ssh key management for the restore images, correct? Ftp is probably reasonable here. > > 3. Partimage based apps can also upload just the filesystem images (as > opposed to the entire disk). I was trying to work on a system using > clonezilla that can PXE boot an installer which will download the > partition table then partition the target disk then copy the > filesystems onto the partitions. After the image is copied the image > filesystem could be resized to match the partition size. I figure that > this would require smaller images as the entire disk image would not > need to be transferred. Yes, Andrew's new version uses partimage for exactly this reason. I did have some problems getting it working in that it didn't mount NFS read-write, which rather than fixing it, moving it to FTP might be cleaner. > > By the way, I read the instructions on the wiki but could not figure > out where to get the cloner-live-cd.iso. Is this just the Fedora Live iso? See Andrew's response on this. You mentioned usage of cloning in a large datacenter type environment, why does kickstart (or other distribution answer files) not work in your particular case? These are more repeatable in that they are declarative and much easier to maintain over the long haul. > --- > Don Khan > Cloud Infrastructure Group, EMC Corporation > 11 Cambridge Center, Cambridge MA 02142-1405 > > > > ------------------------------------------------------------------------ > *From:* [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] *On Behalf Of *Andrew > Brown > *Sent:* Tuesday, September 30, 2008 12:08 PM > *To:* cobbler mailing list > *Subject:* Re: More details on system imaging -- livecd based proposal > > Michael, > I made a few changes to my script. I changed the kernel parameter > from being "save" or "load" to "cloneraction=save" or > "cloneraction=load". That way it inherits properly with cobbler > profiles and such. > > Testing things out, it seems to work very well with cobbler. I have > my distro set up with the basic kernel parameters: > rootflags=loop rootfstype=iso9660 root=/cloner-live-cd.iso > > The profile is per image. So I set my profile parameters to this: > cloneraction=load image=blade13 nfs=10.10.10.1:/export drive=/dev/sda > > And then for each system that should have that image, I just assign it > to that profile. If I want to load an image, I just netboot it. If I > want to save an image, I set cloneraction=save for the system and then > netboot it. > > Of course, that's only one way to do it. I believe what you described > on the wiki was slightly different but still works. That's what I > like about this. > > Two things: > First, how can I get netboot to go back to disabled after an image is > loaded/saved? > > And second, I changed the script to restart automatically when done, > but the shutdown procedure seems to hang on the "Turning off quotas" > step. Any ideas why it doesn't go ahead an restart there? I'm > looking into it, just wondering if you've seen this before or something. > > -Andrew > > On Wed, Sep 17, 2008 at 12:03 PM, Andrew Brown <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> wrote: > > Here's my latest version of my build script (it's GPL), as well as > a SRPM I built for partimage-ng. > > The script takes arguments from the kernel parameters. Here's my > append line for a PXE boot: > > APPEND initrd=initrd0.img root=/cloner-live-cd.iso > rootfstype=iso9660 rootflags=loop nfs=10.10.10.1:/export > image=blade13 drive=/dev/sda save > ONERROR LOCALBOOT 0 > > Note, I haven't actually tried this version since I built > partimage-ng into an rpm, but it should work. I just haven't had > time yet to try it. > -Andrew > > > On Thu, Sep 11, 2008 at 9:21 PM, Andrew Brown <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> wrote: > > > > On Thu, Sep 11, 2008 at 9:03 PM, Michael DeHaan > <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote: > > > I think trying to do this securely in the NFS realm is > going to be > difficult if not impossible, indeed. > > Maybe we just document it with scary blinking lights on > the page that > (when using this feature) it's very easy to replace disk > images without > hosts.allow, hosts.deny, /etc/exports, and/or iptables > locked down to > specify what machines can write to that NFS share. The > vulnerability > is the option to replace someone's partition before they > clone it to > lots of other machines, basically injecting new content. > However if > this is limited such that only machines in the datacenter > can access > this content, then the problem becomes ensuring users > can't access > /those/ machines. > > Doing any sort of better locked down NFS install is a huge > problem for > rw NFS, especially when the user is a CD -- we can't just > stick the > password in the cloner image as the cloner image is public. > > Other proposals welcome, perhaps ok for now. > > Naturally since this NFS feature is not available until > someone turns it > on and so configures their cloner images, we aren't exposing a > vulnerability in a place where users can't see that > message about > limitations -- they'll know the implications when using > the feature. > > This may in fact be fine for most secured lab setups, just > definitely > not something you'd want on an open college network. > > --Michael > > > I was thinking of some setup with ssh and host keys, but any > host key would need to be on the livecd image itself. I can't > think of a good way to secure this system, NFS or not. I > suppose it's okay if this feature is only practical inside of > a secure lab setup though. > > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > cobbler mailing list > [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
