Mike Renfro

I had posted earlier about distributing stowed packages via rsync and puppet to my managed systems, but that method wasn’t quite what I wanted:

1. There was one more file to manage outside my regular puppet manifests, and I’d have to remember to keep them both up to date and in sync.
2. There wasn’t an easy way of ensuring that other versions of a particular package got unstowed before deploying out the desired version.
3. The entire stow tree would be copied out to every system, regardless of whether OpenMPI was a good fit for the web server.

So, here’s my new method:

1. Keep my same metastow module loaded on the rsync server. The metastow module contains one top-level directory per puppet architecture (i686, x86_64, etc.). Each of those architecture folders is a stow tree containing every stowed package for that architecture.
2. Add a stowedpackage definition to my puppet manifests as follows:

   define stowedpackage ( $basepackage, $version,
       $rsyncserver='gold.cae.tntech.edu',
       $rsyncmodule='metastow',
       $stowdestdir='/usr/local/stow' ) {
       file { "stow-initiator_${basepackage}-${version}":
           source => "puppet:///files/stow-initiator_${basepackage}-${version}",
           path   => "/etc/puppet/stow-initiator_${basepackage}-${version}",
       }
       exec { download:
           command     => "/usr/bin/rsync -a --delete ${rsyncserver}::${rsyncmodule}/${hardwaremodel}/${basepackage}-${version} ${stowdestdir}",
           refreshonly => true,
           subscribe   => File["stow-initiator_${basepackage}-${version}"],
           alias       => "download_${basepackage}-${version}"
       }
       exec { unstow-others:
           command     => "cd ${stowdestdir} && stow --delete ${basepackage}-*",
           refreshonly => true,
           subscribe   => Exec["download_${basepackage}-${version}"],
           alias       => "unstow-others_${basepackage}-${version}"
       }
       exec { stow:
           command     => "cd ${stowdestdir} ; stow ${basepackage}-${version}",
           refreshonly => true,
           subscribe   => Exec["unstow-others_${basepackage}-${version}"]
       }
   }
   

3. Use the stowedpackage definition in other parts of my manifests:

   # Create OpenMPI installation and configuration.
   class openmpi {
   
       stowedpackage {
           "openmpi-1.0.1":
               basepackage=>"openmpi",
               version=>"1.0.1";
       }
   
   }
   

4. Add a trigger file to the puppetmaster’s /etc/puppet/files folder:

   /etc/puppet/files# date > stow-initiator_openmpi-1.0.1
   

Back at the infrastructures.org mothership, client configuration management is described as everything that makes a host unique and/or part of a particular group or domain. And for Unix-like systems, everything pretty much comes down to configuration files, services being enabled/disabled, and cron jobs.

Hmm.

• Configuration files
• Services
• Cron jobs

Looks like Puppet pretty much handles all of that. As long as I can describe aspects of my systems with puppet classes and modules, I’ve got reusable, consistent configurations on any servers I care to manage.

Back when the infrastructures.org folks were writing their pages, the page for file replication servers described a need to keep current copies of configuration files in /etc and all programs and other data from /usr/local on all the managed systems. In puppet structures, every file or other resource is just a part of a higher-order class or module. If we’re already keeping our classes and modules up to date on all the managed systems, then old-school file replication goes along automatically.