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


 
 
LinkBack Thread Tools
 
Old 04-06-2008, 06:35 PM
"Aaron Lippold"
 
Default "Snippet Groups"

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


_______________________________________________
et-mgmt-tools mailing list
et-mgmt-tools@redhat.com
https://www.redhat.com/mailman/listinfo/et-mgmt-tools
 
Old 04-07-2008, 03:08 PM
Michael DeHaan
 
Default "Snippet Groups"

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@redhat.com
https://www.redhat.com/mailman/listinfo/et-mgmt-tools
 
Old 04-09-2008, 07:05 AM
"Aaron Lippold"
 
Default "Snippet Groups"

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_p asswd_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@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@redhat.com

https://www.redhat.com/mailman/listinfo/et-mgmt-tools



_______________________________________________
et-mgmt-tools mailing list
et-mgmt-tools@redhat.com
https://www.redhat.com/mailman/listinfo/et-mgmt-tools
 
Old 04-09-2008, 03:27 PM
"Sandor W. Sklar"
 
Default "Snippet Groups"

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:ost

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-

_______________________________________________
et-mgmt-tools mailing list
et-mgmt-tools@redhat.com
https://www.redhat.com/mailman/listinfo/et-mgmt-tools
 
Old 04-09-2008, 03:52 PM
Michael DeHaan
 
Default "Snippet Groups"

Sandor W. Sklar wrote:


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.


Depends. If you are installing a system for use in a disconnected
environment the install needs to be correct by the time the install is
done. You /can/ run the configuration management tool locally and remove
the tool when you are done, however. That's still a possibility
depending on requirements.



_______________________________________________
et-mgmt-tools mailing list
et-mgmt-tools@redhat.com
https://www.redhat.com/mailman/listinfo/et-mgmt-tools
 
Old 04-09-2008, 04:08 PM
Michael DeHaan
 
Default "Snippet Groups"

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.


Minor correction --- Snippets can already take parameters. The built
in cobbler variables are already passed to them. In addition, others
can also be passed along IIRC -- the cheetah syntax for this is "#set
global foo" in the master template (see http://cheetahtemplate.org/) and
then variables set there can be passed to templates.





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.


I'm not sure that directory system was proposed. What /was/ proposed
was a way to be able to indicate templates for systems in a way that
they could be overriden.


So, if you had a snippet named "driveconfig", it would first look for:
/var/lib/cobbler/snippets/driveconfig/system/$system_name if it exists

And would use that snippet if it existed, if not, failing back to:
/var/lib/cobbler/snippets/driveconfig/profile/$profile_name if it exists

And using it unless it didn't exist and failing back to:
/var/lib/cobbler/snippets/driveconfig

This would allow using the same "webserver" template for 500 servers,
and still allowing for the 1 server that for some reason required a
special exemption to get the configuration it needed, without having to
create a new profile for "webserver-this-one-is-special".




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_p asswd_min_lower
REG2:setup_aide
REG3:set_motd



This is getting into config management territory. Have you looked at
running a config management tool locally in post to execute some sort of
policy? Or are there reasons for not doing this? I know there are ways
to execute puppet without requiring a server, and it is probably easier
to express those sort of requirements there as opposed to in Anaconda
scripts with bash/sed/awk.


--Michael

_______________________________________________
et-mgmt-tools mailing list
et-mgmt-tools@redhat.com
https://www.redhat.com/mailman/listinfo/et-mgmt-tools
 
Old 04-12-2008, 04:56 PM
"Aaron Lippold"
 
Default "Snippet Groups"

On Wed, Apr 9, 2008 at 12:08 PM, Michael DeHaan <mdehaan@redhat.com> wrote:






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.





Minor correction --- Snippets can already take parameters. * *The built in cobbler variables are already passed to them. *In addition, others can also be passed along IIRC -- the cheetah syntax for this is "#set global foo" in the master template (see http://cheetahtemplate.org/) and then variables set there can be passed to templates.









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.





I'm not sure that directory system was proposed. *What /was/ proposed was a way to be able to indicate templates for systems in a way that they could be overriden.



So, if you had a snippet named "driveconfig", it would first look for:

/var/lib/cobbler/snippets/driveconfig/system/$system_name if it exists



And would use that snippet if it existed, if not, failing back to:

/var/lib/cobbler/snippets/driveconfig/profile/$profile_name if it exists



And using it unless it didn't exist and failing back to:

/var/lib/cobbler/snippets/driveconfig



This would allow using the same "webserver" template for 500 servers, and still allowing for the 1 server that for some reason required a special exemption to get the configuration it needed, without having to create a new profile for "webserver-this-one-is-special".







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_p asswd_min_lower

REG2:setup_aide

REG3:set_motd






This is getting into config management territory. * *Have you looked at running a config management tool locally in post to execute some sort of policy? *Or are there reasons for not doing this? *I know there are ways to execute puppet without requiring a server, and it is probably easier to express those sort of requirements there as opposed to in Anaconda scripts with bash/sed/awk.

I did look at using puppet and talked to someone about CFEngine. Both say they can run with our without a server.

Your right though I would need to basically assume that this will be in a disconnected environment but I would like to look at trying to make that not the case.


So what I was hoping to get at was that I could break all these little actions into smaller pieces then call a group of them as a set. That's were my idea of snippets and triggers came from.

Here are some examples of my post actions.


# GEN000420 (G011)
# This part creates the same login banner once your username and password has been entered.* This has linefeeds in it.
# Text needs to be cleaned up a touch.
echo "Locking down GEN000420"

perl -npe 's/exits0/
/' -i /etc/X11/gdm/Init/Default

cat << 'EOF' >> /etc/X11/gdm/Init/Default
/usr/bin/gdialog --yesno "`cat /etc/issue`

Agree = 'OK'** Disagree = 'Cancel'"

if ( test 1 -eq $? ); then
*** /usr/sbin/gdm-safe-restart
fi

exit 0
EOF
echo "GEN000420 Completed"

# GEN000920 (G023)
echo "Locking down GEN000920"
# Correct the permissions on /root to a DISA allowed 700

chmod 700 /root
echo "GEN000920 Complete"

# GEN000980 (G026)
echo "GEN000980 Start"
# Direct root logins are only allowed via tty1
echo "tty1" > /etc/securetty
echo "GEN000980 Completed"


# GEN000960 (G025)
echo "Locking down GEN000960"
# If we're not running an POP/IMAP server, remove the user dovecot
rpm -q dovecot 2>&1 > /dev/null
if [ a$? = "a1" ]
then

*** userdel dovecot
else
*** echo "dovecot package installed, not deleting user dovecot"
fi

# If we're not running named, delete the user
rpm -q bind 2>&1 > /dev/null
if [ a$? = "a1" ]

then
******* userdel named
else
*** echo "bind package installed, not deleting user named"
fi
echo "GEN000960 Complete"

# GEN001480 (G053)
# Correct the Red Hat supplied modes on these directories

echo "Locking down GEN001480"
chmod 750 /var/crash /var/www/usage /usr/libexec/dovecot
echo "GEN001480 Complete"

# GEN001569
# Change all user files to mode 740
echo "Locking down GEN001569"

find /home -name '.*' -type f -exec chmod -R 740 {} ;
find /root -name '.*' -type f -exec chmod -R 740 {} ;
echo "GEN001569 Complete"

# GEN002260 (G076)
echo "Locking down GEN0002260"

# check local device files against baseline
# as a note, it may be sufficient to do a rpm --verify on the associated
# block device packabes (devfs?)
find /dev -type b -or -type c -or -type s >> /root/blockdevices

echo "GEN002260 Complete"

# GEN002560
# Reset the umasks for all users to 077
echo "Locking down GEN002560"
perl -npe 's/umasks+0d2/umask 077/g' -i /etc/bashrc
perl -npe 's/umasks+0d2/umask 077/g' -i /etc/csh.cshrc

echo "GEN002560 Complete"

# GEN002720 ~ GEN002840
# This will require refinement.* Commented rules do not insert w/o an error
echo "Locking down audit system (GEN002720 ~ GEN002840)"
cat << 'EOF' > /etc/audit/audit.rules

## Submitted by JasonM at FSO.

# This file contains the auditctl rules that are loaded
# whenever the audit daemon is started via the initscripts.
# The rules are simply the parameters that would be passed

# to auditctl.

# First rule - delete all
-D

# Feel free to add below this line. See auditctl man page

# Increase the buffers to survive stress events
-b 256
-e 1
# Audit Failed opens
-a exit,always -S open -F success!=0

#
# Audit success and failure of delete
-a exit,always -S unlink -S rmdir
#
# Audit success and failure of admin actions
#-a task,always -F uid=0
-w /var/log/audit/ -k ADMIN
-w /etc/auditd.conf -k ADMIN

-w /etc/audit.rules -k ADMIN
-a exit,always -S stime -S acct -S reboot -S swapon -S settimeofday -S setrlimit
-a exit,always -S setdomainname -S sched_setparam -S sched_setscheduler
EOF
echo "GEN002720 ~ GEN002840 Complete (Please review for your own audit needs)"


# GEN002860 (G674)
# Rotate the audit-logs on a daily basis; keep them all
echo "Locking down GEN002860"
cat << 'EOF' > /etc/logrotate.d/audit
/var/log/audit/audit.log {
*** daily

*** notifempty
*** missingok
*** postrotate
******* /sbin/service auditd restart 2> /dev/null > /dev/null || true
*** endscript
}
EOF
echo "GEN002860 Complete"

# GEN002660 (G093)

# SRR does not check to see that auditing is actually running.
echo "Locking down GEN002600"
chkconfig auditd on
echo "GEN002660 Complete"

# GEN002680 (G094)
# reset permissions on audit logs

echo "Locking down GEN002680"
chmod 700 /var/log/audit
chmod -R 600 /var/log/audit/*
echo "GEN002680 Complete"

# GEN003600
echo "Locking down GEN003600"
echo "net.ipv4.tcp_max_syn_backlog = 1280" >> /etc/sysctl.conf

echo "net.ipv4.icmp_echo_ignore_broadcasts = 1" >> /etc/sysctl.conf
echo "GEN003600 Complete"

# LNX00520 (L208)
echo "Locking down LNX00520"
chmod 600 /etc/sysctl.conf

echo "LNX00520 Complete"

# LNX00580 (L222)
echo "Locking down LNX00580"
perl -npe 's/ca::ctrlaltdel:/sbin/shutdown/#ca::ctrlaltdel:/sbin/shutdown/' -i /etc/inittab
echo "LNX00580 Complete"


# G618 (removed)
echo "G618 removed..."
find /dev -name "*ty*" -exec chmod 700 {} ;

# GEN004640 (V126)
echo "Locking down GEN004640"
perl -npe 's/^decode/#decode/' -i /etc/aliases

newaliases
echo "GEN004640 Complete"

My thinking was to break them up into snippets then for the once I could, define variables to make them more useful.

What I liked about this was that I could then use the snippets in other places. But perhaps puppet is a good choice or something like it. Although one of the selling points I do want to try to keep is that we are using base technology. I am hoping to keep my provisioning and upkeep system as simple as possible.



--Michael



_______________________________________________

et-mgmt-tools mailing list

et-mgmt-tools@redhat.com

https://www.redhat.com/mailman/listinfo/et-mgmt-tools



_______________________________________________
et-mgmt-tools mailing list
et-mgmt-tools@redhat.com
https://www.redhat.com/mailman/listinfo/et-mgmt-tools
 
Old 04-14-2008, 02:52 PM
Michael DeHaan
 
Default "Snippet Groups"

Aaron Lippold wrote:



My thinking was to break them up into snippets then for the once I
could, define variables to make them more useful.


What I liked about this was that I could then use the snippets in
other places. But perhaps puppet is a good choice or something like
it. Although one of the selling points I do want to try to keep is
that we are using base technology. I am hoping to keep my provisioning
and upkeep system as simple as possible.


Sure. The above snippet system should work fine for what you want to
do. Essentially the snippet insertion is done /before/ running things
through Cheetah, so when given to Cheetah the templates look as if they
were all part of one big file all along ... so if you do "#set foo =
'bar'" in one snippet (or in the master template), it's valid later on
down the line.


Presently you cannot have one snippet include other snippets through the
Cobbler facility, though you can use Cheetah's built-in include if you
need that. Cheetah includes require the usage of "#set global" for
passing variables between includes.


--Michael



--Michael

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


------------------------------------------------------------------------

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


_______________________________________________
et-mgmt-tools mailing list
et-mgmt-tools@redhat.com
https://www.redhat.com/mailman/listinfo/et-mgmt-tools
 
Old 04-15-2008, 04:59 PM
"Aaron Lippold"
 
Default "Snippet Groups"

Hello All,

Thanks for the good feedback. It was good to have a new way to think about. So has the group talked about the line between provisioning and CM? I haven't found much online about when the business process moves from the provisioning architecture to the cm architecture. It might be a good thing to throw out to the list.


This way we can at least have some basic structure so that, like my requests, we can evaluate which bucket they fall into.

Yours,

Aaron

On Mon, Apr 14, 2008 at 10:52 AM, Michael DeHaan <mdehaan@redhat.com> wrote:

Aaron Lippold wrote:






My thinking was to break them up into snippets then for the once I could, define variables to make them more useful.



What I liked about this was that I could then use the snippets in other places. But perhaps puppet is a good choice or something like it. Although one of the selling points I do want to try to keep is that we are using base technology. I am hoping to keep my provisioning and upkeep system as simple as possible.





Sure. * The above snippet system should work fine for what you want to do. * *Essentially the snippet insertion is done /before/ running things through Cheetah, so when given to Cheetah the templates look as if they were all part of one big file all along ... so if you do "#set foo = 'bar'" in one snippet (or in the master template), it's valid later on down the line.




Presently you cannot have one snippet include other snippets through the Cobbler facility, though you can use Cheetah's built-in include if you need that. * Cheetah includes require the usage of "#set global" for passing variables between includes.




--Michael






* *--Michael



* *_______________________________________________

* *et-mgmt-tools mailing list

* *et-mgmt-tools@redhat.com <mailto:et-mgmt-tools@redhat.com>

* *https://www.redhat.com/mailman/listinfo/et-mgmt-tools





------------------------------------------------------------------------



_______________________________________________

et-mgmt-tools mailing list

et-mgmt-tools@redhat.com

https://www.redhat.com/mailman/listinfo/et-mgmt-tools




_______________________________________________

et-mgmt-tools mailing list

et-mgmt-tools@redhat.com

https://www.redhat.com/mailman/listinfo/et-mgmt-tools



_______________________________________________
et-mgmt-tools mailing list
et-mgmt-tools@redhat.com
https://www.redhat.com/mailman/listinfo/et-mgmt-tools
 
Old 04-15-2008, 05:20 PM
Michael DeHaan
 
Default "Snippet Groups"

Aaron Lippold wrote:

Hello All,

Thanks for the good feedback. It was good to have a new way to think
about. So has the group talked about the line between provisioning and
CM? I haven't found much online about when the business process moves
from the provisioning architecture to the cm architecture. It might be
a good thing to throw out to the list.


Generally the idea is once you get to a certain level of complexity you
will want to use kickstart for setting up your disks, repos, initial
package lists, and bootstrapping your config management software, so
that you can stop having to express your entire configuration in
kickstart scripts or use less maintainable ways of pushing configuration
files out. Config management systems tend to describe the way systems
should "keep being", as opposed to actions that should just happen
once. For instance, "this package should be installed at that version
and this should be running".

As an example, see
https://fedorahosted.org/cobbler/wiki/UsingCobblerWithConfigManagementSystem,
which uses Cobbler's --ksmeta facility to indicate a mapping between a
Cobbler profile and Puppet classes. That probably works similarly in
other configuration management systems. Reviews and improvements to
that doc are welcome as it's been a while since I tried that, and things
may have changed with Puppet since. Contributions for how to integrate
Cobbler with other config management systems are welcome too. We can
probably do some work to make that easier in a future release if there
is a lot of interest in this, though one will never require the other.


In general, we don't want to explicitly link certain config management
tools with certain provisioning tools and vice versa, as part of the
power of smaller, lightweight tools is being able to swap things in and
out, and also being able to use one without the other when you are
starting out. Things are more flexible that way. All it really takes
to integrate them is a little magic in your kickstart file and a Cobbler
--ksmeta parameter.


This means that you can assign a webservers profile to a few config
management classes, and a specific server, if you want, to one more in
addition to what the profile is assigned to. (For instance, a server
could be a "webserver" profile but also be assigned to a class that
dealt with

something hardware/system specific).

--Michael





This way we can at least have some basic structure so that, like my
requests, we can evaluate which bucket they fall into.


There are no buckets, it's more of a large sandbox

--Michael




Yours,

Aaron

On Mon, Apr 14, 2008 at 10:52 AM, Michael DeHaan <mdehaan@redhat.com
<mailto:mdehaan@redhat.com>> wrote:


Aaron Lippold wrote:



My thinking was to break them up into snippets then for the
once I could, define variables to make them more useful.

What I liked about this was that I could then use the snippets
in other places. But perhaps puppet is a good choice or
something like it. Although one of the selling points I do
want to try to keep is that we are using base technology. I am
hoping to keep my provisioning and upkeep system as simple as
possible.


Sure. The above snippet system should work fine for what you
want to do. Essentially the snippet insertion is done /before/
running things through Cheetah, so when given to Cheetah the
templates look as if they were all part of one big file all along
... so if you do "#set foo = 'bar'" in one snippet (or in the
master template), it's valid later on down the line.

Presently you cannot have one snippet include other snippets
through the Cobbler facility, though you can use Cheetah's
built-in include if you need that. Cheetah includes require the
usage of "#set global" for passing variables between includes.

--Michael


--Michael

_______________________________________________
et-mgmt-tools mailing list
et-mgmt-tools@redhat.com <mailto:et-mgmt-tools@redhat.com>
<mailto:et-mgmt-tools@redhat.com
<mailto:et-mgmt-tools@redhat.com>>

https://www.redhat.com/mailman/listinfo/et-mgmt-tools


------------------------------------------------------------------------



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


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


------------------------------------------------------------------------

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


_______________________________________________
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 09:05 AM.

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