9:28 p.m.
Howdy, 'yall. I'm having some trouble using the new templating support
in the devel branch (77f5e38b097e79d5d0de3e994dad54f381bb706f).
$ BASEURL=http://localhost/cblr/svc/op/template
$ cobbler profile edit \
--name=CentOS-5.1-x86_64 \
--template-files=/local/templates/racadm.ini=racadm.ini
$ cobbler sync
$ cobbler system dumpvars --name=00:16:3e:67:2b:43 | grep template_files
'template_files': {'/local/templates/racadm.ini':
'racadm.ini'},
$ curl ${BASEURL}/system/00:16:3e:c9:95:47/path/racadm.ini
# template path not found for specified profile
$ curl ${BASEURL}/profile/CentOS-5.1-x86_64/path/racadm.ini
# template path not found for specified profile
Since we're checking in cobbler.api for template_results.has_key(path),
I made the error a bit more verbose, printing path.keys() as part of the
error message, and attempting other variants:
$ curl ${BASEURL}/system/00:16:3e:c9:95:47/path/racadm.ini
# template path not found for specified system (options: [])
$ curl ${BASEURL}/profile/CentOS-5.1-x86_64/path/racadm.ini
# template path not found for specified profile (options:
['/var/www/cobbler/rendered/racadm.ini'])
$ curl
${BASEURL}/profile/CentOS-5.1-x86_64/path//var/www/cobbler/rendered/racadm.ini
# template path not found for specified profile (options: [])
$ curl
${BASEURL}/profile/CentOS-5.1-x86_64/path/_var_www_cobbler_rendered_racadm.ini
# template path not found for specified profile (options: [])
Any hints/pointers?
8:50 a.m.
Charles Duffy wrote:
Howdy, 'yall. I'm having some trouble using the new
templating support
in the devel branch (77f5e38b097e79d5d0de3e994dad54f381bb706f).
$ BASEURL=http://localhost/cblr/svc/op/template
$ cobbler profile edit \
> --name=CentOS-5.1-x86_64 \
> --template-files=/local/templates/racadm.ini=racadm.ini
Tip: The right hand side of the --template-files invocation should be a
full destination path on the filesystem (iwhere racadm.ini goes)
$ cobbler sync
$ cobbler system dumpvars --name=00:16:3e:67:2b:43 | grep template_files
'template_files': {'/local/templates/racadm.ini':
'racadm.ini'},
$ curl ${BASEURL}/system/00:16:3e:c9:95:47/path/racadm.ini
# template path not found for specified profile
$ curl ${BASEURL}/profile/CentOS-5.1-x86_64/path/racadm.ini
# template path not found for specified profile
This is not the URL that serves up the template form mod_python. If you
have the new sample.ks, you'll see the macro at the bottom is
$SNIPPET('download_config_files')
Which is a snippet in /var/lib/cobbler/snippets once installed. The
purpose of the snippet is to build all the magic URLs for the user, so
they don't have to figure out what they are themselves.
If you look inside that snippet, you will see the code that builds the
URLs contains the following line:
#set $turl =
"http://"+$http_server+"/cblr/svc/op/template/"+$ttype+"/"+$tname+"/path/"+$tpath
If you ever want to see how a kickstart file expands, the best way is to
look at it:
cobbler system getks --name=foo
That will print out the kickstat and you can see the wgets at the bottom
of it.
These URLs are also of the form the new koan uses when you use:
koan --server=cobbler.example.org --update-files --system=name
Basically koan will wget the above URLs from the template server from
the right file locations.
Since we're checking in cobbler.api for
template_results.has_key(path),
I made the error a bit more verbose, printing path.keys() as part of the
error message, and attempting other variants:
$ curl ${BASEURL}/system/00:16:3e:c9:95:47/path/racadm.ini
# template path not found for specified system (options: [])
$ curl ${BASEURL}/profile/CentOS-5.1-x86_64/path/racadm.ini
# template path not found for specified profile (options:
['/var/www/cobbler/rendered/racadm.ini'])
$ curl
${BASEURL}/profile/CentOS-5.1-x86_64/path//var/www/cobbler/rendered/racadm.ini
# template path not found for specified profile (options: [])
$ curl
${BASEURL}/profile/CentOS-5.1-x86_64/path/_var_www_cobbler_rendered_racadm.ini
# template path not found for specified profile (options: [])
Yes, all of the above URLs are wrong, was there somewhere in the docs
that pointed to those being the URL formats? If so, I want to correct them.
All the magic URLs are also documented here:
https://fedorahosted.org/cobbler/wiki/ModPythonDetails
Though the nice thing is cobbler never really makes the user understand
these URLs, as the above SNIPPET builds those for the user and koan also
knows what they are.
--Michael
_______________________________________
2:03 p.m.
Michael DeHaan wrote:
$SNIPPET('download_config_files')
Doesn't work for me. Evaluates to this:
wget
"http://169.254.0.1/cblr/svc/op/template/profile/CentOS-5.1-x86_64/path/racadm.ini"
--output-document="racadm.ini"
...but doesn't work on retrieval:
$ curl
http://169.254.0.1/cblr/svc/op/template/profile/CentOS-5.1-x86_64/path/ra...
# template path not found for specified profile (options:
['/var/www/cobbler/rendered/racadm.ini'])
It looks like adding a leading slash to the path resolves this.
The other thing that surprises me is that a template added on a
per-profile basis is retrieved on a per-profile basis -- such that a
template added to a profile can't use system-local variables.
(Also, when I add a template on a per-system basis, the
download_config_files snippet tries to retrieve it for the profile, not
for the system).
Tip: The right hand side of the --template-files invocation should be
a
full destination path on the filesystem (iwhere racadm.ini goes)
I'm not using it that way; I have no interest in racadm.ini (or the
other files I'm templating) going onto the target system, making both
the snippet and the koan command useful as examples but not otherwise.
Yes, all of the above URLs are wrong, was there somewhere in the docs
that pointed to those being the URL formats? If so, I want to correct them.
No -- that's not from the docs but from a perusal of the source to the
download_config_files snippet (and the koan --update-files option).
Reading TFM, however, it's clear that I didn't look hard enough.
All the magic URLs are also documented here:
https://fedorahosted.org/cobbler/wiki/ModPythonDetails
Ahh; perfect!
3:23 p.m.
Charles Duffy wrote:
Michael DeHaan wrote:
> $SNIPPET('download_config_files')
>
Doesn't work for me. Evaluates to this:
wget
"http://169.254.0.1/cblr/svc/op/template/profile/CentOS-5.1-x86_64/path/racadm.ini"
--output-document="racadm.ini"
...but doesn't work on retrieval:
$ curl
http://169.254.0.1/cblr/svc/op/template/profile/CentOS-5.1-x86_64/path/ra...
# template path not found for specified profile (options:
['/var/www/cobbler/rendered/racadm.ini'])
I'll check on this....
It looks like adding a leading slash to the path resolves this.
The other thing that surprises me is that a template added on a
per-profile basis is retrieved on a per-profile basis -- such that a
template added to a profile can't use system-local variables.
This is all fixed with a change to the snippet that I've pushed, which
is the point of testing it, thanks :)
(Also, when I add a template on a per-system basis, the
download_config_files snippet tries to retrieve it for the profile, not
for the system).
> Tip: The right hand side of the --template-files invocation should be a
> full destination path on the filesystem (iwhere racadm.ini goes)
>
I'm not using it that way; I have no interest in racadm.ini (or the
other files I'm templating) going onto the target system, making both
the snippet and the koan command useful as examples but not otherwise.
Sure...
> Yes, all of the above URLs are wrong, was there somewhere in the docs
> that pointed to those being the URL formats? If so, I want to correct them.
>
No -- that's not from the docs but from a perusal of the source to the
download_config_files snippet (and the koan --update-files option).
Reading TFM, however, it's clear that I didn't look hard enough.
Yep, checking now...
> All the magic URLs are also documented here:
>
> https://fedorahosted.org/cobbler/wiki/ModPythonDetails
>
Ahh; perfect!
_______________________________________________
cobbler mailing list
cobbler(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/cobbler
9:11 a.m.
On Wed, 15 Oct 2008 16:23:55 -0400, Michael DeHaan <mdehaan(a)redhat.com>
wrote:
Charles Duffy wrote:
> Michael DeHaan wrote:
>
>> $SNIPPET('download_config_files')
>>
>
> Doesn't work for me. Evaluates to this:
>
> wget
>
"http://169.254.0.1/cblr/svc/op/template/profile/CentOS-5.1-x86_64/path/racadm.ini"
> --output-document="racadm.ini"
>
> ...but doesn't work on retrieval:
>
> $ curl
>
http://169.254.0.1/cblr/svc/op/template/profile/CentOS-5.1-x86_64/path/ra...
> # template path not found for specified profile (options:
> ['/var/www/cobbler/rendered/racadm.ini'])
>
I'll check on this....
I believe that cobbler wants the template destination to be a full path.
Whether or not that is a bug is up to Michael to determine :)
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
10:44 a.m.
James Cammarata wrote:
On Wed, 15 Oct 2008 16:23:55 -0400, Michael DeHaan
<mdehaan(a)redhat.com>
wrote:
> Charles Duffy wrote:
>
>> Michael DeHaan wrote:
>>
>>
>>> $SNIPPET('download_config_files')
>>>
>>>
>> Doesn't work for me. Evaluates to this:
>>
>> wget
>>
>>
"http://169.254.0.1/cblr/svc/op/template/profile/CentOS-5.1-x86_64/path/racadm.ini"
>> --output-document="racadm.ini"
>>
>> ...but doesn't work on retrieval:
>>
>> $ curl
>>
>>
http://169.254.0.1/cblr/svc/op/template/profile/CentOS-5.1-x86_64/path/ra...
>> # template path not found for specified profile (options:
>> ['/var/www/cobbler/rendered/racadm.ini'])
>>
>>
> I'll check on this....
>
I believe that cobbler wants the template destination to be a full path.
Whether or not that is a bug is up to Michael to determine :)
Nope, it's a feature. We were talking about this on IRC yesterday and I
finished it up yesterday evening.
Now it only downloads them if the destination is a fullpath (in koan or
the %post snippet).
If not, it can be used for templating without auto-downloading the files.
Let me know if anyone thinks there are any other issues/features/ideas
with this.
5686
days inactive
5687
days old
cobbler@lists.fedorahosted.org
5 comments
3 participants
participants (3)
-
Charles Duffy -
James Cammarata -
Michael DeHaan