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@xxxxxxxxxx> wrote:
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 templateAaron 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
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@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/et-mgmt-tools
_______________________________________________ et-mgmt-tools mailing list et-mgmt-tools@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/et-mgmt-tools
