[et-mgmt-tools] Looping through possibilities in a "snippet"

[Sandor W. Sklar]

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 
 >