Puppet users - Apr 2009 - cfengine class to puppet facts, then copy files

I am probably confused on some of the cfengine vs puppet terminology.
Please excuse any bastardization of puppet terms and please correct me
if I am wrong.

I have cfengine working on different sets of machines and I am looking
at puppet at becoming a cfengine replacement.

In configuring & testing puppet, I have made it as far as enforcing
permissions on 1 file (/etc/sudoers) and copying down 1 file (/files/
etc/ntp.conf to /etc/ntp.conf).

I would now like to explore the ability to copy down files based on
the node''s facts, specifically the ''operatingsystem'',
''operatingsystemrelease'', and ''domain'' facts

For example, in our cfagent.conf file, we make user-defined classes of
machines by boolean AND/OR them together
------
RHEL4_DMZ = ( redhat_ws_4&192_168_142 )
RHEL5_THATORG = ( redhat_ws_5&subdomain_example_com )
------

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
-----
I can''t quite wrap my mind around how this is done in puppet? Do I
have to add my own user-created fact to facter?
Or is this done with if-statements and boolean operators?
-----
if ( $operatingsystem == "RedHat" ) and ( $operatingsystemrelease
="5" ) and ( $domain == "subdomain.example.com" ) {
          include copydown
}

OR
if ( $operatingsystem == "RedHat" ) and ( $operatingsystemrelease
="4" ) and ( $network_eth0 == "192.168.142.0" ) {
          include copydown
}
-----

If those ''if-statements'' are correct, then how would the file
copy-
down portion be written?

Thanks in advance,
Jr Sock Puppet

--~--~---------~--~----~------------~-------~--~----~
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+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---

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 -- renfro@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+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---