Red Hat Bugzilla – Bug 304211
SNIPPET::a_b_c matches on file a_b (because it exists), causing an error on the remote install machine
Last modified: 2008-05-14 11:11:47 EDT
Description of problem:
I have two kickstart templates, one for FC6 and above, one for FC5 and below. I
have changed the SNIPPET lines in each kickstart template to provide for
different partitioning schemes (since RHEL4 uses diskdump, and RHEL5 uses kdump
and doesn't need a dedicated partition to dump to).
I used the original partition_select as a template, but forked it off to two
similar filenames, each with their own respective partitioning configuration.
Since the filenames were so similar, my SNIPPET lines matched on the original
snippet and not my customized snippets.
Version-Release number of selected component (if applicable):
[jherm@jherm-fedora ~]$ rpm -qa | grep -i cobbler
[jherm@jherm-fedora ~]$ rpm -qa | grep -i cheetah
[jherm@jherm-fedora ~]$ rpm -qa | grep -i koan
Steps to Reproduce:
1. Copy /var/lib/cobbler/snippets/partition_select to
/var/lib/cobbler/snippets/partition_select_fc6 and make some modification to it
so you can tell it is not included when you sync cobbler.
2. In kickstart_fc6.ks, reference your customized snippet.
3. View the unexpected result in /var/www/cobbler/kickstarts/blahblah/blah.ks
In the case of "SNIPPET::a_b_c", cobbler/cheetah matches on file a_b
The variable name does not end until a space (or some other delimiter), and the
true file we want to use is read in.
After writing this bug I realize it may also be a bug in Cheetah. I didn't look
at the code. Please reply to my e-mail if you need me to change any information
related to this bug.
Thanks, and very sorry for the late response. This apparently got lost by my
mail filter. This is a bug in Cobbler, not Cheetah.
As a workaround though, you can just use Cheetah's built-in include function and
specify the full path to the file.
I may look at making the "SNIPPET" parts automatically get replaced by Cheetah
include directives in the future. Another alternative would be to just sort
the snippet names so the longest names get replaced first.
This message is a reminder that Fedora 7 is nearing the end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 7. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '7'.
Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 7's end of life.
Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 7 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug. If you are unable to change the version, please add a comment here and someone will do it for you.
Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. If possible, it is recommended that you try the newest available Fedora distribution to see if your bug still exists.
Please read the Release Notes for the newest Fedora distribution to make sure it will meet your needs:
The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
This one got lost in bugzilla. My apologies.
I'll reopen this here in Trac and verify that it is no longer a problem, and if
it's still there, I'll fix this for the next release.
Ok, I looked over 0.9.X/1.0's code (the devel branch in git) and that uses a
different system for replacing snippets and does not have this problem.
So this is fixed upstream and will be included in the 1.0 release.