[et-mgmt-tools] "Snippet Groups"

Sandor W. Sklar ssklar at stanford.edu
Wed Apr 9 15:27:34 UTC 2008


On Apr 9, 2008, at 12:05 AM, Aaron Lippold wrote:
>
<... snip ...>

> Snipts and Groups
>
> An organization as sets of requirements - usually security or  
> enterprise wide setting, files, etc. - that it uses to standardize  
> the configuration management of its systems. These sets are usually  
> organized by whatever organizational system they come up with but  
> for the most part they are standard actions from the good old  
> community best practices. ( set bootloader passwords, use sudo,  
> install logging and setup, fixes known configuration issues with  
> sendmail, copy over the standard MOTD, Company Banner etc. )

These things really sound like you would want a configuration  
management tool (puppet, cfengine, etc.) to set those things after the  
kickstart is complete.

What happens if you change the wording in your standard MOTD?  Do your  
re-kickstart and install all of your systems so they get the new MOTD?

<... snip ...>

>
> Although it looks like from the other thread that this is going the  
> directory way, again, is this a mistake given that I don't really  
> want do some things until the end and some right at the beginning or  
> I really do want x to follow y to follow z. If we do it all by  
> directory I would have to name all my snipits 1_... 2_... which  
> would really make things not so elegant.
>
>
> snipit_groups/group1
>
> set_bootloader_password
> set_password_retries
> set_passwd_min_uppper
> set_passwd_min_lower
> set_motd
> setup_aide
> setup_logrotate
>
> This way I can call either a set of actions or a single one in the  
> cobbler kickstart template.
>
> ==== Kickstart Template ====
>
> SNIPIT::_GROUP_
> SNIPIT::small_thing
> SNIPIT::smaller_thing

I'm confused as to why you are assuming that files in a directory  
would have to be in alphabetical order.

With the changes that have been proposed, using this example below,  
lets say "group1" is the name of a Cobbler profile that you are  
using.  In your common /etc/cobbler/common.ks, you'd have something  
like:

%post
SNIPPET::post

If you have the file: /var/lib/cobbler/snippets/group1/post, it could  
contain:

SNIPPET::set_bootloader_password
SNIPPET::set_password_retries
SNIPPET::set_passwd_min_uppper
SNIPPET::set_passwd_min_lower
SNIPPET::set_motd
SNIPPET::setup_aide
SNIPPET::setup_logrotate

... and each of those separate snippet files would be included in the  
rendered kickstart.

<... snip ...>

>
> I know I threw a lot out there but I think there are a few pages we  
> could take from the Bastille and SST books that would really take  
> cobbler to the next level. Most of the changes would be business,  
> organization and execution process which I think could really expand  
> the flexibility of the system.
>
> Let me know what you all think or just slap me around a bit ...

No desire to "slap you around" :-)  but I think your arguments against  
the proposed hierarchy are orthogonal to your proposals; neither  
really impacts the other. And I'm not sure (again, just my opinion)  
that a build system is the best place to do the configuration  
management.  After all, configurations do change, and I prefer not to  
rebuild my systems every time I need to add a user account or update  
the MOTD.

	-s-




More information about the et-mgmt-tools mailing list