[et-mgmt-tools] "Snippet Groups"

Wed Apr 9 07:05:35 UTC 2008

Hi,

If I am a little punchy here, don't mind me, just way too tired....

Sorry it took so long to get to responding really buys few days...

What I am looking for is some additional levels to the profile templates
which allow me to seperate out the code form the profile/template. It is
close to some of the semantics that the Solaris Security Toolkit uses to
break up how it does it system provisioning. It has a concept of Drivers -
much like the cobber kickstart templates which define env settings, runtime
vars, and which Finish scripts- the Finish scripts that do particular
actions but rather than being a long bash script they are broken into
smaller single chunks that can ge used across profiles and profile groups so
that code is centralized. ( ks or bash or perl etc. ) This is where I
started thinking about 'snipits' and 'groups of snipits'. This is also along
the lines of Bastille breakdown as well. The basic problem is what I explain
as "separation of implementation from interface" now this isn't totally
accurate but I think for coders it gets the idea across. My ks templates
shouldn't - i.e. technically cobbler cheetah profiles - hold real code just
references to code that it will render in the final ks.cfg. Now a lot of we
old end users just ignore this fact and put in #raw at the top of post and
go our marry way. But I think stressing this separation could really expand
the use cobber has in the overall system deployment and upkeep of those
systems.

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. ) For my organization we have a whole set of "System Level"
requiremetns, "Webserver", "Database" etc. and I can create a mapping easly
from these requirements to snipits that take care of them.

SNIPIT::set_bootloader_password
SNIPIT::set_sshd_login_banner
SNIPIT::disable_sendmail
SNIPIT::setup_aide

etc.

Even better, if my sniptits take parameters, usually the "lock down and
configuration" difference are only 644 vs 640 perms or what my password
complexity requirments are for pam login or what the defualt file upload
size for apache should be, etc. These "actions" aren't different - just what
we put for the params of the action.

Anther advantage is that some of these actions are different from distro to
distro - just look at RHEL, Fedora and SuSE. The idea or spirit is the same
but the implementation is different.

=== Grouping ====

These sniptits could then be group at a level above - since thier time of
execution could matter - into a file simply...

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

Another thing I find useful in this type of setup is that I can also make a
mapping file :

REG1:set_passwd_retries,set_passwd_min_upper,set_passwd_min_lower
REG2:setup_aide
REG3:set_motd

which I can then use a little awk to parse and stick in logging of the
actions that were taken on a system during a provisioning ( like we do with
a ( set of actions... ) > mylog.txt in the %post most of the time.

As an added benefit, if I also have a set of audit scripts that check for
lockdown or settings that are out of wack and produces a list of those
broken requirements ( REG1, REG23, REG45, REG655 are not set correctly ) its
easy for me to make a quick script to run the set of sniptis that cover
those items by parsing the mapping file. This could even be automated after
a system update so that when I do update a package I run my "audit" scripts,
parse the report, if the updates unset any of the things I set, will
generate a quick script, include all the needed snippets and run them. Then
run the "audit" again to verify that the system is back the way it was the
day I provisioned it. To finish it all off, I could generate a nice report
going "good" to "broken" to "fixed" to "good".

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 ...

Yours,

Aaron

On Mon, Apr 7, 2008 at 11:08 AM, Michael DeHaan <mdehaan at redhat.com> wrote:

> Aaron Lippold wrote:
>
> > Hi All,
> >
> > I did some chatting on the irc on this but wanted to post it to the list
> > to get some feedback.
> >
> > I have some KS files already which setup and secure my systems to my
> > organizations standards. I'd like to break up and generlize my processes and
> > "scripts" - mainly in the post section - into smaller chunks to make it more
> > flexible and manageable. I know I can do includes, snippets and triggers.
> > The idea would be that I could have a "Core Set" of items that I could
> > include into my ks template - OS::Lockdown - which would include / call a
> > known set of actions. I could then develop other "sets" - MySQL, Apache,
> > Oracle, etc. I am hoping that I could also then use those separable pieces
> > after updates and patches to "reverify" the systems - assume I already have
> > a set of scripts that I can run that will give me a list ( Item1, Item2,
> > Item3) which require an action. With a little scripting and a "map" - flat
> > txt with "Item1:OS::Boot::Action: - I could run each item that needs to be
> > fixed again.
> >
> > I think this would be valueable because it would give the end user the
> > ablity to divorce "interface from implamentation" as it were. It would allow
> > you to use cobbler to also assist with maintaining the baseline etc.
> >
> > The question is which path to take. Thoughts, suggestions, "idiot,  you
> > can do that like this" would be appriciated :).
> >
> > Thanks,
> >
> > Aaron
> >
>
> I'm not sure I understand what this would look like.    Could you possibly
> throw out some syntax of what that might look like in the template
> file and how the files might be layed out behind the scenes?
>
> Right now snippets work as includes ... in fact, it's conceptually "just"
> a Cheetah (Cobbler's templating language) include at this point.
>
> SNIPPET::foo  just includes "/var/lib/cobbler/snippets/foo any time it is
> present in the file.
>
> Can you explain further?
> --Michael
>
> _______________________________________________
> et-mgmt-tools mailing list
> et-mgmt-tools at redhat.com
> https://www.redhat.com/mailman/listinfo/et-mgmt-tools
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/et-mgmt-tools/attachments/20080409/c5db694b/attachment.htm>