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. 
 
2. Maybe use ftp/ssh/sshfs/http to download the images. This would also
avoid the use of NFS.
 
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. 
 
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? 
--- 
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]>
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]> wrote:
        



                On Thu, Sep 11, 2008 at 9:03 PM, Michael DeHaan
<[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

Reply via email to