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.
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.
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.
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.
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".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.
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
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/exit\s0/\n/' -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/umask\s+0\d2/umask 077/g' -i /etc/bashrc
perl -npe 's/umask\s+0\d2/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@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
