Junior Sock Puppet wrote:
> Based on their membership in the classes, the clients copy down trees
> of files from the cfengine master to the clientnode.
> -----
> copy:
> ${master_cfinput} server=${policyhost}
> dest=${cfdir}/inputs recurse=inf
> mode=700 type=binary trustkey=true encrypt=true
>
> # Global files for RHEL4_DMZ
> RHEL4_ACF::
> /var/cfengine/masterfiles/redhat_ws_4-DMZ/ server=${policyhost}
> dest=/
> exclude=*~ recurse=inf encrypt=true trustkey=true
> backup=true
>
> # Global files for RHEL5_THATORG
> RHEL4_THISORG::
> /var/cfengine/masterfiles/redhat_ws_5-THATORG/ server=$
> {policyhost} dest=/
> exclude=*~ recurse=inf encrypt=true trustkey=true backup=true
Two ideas, one is conceptually closer to your cfengine setup, the other
will require some mental rearrangement, but will probably work out
cleaner in the long run:
1) A file's source parameter can be an array: each value in the array
will be checked, and the first one found will be used as the actual
source. Example, I have sshd_config files for two different operating
systems, but I have a special copy of that file for one particular host.
I also have a generic sshd_config that's a fallback of last resort:
source => [
"puppet:///openssh/sshd_config.$fqdn",
"puppet:///openssh/sshd_config.$operatingsystem",
"puppet:///openssh/sshd_config"
],
The special host gets its special sshd_config, each operating system
gets a separate config, and there's a fallback in case I bring a new OS
online. I could also get rid of the fallback, and if there's a new OS,
its sshd_config won't get overwritten when I put it in puppet.
2) How much redundant content (or symlinks to original files) are in
your masterfiles tree? Does everyone (or some large subset defined by
some rule or another) in the DMZ get the same resolv.conf file,
regardless of whether they're RH4, RH5, etc? Does every RH4 system get
the same bashrc, regardless of network location?
If that's the case, then you may want to break things up into separate
modules for each configured component, rather than making one massive
file copy. And a few things may be best configured on a per-OS basis,
but you'll find that lots of your configurations can be generalized to
multiple OSes without much trouble.
For example, RH4 and RH5 may get the same sudo configuration: "install
the sudo package, bring down my sudoers file, set its permissions". So
in that case, you'd make a sudo module with its own small tree of
manifests, files, and possibly templates that does all that. That
module's sudo class would get included in a node definition, or in a
'redhat' class defined elsewhere (that gets included in a node definition).
You can also use inheritance to make changes to defined classes -- I
normally use them to add items not defined in parent classes, that need
to be set on a child-by-child basis. Example, I have a cluster-host
class that contains general settings for all my compute nodes. Different
groups of hosts in the cluster need consistent settings among
themselves, but different than other hosts in the cluster:
class sc1435-host inherits cluster-host {
include lsopt
include gaussian
include autodocksuite
include ipmitool
ganglia::config{
"sc1435":
cluster => "CAE Compute Nodes",
mcast_ip => "239.2.11.73";
}
package {
[ "mcelog", "libwxgtk2.6-dev", "libglu1-mesa-dev", "wx-common",
"automake", "mesa-common-dev" ]: ensure => latest
}
}
Some hosts need a different availability schedule, since they're
normally Windows labs:
class dual-boot-cluster-host inherits cluster-host {
include autodocksuite
# A dual-boot cluster host needs:
# - cron jobs to reboot it before classes or open lab hours start
cron { sunday-reboot:
command => "/sbin/shutdown -t10 -r now",
ensure => present,
user => root,
minute => 30,
hour => 13,
weekday => 0,
}
cron { weekday-reboot:
command => "/sbin/shutdown -t10 -r now",
ensure => present,
user => root,
minute => 30,
hour => 7,
weekday => [ 1, 2, 3, 4, 5 ],
}
file { "/etc/network/interfaces":
source => "puppet:///debian/interfaces";
}
}
--
Mike Renfro / R&D Engineer, Center for Manufacturing Research,
931 372-3601 / Tennessee Technological University -- ren...@tntech.edu
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---
