On Wed, Apr 9, 2008 at 12:08 PM, Michael DeHaan <[EMAIL PROTECTED]> 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_passwd_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/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 > [email protected] > https://www.redhat.com/mailman/listinfo/et-mgmt-tools >
_______________________________________________ et-mgmt-tools mailing list [email protected] https://www.redhat.com/mailman/listinfo/et-mgmt-tools
