This is a neat feature, but takes some explaining. Previously we have been able to support things like memtest through special code, we found the image if installed and added it to certain PXE configs. However you couldn't easily do things like make MAC address AA:BB:CC:DD:EE:FF automatically boot memtest, and so forth.
Now, imagine that special code didn't exist and we could do it generically. Also imagine that we weren't booting something as lame as memtest. What if we could easily boot anything we wanted, just as we can deal with kernels and initrds? Now we can.
cobbler image add --name=SuperAwesomeLiveEnvironment --file=/opt/live.iso
Though we don't have to imagine it, we have this on the devel branch now. Admittedly, I still tested with memtest and not SuperAwesomeLiveEnvironment, though the concept is entirely the same :)
Further, we can do things like assign a specific MAC address to boot that live environment:
cobbler system add --name=fooserver --mac=AA:BB:CC:DD:EE:FF --image=SuperAwesomeLiveEnvironment
The next time that system boots, it will boot that image. This doesn't have to be an installation related image, it might just be a firmware update disk.
Note that I didn't use --profile here, I used --image.
One of cobbler's goals is to be able to break down the abstraction between physical and virtual machines. Here we are able to use "cobbler image" objects (with cobbler/koan 1.1 and later) to do installs both physically and virtually.
The ability to netboot a live-image plays critically into our desire to support net-deploying live image cloning environments, and may also have applications for Stateless environments (LTSP thin clients?).
Note that as with cobbler profiles, you can also assign arbitrary "append" options (i..e kernel options) to images. We could also use this to streamline our existing support to memtest, but since that is already "automatic" and relatively clever (it adds it automatically if you have memtestx86+ installed) we probably will leave that as is.
Anyhow, feel free to test this feature out on the devel branch with any bootable images.
I will say adding this feature was relatively complicated, so with the image support, testing will be very welcome to see if we run into any problems. No changes are in place for any existing profiles or system objects, just note that now systems can also "inherit" from images, or profiles, but not both at the same time.
We still need to update the WebUI to take advantage of these features.
So, please help test this out, and if everything is good we'll see about updating the Wiki to show how to use this with other tools, such as the firmware update images that are already out there... and we can also do some more testing with live environments and maybe even stateless applications.
--Michael
+++ Michael DeHaan [05/08/08 17:40 -0400]: <snip>
So, please help test this out, and if everything is good we'll see about updating the Wiki to show how to use this with other tools, such as the firmware update images that are already out there... and we can also do some more testing with live environments and maybe even stateless applications.
Excellent! I'm looking forward to digging into this now. :)
Michael DeHaan schrieb:
So, please help test this out, and if everything is good we'll see about updating the Wiki to show how to use this with other tools, such as the firmware update images that are already out there... and we can also do some more testing with live environments and maybe even stateless applications.
How does one make an RPM out of a checkout?
When I run rpmbuild on the spec-file, I get:
.... copying snippets/partition_select -> /home/rpmbuild/rpm/tmp/cobbler-1.1.0-1-buildroot/var/lib/cobbler/snippets copying snippets/pre_partition_select -> /home/rpmbuild/rpm/tmp/cobbler-1.1.0-1-buildroot/var/lib/cobbler/snippets copying snippets/main_partition_select -> /home/rpmbuild/rpm/tmp/cobbler-1.1.0-1-buildroot/var/lib/cobbler/snippets creating /home/rpmbuild/rpm/tmp/cobbler-1.1.0-1-buildroot/usr/share creating /home/rpmbuild/rpm/tmp/cobbler-1.1.0-1-buildroot/usr/share/man creating /home/rpmbuild/rpm/tmp/cobbler-1.1.0-1-buildroot/usr/share/man/man1 error: can't copy 'docs/cobbler.1.gz': doesn't exist or not a regular file error: Bad exit status from /home/rpmbuild/rpm/tmp/rpm-tmp.32473 (%install)
Am I missing something? I don't have a spare server, so I'm going to backup what is in /etc/cobbler and /var/lib/cobbler (anything else?) and try to upgrade to the devel-snapshot - does that work?
(We'd like to have this support for booting images - otherwhise I'd most likely not play with this as the stable branch does already more than I use...)
cheers, Rainer
+++ Rainer Duffner [06/08/08 15:04 +0200]:
Michael DeHaan schrieb:
So, please help test this out, and if everything is good we'll see about updating the Wiki to show how to use this with other tools, such as the firmware update images that are already out there... and we can also do some more testing with live environments and maybe even stateless applications.
How does one make an RPM out of a checkout?
When I run rpmbuild on the spec-file, I get:
In your checked out repo, do "make rpms". If you're missing a dependency, it'll tell you (I was missing python-setuptools-devel).
Darryl L. Pierce wrote:
+++ Rainer Duffner [06/08/08 15:04 +0200]:
Michael DeHaan schrieb:
So, please help test this out, and if everything is good we'll see about updating the Wiki to show how to use this with other tools, such as the firmware update images that are already out there... and we can also do some more testing with live environments and maybe even stateless applications.
How does one make an RPM out of a checkout?
When I run rpmbuild on the spec-file, I get:
In your checked out repo, do "make rpms". If you're missing a dependency, it'll tell you (I was missing python-setuptools-devel).
cobbler mailing list cobbler@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/cobbler
Just "make".
rpm's show up in the "rpm-build" subdirectory of the checkout.
--Michael
Michael DeHaan wrote:
This is a neat feature, but takes some explaining. Previously we have been able to support things like memtest through special code, we found the image if installed and added it to certain PXE configs. However you couldn't easily do things like make MAC address AA:BB:CC:DD:EE:FF automatically boot memtest, and so forth.
Now, imagine that special code didn't exist and we could do it generically. Also imagine that we weren't booting something as lame as memtest. What if we could easily boot anything we wanted, just as we can deal with kernels and initrds? Now we can.
cobbler image add --name=SuperAwesomeLiveEnvironment --file=/opt/live.iso
Though we don't have to imagine it, we have this on the devel branch now. Admittedly, I still tested with memtest and not SuperAwesomeLiveEnvironment, though the concept is entirely the same :)
Further, we can do things like assign a specific MAC address to boot that live environment:
cobbler system add --name=fooserver --mac=AA:BB:CC:DD:EE:FF --image=SuperAwesomeLiveEnvironment
The next time that system boots, it will boot that image. This doesn't have to be an installation related image, it might just be a firmware update disk.
Note that I didn't use --profile here, I used --image.
One of cobbler's goals is to be able to break down the abstraction between physical and virtual machines. Here we are able to use "cobbler image" objects (with cobbler/koan 1.1 and later) to do installs both physically and virtually.
The ability to netboot a live-image plays critically into our desire to support net-deploying live image cloning environments, and may also have applications for Stateless environments (LTSP thin clients?).
Note that as with cobbler profiles, you can also assign arbitrary "append" options (i..e kernel options) to images. We could also use this to streamline our existing support to memtest, but since that is already "automatic" and relatively clever (it adds it automatically if you have memtestx86+ installed) we probably will leave that as is.
Anyhow, feel free to test this feature out on the devel branch with any bootable images.
I will say adding this feature was relatively complicated, so with the image support, testing will be very welcome to see if we run into any problems. No changes are in place for any existing profiles or system objects, just note that now systems can also "inherit" from images, or profiles, but not both at the same time.
We still need to update the WebUI to take advantage of these features.
So, please help test this out, and if everything is good we'll see about updating the Wiki to show how to use this with other tools, such as the firmware update images that are already out there... and we can also do some more testing with live environments and maybe even stateless applications.
--Michael
cobbler mailing list cobbler@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/cobbler
It takes more than this to PXE-boot a non-live image.
I'll look into this and have some more instructions on the Wiki later (and others are welcome to add to it once up).
Doing some extra live testing now.
--Michael
An interesting idea for additional functionality behind this would be to enable a "watch folder" in the cobbler directory where ISOs could be dumped with a descriptive filename. Then Cobbler could automatically add them to the PXE menu on a sync.
For example, you could have a few images named:
really_cool_image.iso random_install_image.iso
in a directory like /var/www/html/cobbler/ISO/
and then the menu would have entries that look like:
really_cool_image random_install_image
Since these would have no other integration with the cobbler system, Cobbler would only need to know their location to put them into the PXE menu. This would also make it very easy to allow for updates to the images without requiring any fuss with the Cobbler interface, especially when these ISO images wouldn't be handled with any kickstarting or any of the other nifty features that Cobbler usually takes care of. Thoughts?
~Steven
On Wed, Aug 6, 2008 at 4:28 PM, Michael DeHaan mdehaan@redhat.com wrote:
Michael DeHaan wrote:
This is a neat feature, but takes some explaining. Previously we have been able to support things like memtest through special code, we found the image if installed and added it to certain PXE configs. However you couldn't easily do things like make MAC address AA:BB:CC:DD:EE:FF automatically boot memtest, and so forth.
Now, imagine that special code didn't exist and we could do it generically. Also imagine that we weren't booting something as lame as memtest. What if we could easily boot anything we wanted, just as we can deal with kernels and initrds? Now we can.
cobbler image add --name=SuperAwesomeLiveEnvironment --file=/opt/live.iso
Though we don't have to imagine it, we have this on the devel branch now. Admittedly, I still tested with memtest and not SuperAwesomeLiveEnvironment, though the concept is entirely the same :)
Further, we can do things like assign a specific MAC address to boot that live environment:
cobbler system add --name=fooserver --mac=AA:BB:CC:DD:EE:FF --image=SuperAwesomeLiveEnvironment
The next time that system boots, it will boot that image. This doesn't have to be an installation related image, it might just be a firmware update disk.
Note that I didn't use --profile here, I used --image.
One of cobbler's goals is to be able to break down the abstraction between physical and virtual machines. Here we are able to use "cobbler image" objects (with cobbler/koan 1.1 and later) to do installs both physically and virtually.
The ability to netboot a live-image plays critically into our desire to support net-deploying live image cloning environments, and may also have applications for Stateless environments (LTSP thin clients?).
Note that as with cobbler profiles, you can also assign arbitrary "append" options (i..e kernel options) to images. We could also use this to streamline our existing support to memtest, but since that is already "automatic" and relatively clever (it adds it automatically if you have memtestx86+ installed) we probably will leave that as is.
Anyhow, feel free to test this feature out on the devel branch with any bootable images.
I will say adding this feature was relatively complicated, so with the image support, testing will be very welcome to see if we run into any problems. No changes are in place for any existing profiles or system objects, just note that now systems can also "inherit" from images, or profiles, but not both at the same time.
We still need to update the WebUI to take advantage of these features.
So, please help test this out, and if everything is good we'll see about updating the Wiki to show how to use this with other tools, such as the firmware update images that are already out there... and we can also do some more testing with live environments and maybe even stateless applications.
--Michael
cobbler mailing list cobbler@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/cobbler
It takes more than this to PXE-boot a non-live image.
I'll look into this and have some more instructions on the Wiki later (and others are welcome to add to it once up).
Doing some extra live testing now.
--Michael _______________________________________________ cobbler mailing list cobbler@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/cobbler
Steven W. Carter wrote:
An interesting idea for additional functionality behind this would be to enable a "watch folder" in the cobbler directory where ISOs could be dumped with a descriptive filename. Then Cobbler could automatically add them to the PXE menu on a sync.
For example, you could have a few images named:
really_cool_image.iso random_install_image.iso
in a directory like /var/www/html/cobbler/ISO/
and then the menu would have entries that look like:
really_cool_image random_install_image
Since these would have no other integration with the cobbler system, Cobbler would only need to know their location to put them into the PXE menu. This would also make it very easy to allow for updates to the images without requiring any fuss with the Cobbler interface, especially when these ISO images wouldn't be handled with any kickstarting or any of the other nifty features that Cobbler usually takes care of. Thoughts?
~Steven
Yes, we could easily do something like this ...
I think a first step is being able to flag a cobbler image object for use with memdisk, so you can do "cobbler image add --name=foo --path=/splat/foo.iso --bootmethod=memdisk
Right now if you add an image record it shows up as if it was directly bootable, which is wrong.
The watch directory behavior could then implemented as a cobbler pre-sync trigger.
We currently don't ship many triggers, but we could ship more -- possibly installing all the "potentially useful" triggers in a parallel directory where someone could just create a symlink to enable them.
As I still have more to do with image objects, I'll look into that first part today.
--Michael
On Wed, Aug 6, 2008 at 4:28 PM, Michael DeHaan <mdehaan@redhat.com mailto:mdehaan@redhat.com> wrote:
Michael DeHaan wrote: > This is a neat feature, but takes some explaining. Previously we have > been able to support things like memtest through special code, we found > the image if installed and added it to certain PXE configs. However you > couldn't easily do things like make MAC address AA:BB:CC:DD:EE:FF > automatically boot memtest, and so forth. > > Now, imagine that special code didn't exist and we could do it > generically. Also imagine that we weren't booting something as lame as > memtest. What if we could easily boot anything we wanted, just as we > can deal with kernels and initrds? Now we can. > > cobbler image add --name=SuperAwesomeLiveEnvironment --file=/opt/live.iso > > Though we don't have to imagine it, we have this on the devel branch > now. Admittedly, I still tested with memtest and not > SuperAwesomeLiveEnvironment, though the concept is entirely the same :) > > Further, we can do things like assign a specific MAC address to boot > that live environment: > > cobbler system add --name=fooserver --mac=AA:BB:CC:DD:EE:FF > --image=SuperAwesomeLiveEnvironment > > The next time that system boots, it will boot that image. This doesn't > have to be an installation related image, it might just be a firmware > update disk. > > Note that I didn't use --profile here, I used --image. > > One of cobbler's goals is to be able to break down the abstraction > between physical and virtual machines. Here we are able to use "cobbler > image" objects (with cobbler/koan 1.1 and later) to do installs both > physically and virtually. > > The ability to netboot a live-image plays critically into our desire to > support net-deploying live image cloning environments, and may also have > applications for Stateless environments (LTSP thin clients?). > > Note that as with cobbler profiles, you can also assign arbitrary > "append" options (i..e kernel options) to images. We could also use > this to streamline our existing support to memtest, but since that is > already "automatic" and relatively clever (it adds it automatically if > you have memtestx86+ installed) we probably will leave that as is. > > Anyhow, feel free to test this feature out on the devel branch with any > bootable images. > > I will say adding this feature was relatively complicated, so with the > image support, testing will be very welcome to see if we run into any > problems. No changes are in place for any existing profiles or system > objects, just note that now systems can also "inherit" from images, or > profiles, but not both at the same time. > > We still need to update the WebUI to take advantage of these features. > > So, please help test this out, and if everything is good we'll see about > updating the Wiki to show how to use this with other tools, such as the > firmware update images that are already out there... and we can also do > some more testing with live environments and maybe even stateless > applications. > > --Michael > > _______________________________________________ > cobbler mailing list > cobbler@lists.fedorahosted.org <mailto:cobbler@lists.fedorahosted.org> > https://fedorahosted.org/mailman/listinfo/cobbler > It takes more than this to PXE-boot a non-live image. I'll look into this and have some more instructions on the Wiki later (and others are welcome to add to it once up). Doing some extra live testing now. --Michael _______________________________________________ cobbler mailing list cobbler@lists.fedorahosted.org <mailto:cobbler@lists.fedorahosted.org> https://fedorahosted.org/mailman/listinfo/cobbler
cobbler mailing list cobbler@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/cobbler
Michael DeHaan wrote:
Steven W. Carter wrote:
An interesting idea for additional functionality behind this would be to enable a "watch folder" in the cobbler directory where ISOs could be dumped with a descriptive filename. Then Cobbler could automatically add them to the PXE menu on a sync.
For example, you could have a few images named:
really_cool_image.iso random_install_image.iso
in a directory like /var/www/html/cobbler/ISO/
and then the menu would have entries that look like:
really_cool_image random_install_image
Since these would have no other integration with the cobbler system, Cobbler would only need to know their location to put them into the PXE menu. This would also make it very easy to allow for updates to the images without requiring any fuss with the Cobbler interface, especially when these ISO images wouldn't be handled with any kickstarting or any of the other nifty features that Cobbler usually takes care of. Thoughts?
~Steven
Yes, we could easily do something like this ...
I think a first step is being able to flag a cobbler image object for use with memdisk, so you can do "cobbler image add --name=foo --path=/splat/foo.iso --bootmethod=memdisk
Right now if you add an image record it shows up as if it was directly bootable, which is wrong.
The watch directory behavior could then implemented as a cobbler pre-sync trigger.
We currently don't ship many triggers, but we could ship more -- possibly installing all the "potentially useful" triggers in a parallel directory where someone could just create a symlink to enable them.
As I still have more to do with image objects, I'll look into that first part today.
--Michael
On Wed, Aug 6, 2008 at 4:28 PM, Michael DeHaan <mdehaan@redhat.com mailto:mdehaan@redhat.com> wrote:
Michael DeHaan wrote: > This is a neat feature, but takes some explaining. Previously we have > been able to support things like memtest through special code, we found > the image if installed and added it to certain PXE configs. However you > couldn't easily do things like make MAC address AA:BB:CC:DD:EE:FF > automatically boot memtest, and so forth. > > Now, imagine that special code didn't exist and we could do it > generically. Also imagine that we weren't booting something as lame as > memtest. What if we could easily boot anything we wanted, just as we > can deal with kernels and initrds? Now we can. > > cobbler image add --name=SuperAwesomeLiveEnvironment --file=/opt/live.iso > > Though we don't have to imagine it, we have this on the devel branch > now. Admittedly, I still tested with memtest and not > SuperAwesomeLiveEnvironment, though the concept is entirely the same :) > > Further, we can do things like assign a specific MAC address to boot > that live environment: > > cobbler system add --name=fooserver --mac=AA:BB:CC:DD:EE:FF > --image=SuperAwesomeLiveEnvironment > > The next time that system boots, it will boot that image. This doesn't > have to be an installation related image, it might just be a firmware > update disk. > > Note that I didn't use --profile here, I used --image. > > One of cobbler's goals is to be able to break down the abstraction > between physical and virtual machines. Here we are able to use "cobbler > image" objects (with cobbler/koan 1.1 and later) to do installs both > physically and virtually. > > The ability to netboot a live-image plays critically into our desire to > support net-deploying live image cloning environments, and may also have > applications for Stateless environments (LTSP thin clients?). > > Note that as with cobbler profiles, you can also assign arbitrary > "append" options (i..e kernel options) to images. We could also use > this to streamline our existing support to memtest, but since that is > already "automatic" and relatively clever (it adds it automatically if > you have memtestx86+ installed) we probably will leave that as is. > > Anyhow, feel free to test this feature out on the devel branch with any > bootable images. > > I will say adding this feature was relatively complicated, so with the > image support, testing will be very welcome to see if we run into any > problems. No changes are in place for any existing profiles or system > objects, just note that now systems can also "inherit" from images, or > profiles, but not both at the same time. > > We still need to update the WebUI to take advantage of these features. > > So, please help test this out, and if everything is good we'll see about > updating the Wiki to show how to use this with other tools, such as the > firmware update images that are already out there... and we can also do > some more testing with live environments and maybe even stateless > applications. > > --Michael > > _______________________________________________ > cobbler mailing list > cobbler@lists.fedorahosted.org <mailto:cobbler@lists.fedorahosted.org> > https://fedorahosted.org/mailman/listinfo/cobbler > It takes more than this to PXE-boot a non-live image. I'll look into this and have some more instructions on the Wiki later (and others are welcome to add to it once up). Doing some extra live testing now. --Michael _______________________________________________ cobbler mailing list cobbler@lists.fedorahosted.org <mailto:cobbler@lists.fedorahosted.org> https://fedorahosted.org/mailman/listinfo/cobbler
cobbler mailing list cobbler@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/cobbler
cobbler mailing list cobbler@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/cobbler
Lots of neverending changes/refinements on this.
It looks like "image add/edit" is now going to take an --image-type
Values:
direct # PXEs directly (like "memtest"), does not support virt iso # PXEs via memdisk helper, or supports virt installations virt-clone # for things like virt-cloning, which is not yet supported
If anyone can think of a better word for "direct", please suggest one.
--Michael
Michael DeHaan wrote:
Michael DeHaan wrote:
Steven W. Carter wrote:
An interesting idea for additional functionality behind this would be to enable a "watch folder" in the cobbler directory where ISOs could be dumped with a descriptive filename. Then Cobbler could automatically add them to the PXE menu on a sync.
For example, you could have a few images named:
really_cool_image.iso random_install_image.iso
in a directory like /var/www/html/cobbler/ISO/
and then the menu would have entries that look like:
really_cool_image random_install_image
Since these would have no other integration with the cobbler system, Cobbler would only need to know their location to put them into the PXE menu. This would also make it very easy to allow for updates to the images without requiring any fuss with the Cobbler interface, especially when these ISO images wouldn't be handled with any kickstarting or any of the other nifty features that Cobbler usually takes care of. Thoughts?
~Steven
Yes, we could easily do something like this ...
I think a first step is being able to flag a cobbler image object for use with memdisk, so you can do "cobbler image add --name=foo --path=/splat/foo.iso --bootmethod=memdisk
Right now if you add an image record it shows up as if it was directly bootable, which is wrong.
The watch directory behavior could then implemented as a cobbler pre-sync trigger.
We currently don't ship many triggers, but we could ship more -- possibly installing all the "potentially useful" triggers in a parallel directory where someone could just create a symlink to enable them.
As I still have more to do with image objects, I'll look into that first part today.
--Michael
On Wed, Aug 6, 2008 at 4:28 PM, Michael DeHaan <mdehaan@redhat.com mailto:mdehaan@redhat.com> wrote:
Michael DeHaan wrote: > This is a neat feature, but takes some explaining. Previously we have > been able to support things like memtest through special code, we found > the image if installed and added it to certain PXE configs. However you > couldn't easily do things like make MAC address AA:BB:CC:DD:EE:FF > automatically boot memtest, and so forth. > > Now, imagine that special code didn't exist and we could do it > generically. Also imagine that we weren't booting something as lame as > memtest. What if we could easily boot anything we wanted, just as we > can deal with kernels and initrds? Now we can. > > cobbler image add --name=SuperAwesomeLiveEnvironment --file=/opt/live.iso > > Though we don't have to imagine it, we have this on the devel branch > now. Admittedly, I still tested with memtest and not > SuperAwesomeLiveEnvironment, though the concept is entirely the same :) > > Further, we can do things like assign a specific MAC address to boot > that live environment: > > cobbler system add --name=fooserver --mac=AA:BB:CC:DD:EE:FF > --image=SuperAwesomeLiveEnvironment > > The next time that system boots, it will boot that image. This doesn't > have to be an installation related image, it might just be a firmware > update disk. > > Note that I didn't use --profile here, I used --image. > > One of cobbler's goals is to be able to break down the abstraction > between physical and virtual machines. Here we are able to use "cobbler > image" objects (with cobbler/koan 1.1 and later) to do installs both > physically and virtually. > > The ability to netboot a live-image plays critically into our desire to > support net-deploying live image cloning environments, and may also have > applications for Stateless environments (LTSP thin clients?). > > Note that as with cobbler profiles, you can also assign arbitrary > "append" options (i..e kernel options) to images. We could also use > this to streamline our existing support to memtest, but since that is > already "automatic" and relatively clever (it adds it automatically if > you have memtestx86+ installed) we probably will leave that as is. > > Anyhow, feel free to test this feature out on the devel branch with any > bootable images. > > I will say adding this feature was relatively complicated, so with the > image support, testing will be very welcome to see if we run into any > problems. No changes are in place for any existing profiles or system > objects, just note that now systems can also "inherit" from images, or > profiles, but not both at the same time. > > We still need to update the WebUI to take advantage of these features. > > So, please help test this out, and if everything is good we'll see about > updating the Wiki to show how to use this with other tools, such as the > firmware update images that are already out there... and we can also do > some more testing with live environments and maybe even stateless > applications. > > --Michael > > _______________________________________________ > cobbler mailing list > cobbler@lists.fedorahosted.org <mailto:cobbler@lists.fedorahosted.org> > https://fedorahosted.org/mailman/listinfo/cobbler > It takes more than this to PXE-boot a non-live image. I'll look into this and have some more instructions on the Wiki later (and others are welcome to add to it once up). Doing some extra live testing now. --Michael _______________________________________________ cobbler mailing list cobbler@lists.fedorahosted.org <mailto:cobbler@lists.fedorahosted.org> https://fedorahosted.org/mailman/listinfo/cobbler
cobbler mailing list cobbler@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/cobbler
cobbler mailing list cobbler@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/cobbler
Lots of neverending changes/refinements on this.
It looks like "image add/edit" is now going to take an --image-type
Values:
direct # PXEs directly (like "memtest"), does not support virt iso # PXEs via memdisk helper, or supports virt installations virt-clone # for things like virt-cloning, which is not yet supported
If anyone can think of a better word for "direct", please suggest one.
--Michael
cobbler mailing list cobbler@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/cobbler
memdisk seems a bit unhappy, maybe we end up with "direct, memdisk, live, and virt-clone", and have live know to run livecd-iso-to-pxe if it needs to.
Since Cobbler's job is partly to make dissimilar technology consumable in logical ways, I'm ultimately not sure how far we should go here into smoothing things out. Thoughts welcome and stay tuned ...
--Michael
livecd-iso-to-pxe does some sort of check to determine if the image is in fact a livecd. Could we possible just have three options (direct, iso, virt-clone) and have the iso option first run whatever check livecd-iso-to-pxe uses to determine if it's a live image? Worst case, we could do some janky grepping for the error after it runs the check. That would reduce you from four to only three options.
Additionally, I'm attemping to test this fuctionality (cobbler image add --name=something --file=/path/to/image --image-type=memdisk) but it doesn't output anything to the menu in the boot options. Do I have to do something else to add it to the menu?
On Thu, Aug 7, 2008 at 3:51 PM, Michael DeHaan mdehaan@redhat.com wrote:
Michael DeHaan wrote:
Michael DeHaan wrote:
Steven W. Carter wrote:
An interesting idea for additional functionality behind this would be to enable a "watch folder" in the cobbler directory where ISOs could be dumped with a descriptive filename. Then Cobbler could automatically add them to the PXE menu on a sync.
For example, you could have a few images named:
really_cool_image.iso random_install_image.iso
in a directory like /var/www/html/cobbler/ISO/
and then the menu would have entries that look like:
really_cool_image random_install_image
Since these would have no other integration with the cobbler system, Cobbler would only need to know their location to put them into the PXE menu. This would also make it very easy to allow for updates to the images without requiring any fuss with the Cobbler interface, especially when these ISO images wouldn't be handled with any kickstarting or any of the other nifty features that Cobbler usually takes care of. Thoughts?
~Steven
Yes, we could easily do something like this ...
I think a first step is being able to flag a cobbler image object for use with memdisk, so you can do "cobbler image add --name=foo --path=/splat/foo.iso --bootmethod=memdisk
Right now if you add an image record it shows up as if it was directly bootable, which is wrong.
The watch directory behavior could then implemented as a cobbler pre-sync trigger.
We currently don't ship many triggers, but we could ship more -- possibly installing all the "potentially useful" triggers in a parallel directory where someone could just create a symlink to enable them.
As I still have more to do with image objects, I'll look into that first part today.
--Michael
On Wed, Aug 6, 2008 at 4:28 PM, Michael DeHaan <mdehaan@redhat.com mailto:mdehaan@redhat.com> wrote:
Michael DeHaan wrote: > This is a neat feature, but takes some explaining. Previously we have > been able to support things like memtest through special code, we found > the image if installed and added it to certain PXE configs. However you > couldn't easily do things like make MAC address AA:BB:CC:DD:EE:FF > automatically boot memtest, and so forth. > > Now, imagine that special code didn't exist and we could do it > generically. Also imagine that we weren't booting something as lame as > memtest. What if we could easily boot anything we wanted, just as we > can deal with kernels and initrds? Now we can. > > cobbler image add --name=SuperAwesomeLiveEnvironment --file=/opt/live.iso > > Though we don't have to imagine it, we have this on the devel
branch
> now. Admittedly, I still tested with memtest and not > SuperAwesomeLiveEnvironment, though the concept is entirely the same :) > > Further, we can do things like assign a specific MAC address to
boot
> that live environment: > > cobbler system add --name=fooserver --mac=AA:BB:CC:DD:EE:FF > --image=SuperAwesomeLiveEnvironment > > The next time that system boots, it will boot that image. This doesn't > have to be an installation related image, it might just be a firmware > update disk. > > Note that I didn't use --profile here, I used --image. > > One of cobbler's goals is to be able to break down the
abstraction
> between physical and virtual machines. Here we are able to use "cobbler > image" objects (with cobbler/koan 1.1 and later) to do installs
both
> physically and virtually. > > The ability to netboot a live-image plays critically into our desire to > support net-deploying live image cloning environments, and may also have > applications for Stateless environments (LTSP thin clients?). > > Note that as with cobbler profiles, you can also assign arbitrary > "append" options (i..e kernel options) to images. We could also use > this to streamline our existing support to memtest, but since that is > already "automatic" and relatively clever (it adds it automatically if > you have memtestx86+ installed) we probably will leave that as
is.
> > Anyhow, feel free to test this feature out on the devel branch with any > bootable images. > > I will say adding this feature was relatively complicated, so with the > image support, testing will be very welcome to see if we run into any > problems. No changes are in place for any existing profiles or system > objects, just note that now systems can also "inherit" from images, or > profiles, but not both at the same time. > > We still need to update the WebUI to take advantage of these features. > > So, please help test this out, and if everything is good we'll see about > updating the Wiki to show how to use this with other tools, such as the > firmware update images that are already out there... and we can also do > some more testing with live environments and maybe even stateless > applications. > > --Michael > > _______________________________________________ > cobbler mailing list > cobbler@lists.fedorahosted.org <mailto:cobbler@lists.fedorahosted.org> > https://fedorahosted.org/mailman/listinfo/cobbler > It takes more than this to PXE-boot a non-live image. I'll look into this and have some more instructions on the Wiki
later
(and others are welcome to add to it once up). Doing some extra live testing now. --Michael _______________________________________________ cobbler mailing list cobbler@lists.fedorahosted.org <mailto:
cobbler@lists.fedorahosted.org>
https://fedorahosted.org/mailman/listinfo/cobbler
cobbler mailing list cobbler@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/cobbler
cobbler mailing list cobbler@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/cobbler
Lots of neverending changes/refinements on this.
It looks like "image add/edit" is now going to take an --image-type
Values:
direct # PXEs directly (like "memtest"), does not support virt iso # PXEs via memdisk helper, or supports virt installations virt-clone # for things like virt-cloning, which is not yet supported
If anyone can think of a better word for "direct", please suggest one.
--Michael
cobbler mailing list cobbler@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/cobbler
memdisk seems a bit unhappy, maybe we end up with "direct, memdisk, live, and virt-clone", and have live know to run livecd-iso-to-pxe if it needs to.
Since Cobbler's job is partly to make dissimilar technology consumable in logical ways, I'm ultimately not sure how far we should go here into smoothing things out. Thoughts welcome and stay tuned ...
--Michael
cobbler mailing list cobbler@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/cobbler
Steven W. Carter wrote:
livecd-iso-to-pxe does some sort of check to determine if the image is in fact a livecd. Could we possible just have three options (direct, iso, virt-clone) and have the iso option first run whatever check livecd-iso-to-pxe uses to determine if it's a live image? Worst case, we could do some janky grepping for the error after it runs the check. That would reduce you from four to only three options.
Possibly, the alternative might be doing something like "cobbler liveimport" to automate the distro+profile creation for live ISOs. Currently I'm experiencing problems with getting a full Fedora live ISO to boot over the network, so I want to chase that first. It is probably a problem with the live image itself.
Additionally, I'm attemping to test this fuctionality (cobbler image add --name=something --file=/path/to/image --image-type=memdisk) but it doesn't output anything to the menu in the boot options. Do I have to do something else to add it to the menu?
It is intended to show up, I'll look into this.
--Michael
On Thu, Aug 7, 2008 at 3:51 PM, Michael DeHaan <mdehaan@redhat.com mailto:mdehaan@redhat.com> wrote:
Michael DeHaan wrote: > Michael DeHaan wrote: > >> Steven W. Carter wrote: >> >> >>> An interesting idea for additional functionality behind this would be >>> to enable a "watch folder" in the cobbler directory where ISOs could >>> be dumped with a descriptive filename. Then Cobbler could >>> automatically add them to the PXE menu on a sync. >>> >>> For example, you could have a few images named: >>> >>> really_cool_image.iso >>> random_install_image.iso >>> >>> in a directory like /var/www/html/cobbler/ISO/ >>> >>> and then the menu would have entries that look like: >>> >>> really_cool_image >>> random_install_image >>> >>> Since these would have no other integration with the cobbler system, >>> Cobbler would only need to know their location to put them into the >>> PXE menu. This would also make it very easy to allow for updates to >>> the images without requiring any fuss with the Cobbler interface, >>> especially when these ISO images wouldn't be handled with any >>> kickstarting or any of the other nifty features that Cobbler usually >>> takes care of. Thoughts? >>> >>> ~Steven >>> >>> >> Yes, we could easily do something like this ... >> >> I think a first step is being able to flag a cobbler image object for >> use with memdisk, so you can do "cobbler image add --name=foo >> --path=/splat/foo.iso --bootmethod=memdisk >> >> Right now if you add an image record it shows up as if it was directly >> bootable, which is wrong. >> >> The watch directory behavior could then implemented as a cobbler >> pre-sync trigger. >> >> We currently don't ship many triggers, but we could ship more -- >> possibly installing all the "potentially useful" triggers in a parallel >> directory where someone could just create a symlink to enable them. >> >> As I still have more to do with image objects, I'll look into that first >> part today. >> >> --Michael >> >> >> >> >> >>> On Wed, Aug 6, 2008 at 4:28 PM, Michael DeHaan <mdehaan@redhat.com <mailto:mdehaan@redhat.com> >>> <mailto:mdehaan@redhat.com <mailto:mdehaan@redhat.com>>> wrote: >>> >>> Michael DeHaan wrote: >>> > This is a neat feature, but takes some explaining. Previously >>> we have >>> > been able to support things like memtest through special code, >>> we found >>> > the image if installed and added it to certain PXE configs. >>> However you >>> > couldn't easily do things like make MAC address AA:BB:CC:DD:EE:FF >>> > automatically boot memtest, and so forth. >>> > >>> > Now, imagine that special code didn't exist and we could do it >>> > generically. Also imagine that we weren't booting something as >>> lame as >>> > memtest. What if we could easily boot anything we wanted, just >>> as we >>> > can deal with kernels and initrds? Now we can. >>> > >>> > cobbler image add --name=SuperAwesomeLiveEnvironment >>> --file=/opt/live.iso >>> > >>> > Though we don't have to imagine it, we have this on the devel branch >>> > now. Admittedly, I still tested with memtest and not >>> > SuperAwesomeLiveEnvironment, though the concept is entirely the >>> same :) >>> > >>> > Further, we can do things like assign a specific MAC address to boot >>> > that live environment: >>> > >>> > cobbler system add --name=fooserver --mac=AA:BB:CC:DD:EE:FF >>> > --image=SuperAwesomeLiveEnvironment >>> > >>> > The next time that system boots, it will boot that image. This >>> doesn't >>> > have to be an installation related image, it might just be a >>> firmware >>> > update disk. >>> > >>> > Note that I didn't use --profile here, I used --image. >>> > >>> > One of cobbler's goals is to be able to break down the abstraction >>> > between physical and virtual machines. Here we are able to use >>> "cobbler >>> > image" objects (with cobbler/koan 1.1 and later) to do installs both >>> > physically and virtually. >>> > >>> > The ability to netboot a live-image plays critically into our >>> desire to >>> > support net-deploying live image cloning environments, and may >>> also have >>> > applications for Stateless environments (LTSP thin clients?). >>> > >>> > Note that as with cobbler profiles, you can also assign arbitrary >>> > "append" options (i..e kernel options) to images. We could >>> also use >>> > this to streamline our existing support to memtest, but since >>> that is >>> > already "automatic" and relatively clever (it adds it >>> automatically if >>> > you have memtestx86+ installed) we probably will leave that as is. >>> > >>> > Anyhow, feel free to test this feature out on the devel branch >>> with any >>> > bootable images. >>> > >>> > I will say adding this feature was relatively complicated, so >>> with the >>> > image support, testing will be very welcome to see if we run >>> into any >>> > problems. No changes are in place for any existing profiles or >>> system >>> > objects, just note that now systems can also "inherit" from >>> images, or >>> > profiles, but not both at the same time. >>> > >>> > We still need to update the WebUI to take advantage of these >>> features. >>> > >>> > So, please help test this out, and if everything is good we'll >>> see about >>> > updating the Wiki to show how to use this with other tools, such >>> as the >>> > firmware update images that are already out there... and we can >>> also do >>> > some more testing with live environments and maybe even stateless >>> > applications. >>> > >>> > --Michael >>> > >>> > _______________________________________________ >>> > cobbler mailing list >>> > cobbler@lists.fedorahosted.org <mailto:cobbler@lists.fedorahosted.org> >>> <mailto:cobbler@lists.fedorahosted.org <mailto:cobbler@lists.fedorahosted.org>> >>> > https://fedorahosted.org/mailman/listinfo/cobbler >>> > >>> >>> It takes more than this to PXE-boot a non-live image. >>> >>> I'll look into this and have some more instructions on the Wiki later >>> (and others are welcome to add to it once up). >>> >>> Doing some extra live testing now. >>> >>> --Michael >>> _______________________________________________ >>> cobbler mailing list >>> cobbler@lists.fedorahosted.org <mailto:cobbler@lists.fedorahosted.org> <mailto:cobbler@lists.fedorahosted.org <mailto:cobbler@lists.fedorahosted.org>> >>> https://fedorahosted.org/mailman/listinfo/cobbler >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> cobbler mailing list >>> cobbler@lists.fedorahosted.org <mailto:cobbler@lists.fedorahosted.org> >>> https://fedorahosted.org/mailman/listinfo/cobbler >>> >>> >>> >> _______________________________________________ >> cobbler mailing list >> cobbler@lists.fedorahosted.org <mailto:cobbler@lists.fedorahosted.org> >> https://fedorahosted.org/mailman/listinfo/cobbler >> >> > > Lots of neverending changes/refinements on this. > > It looks like "image add/edit" is now going to take an --image-type > > Values: > > direct # PXEs directly (like "memtest"), does not support virt > iso # PXEs via memdisk helper, or supports virt installations > virt-clone # for things like virt-cloning, which is not yet supported > > If anyone can think of a better word for "direct", please suggest one. > > --Michael > > > > > _______________________________________________ > cobbler mailing list > cobbler@lists.fedorahosted.org <mailto:cobbler@lists.fedorahosted.org> > https://fedorahosted.org/mailman/listinfo/cobbler > memdisk seems a bit unhappy, maybe we end up with "direct, memdisk, live, and virt-clone", and have live know to run livecd-iso-to-pxe if it needs to. Since Cobbler's job is partly to make dissimilar technology consumable in logical ways, I'm ultimately not sure how far we should go here into smoothing things out. Thoughts welcome and stay tuned ... --Michael _______________________________________________ cobbler mailing list cobbler@lists.fedorahosted.org <mailto:cobbler@lists.fedorahosted.org> https://fedorahosted.org/mailman/listinfo/cobbler
cobbler mailing list cobbler@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/cobbler
Steven W. Carter wrote:
livecd-iso-to-pxe does some sort of check to determine if the image is in fact a livecd. Could we possible just have three options (direct, iso, virt-clone) and have the iso option first run whatever check livecd-iso-to-pxe uses to determine if it's a live image? Worst case, we could do some janky grepping for the error after it runs the check. That would reduce you from four to only three options.
Additionally, I'm attemping to test this fuctionality (cobbler image add --name=something --file=/path/to/image --image-type=memdisk) but it doesn't output anything to the menu in the boot options. Do I have to do something else to add it to the menu?
There were some typos in the way that the objects were being saved that kept the type from sticking. Also some other bits that were causing problems with the "direct" type. Both of these items should now be resolved on the devel branch.
On Thu, Aug 7, 2008 at 3:51 PM, Michael DeHaan <mdehaan@redhat.com mailto:mdehaan@redhat.com> wrote:
Michael DeHaan wrote: > Michael DeHaan wrote: > >> Steven W. Carter wrote: >> >> >>> An interesting idea for additional functionality behind this would be >>> to enable a "watch folder" in the cobbler directory where ISOs could >>> be dumped with a descriptive filename. Then Cobbler could >>> automatically add them to the PXE menu on a sync. >>> >>> For example, you could have a few images named: >>> >>> really_cool_image.iso >>> random_install_image.iso >>> >>> in a directory like /var/www/html/cobbler/ISO/ >>> >>> and then the menu would have entries that look like: >>> >>> really_cool_image >>> random_install_image >>> >>> Since these would have no other integration with the cobbler system, >>> Cobbler would only need to know their location to put them into the >>> PXE menu. This would also make it very easy to allow for updates to >>> the images without requiring any fuss with the Cobbler interface, >>> especially when these ISO images wouldn't be handled with any >>> kickstarting or any of the other nifty features that Cobbler usually >>> takes care of. Thoughts? >>> >>> ~Steven >>> >>> >> Yes, we could easily do something like this ... >> >> I think a first step is being able to flag a cobbler image object for >> use with memdisk, so you can do "cobbler image add --name=foo >> --path=/splat/foo.iso --bootmethod=memdisk >> >> Right now if you add an image record it shows up as if it was directly >> bootable, which is wrong. >> >> The watch directory behavior could then implemented as a cobbler >> pre-sync trigger. >> >> We currently don't ship many triggers, but we could ship more -- >> possibly installing all the "potentially useful" triggers in a parallel >> directory where someone could just create a symlink to enable them. >> >> As I still have more to do with image objects, I'll look into that first >> part today. >> >> --Michael >> >> >> >> >> >>> On Wed, Aug 6, 2008 at 4:28 PM, Michael DeHaan <mdehaan@redhat.com <mailto:mdehaan@redhat.com> >>> <mailto:mdehaan@redhat.com <mailto:mdehaan@redhat.com>>> wrote: >>> >>> Michael DeHaan wrote: >>> > This is a neat feature, but takes some explaining. Previously >>> we have >>> > been able to support things like memtest through special code, >>> we found >>> > the image if installed and added it to certain PXE configs. >>> However you >>> > couldn't easily do things like make MAC address AA:BB:CC:DD:EE:FF >>> > automatically boot memtest, and so forth. >>> > >>> > Now, imagine that special code didn't exist and we could do it >>> > generically. Also imagine that we weren't booting something as >>> lame as >>> > memtest. What if we could easily boot anything we wanted, just >>> as we >>> > can deal with kernels and initrds? Now we can. >>> > >>> > cobbler image add --name=SuperAwesomeLiveEnvironment >>> --file=/opt/live.iso >>> > >>> > Though we don't have to imagine it, we have this on the devel branch >>> > now. Admittedly, I still tested with memtest and not >>> > SuperAwesomeLiveEnvironment, though the concept is entirely the >>> same :) >>> > >>> > Further, we can do things like assign a specific MAC address to boot >>> > that live environment: >>> > >>> > cobbler system add --name=fooserver --mac=AA:BB:CC:DD:EE:FF >>> > --image=SuperAwesomeLiveEnvironment >>> > >>> > The next time that system boots, it will boot that image. This >>> doesn't >>> > have to be an installation related image, it might just be a >>> firmware >>> > update disk. >>> > >>> > Note that I didn't use --profile here, I used --image. >>> > >>> > One of cobbler's goals is to be able to break down the abstraction >>> > between physical and virtual machines. Here we are able to use >>> "cobbler >>> > image" objects (with cobbler/koan 1.1 and later) to do installs both >>> > physically and virtually. >>> > >>> > The ability to netboot a live-image plays critically into our >>> desire to >>> > support net-deploying live image cloning environments, and may >>> also have >>> > applications for Stateless environments (LTSP thin clients?). >>> > >>> > Note that as with cobbler profiles, you can also assign arbitrary >>> > "append" options (i..e kernel options) to images. We could >>> also use >>> > this to streamline our existing support to memtest, but since >>> that is >>> > already "automatic" and relatively clever (it adds it >>> automatically if >>> > you have memtestx86+ installed) we probably will leave that as is. >>> > >>> > Anyhow, feel free to test this feature out on the devel branch >>> with any >>> > bootable images. >>> > >>> > I will say adding this feature was relatively complicated, so >>> with the >>> > image support, testing will be very welcome to see if we run >>> into any >>> > problems. No changes are in place for any existing profiles or >>> system >>> > objects, just note that now systems can also "inherit" from >>> images, or >>> > profiles, but not both at the same time. >>> > >>> > We still need to update the WebUI to take advantage of these >>> features. >>> > >>> > So, please help test this out, and if everything is good we'll >>> see about >>> > updating the Wiki to show how to use this with other tools, such >>> as the >>> > firmware update images that are already out there... and we can >>> also do >>> > some more testing with live environments and maybe even stateless >>> > applications. >>> > >>> > --Michael >>> > >>> > _______________________________________________ >>> > cobbler mailing list >>> > cobbler@lists.fedorahosted.org <mailto:cobbler@lists.fedorahosted.org> >>> <mailto:cobbler@lists.fedorahosted.org <mailto:cobbler@lists.fedorahosted.org>> >>> > https://fedorahosted.org/mailman/listinfo/cobbler >>> > >>> >>> It takes more than this to PXE-boot a non-live image. >>> >>> I'll look into this and have some more instructions on the Wiki later >>> (and others are welcome to add to it once up). >>> >>> Doing some extra live testing now. >>> >>> --Michael >>> _______________________________________________ >>> cobbler mailing list >>> cobbler@lists.fedorahosted.org <mailto:cobbler@lists.fedorahosted.org> <mailto:cobbler@lists.fedorahosted.org <mailto:cobbler@lists.fedorahosted.org>> >>> https://fedorahosted.org/mailman/listinfo/cobbler >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> cobbler mailing list >>> cobbler@lists.fedorahosted.org <mailto:cobbler@lists.fedorahosted.org> >>> https://fedorahosted.org/mailman/listinfo/cobbler >>> >>> >>> >> _______________________________________________ >> cobbler mailing list >> cobbler@lists.fedorahosted.org <mailto:cobbler@lists.fedorahosted.org> >> https://fedorahosted.org/mailman/listinfo/cobbler >> >> > > Lots of neverending changes/refinements on this. > > It looks like "image add/edit" is now going to take an --image-type > > Values: > > direct # PXEs directly (like "memtest"), does not support virt > iso # PXEs via memdisk helper, or supports virt installations > virt-clone # for things like virt-cloning, which is not yet supported > > If anyone can think of a better word for "direct", please suggest one. > > --Michael > > > > > _______________________________________________ > cobbler mailing list > cobbler@lists.fedorahosted.org <mailto:cobbler@lists.fedorahosted.org> > https://fedorahosted.org/mailman/listinfo/cobbler > memdisk seems a bit unhappy, maybe we end up with "direct, memdisk, live, and virt-clone", and have live know to run livecd-iso-to-pxe if it needs to. Since Cobbler's job is partly to make dissimilar technology consumable in logical ways, I'm ultimately not sure how far we should go here into smoothing things out. Thoughts welcome and stay tuned ... --Michael _______________________________________________ cobbler mailing list cobbler@lists.fedorahosted.org <mailto:cobbler@lists.fedorahosted.org> https://fedorahosted.org/mailman/listinfo/cobbler
cobbler mailing list cobbler@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/cobbler
I've noticed that when the images are copied over to the images2 directory they keep the source permissions. Also, I am currently playing around with using memdisk to boot an ISO image. I'll update with my successes, and then hopefully patch the section of the pxe-writing configuration to enable this functionality. (or I'll just submit the patch since I've never used git)
On Tue, Aug 12, 2008 at 12:43 PM, Michael DeHaan mdehaan@redhat.com wrote:
Steven W. Carter wrote:
livecd-iso-to-pxe does some sort of check to determine if the image is in fact a livecd. Could we possible just have three options (direct, iso, virt-clone) and have the iso option first run whatever check livecd-iso-to-pxe uses to determine if it's a live image? Worst case, we could do some janky grepping for the error after it runs the check. That would reduce you from four to only three options.
Additionally, I'm attemping to test this fuctionality (cobbler image add --name=something --file=/path/to/image --image-type=memdisk) but it doesn't output anything to the menu in the boot options. Do I have to do something else to add it to the menu?
There were some typos in the way that the objects were being saved that kept the type from sticking. Also some other bits that were causing problems with the "direct" type. Both of these items should now be resolved on the devel branch.
On Thu, Aug 7, 2008 at 3:51 PM, Michael DeHaan <mdehaan@redhat.com mailto:mdehaan@redhat.com> wrote:
Michael DeHaan wrote: > Michael DeHaan wrote: > >> Steven W. Carter wrote: >> >> >>> An interesting idea for additional functionality behind this would be >>> to enable a "watch folder" in the cobbler directory where ISOs could >>> be dumped with a descriptive filename. Then Cobbler could >>> automatically add them to the PXE menu on a sync. >>> >>> For example, you could have a few images named: >>> >>> really_cool_image.iso >>> random_install_image.iso >>> >>> in a directory like /var/www/html/cobbler/ISO/ >>> >>> and then the menu would have entries that look like: >>> >>> really_cool_image >>> random_install_image >>> >>> Since these would have no other integration with the cobbler system, >>> Cobbler would only need to know their location to put them into the >>> PXE menu. This would also make it very easy to allow for updates to >>> the images without requiring any fuss with the Cobbler interface, >>> especially when these ISO images wouldn't be handled with any >>> kickstarting or any of the other nifty features that Cobbler usually >>> takes care of. Thoughts? >>> >>> ~Steven >>> >>> >> Yes, we could easily do something like this ... >> >> I think a first step is being able to flag a cobbler image object for >> use with memdisk, so you can do "cobbler image add --name=foo >> --path=/splat/foo.iso --bootmethod=memdisk >> >> Right now if you add an image record it shows up as if it was directly >> bootable, which is wrong. >> >> The watch directory behavior could then implemented as a cobbler >> pre-sync trigger. >> >> We currently don't ship many triggers, but we could ship more -- >> possibly installing all the "potentially useful" triggers in a parallel >> directory where someone could just create a symlink to enable
them.
>> >> As I still have more to do with image objects, I'll look into that first >> part today. >> >> --Michael >> >> >> >> >> >>> On Wed, Aug 6, 2008 at 4:28 PM, Michael DeHaan <mdehaan@redhat.com <mailto:mdehaan@redhat.com> >>> <mailto:mdehaan@redhat.com <mailto:mdehaan@redhat.com>>> wrote: >>> >>> Michael DeHaan wrote: >>> > This is a neat feature, but takes some explaining. Previously >>> we have >>> > been able to support things like memtest through special code, >>> we found >>> > the image if installed and added it to certain PXE configs. >>> However you >>> > couldn't easily do things like make MAC address AA:BB:CC:DD:EE:FF >>> > automatically boot memtest, and so forth. >>> > >>> > Now, imagine that special code didn't exist and we could do it >>> > generically. Also imagine that we weren't booting something as >>> lame as >>> > memtest. What if we could easily boot anything we wanted, just >>> as we >>> > can deal with kernels and initrds? Now we can. >>> > >>> > cobbler image add --name=SuperAwesomeLiveEnvironment >>> --file=/opt/live.iso >>> > >>> > Though we don't have to imagine it, we have this on the devel branch >>> > now. Admittedly, I still tested with memtest and not >>> > SuperAwesomeLiveEnvironment, though the concept is entirely the >>> same :) >>> > >>> > Further, we can do things like assign a specific MAC address to boot >>> > that live environment: >>> > >>> > cobbler system add --name=fooserver --mac=AA:BB:CC:DD:EE:FF >>> > --image=SuperAwesomeLiveEnvironment >>> > >>> > The next time that system boots, it will boot that image. This >>> doesn't >>> > have to be an installation related image, it might just be
a
>>> firmware >>> > update disk. >>> > >>> > Note that I didn't use --profile here, I used --image. >>> > >>> > One of cobbler's goals is to be able to break down the abstraction >>> > between physical and virtual machines. Here we are able to use >>> "cobbler >>> > image" objects (with cobbler/koan 1.1 and later) to do installs both >>> > physically and virtually. >>> > >>> > The ability to netboot a live-image plays critically into our >>> desire to >>> > support net-deploying live image cloning environments, and may >>> also have >>> > applications for Stateless environments (LTSP thin clients?). >>> > >>> > Note that as with cobbler profiles, you can also assign arbitrary >>> > "append" options (i..e kernel options) to images. We
could
>>> also use >>> > this to streamline our existing support to memtest, but since >>> that is >>> > already "automatic" and relatively clever (it adds it >>> automatically if >>> > you have memtestx86+ installed) we probably will leave that as is. >>> > >>> > Anyhow, feel free to test this feature out on the devel branch >>> with any >>> > bootable images. >>> > >>> > I will say adding this feature was relatively complicated, so >>> with the >>> > image support, testing will be very welcome to see if we
run
>>> into any >>> > problems. No changes are in place for any existing profiles or >>> system >>> > objects, just note that now systems can also "inherit" from >>> images, or >>> > profiles, but not both at the same time. >>> > >>> > We still need to update the WebUI to take advantage of
these
>>> features. >>> > >>> > So, please help test this out, and if everything is good we'll >>> see about >>> > updating the Wiki to show how to use this with other tools, such >>> as the >>> > firmware update images that are already out there... and we can >>> also do >>> > some more testing with live environments and maybe even stateless >>> > applications. >>> > >>> > --Michael >>> > >>> > _______________________________________________ >>> > cobbler mailing list >>> > cobbler@lists.fedorahosted.org <mailto:cobbler@lists.fedorahosted.org> >>> <mailto:cobbler@lists.fedorahosted.org <mailto:cobbler@lists.fedorahosted.org>> >>> > https://fedorahosted.org/mailman/listinfo/cobbler >>> > >>> >>> It takes more than this to PXE-boot a non-live image. >>> >>> I'll look into this and have some more instructions on the Wiki later >>> (and others are welcome to add to it once up). >>> >>> Doing some extra live testing now. >>> >>> --Michael >>> _______________________________________________ >>> cobbler mailing list >>> cobbler@lists.fedorahosted.org <mailto:cobbler@lists.fedorahosted.org> <mailto:cobbler@lists.fedorahosted.org <mailto:cobbler@lists.fedorahosted.org>> >>> https://fedorahosted.org/mailman/listinfo/cobbler >>> >>> >>>
>>> >>> _______________________________________________ >>> cobbler mailing list >>> cobbler@lists.fedorahosted.org <mailto:cobbler@lists.fedorahosted.org> >>> https://fedorahosted.org/mailman/listinfo/cobbler >>> >>> >>> >> _______________________________________________ >> cobbler mailing list >> cobbler@lists.fedorahosted.org <mailto:cobbler@lists.fedorahosted.org> >> https://fedorahosted.org/mailman/listinfo/cobbler >> >> > > Lots of neverending changes/refinements on this. > > It looks like "image add/edit" is now going to take an --image-type > > Values: > > direct # PXEs directly (like "memtest"), does not support virt > iso # PXEs via memdisk helper, or supports virt installations > virt-clone # for things like virt-cloning, which is not yet supported > > If anyone can think of a better word for "direct", please suggest one. > > --Michael > > > > > _______________________________________________ > cobbler mailing list > cobbler@lists.fedorahosted.org <mailto:cobbler@lists.fedorahosted.org> > https://fedorahosted.org/mailman/listinfo/cobbler > memdisk seems a bit unhappy, maybe we end up with "direct, memdisk, live, and virt-clone", and have live know to run livecd-iso-to-pxe if it needs to. Since Cobbler's job is partly to make dissimilar technology
consumable
in logical ways, I'm ultimately not sure how far we should go here into smoothing things out. Thoughts welcome and stay tuned ... --Michael _______________________________________________ cobbler mailing list cobbler@lists.fedorahosted.org <mailto:
cobbler@lists.fedorahosted.org>
https://fedorahosted.org/mailman/listinfo/cobbler
cobbler mailing list cobbler@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/cobbler
cobbler mailing list cobbler@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/cobbler
Steven W. Carter wrote:
I've noticed that when the images are copied over to the images2 directory they keep the source permissions. Also, I am currently playing around with using memdisk to boot an ISO image. I'll update with my successes, and then hopefully patch the section of the pxe-writing configuration to enable this functionality. (or I'll just submit the patch since I've never used git)
That's fine.
From what I found, memdisk is intented to boot disk images and might not be usable to directly boot an ISO. This is why for the live CD we have livecd-iso-to-pxeboot.
As for "images2", that's probably because it's missing from the cobbler specfile. I can take care of that. Thanks for the heads up!
--Michael
On Tue, Aug 12, 2008 at 12:43 PM, Michael DeHaan <mdehaan@redhat.com mailto:mdehaan@redhat.com> wrote:
Steven W. Carter wrote: > livecd-iso-to-pxe does some sort of check to determine if the image is > in fact a livecd. Could we possible just have three options (direct, > iso, virt-clone) and have the iso option first run whatever check > livecd-iso-to-pxe uses to determine if it's a live image? Worst case, > we could do some janky grepping for the error after it runs the > check. That would reduce you from four to only three options. > > Additionally, I'm attemping to test this fuctionality (cobbler image > add --name=something --file=/path/to/image --image-type=memdisk) but > it doesn't output anything to the menu in the boot options. Do I have > to do something else to add it to the menu? There were some typos in the way that the objects were being saved that kept the type from sticking. Also some other bits that were causing problems with the "direct" type. Both of these items should now be resolved on the devel branch. > > On Thu, Aug 7, 2008 at 3:51 PM, Michael DeHaan <mdehaan@redhat.com <mailto:mdehaan@redhat.com> > <mailto:mdehaan@redhat.com <mailto:mdehaan@redhat.com>>> wrote: > > Michael DeHaan wrote: > > Michael DeHaan wrote: > > > >> Steven W. Carter wrote: > >> > >> > >>> An interesting idea for additional functionality behind this > would be > >>> to enable a "watch folder" in the cobbler directory where ISOs > could > >>> be dumped with a descriptive filename. Then Cobbler could > >>> automatically add them to the PXE menu on a sync. > >>> > >>> For example, you could have a few images named: > >>> > >>> really_cool_image.iso > >>> random_install_image.iso > >>> > >>> in a directory like /var/www/html/cobbler/ISO/ > >>> > >>> and then the menu would have entries that look like: > >>> > >>> really_cool_image > >>> random_install_image > >>> > >>> Since these would have no other integration with the cobbler > system, > >>> Cobbler would only need to know their location to put them > into the > >>> PXE menu. This would also make it very easy to allow for > updates to > >>> the images without requiring any fuss with the Cobbler interface, > >>> especially when these ISO images wouldn't be handled with any > >>> kickstarting or any of the other nifty features that Cobbler > usually > >>> takes care of. Thoughts? > >>> > >>> ~Steven > >>> > >>> > >> Yes, we could easily do something like this ... > >> > >> I think a first step is being able to flag a cobbler image > object for > >> use with memdisk, so you can do "cobbler image add --name=foo > >> --path=/splat/foo.iso --bootmethod=memdisk > >> > >> Right now if you add an image record it shows up as if it was > directly > >> bootable, which is wrong. > >> > >> The watch directory behavior could then implemented as a cobbler > >> pre-sync trigger. > >> > >> We currently don't ship many triggers, but we could ship more -- > >> possibly installing all the "potentially useful" triggers in a > parallel > >> directory where someone could just create a symlink to enable them. > >> > >> As I still have more to do with image objects, I'll look into > that first > >> part today. > >> > >> --Michael > >> > >> > >> > >> > >> > >>> On Wed, Aug 6, 2008 at 4:28 PM, Michael DeHaan > <mdehaan@redhat.com <mailto:mdehaan@redhat.com> <mailto:mdehaan@redhat.com <mailto:mdehaan@redhat.com>> > >>> <mailto:mdehaan@redhat.com <mailto:mdehaan@redhat.com> <mailto:mdehaan@redhat.com <mailto:mdehaan@redhat.com>>>> wrote: > >>> > >>> Michael DeHaan wrote: > >>> > This is a neat feature, but takes some explaining. > Previously > >>> we have > >>> > been able to support things like memtest through special > code, > >>> we found > >>> > the image if installed and added it to certain PXE configs. > >>> However you > >>> > couldn't easily do things like make MAC address > AA:BB:CC:DD:EE:FF > >>> > automatically boot memtest, and so forth. > >>> > > >>> > Now, imagine that special code didn't exist and we could > do it > >>> > generically. Also imagine that we weren't booting > something as > >>> lame as > >>> > memtest. What if we could easily boot anything we > wanted, just > >>> as we > >>> > can deal with kernels and initrds? Now we can. > >>> > > >>> > cobbler image add --name=SuperAwesomeLiveEnvironment > >>> --file=/opt/live.iso > >>> > > >>> > Though we don't have to imagine it, we have this on the > devel branch > >>> > now. Admittedly, I still tested with memtest and not > >>> > SuperAwesomeLiveEnvironment, though the concept is > entirely the > >>> same :) > >>> > > >>> > Further, we can do things like assign a specific MAC > address to boot > >>> > that live environment: > >>> > > >>> > cobbler system add --name=fooserver --mac=AA:BB:CC:DD:EE:FF > >>> > --image=SuperAwesomeLiveEnvironment > >>> > > >>> > The next time that system boots, it will boot that > image. This > >>> doesn't > >>> > have to be an installation related image, it might just be a > >>> firmware > >>> > update disk. > >>> > > >>> > Note that I didn't use --profile here, I used --image. > >>> > > >>> > One of cobbler's goals is to be able to break down the > abstraction > >>> > between physical and virtual machines. Here we are able > to use > >>> "cobbler > >>> > image" objects (with cobbler/koan 1.1 and later) to do > installs both > >>> > physically and virtually. > >>> > > >>> > The ability to netboot a live-image plays critically > into our > >>> desire to > >>> > support net-deploying live image cloning environments, > and may > >>> also have > >>> > applications for Stateless environments (LTSP thin > clients?). > >>> > > >>> > Note that as with cobbler profiles, you can also assign > arbitrary > >>> > "append" options (i..e kernel options) to images. We could > >>> also use > >>> > this to streamline our existing support to memtest, but > since > >>> that is > >>> > already "automatic" and relatively clever (it adds it > >>> automatically if > >>> > you have memtestx86+ installed) we probably will leave > that as is. > >>> > > >>> > Anyhow, feel free to test this feature out on the devel > branch > >>> with any > >>> > bootable images. > >>> > > >>> > I will say adding this feature was relatively > complicated, so > >>> with the > >>> > image support, testing will be very welcome to see if we run > >>> into any > >>> > problems. No changes are in place for any existing > profiles or > >>> system > >>> > objects, just note that now systems can also "inherit" from > >>> images, or > >>> > profiles, but not both at the same time. > >>> > > >>> > We still need to update the WebUI to take advantage of these > >>> features. > >>> > > >>> > So, please help test this out, and if everything is good > we'll > >>> see about > >>> > updating the Wiki to show how to use this with other > tools, such > >>> as the > >>> > firmware update images that are already out there... and > we can > >>> also do > >>> > some more testing with live environments and maybe even > stateless > >>> > applications. > >>> > > >>> > --Michael > >>> > > >>> > _______________________________________________ > >>> > cobbler mailing list > >>> > cobbler@lists.fedorahosted.org <mailto:cobbler@lists.fedorahosted.org> > <mailto:cobbler@lists.fedorahosted.org <mailto:cobbler@lists.fedorahosted.org>> > >>> <mailto:cobbler@lists.fedorahosted.org <mailto:cobbler@lists.fedorahosted.org> > <mailto:cobbler@lists.fedorahosted.org <mailto:cobbler@lists.fedorahosted.org>>> > >>> > https://fedorahosted.org/mailman/listinfo/cobbler > >>> > > >>> > >>> It takes more than this to PXE-boot a non-live image. > >>> > >>> I'll look into this and have some more instructions on the > Wiki later > >>> (and others are welcome to add to it once up). > >>> > >>> Doing some extra live testing now. > >>> > >>> --Michael > >>> _______________________________________________ > >>> cobbler mailing list > >>> cobbler@lists.fedorahosted.org <mailto:cobbler@lists.fedorahosted.org> > <mailto:cobbler@lists.fedorahosted.org <mailto:cobbler@lists.fedorahosted.org>> > <mailto:cobbler@lists.fedorahosted.org <mailto:cobbler@lists.fedorahosted.org> > <mailto:cobbler@lists.fedorahosted.org <mailto:cobbler@lists.fedorahosted.org>>> > >>> https://fedorahosted.org/mailman/listinfo/cobbler > >>> > >>> > >>> > ------------------------------------------------------------------------ > >>> > >>> _______________________________________________ > >>> cobbler mailing list > >>> cobbler@lists.fedorahosted.org <mailto:cobbler@lists.fedorahosted.org> > <mailto:cobbler@lists.fedorahosted.org <mailto:cobbler@lists.fedorahosted.org>> > >>> https://fedorahosted.org/mailman/listinfo/cobbler > >>> > >>> > >>> > >> _______________________________________________ > >> cobbler mailing list > >> cobbler@lists.fedorahosted.org <mailto:cobbler@lists.fedorahosted.org> > <mailto:cobbler@lists.fedorahosted.org <mailto:cobbler@lists.fedorahosted.org>> > >> https://fedorahosted.org/mailman/listinfo/cobbler > >> > >> > > > > Lots of neverending changes/refinements on this. > > > > It looks like "image add/edit" is now going to take an --image-type > > > > Values: > > > > direct # PXEs directly (like "memtest"), does not support virt > > iso # PXEs via memdisk helper, or supports virt installations > > virt-clone # for things like virt-cloning, which is not yet > supported > > > > If anyone can think of a better word for "direct", please > suggest one. > > > > --Michael > > > > > > > > > > _______________________________________________ > > cobbler mailing list > > cobbler@lists.fedorahosted.org <mailto:cobbler@lists.fedorahosted.org> > <mailto:cobbler@lists.fedorahosted.org <mailto:cobbler@lists.fedorahosted.org>> > > https://fedorahosted.org/mailman/listinfo/cobbler > > > > memdisk seems a bit unhappy, maybe we end up with "direct, memdisk, > live, and virt-clone", and have live know to run livecd-iso-to-pxe > if it > needs to. > > Since Cobbler's job is partly to make dissimilar technology consumable > in logical ways, I'm ultimately not sure how far we should go here > into > smoothing things out. Thoughts welcome and stay tuned ... > > --Michael > > > _______________________________________________ > cobbler mailing list > cobbler@lists.fedorahosted.org <mailto:cobbler@lists.fedorahosted.org> <mailto:cobbler@lists.fedorahosted.org <mailto:cobbler@lists.fedorahosted.org>> > https://fedorahosted.org/mailman/listinfo/cobbler > > > ------------------------------------------------------------------------ > > _______________________________________________ > cobbler mailing list > cobbler@lists.fedorahosted.org <mailto:cobbler@lists.fedorahosted.org> > https://fedorahosted.org/mailman/listinfo/cobbler > _______________________________________________ cobbler mailing list cobbler@lists.fedorahosted.org <mailto:cobbler@lists.fedorahosted.org> https://fedorahosted.org/mailman/listinfo/cobbler
cobbler mailing list cobbler@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/cobbler
Steven W. Carter wrote:
I've noticed that when the images are copied over to the images2 directory they keep the source permissions.
We no longer package these directories as between F8 and F9 the TFTP directory moved from /tftpboot to /var/lib/tftpboot. Given tftpboot runs chroot I don't believe any more user permissions are required. If this is causing specific problems let me know, things seemed to work fine for me.
Also, I am currently playing around with using memdisk to boot an ISO image. I'll update with my successes, and then hopefully patch the section of the pxe-writing configuration to enable this functionality. (or I'll just submit the patch since I've never used git)
I was told memdisk was only for netbooting hard disk images and could not do CD/DVD isos (hence why livecd-iso-to-pxeboot exists). If that's not the case that would be interesting.
Submitting the patch via "patch" is fine, though you should find "git-format-patch" easier and it's more likely to get things right.
Fedora Hosted is down for the moment, though there is a "Patch Process" doc on the Wiki that explains a bit of the commands involved. The git tutorials are also pretty good for starters, though you don't really need to learn much more outside the "git-format-patch" workflow at first.
On Tue, Aug 12, 2008 at 12:43 PM, Michael DeHaan <mdehaan@redhat.com mailto:mdehaan@redhat.com> wrote:
Steven W. Carter wrote: > livecd-iso-to-pxe does some sort of check to determine if the image is > in fact a livecd. Could we possible just have three options (direct, > iso, virt-clone) and have the iso option first run whatever check > livecd-iso-to-pxe uses to determine if it's a live image? Worst case, > we could do some janky grepping for the error after it runs the > check. That would reduce you from four to only three options. > > Additionally, I'm attemping to test this fuctionality (cobbler image > add --name=something --file=/path/to/image --image-type=memdisk) but > it doesn't output anything to the menu in the boot options. Do I have > to do something else to add it to the menu? There were some typos in the way that the objects were being saved that kept the type from sticking. Also some other bits that were causing problems with the "direct" type. Both of these items should now be resolved on the devel branch. > > On Thu, Aug 7, 2008 at 3:51 PM, Michael DeHaan <mdehaan@redhat.com <mailto:mdehaan@redhat.com> > <mailto:mdehaan@redhat.com <mailto:mdehaan@redhat.com>>> wrote: > > Michael DeHaan wrote: > > Michael DeHaan wrote: > > > >> Steven W. Carter wrote: > >> > >> > >>> An interesting idea for additional functionality behind this > would be > >>> to enable a "watch folder" in the cobbler directory where ISOs > could > >>> be dumped with a descriptive filename. Then Cobbler could > >>> automatically add them to the PXE menu on a sync. > >>> > >>> For example, you could have a few images named: > >>> > >>> really_cool_image.iso > >>> random_install_image.iso > >>> > >>> in a directory like /var/www/html/cobbler/ISO/ > >>> > >>> and then the menu would have entries that look like: > >>> > >>> really_cool_image > >>> random_install_image > >>> > >>> Since these would have no other integration with the cobbler > system, > >>> Cobbler would only need to know their location to put them > into the > >>> PXE menu. This would also make it very easy to allow for > updates to > >>> the images without requiring any fuss with the Cobbler interface, > >>> especially when these ISO images wouldn't be handled with any > >>> kickstarting or any of the other nifty features that Cobbler > usually > >>> takes care of. Thoughts? > >>> > >>> ~Steven > >>> > >>> > >> Yes, we could easily do something like this ... > >> > >> I think a first step is being able to flag a cobbler image > object for > >> use with memdisk, so you can do "cobbler image add --name=foo > >> --path=/splat/foo.iso --bootmethod=memdisk > >> > >> Right now if you add an image record it shows up as if it was > directly > >> bootable, which is wrong. > >> > >> The watch directory behavior could then implemented as a cobbler > >> pre-sync trigger. > >> > >> We currently don't ship many triggers, but we could ship more -- > >> possibly installing all the "potentially useful" triggers in a > parallel > >> directory where someone could just create a symlink to enable them. > >> > >> As I still have more to do with image objects, I'll look into > that first > >> part today. > >> > >> --Michael > >> > >> > >> > >> > >> > >>> On Wed, Aug 6, 2008 at 4:28 PM, Michael DeHaan > <mdehaan@redhat.com <mailto:mdehaan@redhat.com> <mailto:mdehaan@redhat.com <mailto:mdehaan@redhat.com>> > >>> <mailto:mdehaan@redhat.com <mailto:mdehaan@redhat.com> <mailto:mdehaan@redhat.com <mailto:mdehaan@redhat.com>>>> wrote: > >>> > >>> Michael DeHaan wrote: > >>> > This is a neat feature, but takes some explaining. > Previously > >>> we have > >>> > been able to support things like memtest through special > code, > >>> we found > >>> > the image if installed and added it to certain PXE configs. > >>> However you > >>> > couldn't easily do things like make MAC address > AA:BB:CC:DD:EE:FF > >>> > automatically boot memtest, and so forth. > >>> > > >>> > Now, imagine that special code didn't exist and we could > do it > >>> > generically. Also imagine that we weren't booting > something as > >>> lame as > >>> > memtest. What if we could easily boot anything we > wanted, just > >>> as we > >>> > can deal with kernels and initrds? Now we can. > >>> > > >>> > cobbler image add --name=SuperAwesomeLiveEnvironment > >>> --file=/opt/live.iso > >>> > > >>> > Though we don't have to imagine it, we have this on the > devel branch > >>> > now. Admittedly, I still tested with memtest and not > >>> > SuperAwesomeLiveEnvironment, though the concept is > entirely the > >>> same :) > >>> > > >>> > Further, we can do things like assign a specific MAC > address to boot > >>> > that live environment: > >>> > > >>> > cobbler system add --name=fooserver --mac=AA:BB:CC:DD:EE:FF > >>> > --image=SuperAwesomeLiveEnvironment > >>> > > >>> > The next time that system boots, it will boot that > image. This > >>> doesn't > >>> > have to be an installation related image, it might just be a > >>> firmware > >>> > update disk. > >>> > > >>> > Note that I didn't use --profile here, I used --image. > >>> > > >>> > One of cobbler's goals is to be able to break down the > abstraction > >>> > between physical and virtual machines. Here we are able > to use > >>> "cobbler > >>> > image" objects (with cobbler/koan 1.1 and later) to do > installs both > >>> > physically and virtually. > >>> > > >>> > The ability to netboot a live-image plays critically > into our > >>> desire to > >>> > support net-deploying live image cloning environments, > and may > >>> also have > >>> > applications for Stateless environments (LTSP thin > clients?). > >>> > > >>> > Note that as with cobbler profiles, you can also assign > arbitrary > >>> > "append" options (i..e kernel options) to images. We could > >>> also use > >>> > this to streamline our existing support to memtest, but > since > >>> that is > >>> > already "automatic" and relatively clever (it adds it > >>> automatically if > >>> > you have memtestx86+ installed) we probably will leave > that as is. > >>> > > >>> > Anyhow, feel free to test this feature out on the devel > branch > >>> with any > >>> > bootable images. > >>> > > >>> > I will say adding this feature was relatively > complicated, so > >>> with the > >>> > image support, testing will be very welcome to see if we run > >>> into any > >>> > problems. No changes are in place for any existing > profiles or > >>> system > >>> > objects, just note that now systems can also "inherit" from > >>> images, or > >>> > profiles, but not both at the same time. > >>> > > >>> > We still need to update the WebUI to take advantage of these > >>> features. > >>> > > >>> > So, please help test this out, and if everything is good > we'll > >>> see about > >>> > updating the Wiki to show how to use this with other > tools, such > >>> as the > >>> > firmware update images that are already out there... and > we can > >>> also do > >>> > some more testing with live environments and maybe even > stateless > >>> > applications. > >>> > > >>> > --Michael > >>> > > >>> > _______________________________________________ > >>> > cobbler mailing list > >>> > cobbler@lists.fedorahosted.org <mailto:cobbler@lists.fedorahosted.org> > <mailto:cobbler@lists.fedorahosted.org <mailto:cobbler@lists.fedorahosted.org>> > >>> <mailto:cobbler@lists.fedorahosted.org <mailto:cobbler@lists.fedorahosted.org> > <mailto:cobbler@lists.fedorahosted.org <mailto:cobbler@lists.fedorahosted.org>>> > >>> > https://fedorahosted.org/mailman/listinfo/cobbler > >>> > > >>> > >>> It takes more than this to PXE-boot a non-live image. > >>> > >>> I'll look into this and have some more instructions on the > Wiki later > >>> (and others are welcome to add to it once up). > >>> > >>> Doing some extra live testing now. > >>> > >>> --Michael > >>> _______________________________________________ > >>> cobbler mailing list > >>> cobbler@lists.fedorahosted.org <mailto:cobbler@lists.fedorahosted.org> > <mailto:cobbler@lists.fedorahosted.org <mailto:cobbler@lists.fedorahosted.org>> > <mailto:cobbler@lists.fedorahosted.org <mailto:cobbler@lists.fedorahosted.org> > <mailto:cobbler@lists.fedorahosted.org <mailto:cobbler@lists.fedorahosted.org>>> > >>> https://fedorahosted.org/mailman/listinfo/cobbler > >>> > >>> > >>> > ------------------------------------------------------------------------ > >>> > >>> _______________________________________________ > >>> cobbler mailing list > >>> cobbler@lists.fedorahosted.org <mailto:cobbler@lists.fedorahosted.org> > <mailto:cobbler@lists.fedorahosted.org <mailto:cobbler@lists.fedorahosted.org>> > >>> https://fedorahosted.org/mailman/listinfo/cobbler > >>> > >>> > >>> > >> _______________________________________________ > >> cobbler mailing list > >> cobbler@lists.fedorahosted.org <mailto:cobbler@lists.fedorahosted.org> > <mailto:cobbler@lists.fedorahosted.org <mailto:cobbler@lists.fedorahosted.org>> > >> https://fedorahosted.org/mailman/listinfo/cobbler > >> > >> > > > > Lots of neverending changes/refinements on this. > > > > It looks like "image add/edit" is now going to take an --image-type > > > > Values: > > > > direct # PXEs directly (like "memtest"), does not support virt > > iso # PXEs via memdisk helper, or supports virt installations > > virt-clone # for things like virt-cloning, which is not yet > supported > > > > If anyone can think of a better word for "direct", please > suggest one. > > > > --Michael > > > > > > > > > > _______________________________________________ > > cobbler mailing list > > cobbler@lists.fedorahosted.org <mailto:cobbler@lists.fedorahosted.org> > <mailto:cobbler@lists.fedorahosted.org <mailto:cobbler@lists.fedorahosted.org>> > > https://fedorahosted.org/mailman/listinfo/cobbler > > > > memdisk seems a bit unhappy, maybe we end up with "direct, memdisk, > live, and virt-clone", and have live know to run livecd-iso-to-pxe > if it > needs to. > > Since Cobbler's job is partly to make dissimilar technology consumable > in logical ways, I'm ultimately not sure how far we should go here > into > smoothing things out. Thoughts welcome and stay tuned ... > > --Michael > > > _______________________________________________ > cobbler mailing list > cobbler@lists.fedorahosted.org <mailto:cobbler@lists.fedorahosted.org> <mailto:cobbler@lists.fedorahosted.org <mailto:cobbler@lists.fedorahosted.org>> > https://fedorahosted.org/mailman/listinfo/cobbler > > > ------------------------------------------------------------------------ > > _______________________________________________ > cobbler mailing list > cobbler@lists.fedorahosted.org <mailto:cobbler@lists.fedorahosted.org> > https://fedorahosted.org/mailman/listinfo/cobbler > _______________________________________________ cobbler mailing list cobbler@lists.fedorahosted.org <mailto:cobbler@lists.fedorahosted.org> https://fedorahosted.org/mailman/listinfo/cobbler
cobbler mailing list cobbler@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/cobbler
cobbler@lists.fedorahosted.org