FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora/Linux Management Tools

 
 
LinkBack Thread Tools
 
Old 04-06-2008, 06:57 PM
"Sandor W. Sklar"
 
Default Looping through possibilities in a "snippet"

I'd like to use snippets in my kickstart file for selecting things
like partitioning, packages, and post portions based on either user-
provided ksmeta variables or the Cobbler-provided variables.
Unfortunately, I know very little Python, and my googling around for
Cheetah examples of what I'd like to do has been less then fruitful.


Example: In my /etc/cobbler/rhel5xen.ks kickstart template, I've
got ...


%packages
SNIPPET:ackages_select


What I'd like that file /usr/lib/cobbler/snippets/packages_select is
to do something like (in psuedo-code here; if I could write the "real"
code, I wouldn't be asking. :-)



====================================

$package_snip_dir = /var/lib/cobbler/snippets/packages.d

If if the ksmeta var "$packages" has a value AND if $package_snip_dir/
$packages exists , use it ...


... else if $package_snip_dir/$name exists, use it ...

... else if $package_snip_dir/$profile exists, use it ...

... else, use $package_snip_dir/default.

===================================

I've tried making this work, with "#try ... #except ... #finally"
blocks, "#if ... #elif ... #then" blocks, "os.path.isfile", and so
on. All of my attempts have ended in various syntax errors or
failures that I'm at a loss to resolve.


I expect that the solution to this is simple, and I'm going to feel
really stupid when someone points that solution out to me, but I can
live with that. :-)


Below is my last, best attempt, along with the error that gets
generated.


[root ~]# cat /var/lib/cobbler/snippets/packages_select
#try
#include raw source='/var/lib/cobbler/snippets/packages.d/' +
$packages

#except
#try
#include raw source='/var/lib/cobbler/snippets/packages.d/' + $name
#except
#try
#include raw source='/var/lib/cobbler/snippets/packages.d/' +
$profile

#except
#try
#include raw "/var/lib/cobbler/snippets/packages.d/DEFAULT"
#end try
#end try
#end try
#end try

[root ~]# cobbler sync
sync distro: rhel4AS-x86_64
sync distro: rhel4AS-xen-x86_64
sync distro: rhel5Server-x86_64
sync distro: rhel5Server-xen-x86_64
sync profile: xen-big
Traceback (most recent call last):
File "/usr/lib/python2.4/site-packages/cobbler/action_sync.py",
line 373, in validate_kickstart_for_specific_profile

self.apply_template(kfile, meta, dest)
File "/usr/lib/python2.4/site-packages/cobbler/action_sync.py",
line 627, in apply_template

t = Template(source=data, searchList=[metadata])
File "/usr/lib64/python2.4/site-packages/Cheetah/Template.py", line
1204, in __init__

self._compile(source, file, compilerSettings=compilerSettings)
File "/usr/lib64/python2.4/site-packages/Cheetah/Template.py", line
1492, in _compile

keepRefToGeneratedCode=True)
File "/usr/lib64/python2.4/site-packages/Cheetah/Template.py", line
791, in compile

raise parseError
ParseError:

Error in the Python code which Cheetah generated for this template:
=
=
=
=
=
=
=
=
================================================== ======================


invalid syntax
(cheetah_DynamicallyCompiledCheetahTemplate_120750 8119_67_52126.py,
line 210)


Line|Python Code
----|-------------------------------------------------------------
208 | try: # generated from line 51, col 4
209 | self._handleCheetahInclude("/var/lib/
cobbler/snippets/packages.d/DEFAULT", trans=trans, includeFrom="file",
raw=True)

210 | write('
^
211 |%post
212 |
213 |')

=
=
=
=
=
=
=
=
================================================== ======================


Here is the corresponding Cheetah code.
** I had to guess the line & column numbers, so they are probably
incorrect:


Line 61, column 1

Line|Cheetah Code
----|-------------------------------------------------------------
58 |
59 |%post
60 |
61 |$yum_config_stanza
^
62 |
63 |## post_select
64 |##

Error while rendering kickstart file /etc/cobbler/rhel5xen.ks to /var/
www/cobbler/kickstarts/xen-big/ks.cfg





_______________________________________________
et-mgmt-tools mailing list
et-mgmt-tools@redhat.com
https://www.redhat.com/mailman/listinfo/et-mgmt-tools
 
Old 04-07-2008, 03:42 PM
Michael DeHaan
 
Default Looping through possibilities in a "snippet"

Sandor W. Sklar wrote:




I would probably solve the problem of sourcing the packages list from an
external file in a different way...


For starters, assume you have your packages list arranged as follows:

/var/www/html/packages_list/systems/* (file named after systems go heere)
/var/www/html/packages_list/profiles/* (file named after profiles go here)
/var/www/html/packages_list/default (default files go here)

What follows is a bash script for the kickstart .. the format is
slightly different as we have to escape the bash for Cheetah -- and we
also need to do a quick trick to pass Cheetah variables into the bash
section as bash variables... So that's what the first four lines up to
"#raw" do.


you can validate that this works for you by running "cobbler sync" and
then looking at http://server/cobbler/kickstart_sys/name/ks.cfg to make
sure it's templated out with URLs/values that look good to you, though
this should be pretty close.


Basically it makes three seperate wget requests and stops when it gets a
file that is not zero length. Once it has the file saved to
/tmp/packages we later include (using kickstart) the file /tmp/packages
into the middle of the package list at runtime. This also allows the
package list to be modified without having to run "cobbler sync" to
apply changes to it.


%pre
profile = $profile
name = $name
server = $server
#raw
wget http://$server/packages_list/systems/$name -O /tmp/packages
if [ ! -s /tmp/packages ]
then

wget http://$server/packages_list/profiles/$profile -O /tmp/packages

if [ ! -s /tmp/packages ]
then
wget http://$server/packages_list/default -O /tmp/packages
fi

fi
#endraw


In your %packages section:
%include /tmp/packages


Will that work? That's a pretty good idea for a way to source a packages
list, so I may include that snippet in a future release of Cobbler if it
meets requirements. We could carve out space in /var/www/cobbler to
store the packages lists and include info on the Wiki about how to use
it. (Note that right now, that's not advisable, as cobbler cleans out
content in /var/www/cobbler each time it runs).


--Michael

_______________________________________________
et-mgmt-tools mailing list
et-mgmt-tools@redhat.com
https://www.redhat.com/mailman/listinfo/et-mgmt-tools
 
Old 04-07-2008, 04:01 PM
"Sandor W. Sklar"
 
Default Looping through possibilities in a "snippet"

On Apr 7, 2008, at 8:42 AM, Michael DeHaan wrote:

Sandor W. Sklar wrote:




I would probably solve the problem of sourcing the packages list
from an external file in a different way...


Hi, Michael,

Thanks; I hadn't thought of doing it that way. I'd prefer that the
cobbler-rendered kickstarts were "complete", but it seems that this is
a good workaround that accomplishes what I'm trying to do.


Knowing very little of python (guess I'm going to have to crack a book
some day), can I assume that doing what I originally hoped for would
be too awkward? ( I use that word instead of "not possible", because
the Perl that I know has let me to understand that nothing is
impossible! :-)


Thanks,
-s-

_______________________________________________
et-mgmt-tools mailing list
et-mgmt-tools@redhat.com
https://www.redhat.com/mailman/listinfo/et-mgmt-tools
 
Old 04-07-2008, 04:13 PM
Michael DeHaan
 
Default Looping through possibilities in a "snippet"

Sandor W. Sklar wrote:


On Apr 7, 2008, at 8:42 AM, Michael DeHaan wrote:

Sandor W. Sklar wrote:




I would probably solve the problem of sourcing the packages list from
an external file in a different way...


Hi, Michael,

Thanks; I hadn't thought of doing it that way. I'd prefer that the
cobbler-rendered kickstarts were "complete", but it seems that this is
a good workaround that accomplishes what I'm trying to do.


I'll file an RFE on exploring it this way.



Knowing very little of python (guess I'm going to have to crack a book
some day), can I assume that doing what I originally hoped for would
be too awkward? ( I use that word instead of "not possible", because
the Perl that I know has let me to understand that nothing is
impossible! :-)


Kinda, in general a template that tries to test for existance of a file
on the filesystem starts being more "code" than template. That can get
scary, as you've seen. Cheetah does allow blurring that line, but I like
keeping the template files as "data" for basic string substitution and
not pushing it that far.


This isn't to say we can't achieve a similar solution in Cobbler itself,
that may be more elegant than either option. I'll open up a RFE on this
to see what the options are -- things that allow someone to edit
kickstarts /less/ would be good, and I can see something like this even
being presented in the UI.


We could have cobbler automatically include content from
/var/lib/cobbler/packages_list/profiles/$name and
/var/lib/cobbler/packages_list/systems/$name every time we sync if we
wanted to. We do have the question then of what gets appended to a list
or what gets used /instead/, and which use case is more important. I can
kind of see cases for both.


Ideally one wouldn't be assigning specific packages to specific systems,
as the point of a profile is to make a configuration available to all
things that look "like" something. Can you explain your use case for
assigning specific packages to specific systems?


Thoughts on how that should work?

I do like this idea a lot...

--Michael


_______________________________________________
et-mgmt-tools mailing list
et-mgmt-tools@redhat.com
https://www.redhat.com/mailman/listinfo/et-mgmt-tools
 
Old 04-07-2008, 05:56 PM
"Sandor W. Sklar"
 
Default Looping through possibilities in a "snippet"

On Apr 7, 2008, at 9:13 AM, Michael DeHaan wrote:


We could have cobbler automatically include content from /var/lib/
cobbler/packages_list/profiles/$name and /var/lib/cobbler/
packages_list/systems/$name every time we sync if we wanted to. We
do have the question then of what gets appended to a list or what
gets used /instead/, and which use case is more important. I can
kind of see cases for both.


Agreed. Also keep in mind that I used "packages" as an example; I'm
hoping to use the same method with the disk partitioning section of
the ks, as well as the post section (and, I guess, for the pre section
as well; always forget about that one. :-)



Ideally one wouldn't be assigning specific packages to specific
systems, as the point of a profile is to make a configuration
available to all things that look "like" something. Can you explain
your use case for assigning specific packages to specific systems?


Good question. I agree that it would be rare to have something
assigned on a "system" basis, as opposed to a profile. That said,
I've taken responsibility for setting up the Cobbler environment for
my team of sysadmins, and I guess I'm just anticipating the
probability that one of them would say, "what if I want X, Y, and Z
only for one system, and I don't want to make a separate profile."
Fairly contrived example, I think, but I won't be surprised to have it
posed to me. :-)




Thoughts on how that should work?


Well, in my "perfect" world, I kind of like the pseudo-code from my
original email, but I understand the desire to keep more complex code
out of what should be a template. I guess, if you start with the idea
that a proper kickstart file has four "official" sections[1] (command,
%packages, %pre, %post), it would make sense to maybe have each of
those items defined as standard cobbler profile metadata; doing so
would completely modularize kickstart generation.


I'm sure there are holes in that logic (one is, I actually consider
the "disk partitioning" a separate section, but it "officially" is
just a part of the "command" section. Doubtless there are other holes
that I'm not seeing right now.





I do like this idea a lot...


Thanks! I like cobbler a lot!

-s-


[1] <http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/sysadmin-guide/s1-kickstart2-file.html
>


_______________________________________________
et-mgmt-tools mailing list
et-mgmt-tools@redhat.com
https://www.redhat.com/mailman/listinfo/et-mgmt-tools
 
Old 04-07-2008, 06:06 PM
Michael DeHaan
 
Default Looping through possibilities in a "snippet"

Sandor W. Sklar wrote:


On Apr 7, 2008, at 9:13 AM, Michael DeHaan wrote:


We could have cobbler automatically include content from
/var/lib/cobbler/packages_list/profiles/$name and
/var/lib/cobbler/packages_list/systems/$name every time we sync if we
wanted to. We do have the question then of what gets appended to a
list or what gets used /instead/, and which use case is more
important. I can kind of see cases for both.


Agreed. Also keep in mind that I used "packages" as an example; I'm
hoping to use the same method with the disk partitioning section of
the ks, as well as the post section (and, I guess, for the pre section
as well; always forget about that one. :-)


Yes, so really about groups of snippets then. I follow. Sounds cleaner too!

This may get close to what Aaron was referring to earlier today also --
not sure.





Ideally one wouldn't be assigning specific packages to specific
systems, as the point of a profile is to make a configuration
available to all things that look "like" something. Can you explain
your use case for assigning specific packages to specific systems?


Good question. I agree that it would be rare to have something
assigned on a "system" basis, as opposed to a profile. That said, I've
taken responsibility for setting up the Cobbler environment for my
team of sysadmins, and I guess I'm just anticipating the probability
that one of them would say, "what if I want X, Y, and Z only for one
system, and I don't want to make a separate profile." Fairly contrived
example, I think, but I won't be surprised to have it posed to me. :-)


Yes, that definitely happens... I can see that being more useful in a
general context if we don't just apply it to packages. (For instance,
this system has storage that is just /slightly/ off) ... at least
conceptually.




Thoughts on how that should work?


Well, in my "perfect" world, I kind of like the pseudo-code from my
original email, but I understand the desire to keep more complex code
out of what should be a template. I guess, if you start with the idea
that a proper kickstart file has four "official" sections[1] (command,
%packages, %pre, %post), it would make sense to maybe have each of
those items defined as standard cobbler profile metadata; doing so
would completely modularize kickstart generation.




What if we changed the semantics of...

SNIPPET::foosball

which would now be smart and would pull one of the following, whichever
exists first:


/var/lib/cobbler/snippets/system/foosball/$system_name
/var/lib/cobbler/snippets/profile/foosball/$profile_name
/var/lib/cobbler/snippets/distro/foosball/$distro_name
/var/lib/cobbler/snippets/foosball

whichever was found first.

I think this is what you're getting at and could be done fairly cleanly
without being package specific.


Of course the stock install would lay down none of these paths except
the directories and this would largely be just documented

if you decide to use it (on the Wiki).

--Michael





_______________________________________________
et-mgmt-tools mailing list
et-mgmt-tools@redhat.com
https://www.redhat.com/mailman/listinfo/et-mgmt-tools
 
Old 04-08-2008, 02:53 AM
Msquared
 
Default Looping through possibilities in a "snippet"

On Mon, Apr 07, 2008 at 12:13:46PM -0400, Michael DeHaan wrote:

> Ideally one wouldn't be assigning specific packages to specific systems,
> as the point of a profile is to make a configuration available to all
> things that look "like" something. Can you explain your use case for
> assigning specific packages to specific systems?

I can: I have two 'workstations' that run on power from a single UPS.
Only one of them, however, is actually connected to the UPS'
communications port - the other one talks via TCP/IP to the first to
determine UPS status.

All workstations have nut-client installed, but only the workstation
connected to the UPS' communications port has nut installed.

Granted, I could probably have a 'with-ups' profile based on the standard
workstation profile, but it hardly seems worth it to me. :-)

Actually, relevant question: If I have a 'workstation-with-ups' profile
based on a 'workstation' profile, and add packages to the 'workstation'
profile, will the packages also be automatically added to the
'workstation-with-ups' profile?

(Note: I have not (yet) set up either of the aforementioned workstations
with Cobbler, but they do exist and they are on a UPS via nut - it's just
a valid use-case that I think bears inclusion.)


On Mon, Apr 07, 2008 at 10:56:43AM -0700, Sandor W. Sklar wrote:

> I'm sure there are holes in that logic (one is, I actually consider the
> "disk partitioning" a separate section, but it "officially" is just a
> part of the "command" section. Doubtless there are other holes that
> I'm not seeing right now.

The original logic seems to me that you get to choose only one snippet
(system, profile, or default), but how about additive? (Perhaps a better
term is inheritance...)

For example, with my little workstations-on-a-UPS example, the workstation
that is on the UPS will need the nut package added, but will otherwise be
identical to any other workstation (I would want the UPS-connected
workstation to inherit the same package list and configuration as the
other workstations).

Regards, Msquared...

_______________________________________________
et-mgmt-tools mailing list
et-mgmt-tools@redhat.com
https://www.redhat.com/mailman/listinfo/et-mgmt-tools
 
Old 04-08-2008, 03:13 PM
Michael DeHaan
 
Default Looping through possibilities in a "snippet"

Msquared wrote:

On Mon, Apr 07, 2008 at 12:13:46PM -0400, Michael DeHaan wrote:



Ideally one wouldn't be assigning specific packages to specific systems,
as the point of a profile is to make a configuration available to all
things that look "like" something. Can you explain your use case for
assigning specific packages to specific systems?



I can: I have two 'workstations' that run on power from a single UPS.
Only one of them, however, is actually connected to the UPS'
communications port - the other one talks via TCP/IP to the first to
determine UPS status.

All workstations have nut-client installed, but only the workstation
connected to the UPS' communications port has nut installed.

Granted, I could probably have a 'with-ups' profile based on the standard
workstation profile, but it hardly seems worth it to me. :-)

Actually, relevant question: If I have a 'workstation-with-ups' profile
based on a 'workstation' profile, and add packages to the 'workstation'
profile, will the packages also be automatically added to the
'workstation-with-ups' profile?

Currently it's all based on the kickstart template, so there's not
anything there that explicitly knows what a "package"

is.

If we do implement something like what we've been talking about, you
could possibly achieve that behavior with something like


%packages
SNIPPET:rofile_packages_list
SNIPPET::system_packages_list


And that would source files from
/var/lib/cobbler/snippets/profiles/profile_packages_list/$profile_name
/var/lib/cobbler/snippets/systems/system_packages_list/$system_name

It would also be looking in a few other directories, but as those files
would not exist, it would not find those.


Would that be workable? It seems cleaner than making Cobbler grok what a
"package" is, and also tends to work better
when supporting non-kickstart distros (as they could still then utilize
the expanded template system in a generic way).


(It's also technically possible to have the kickstart detect that the
kickstart template describes a system and put in some logic into the
template

to add "nut" for certain systems... so there are lots of ways to do it)

--Michael





_______________________________________________
et-mgmt-tools mailing list
et-mgmt-tools@redhat.com
https://www.redhat.com/mailman/listinfo/et-mgmt-tools
 
Old 04-08-2008, 04:11 PM
"Sandor W. Sklar"
 
Default Looping through possibilities in a "snippet"

On Apr 7, 2008, at 11:06 AM, Michael DeHaan wrote:


What if we changed the semantics of...

SNIPPET::foosball

which would now be smart and would pull one of the following,
whichever exists first:


/var/lib/cobbler/snippets/system/foosball/$system_name
/var/lib/cobbler/snippets/profile/foosball/$profile_name
/var/lib/cobbler/snippets/distro/foosball/$distro_name
/var/lib/cobbler/snippets/foosball

whichever was found first.

I think this is what you're getting at and could be done fairly
cleanly without being package specific.


Of course the stock install would lay down none of these paths
except the directories and this would largely be just documented

if you decide to use it (on the Wiki).


I think that would be perfect! Thanks!

-s-


_______________________________________________
et-mgmt-tools mailing list
et-mgmt-tools@redhat.com
https://www.redhat.com/mailman/listinfo/et-mgmt-tools
 
Old 04-11-2008, 08:05 PM
Michael DeHaan
 
Default Looping through possibilities in a "snippet"

What if we changed the semantics of...

SNIPPET::foosball

which would now be smart and would pull one of the following,
whichever exists first:


/var/lib/cobbler/snippets/system/foosball/$system_name
/var/lib/cobbler/snippets/profile/foosball/$profile_name
/var/lib/cobbler/snippets/distro/foosball/$distro_name
/var/lib/cobbler/snippets/foosball

whichever was found first.

I think this is what you're getting at and could be done fairly
cleanly without being package specific.


Of course the stock install would lay down none of these paths except
the directories and this would largely be just documented

if you decide to use it (on the Wiki).


I think that would be perfect! Thanks!

-s-


I've implemented this here -- with only a slight change to the way the
above behavior works (basically there are no distro-overrides

and the paths are slightly different):

https://fedorahosted.org/cobbler/wiki/KickstartSnippets

It's under the "Advanced Snippets" section and is available now in the
git/devel branch. Testing welcome!


--Michael


_______________________________________________
et-mgmt-tools mailing list
et-mgmt-tools@redhat.com
https://www.redhat.com/mailman/listinfo/et-mgmt-tools
 

Thread Tools




All times are GMT. The time now is 02:06 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org