Dylan Swift wrote:
> On Tue, Jan 27, 2009 at 8:48 PM, Michael DeHaan
<mdehaan(a)redhat.com> wrote:
>
>> Corey Kovacs wrote:
>>
>>> I was working on setting up my cobbler server today when it occurred
>>> to me that the ability to "chain" profiles might be useful. The
>>> concept would basically allow you to assign a sequence of profiles to
>>> run against a machine.
>>>
>>> For example.
>>>
>>> a system has profile1, profile2, profile3
>>>
>>> profile1 boots to a firmware update image, then reboots and cobbler
>>> uses profile2
>>> profile2 boots to the HP scripting toolkit, goes through it's
>>> gyrations, then reboots and cobbler uses profile3
>>> profile3 boots into the standard kickstart mode and builds the machine
>>> as normal.
>>>
>>> Profile might not be the right word to describe this but I think the
>>> idea is clear. Seems it wouldn't be too much trouble to do this using
>>> the status mechanism.
>>>
>>>
>>> Has anyone done this in another way?
>>>
>>> Thanks for a great project by the way.
>>>
>>>
>> I used to have a crazy implementation of this, but I've since discarded it.
>>
>> Thankfully, it's already doable.
>>
>> All you need to do is install koan and use koan with --replace-self in
>> %post, and then call /sbin/reboot.
>>
>> This lacks logging, however, but any failures earlier up on the post
>> script should terminate the installation and not make it reboot,
>> allowing you to do some debug.
>>
>> The trick though is that since the first profile is essentially generic,
>> you would need to set a --ks-meta variable on the system itself to tell
>> it what the name of profile2 is and profile3.
>>
>> Make sense?
>>
>>
>>
>>> Corey
>>>
I would also be looking to do something like this, though my need is
to run an image against a system, then on reboot run a second image,
then a third, fourth and possibly even a fifth.
The task I have to undertake is to update the firmware on IBM 'System
X' (read Intel architecture) server hardware, which usually consists
of multiple bootable images. As the equipment is being prepared for a
customer install, and often does not have local hard disk drive, an
operating system (& koan) install is not possible (though I have
considered booting a live distro and mounting the firmware from an nfs
share).
koan works by calling grubby, if you don't have a python stack mangling
the bootloader and config on the HDD sufficient. (grub-install, for one)
As far as I can see, the main problem is being able to reliably
detect
when the current image has been successfully run against a system,
before cobbler would be able to change the image to the next in a list
of images, ready for the next reboot. Cobbler could rely on logging
(from tftpd server - /var/log/messages) of a successful download by
the client as a trigger to move on. This would require adding the
verbose flag to the server_args in the file /etc/xinetd.d/tftpd to
obtain this information - something I have yet to try out.
Hmm...
If not all driven by kickstart, yes, you don't have a clean "do this in
order" kind of thing, especially when it's a closed image you can't get
inside of.
Then again, in that scenario, it would also not be logging... Catch-22?
If you have kickstart the chaining would work and you could also get
koan on there. Same for live images which cobbler can boot since you can
convert
them into a kernel and a very large initrd using livecd-iso-to-pxeboot
from livecd-tools.
Monitoring tftp logs and running cobbler commands and such is possible
though you would need to guess how long each would need to run.
Could be an interesting script and showcase of some cobbler API
coolness, but might also get a little complex.
I do feel your pain with that setup. If anyone has better ways to handle
this chain order that don't require kickstart or special code to run,
maybe there's a nice
way to do it.
Anybody have any thoughts on this?
Regards
Dylan
_______________________________________________
cobbler mailing list
cobbler(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/cobbler