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 <ambrown4(a)ncsu.edu> 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 <ambrown4(a)ncsu.edu> wrote:
>
>>
>>
>> On Thu, Sep 11, 2008 at 9:03 PM, Michael DeHaan <mdehaan(a)redhat.com>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.
>>
>>
>>
>>
>