Your cluster sounds more like an HPC cluster than an OLTP one like mine, but I think the setup I'm using would work for you too. I call it the "mpdehaan trifecta" because thats the ircnick of the guy who wrote or manages the three tools involved.
1.) Cobbler for base-build provisioning. Cobbler is a project that aims to be the intersection of your kickstart, pxe, yum-repo, dhcp, dns, etc systems. Its by far the easiest way to get a kickstart setup up and running, and you can grow into the other features as needed.
2.) Puppet for configuration management. Ideally your cobbler built hosts are very barebones configs that know just enough to phone home to your puppet server on startup. Puppet will then apply your configuration settings and keep them consistent across your environment in perpetuity.
3.) Func for ad-hoc commands to multiple machines in parallel. For instance "deploy a new svn checkout of the code and restart apache". Its pretty easy to just use func to call the same bash command on a group of servers much like cluster-ssh. If you really want to get into it you can write your own modules for it with some really simple python.
All three of these tools have good wiki's and active irc channels for help on freenode.
Part of the answer is that the behavior of the authconfig
command changed between RHEL5 and RHEL6. In RHEL6, instead of reading /etc/sysconfig/authconfig
and then generating the configuration, authconfig
in RHEL6 appears to parse each individual configuration file that it manages, and then generates /etc/sysconfig/authconfig
as a record of the current state.
This means that one has to edit configuration files directly if one is either (a) trying to avoid running the authconfig
command, or (b) trying to take advantage of features that aren't supported on the authconfig
command line.
This is what I ended up with to enabled the passwdqc
PAM module:
augeas { 'pam_passwdqc':
context => '/files/etc/pam.d/system-auth-ac/',
changes => [
'rm *[module="pam_cracklib.so"]',
'ins 9999 before *[type="password"][module="pam_unix.so"]',
'set 9999/type password',
'set 9999/control requisite',
'set 9999/module pam_passwdqc.so',
'set 9999/argument enforce=everyone',
],
onlyif => 'match *[module="pam_passwdqc.so"] size == 0',
notify => Exec['authconfig-update-all'],
}
exec { 'authconfig-update-all':
command => '/usr/sbin/authconfig --updateall',
refreshonly => true,
}
If you find yourself reading this answer, I'd love to hear your comments on whether or not this is sane way of handling things. I'm new to Puppet so I'm still feeling my way around the way things work.
Best Answer
Here's what I'm doing with Red Hat Enterprise (RHEL).
RHEL has an
iptables
service that loads rules from/etc/sysconfig/iptables
and I'm working with modifying that file and restarting the iptables service. Many people like to drop fragments into an iptables.d directory and build an iptables (via make or something like that) ruleset from that. I include stuff for rebuilding the default ruleset, but that usually never does anything. If your needs are simple you could just copy an iptables file to the system.Despite how ugly this seems, it's quite thoroughly tested on RHEL4, RHEL5 and RHEL6.
I had this going before augeas support was in puppet. If I was writing it again today I'd look at the augeas iptables lens before resorting to
exec { "perl ...": }
.Some global defines for editing files in place
Based on stuff originally from http://reductivelabs.com/trac/puppet/wiki/SimpleTextRecipes
My iptables class:
Some examples of usage in other classes: