The vmware support patch started using the field "fetchable_files" to add some files to be copied into /tftpboot by sync. (Well, by a post-sync trigger, but that's slightly different issue). Unfortunately, if you're using fetchable_files for the reason I originally envisioned, the trigger will likely blow up.
I added fetchable_files to handle tftp clients that requested hardcoded paths. For example, FreeBSDs pxeboot client looks for "/boot/mfsroot.gz". The fetchable_files support is required to sanely support multiple versions of FreeBSD.
The VMWare import module uses it differently. It looks like the VMWare module is using it to list additional files that need to be copied into /tftpboot to support VMWare, beyond just the two that cobbler already supports (kernel,initrd).
The VMWare import patch added two triggers: one post sync, the other post distro-add to copy files in fetchable_files into /tftpboot.
From the perspective of the python tftp server, that's not a problem. So there are some bad paths in fetchable files: that's ok. We'll just never check them.
However, the new triggers can't really handle fetchable_files being used for the original use case. The copy fails.
I think the use case that the VMWare module has is a very rational use case. I just don't think it's the appropriate use case for fetchable_files. So I'd like to propose a new field: "boot_files".
I've got a couple of proposed patches on my github tree (https://github.com/kilpatds/cobbler/commits/master). At the commit history on the tree, both changes are were made on May 26th.
https://github.com/kilpatds/cobbler/commit/24a531ea4943848598e8774aff408d79c... is the change that adds the boot_files field.
https://github.com/kilpatds/cobbler/commit/5b90509288d09bf337c7e14de780f08c3... changes the sync/add triggers to use it.
(The change on the 30th refactors things to get rid of the triggers: move the copy logic over to sync/litesync. But I'm not done testing that)
Comments? Commentary? Requests for "TL;DR" blocks?
Doug
On Tue, May 31, 2011 at 11:33 AM, Douglas Kilpatrick kilpatds@oppositelock.org wrote:
The vmware support patch started using the field "fetchable_files" to add some files to be copied into /tftpboot by sync. (Well, by a post-sync trigger, but that's slightly different issue). Unfortunately, if you're using fetchable_files for the reason I originally envisioned, the trigger will likely blow up.
I added fetchable_files to handle tftp clients that requested hardcoded paths. For example, FreeBSDs pxeboot client looks for "/boot/mfsroot.gz". The fetchable_files support is required to sanely support multiple versions of FreeBSD.
The VMWare import module uses it differently. It looks like the VMWare module is using it to list additional files that need to be copied into /tftpboot to support VMWare, beyond just the two that cobbler already supports (kernel,initrd).
The VMWare import patch added two triggers: one post sync, the other post distro-add to copy files in fetchable_files into /tftpboot.
From the perspective of the python tftp server, that's not a problem. So there are some bad paths in fetchable files: that's ok. We'll just never check them.
However, the new triggers can't really handle fetchable_files being used for the original use case. The copy fails.
I think the use case that the VMWare module has is a very rational use case. I just don't think it's the appropriate use case for fetchable_files. So I'd like to propose a new field: "boot_files".
I've got a couple of proposed patches on my github tree (https://github.com/kilpatds/cobbler/commits/master). At the commit history on the tree, both changes are were made on May 26th.
https://github.com/kilpatds/cobbler/commit/24a531ea4943848598e8774aff408d79c... is the change that adds the boot_files field.
https://github.com/kilpatds/cobbler/commit/5b90509288d09bf337c7e14de780f08c3... changes the sync/add triggers to use it.
(The change on the 30th refactors things to get rid of the triggers: move the copy logic over to sync/litesync. But I'm not done testing that)
Comments? Commentary? Requests for "TL;DR" blocks?
Doug
Doug Kilpatrick kilpatds@oppositelock.org _______________________________________________ cobbler mailing list cobbler@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/cobbler
I want this functionality so I support adding the fields for the two use cases. This fixes the issues we have currently installing ESXi and FreeBSD. I've tested out the latest commits and everything seems stable to me. We worked through a few bugs and now I think it's good to go. I've tested RHEL, ESXi, and FreeBSD installs and importing.
+1..
Yeah I have no problem with this, there was zero documentation about fetchable_files so I was kind of working in the dark.
The same boot_files field could be used for Solaris support if someone wanted to hack that together, assuming people still use Solaris :) On Jun 1, 2011 3:09 PM, "Jonathan Sabo" jsabo@criminal.org wrote:
On Tue, May 31, 2011 at 11:33 AM, Douglas Kilpatrick kilpatds@oppositelock.org wrote:
The vmware support patch started using the field "fetchable_files" to add some files to be copied into /tftpboot by sync. (Well, by a post-sync trigger, but that's slightly different issue). Unfortunately, if you're using fetchable_files for the reason I originally envisioned, the trigger will likely blow up.
I added fetchable_files to handle tftp clients that requested hardcoded paths. For example, FreeBSDs pxeboot client looks for "/boot/mfsroot.gz". The fetchable_files support is required to sanely support multiple versions of FreeBSD.
The VMWare import module uses it differently. It looks like the VMWare module is using it to list additional files that need to be copied into /tftpboot to support VMWare, beyond just the two that cobbler already supports (kernel,initrd).
The VMWare import patch added two triggers: one post sync, the other post distro-add to copy files in fetchable_files into /tftpboot.
From the perspective of the python tftp server, that's not a problem. So there are some bad paths in fetchable files: that's ok. We'll just never check them.
However, the new triggers can't really handle fetchable_files being used for the original use case. The copy fails.
I think the use case that the VMWare module has is a very rational use case. I just don't think it's the appropriate use case for fetchable_files. So I'd like to propose a new field: "boot_files".
I've got a couple of proposed patches on my github tree (https://github.com/kilpatds/cobbler/commits/master). At the commit history on the tree, both changes are were made on May 26th.
https://github.com/kilpatds/cobbler/commit/24a531ea4943848598e8774aff408d79c...
is the change that adds the boot_files field.
https://github.com/kilpatds/cobbler/commit/5b90509288d09bf337c7e14de780f08c3...
changes the sync/add triggers to use it.
(The change on the 30th refactors things to get rid of the triggers: move the copy logic over to sync/litesync. But I'm not done testing
that)
Comments? Commentary? Requests for "TL;DR" blocks?
Doug
Doug Kilpatrick kilpatds@oppositelock.org _______________________________________________ cobbler mailing list cobbler@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/cobbler
I want this functionality so I support adding the fields for the two use cases. This fixes the issues we have currently installing ESXi and FreeBSD. I've tested out the latest commits and everything seems stable to me. We worked through a few bugs and now I think it's good to go. I've tested RHEL, ESXi, and FreeBSD installs and importing.
+1.. _______________________________________________ cobbler mailing list cobbler@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/cobbler
On Wed, Jun 1, 2011 at 4:22 PM, Scott Henson shenson@redhat.com wrote:
Merged.
I just did a pull and saw this:
41 files changed, 1275 insertions(+), 1152 deletions(-) delete mode 100644 cobbler/modules/add_post_distro_tftp_copy_fetchable_files.py delete mode 100644 cobbler/modules/sync_post_tftp_copy_fetchable_files.py
I thought we were changing those to use boot_files, not deleting them? This will break ESXi support.
On Sat, Jun 11, 2011 at 2:18 PM, James Cammarata jimi@sngx.net wrote:
On Wed, Jun 1, 2011 at 4:22 PM, Scott Henson shenson@redhat.com wrote:
Merged.
I just did a pull and saw this:
41 files changed, 1275 insertions(+), 1152 deletions(-) delete mode 100644 cobbler/modules/add_post_distro_tftp_copy_fetchable_files.py delete mode 100644 cobbler/modules/sync_post_tftp_copy_fetchable_files.py
I thought we were changing those to use boot_files, not deleting them? This will break ESXi support. _______________________________________________ cobbler mailing list cobbler@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/cobbler
He moved this code into some other part of cobbler in another commit. ESXi installs still working like a charm and now so do FreeBSD installs.
On Sat, Jun 11, 2011 at 6:16 PM, Jonathan Sabo jsabo@criminal.org wrote:
On Sat, Jun 11, 2011 at 2:18 PM, James Cammarata jimi@sngx.net wrote:
On Wed, Jun 1, 2011 at 4:22 PM, Scott Henson shenson@redhat.com wrote:
Merged.
I just did a pull and saw this:
41 files changed, 1275 insertions(+), 1152 deletions(-) delete mode 100644 cobbler/modules/add_post_distro_tftp_copy_fetchable_files.py delete mode 100644 cobbler/modules/sync_post_tftp_copy_fetchable_files.py
I thought we were changing those to use boot_files, not deleting them? This will break ESXi support.
He moved this code into some other part of cobbler in another commit. ESXi installs still working like a charm and now so do FreeBSD installs.
Ok cool, I just took a quick peek, I hadn't really dug into things and wanted to make sure.
On Wed, Jun 1, 2011 at 11:16 PM, James Cammarata jimi@sngx.net wrote: <snip>
The same boot_files field could be used for Solaris support if someone wanted to hack that together, assuming people still use Solaris :)
Excellent!! I will take a look at Solaris support and report back here. It will take some time though...
Grtz, Jorgen
cobbler@lists.fedorahosted.org
-
Douglas Kilpatrick -
James Cammarata -
Jonathan Sabo -
Jörgen Maas -
Scott Henson